unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Juri Linkov <juri@linkov.net>
Cc: "積丹尼 Dan Jacobson" <jidanni@jidanni.org>,
	"48134@debbugs.gnu.org" <48134@debbugs.gnu.org>
Subject: bug#48134: [External] : bug#48134: When sitting on top of a M-x item in the manual
Date: Mon, 3 May 2021 00:35:56 +0000	[thread overview]
Message-ID: <SA2PR10MB44748E433AC7EC034518D911F35B9@SA2PR10MB4474.namprd10.prod.outlook.com> (raw)
In-Reply-To: <87im403ll0.fsf@mail.linkov.net>

> > It's unfortunate that Emacs has chosen to waste a
> > repeatable key on a nonrepeatable command such as
> > `xref-find-definitions', but so it goes.
> 
> A command to pull text to the minibuffer is not
> repeatable either.

I disagree.  And I think this points to an
under-appreciation of the importance of repeatable
keys and of not wasting them on nonrepeatable
commands (or wasting them on non-prefix commands).

The command I pointed to IS repeatable.  The doc I
showed for it describes the behavior.

You can hold down `M-.' to repeatedly select things
of a given kind and insert them into the minibuffer,
appending them one after the other.  The user option
defines which kind of thing to repeatedly grab.

By default, successive words are grabbed.  You can
use any function that moves point.  The default is
`forward-word'.  Change that to `forward-char' and
hold down `M-.' to stream chars to the minibuffer
after point there.  Change it to `backward-char' and
you can stream chars to the minibuffer before point
(i.e., prepend instead of append).  Change it to
`forward-sentence to stream sentences after point.
And so on.

OR you can - alternatively - hold down `M-.' to cycle
through different kinds of thing at point: Each `M-.'
replaces the thing inserted the immediately previous
`M-.'.  Cycle till you get the kind of thing you want.

Those are thus two kinds of repeated action.  A user
option defines which one is used by default.

And plain `C-u' as prefix arg flips the option, to use
the opposite behavior temporarily.  So you can, e.g.,
in general prefer to have `M-.' cycle among thing
types but use `C-u M-x' as a one-off, to instead pull
in  successive things of the same type from the buffer.

This is all explained in the doc string that Eli
didn't want to be bothered with.

And it's explained even better/more at the doc page
I cited.

https://www.emacswiki.org/emacs/Icicles_-_Inserting_Text_from_Cursor

Heading "Repeat `M-.' To Grab More or Different"
there presents the two alternative behaviors.

[I haven't bothered to do this, but if it were thought
useful then it could be introduced: Instead of the
option defining at most one repeat-me function (e.g.
`forward-word'), it could let you define more than one,
and the command (`M-.') could provide some way to switch
among them.]

> > What I tried to suggest was to have a more general
> > feature to insert text at point into the minibuffer.
> > There are lots of possibilities for that.
> 
> I agree such a command would be useful.
> But to what key to bind it?

I suggested `M-.'.  That's still my suggestion, as I
don't think it was a good idea to give that key to xref
for a nonrepeatable command.  But I don't really expect
anyone to make such a change.  Not any more than I expect
anyone to add any feature such as what I've suggested.

`M-n' is something else.  FWIW, I think it's a mistake
to speak "future history" regarding it.  "History" for
minibuffer input refers to text you've actually accepted
as input previously.  We correctly referred to what `M-n'
offers as "default values", and the Elisp doc still does
that.  Why someone (you perhaps?) introduced "future
history" I don't know.  But IMHO it's more likely to
confuse than aid.  Seems "cute", but does it help?

`M-n' cycles among default values.  Those values are
_not_, in general, text at point in the buffer.  They,
or some of them, can be, of course.  But `M-n' is more
general - it's not necessarily, or even usually, about
offering text at point as default values.

IMO, it would be better to have a separate key for
grabbing buffer text and inserting into the minibuffer.
And that should NOT be only when reading with completion.

Hence what I did with `M-.'.

HTH.





      reply	other threads:[~2021-05-03  0:35 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-01  5:41 bug#48134: When sitting on top of a M-x item in the manual 積丹尼 Dan Jacobson
2021-05-01  8:59 ` Kévin Le Gouguec
2021-05-01 12:15   ` 積丹尼 Dan Jacobson
2021-05-02  7:14     ` Lars Ingebrigtsen
2021-05-02 14:09       ` Howard Melman
2021-05-02 16:09       ` Kévin Le Gouguec
2021-05-03  9:00         ` Lars Ingebrigtsen
2021-05-01 14:01 ` bug#48134: [External] : " Drew Adams
2021-05-01 14:35   ` Eli Zaretskii
2021-05-01 16:28     ` Drew Adams
2021-05-01 20:09   ` Juri Linkov
2021-05-01 23:23     ` Drew Adams
2021-05-02 20:52       ` Juri Linkov
2021-05-03  0:35         ` Drew Adams [this message]

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=SA2PR10MB44748E433AC7EC034518D911F35B9@SA2PR10MB4474.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=48134@debbugs.gnu.org \
    --cc=jidanni@jidanni.org \
    --cc=juri@linkov.net \
    /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).