unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
Subject: RE: key to yank text at point into minibuffer?
Date: Mon, 20 Feb 2006 15:10:39 -0800	[thread overview]
Message-ID: <DNEMKBNJBGPAOPIJOOICOEOHDCAA.drew.adams@oracle.com> (raw)
In-Reply-To: <87d5hhddow.fsf@jurta.org>

    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	other threads:[~2006-02-20 23:10 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-11 17:17 key to yank text at point into minibuffer? Drew Adams
2006-02-12 14:51 ` Mathias Dahl
2006-02-12 17:22   ` Drew Adams
2006-02-12 21:07     ` Mathias Dahl
2006-02-12 21:24       ` Drew Adams
2006-02-13 18:00 ` Kevin Rodgers
2006-02-13 18:22   ` Drew Adams
2006-02-13 21:39     ` Kevin Rodgers
2006-02-13 21:50       ` Drew Adams
2006-02-14 15:53         ` Kevin Rodgers
2006-02-14 21:24           ` Drew Adams
2006-02-16 17:16             ` Kevin Rodgers
2006-02-19 17:27               ` Juri Linkov
2006-02-14  1:45 ` Juri Linkov
2006-02-14 16:55   ` Drew Adams
2006-02-17 21:57     ` Juri Linkov
2006-02-18  2:55       ` Drew Adams
2006-02-19 17:28         ` Juri Linkov
2006-02-19 19:53           ` Drew Adams
2006-02-20  9:03             ` Drew Adams
2006-02-20 19:34               ` Juri Linkov
2006-02-20 23:10                 ` Drew Adams [this message]
2006-02-21 13:43                   ` Mathias Dahl
2006-02-21 13:46                   ` Mathias Dahl
2006-02-22  6:10                     ` Miles Bader
2006-02-22 15:31                   ` Johan Bockgård
2006-02-24 15:48                     ` Drew Adams
2006-02-26  1:31                     ` Miles Bader
2006-02-26 15:35                       ` Drew Adams
2006-02-26 23:42                         ` Miles Bader
2006-02-27  1:17                           ` Drew Adams
2006-02-28  0:09                           ` Thien-Thi Nguyen
2006-02-28  1:55                             ` Miles Bader
2006-03-02 19:44                               ` Richard Stallman
2006-03-03  7:19                                 ` Miles Bader
2006-03-03 18:30                                 ` Luc Teirlinck
2006-03-04  2:00                                   ` Miles Bader
2006-03-04 13:38                                   ` Richard Stallman
2006-03-04 16:00                                     ` Luc Teirlinck
2006-03-06  0:48                                       ` Richard Stallman
2006-03-06  8:06                                         ` Miles Bader
2006-03-07  8:18                                           ` Kim F. Storm
2006-02-24  0:34                   ` Juri Linkov
2006-02-24 16:44                     ` Drew Adams
2006-02-25  8:06                       ` Mathias Dahl
2006-02-25 16:36                         ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DNEMKBNJBGPAOPIJOOICOEOHDCAA.drew.adams@oracle.com \
    --to=drew.adams@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).