[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: key to yank text at point into minibuffer?

From: Juri Linkov
Subject: Re: key to yank text at point into minibuffer?
Date: Sun, 19 Feb 2006 19:28:14 +0200
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)

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

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

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

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.

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

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

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

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.

Juri Linkov

reply via email to

[Prev in Thread] Current Thread [Next in Thread]