RE: key to yank text at point into minibuffer?

[Drew Adams]

    > Providing `M-.' lets you get the text at point even when the command's
    > default value is something else. You can think of it as an
    > extension to `M-n' in this respect.

    Then why not use `M-n' directly,

Because it often makes sense for a given command to use a default value that
is *not* the word/symbol/whatever at point - the command provides a value
that is (in principle) smarter, more specific to that command (DTRT). The
thing at point can sometimes be useful, but there is sometimes a better
default value, which might be totally unrelated to the buffer text.

There is no reason not to have both available: 1) an intelligent,
command-specific default value and 2) something at point (available always).

    with every successive `M-n' inserting the next symbol/URL/file
    name to the minibuffer?

Do you mean insert (so, accumulate) or replace what's in the minibuffer?
Your grep example below makes me think the former.

Successive `M-n' have the meaning now of traversing the history list. There
is no reason to confuse people by mapping an additional meaning onto
successive `M-n'. And there is no reason not to provide this orthogonal
feature (value) via a different key.

Also, assuming you mean to accumulate (not replace) successive words, there
are relatively few commands that expect/accept minibuffer input of multiple
words - `grep' is one such (provided you quote the string). For those
exceptional commands, users could simply select the words and then paste
them into the minibuffer.

This is a design choice - whether successive `M-.' (or `M-n', in your
suggestion) should accumulate text at point, as you suggest, or should
provide alternative kinds of thing at point, as I suggested. I can see
arguments for each approach.

I admitted, for instance, that 90% of the time I use simply the symbol at
point, and the other 9-10% of the time I use the word at point. One might
argue, then, that there is not much need for providing alternative
text-grabbing functions. I expect that such alternatives can be useful,
especially with buffer-local values specific to particular modes, but that's
just my intuition speaking.

My guess is that being able to grab successive words at point is less useful
than being able to grab different kinds of thing at point.

Note too that one could have a particular text-grabbing function that would
do just what you describe: it could, itself, let you grab successive words.
There are several ways it could do this. So, in this sense, your approach
could be a particular implementation of mine (just use a particular
text-grabbing function).

    I have a simple patch that does this for the grep prompt, but
    it was held due to the feature freeze.

    However, to implement a replacement for ffap,

To be clear about my proposal, anyway: I wasn't suggesting to get rid of
ffap. I meant only that (even independently of employing it as a poor-man's
ffap) using `M-.' to retrieve something at point would be useful. We can
forget about ffap in this discussion.

    it should be improved further to allow extending the list of
    default values with more user-defined values.
    I.e. instead of giving the list of default values as an
    argument of one of the minibuffer functions, there should be
    a new buffer-local variable with a user-defined function to
    get some text from the buffer and add it to
    the list of default values.

I don't follow you completely. Could you give an example of what you mean,
contrasting it with the behavior I described?

I think (but please clarify) that you're saying a few things: 1) Use a
single buffer-local function, not a list of functions, to retrieve the thing
at point; 2) Make the function buffer-local; 3) Add the retrieved thing to
the standard list of default values.

I spoke to #3 above: I'd prefer to keep the default-value list separate from
this text-grabbing feature. They are logically independent: one is decided
by the command; the other is decided by the text at point and the user.

Wrt #1: I'd prefer a list of different grab functions, as I said (with
successive `M-.' using successive functions), rather than a single function.

Wrt #2: Nothing would prevent a library or user from making the list of
functions buffer-local and giving it different values in particular buffers.

That is, I don't see the "further improvement" needed: Just have a variable
that is the list of grab functions. Users and programs can always make it
buffer-local and give it different values. (Yes, I know, there is a conflict
between having the variable be a user option and letting programs modify it,
but that can be resolved in different ways.)