From: Juri Linkov <juri@jurta.org>
Cc: emacs-devel@gnu.org
Subject: Re: key to yank text at point into minibuffer?
Date: Sun, 19 Feb 2006 19:28:14 +0200 [thread overview]
Message-ID: <87slqfb5w1.fsf@jurta.org> (raw)
In-Reply-To: <DNEMKBNJBGPAOPIJOOICMEMIDCAA.drew.adams@oracle.com> (Drew Adams's message of "Fri, 17 Feb 2006 18:55:38 -0800")
> > 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
input.
> 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
http://www.jurta.org/emacs/
next prev parent reply other threads:[~2006-02-19 17:28 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 [this message]
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
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=87slqfb5w1.fsf@jurta.org \
--to=juri@jurta.org \
--cc=emacs-devel@gnu.org \
/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).