RE: key to yank text at point into minibuffer?

[Drew Adams]

    >     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?

    I mean to replace i.e. exactly how M-p works.

OK, me too.

    > 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'.

    There is no reason to limit the default value list only to one value.

That may be, but I think it's beside the point I was making: There would
still be two different things that `M-n' would be doing (promoting
confusion, IMO): 1) cycle among the values in your default-value list and 2)
what it does now: advance in the history list.

    > 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.

    These approaches are not conflicting.  You suggest `M-.' to accumulate
    text at point with replacing alternative kinds of thing at point.

Not sure what you mean by "accumulate...replacing". I suggested to _replace_
the minibuffer input successively by different alternative things at point.
There was no accumulation.

    And I suggest `M-n' to replace the minibuffer contents with default
    value pre-constructed from alternative kinds of thing at point.

Again, I'm not sure what you mean here. Previously you suggested that M-n
would replace (I wasn't sure whether it was accumulate or replace, but
you've confirmed replace) the minibuffer input with increasingly greater
numbers of words at point.

    So these approaches are rather complementary.

IIUYC, that's also what I said, mentioning that your suite of alternatives
(longer strings of words) could be implemented as one of the list of
alternative text-grabbing functions that I proposed.

    >     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.

    This is what I meant too: to leave ffap alone, and to develop a
    simpler way to do the same things as ffap.

Some of the same things, yes.

    >     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 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.

    Yes, exactly.

    > I spoke to #3 above: I'd prefer to keep the default-value
    > list separate from this text-grabbing feature.

    Yes, they are separate features.

    > They are logically independent: one is decided by the
    > command; the other is decided by the text at point and the user.

    They are not completely independent: often the text at point is what the
    user wants to have in a particular place inside the command in
    the minibuffer.

They are _logically_ independent. Some commands provide text at point as the
default value, so in those cases the two coincide. But in the general case
they don't.

I don't know what you mean by "in a particular place inside the command". If
you are talking about inserting the text at point in a particular place
within the existing input string, then I'm confused. I thought you were (as
I am) talking about the text at point _replacing_ the existing minibuffer
input, not being inserted into it.

    And `M-n' does this just fine.  OTOH, `M-.' does the same thing
    the other way with more keystrokes required from the user,

Sorry, I must not be following you at all. How is `M-.' more keystrokes than
`M-n'?

    and still is restricted in what the user might expect from this
    feature: to grab successive characters, words,
    maybe even lines to the minibuffer the same way as e.g. isearch
    does with C-w and C-y.

Sorry, I'm lost. I don't see the restriction you're suggesting. Perhaps a
concrete example would clear this up. I think I have not understood you.