RE: key to yank text at point into minibuffer?

[Drew Adams]

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

    I mean accumulating only on the first `M-.', and replacing the thing
    inserted to the minibuffer by the first `M-.' with other things on all
    successive `M-.'.  It would be useful to keep the initial minibuffer
    input intact, and to insert/replace things within the existing
    minibuffer input.

    I think `M-.' should not replace the existing minibuffer input,
    because I imagine such a situation when the user types e.g. `M-!', types
    a command and wants to *add* the thing at point to the end of the
command in
    the minibuffer.

The version I currently use replaces all minibuffer input, even the first
time. But I can see your point. It probably makes sense not to replace
minibuffer input on the first use of `M-.' It should only replace stuff that
it has previously inserted itself (immediately before).

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

    `M-.' requires more keystrokes than `M-n' only for the cases where
    a complex input string is constructed from things at point
    (like the grep case).  Thus `M-.'  requires from the user typing the
    input string, navigating to the correct place in it and typing `M-.'.

I don't see this. Whether the new behavior being discussed is bound to `M-n'
or `M-.', it has the same behavior, so the same number of keystrokes would
be required in each case. The only issue wrt the key binding is the
double-duty that you want `M-n' to perform: minibuffer history traversal and
text-grabbing at point. I want to put those two different behaviors on
different bindings.

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

Still no concrete example, BTW. Maybe you're right, but how can I tell
without a reason or an example of what you mean?

    I think a single key is not enough to unleash the full potential
    of `M-.'.  I expect that users might want additional keybindings
    to yank successive characters/words/lines to the minibuffer.

I think you're now making my argument - not the part about needing more key
bindings, but the part about the utility of having alternative text-grabbing
functions.

To be clear, here are my points, after adopting your proposal to not replace
initial input, and after thinking some more about the utility of
successively grabbing more of the same kind of thing (e.g. words) at point:

1. Use a separate key, not `M-n' (which is history traversal), for
text-grabbing. E.g. `M-.'.

2. Bind `M-.' to a list of two things: a) a list of alternative
text-grabbing functions - my approach and b) a single function that grabs
successive things (e.g. words) - your approach. Either component could be
nil, in which case that behavior would not be available. The default value
could be this:

  ((symbol-grabber word-grabber line-grabber URL-grabber) word-grabber).

If you never wanted my approach, you would use (nil word-grabber). If I
never wanted your approach, I would use ((symbol-grabber word-grabber
line-grabber URL-grabber) nil)

3. If both components are present, one of them is the default, to be
determined by a new user option.

Alternatively, the order of the components could determine which is the
default, but in that case you could not use a lambda list for the
single-function component (or else we we need to recognize lambda, quoted
lambda, function, #', etc).

4. When you use `M-.', you always get the default behavior, as determined by
the new option, unless you first use `C-u', in which case you get the
alternate behavior.

Example: I like the default behavior to cause successive `M-.' to grab
alternative things, so I set the option to choose this (i.e. to use the
first component). You like the default behavior to cause successive `M-.' to
grab successive things of the same kind (e.g. words), so you set the option
to choose that (i.e. to use the second component). Each of us is happy.

If at some point while inputting I want your preferred behavior, I use `C-u
M-.' in the minibuffer. From then on, as long as I keep doing `M-.', I get
your behavior of grabbing successive words.

If at some point while inputting you want my preferred behavior, you use
`C-u M-.'. From then on, as long as you keep using `M-.', you get my
behavior of grabbing different kinds of thing at point. Each of us is happy
to be able to get the alternate behavior for a one-off use.

5. `C-u' could be more sophisticated yet. If you use a numeric arg, not just
plain `C-u', then the numeric arg could specify the number of things to
grab, in the case of alternative types of things (first component of the
`M-.' list). The second component does let you grab multiple things, but
they are always of the same type (e.g. words). Using this, I could use `C-u
6 M-. M-.' to grab 6 of whatever kind of thing the second grabbing function
grabs.

For example, if I wanted to insert 6 lines, then I could use `C-u 6 M-. M-.
M-.'. Granted, for the default grabbing functions this might have limited
utility, but users might have special grabbers for which this could be
useful.