[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: Drew Adams
Subject: RE: key to yank text at point into minibuffer?
Date: Mon, 20 Feb 2006 15:10:39 -0800

    Basically I like this functionality.  But it still doesn't work
    as I expected. It is not easy to use as ffap.  For instance I can't
    easily put URLs at point to the minibuffer created by C-x C-f.
    Unlike ffap that puts the URL to the minibuffer just after typing
    C-x C-f, `M-.' requires typing more keys:
    C-x C-f C-a C-k C-u M-.

Ffap tries to do only one thing - it always replaces the existing input,
IIUC. That was the way I approached this initially, but you made me see the
light ;-).

(BTW, everyone should have a key bound in the minibuffer to a command that
erases the minibuffer. I use `M-S-backspace'.)

    When I suggested adding the thing at point instead of replacing the
    minibuffer input, I meant that preserving the minibuffer input is needed
    only for the input typed by the user, but not for the initial input.

That difference can be known perhaps at the beginning of minibuffer input,
by the particular command that reads input (and inserts the initial value).
Ffap operates with such knowledge (although I don't think it does anything
particular with it). Ffap replaces particular input-reading commands with
others, in effect.

The approach being discussed is, on the other hand, very general. `M-n' is
not a top-level command; it is a minibuffer command. You can use `M-.' at
any position in the minibuffer to yank things there - as you suggested.
Because of this, there is no way for the `M-.' command to know if what is
currently in the minibuffer is stuff that you typed or stuff that was put
there initially (by the command using the minibuffer to read). At best, it
can know what it has, itself, inserted previously.

Further, there is certainly no way for `M-.' to know when _you want_ to add
to the input vs replace it. Unless you somehow tell it.

`C-u C-u', for instance, might be used to indicate that you want to first
erase the minibuffer, before inserting grabbed text - or vice versa, if
replacement were the default behavior. However, the very different behaviors
of `C-u' and `C-u C-u' might result in confusion. And of course `C-u C-u' is
no easier than `C-a C-k'.

As I see it, the main alternative to explicitly indicating one's intention
wrt the existing input is to return to the behavior I had before: when
alternative text-grabbing functions are cycled, they each replace the
existing input (no matter where it came from) - no insertion without
replacement in the case of alternative grab functions.

My preference would be what I currently have: insertion without replacement,
requiring you to first empty the minibuffer if you want replacement.


FYI, I just uploaded a new version that also lets you use a negative prefix
arg to successively grab text to the left of the cursor. A numeric prefix
arg (not plain `C-u') imposes the grab direction for all subsequent `M-.' -
until the next numeric prefix arg of course. And, as before, the magnitude
of the arg determines the number of things to grab.

For instance, `M-- M-.' grabs and inserts the word to the left of point.
Subsequent `M-.' continue to yank words further to the left, so that you can
build up the string to the left of point (in order of course).

If you then use `C-u 2 M-.', the previously yanked input is replaced by the
two (prefix value=2) words to the right of point. Subsequent `M-.' then
continue to grab successive words to the right. Yes, I said "replaced".

You can get the effect of grabbing text both to the left and to the right,
by simply doing something (e.g. `C-b C-f') to interrupt the chain of
consecutive `M-n'. For instance, `M-x foobar M-- M-. M-. M-. C-b C-f C-u 1
M-.' will yank three words to the left of point and one word to the right of
it.  This is quicker than it sounds - again, it's easier to experience than
to describe. In this way, the exact position of point is not so critical.

Try it here: http://www.emacswiki.org/cgi-bin/wiki/icicles.el

reply via email to

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