bug#48134: When sitting on top of a M-x item in the manual

bug#48134: When sitting on top of a M-x item in the manual

[積丹尼 Dan Jacobson]

Do (info "(emacs) Colors")
Now put the cursor on top of
‘M-x list-colors-display’
and hope emacs realizes it... but it doesn't so we end up typing
 <escape> x		 ;; execute-extended-command
 l			 ;; self-insert-command
 <tab>			 ;; minibuffer-complete
 i			 ;; self-insert-command
 <tab>			 ;; minibuffer-complete
 s			 ;; self-insert-command
 <tab>			 ;; minibuffer-complete
 t			 ;; self-insert-command
 <tab>			 ;; minibuffer-complete
 c			 ;; self-insert-command
 <tab>			 ;; minibuffer-complete
 o			 ;; self-insert-command
 <tab>			 ;; minibuffer-complete
 l			 ;; self-insert-command
 <tab>			 ;; minibuffer-complete
ah, finally we can hit RET.

One would think some default would show up based on what our cursor was
on or something.

Or maybe the item should be hyperlinked.

emacs-version "27.1"

bug#48134: When sitting on top of a M-x item in the manual

[Kévin Le Gouguec]

積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:

> Do (info "(emacs) Colors")
> Now put the cursor on top of
> ‘M-x list-colors-display’
> and hope emacs realizes it... but it doesn't so we end up typing
> <snip>
> ah, finally we can hit RET.
>
> One would think some default would show up based on what our cursor was
> on or something.

Note that M-n does the sort of "mind-reading" you're looking for,
IIUC:

- put cursor on top of ‘M-x list-colors-display’
- M-x M-n

Would that be an acceptable answer for you?  If not, maybe there are
some completion UIs that are more eager and will default to whatever M-n
suggests; none comes to mind at the moment, but I'd be surprised if none
existed.


All in all though, maybe "buttonizing" ‘M-x foo’ commands in Info
manuals would make sense: one could then trigger them with RET or
mouse-1, and reach them with TAB; no idea how hard it would be to
implement.

bug#48134: When sitting on top of a M-x item in the manual

[積丹尼 Dan Jacobson]

OK, M-x M-n indeed works.
However, we are used to "Default: list-colors-display" type hints,
that in no way hinder power users or others who don't want the default,
and also provides the bonus of not needing to be super savvy to know
about arrows or M-n to get the hidden choice out into the open.

Also indeed lots of stuff in the info manuals is already brightly
hyperlinked, so it is odd that there are a few things that were
forgotten about.

bug#48134: [External] : bug#48134: When sitting on top of a M-x item in the manual

[Drew Adams]

> Do (info "(emacs) Colors")
> Now put the cursor on top of ‘M-x list-colors-display’
> and hope emacs realizes it... but it doesn't so we end up typing...

Icicles provides a trivial remedy for this, which
isn't really connected with completion or anything
particular to do with Icicles (except that it helps):

It binds `M-.' in `minibuffer-local-map' to a command
(`icicle-insert-string-at-point') that inserts some
text at point into the minibuffer.

With cursor on `list-colors-display', `M-x', then `M-.'
pulls that text into the minibuffer: `M-x M-. RET'.

You can use `M-.' anytime the minibuffer is active.
It inserts the text at point in the minibuffer.  You
can use it to pull in more than one bit of text.

I suggested several times that vanilla Emacs have such
a simple feature, but...
_____________

See this description:

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

And here's the doc string:

icicle-insert-string-at-point is an interactive compiled Lisp function
in ‘icicles-mcmd.el’.

(icicle-insert-string-at-point &optional ARG)

Insert text at the cursor into the minibuffer.

Each time this command is called, some text at or near the cursor is
inserted into the minibuffer.  One of two things happens, depending on
the value of option `icicle-default-thing-insertion' and whether or
not you use `C-u'.

See the doc for option `icicle-thing-at-point-functions' for a
complete description of its behavior.  What follows is an overview.

`icicle-thing-at-point-functions' is a cons of two parts - call them
ALTERNATIVES and FORWARD-THING.

If ALTERNATIVES is not nil and one of the following is true:
 - FORWARD-THING is nil
 - the value of `icicle-default-thing-insertion' is `alternatives' and
   you have not used plain `C-u' in this series of `M-.'
 - the value of `icicle-default-thing-insertion' is `more-of-the-same'
   and you have used plain `C-u' in this series of `M-.'
then the next function in ALTERNATIVES is used to retrieve the text to
be inserted.

If FORWARD-THING is not nil and one of the following is true:
 - ALTERNATIVES is nil
 - the value of `icicle-default-thing-insertion' is `more-of-the-same'
   and you have not used `C-u' in this series of `M-.'
 - the value of `icicle-default-thing-insertion' is `alternatives' and
   you have used `C-u' in this series of `M-.'
then function FORWARD-THING is used to retrieve the text to be
inserted.

If you use a numeric prefix arg (not just plain `C-u'), the behavior
is as follows.

* If a function in ALTERNATIVES is used (see above), then the text
  that is grabbed at or near point is read as a Lisp sexp and
  evaluated, and the value is inserted instead of the grabbed text.

  Yes, this means you need to know when the particular ALTERNATIVES
  function that you want is coming up next, and use, say, `C-9' just
  before hitting `M-.' for that alternative.

* If the FORWARD-THING is being used, then the prefix arg determines
  the number of things to grab, and the direction of grabbing.: A
  negative argument grabs text to the left of the cursor; a positive
  argument grabs text to the right.

You can use this command only from the minibuffer (`M-.').

bug#48134: [External] : bug#48134: When sitting on top of a M-x item in the manual

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> Date: Sat, 1 May 2021 14:01:26 +0000
> 
> > Do (info "(emacs) Colors")
> > Now put the cursor on top of ‘M-x list-colors-display’
> > and hope emacs realizes it... but it doesn't so we end up typing...
> 
> Icicles provides a trivial remedy for this, which
> isn't really connected with completion or anything
> particular to do with Icicles (except that it helps):

How is this and the following text relevant to the bug report?  If you
want to suggest that a similar implementation be included in Emacs, it
is enough to mention the existence of the solution.  You could also
describe your proposed implementation, while you are at that, as that
gives ideas for our internal implementation.

But quoting a long documentation string adds nothing to the bug
report, and looks like a shameless plug to me.  It also makes the bug
report harder to read.  Please don't clutter the bug tracker with such
useless information.

bug#48134: [External] : bug#48134: When sitting on top of a M-x item in the manual

[Drew Adams]

Here we go again...

> If you want to suggest that a similar implementation be
> included in Emacs, it is enough to mention the existence
> of the solution.

I did that.  I did better than that.  I suggested
adding a similar, _general_ feature, instead of
arguing for this or that particular way to provide
such a feature.

> You could also describe your proposed implementation,
> while you are at that, as that gives ideas for our
> internal implementation.

... and I described the "solution" whose "existence"
I mentioned (and pointed to its code).

What's missing in Emacs is a simple way to pull text
at point into the minibuffer at point - into ANY
minibuffer (not just for `M-x' or completion).

Just what text gets pulled in, and how, is worth
discussing in the bug thread perhaps.  What I
offered was a suggestion to do so in a general way,
by e.g. binding a key in the most general minibuffer
keymap (not in a completion keymap).

I provided info about one particular example of such
a feature, describing possible behaviors wrt pulling
in text at point.  Maybe worth considering in the
context of the feature request, as food for thought.

But feel free to ignore those food-for-thought
details.  (The general suggestion has been made
before - and ignored.)

How is your rant against my contributed suggestion
helpful?

> looks like a shameless plug to me

I'm not plugging anything.  I made a point of
saying that this feature really has nothing to do
with the rest of Icicles, and that it's simple for
Emacs to implement it or something similar.

It's in Icicles only because it wasn't in Emacs and
because it's useful for interacting with the
minibuffer (which is important for using Icicles).

It would be good for Emacs itself to have such a
feature.  That's the point.  It's not about Icicles
having such a feature.

The doc I pointed to describes what the feature
does.  That info could be helpful in deciding what
to do for Emacs.  That's the point of describing
it for you.  If you don't find it helpful, ignore
it.

> Please don't clutter the bug tracker with such
> useless information.

Please consider implementing the enhancement
requested by Jidanni.  Just how that's done is less
important than doing it.  It could have been done
decades ago, when first suggested.

Do you really want a description of the Icicles
_implementation_ of this, as you say?  Describing
the behavior for users isn't enough?

Here's a high-level implementation description that
should be appropriate for this thread:

 1. Define a user option that provides functions
    that return a string of text at point or else
    nil.

 2. Call one of those functions when a user invokes
    the command for inserting text at point using
    some key (such as `M-.').

The option could be like what Icicles uses
(`icicle-thing-at-point-functions').  But it need
not be - it could be much simpler.

The way one of those functions is chosen could be
similar to what Icicles does.  But it need not be
- it could be much simpler.

I won't bore you more with the particular behavior
Icicles provides, or how.  That's not the point.

If you want more, just ask.  But again, I'm not
proposing that Emacs adopt the same behavior or
implementation.  I offered a description only as
food for thought.

To be extra clear: I _don't want_ more people to
use Icicles.  Really.  I don't have the time or
will to keep up with changes to vanilla Emacs
that make changes to my code necessary.  That's
life.

Icicles can, I think, offer food for thought, in
various ways.  It has already done so, resulting
in several other completion "frameworks" now.
That's all.  Food for thought.

bug#48134: [External] : bug#48134: When sitting on top of a M-x item in the manual

[Juri Linkov]

> With cursor on `list-colors-display', `M-x', then `M-.'
> pulls that text into the minibuffer: `M-x M-. RET'.

`M-x M-. RET' can't be used because `M-.' is bound to the command
`xref-find-definitions' useful in the minibuffer too.  Fortunately,
`M-x M-n RET' already pulls that text into the minibuffer.

bug#48134: [External] : bug#48134: When sitting on top of a M-x item in the manual

[Drew Adams]

> > With cursor on `list-colors-display', `M-x', then `M-.'
> > pulls that text into the minibuffer: `M-x M-. RET'.
> 
> `M-x M-. RET' can't be used because `M-.' is bound to the command
> `xref-find-definitions' useful in the minibuffer too.

Yes, well choose another key then.

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.

> Fortunately, `M-x M-n RET' already pulls that text
> into the minibuffer.

What text?  Just a command name at point?

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.

(Some of them are available with `M-.' in Icicles.
You can see them described in the doc string Eli
so objected to being shown.)

bug#48134: When sitting on top of a M-x item in the manual

[Lars Ingebrigtsen]

積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:

> OK, M-x M-n indeed works.
> However, we are used to "Default: list-colors-display" type hints,
> that in no way hinder power users or others who don't want the default,
> and also provides the bonus of not needing to be super savvy to know
> about arrows or M-n to get the hidden choice out into the open.

This is how Emacs works all over the place -- `M-n' should get you the
suggestion.  Making all prompts tell you about this standard feature
would be less than optimal, so I don't think there's anything to fix
here, and I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#48134: When sitting on top of a M-x item in the manual

[Howard Melman]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> This is how Emacs works all over the place -- `M-n' should get you the
> suggestion.  Making all prompts tell you about this standard feature
> would be less than optimal, so I don't think there's anything to fix
> here, and I'm closing this bug report.

I suggest making this standard feature a little more
explicit in the emacs manual.  I think it's only mentioned
in the Minibuffer History node (in Emacs 27) which is fine,
but the only index entry for this is "future history for
file names".  I think it would be better to also (or just)
index "future history" in the previous paragraph.

Also a sentence explaining how this standard feature
commonly behaves would help.  Something like:

This is often a value at point relevant to the command such
as a symbol, word, file name or color.

(with perhaps a mention of thing-at-point)

-- 

Howard

bug#48134: When sitting on top of a M-x item in the manual

[Kévin Le Gouguec]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> This is how Emacs works all over the place -- `M-n' should get you the
> suggestion.  Making all prompts tell you about this standard feature
> would be less than optimal, so I don't think there's anything to fix
> here, and I'm closing this bug report.

FWIW, I think I only ever found out about M-n because someone sang its
praise somewhere on the Net.  I see that (info "(emacs) Minibuffer
History") mentions its DWIM behaviour and gives examples for filename
prompts, but given how ubiquitous and useful M-n is, I wonder if we
couldn't do more to advertise it.

Emacs does tell users about (some) standard features, e.g. after C-h f,
we get a message advertising "q" and "C-M-v".  I get that longtime users
mostly see that as noise, but I think messaging a concise hint along the
lines of "N suggestions; select them with M-n" would make this "future
history" easier to discover.

I realize that this would probably not be trivial to implement though.
Looking up "future history in minibuffer input" in the Elisp manual
brought me to (info "(elisp) Text from Minibuffer"), which lured me into
thinking that this hypothetical hint could simply be added in
read-from-minibuffer, by looking at the DEFAULT argument; a stroll
through read-extended-command taught me that some functions compute
their "future history" dynamically with minibuffer-default-add-function,
which I guess complicates things a bit?


(… Alternatively, read-extended-command could just default to the
command at point, like describe-{function,variable,symbol} do)

bug#48134: [External] : bug#48134: When sitting on top of a M-x item in the manual

[Juri Linkov]

>> > With cursor on `list-colors-display', `M-x', then `M-.'
>> > pulls that text into the minibuffer: `M-x M-. RET'.
>> 
>> `M-x M-. RET' can't be used because `M-.' is bound to the command
>> `xref-find-definitions' useful in the minibuffer too.
>
> Yes, well choose another key then.

Which one?

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

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

bug#48134: [External] : bug#48134: When sitting on top of a M-x item in the manual

[Drew Adams]

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

bug#48134: When sitting on top of a M-x item in the manual

[Lars Ingebrigtsen]

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> I see that (info "(emacs) Minibuffer History") mentions its DWIM
> behaviour and gives examples for filename prompts, but given how
> ubiquitous and useful M-n is, I wonder if we couldn't do more to
> advertise it.

Yeah, it is perhaps a too-hidden feature.

> I realize that this would probably not be trivial to implement though.
> Looking up "future history in minibuffer input" in the Elisp manual
> brought me to (info "(elisp) Text from Minibuffer"), which lured me into
> thinking that this hypothetical hint could simply be added in
> read-from-minibuffer, by looking at the DEFAULT argument; a stroll
> through read-extended-command taught me that some functions compute
> their "future history" dynamically with minibuffer-default-add-function,
> which I guess complicates things a bit?

Yes, in general we don't really know whether we have anything in the
future history until the user hits `M-n', I think?  We could say
something in the instances where we do know in advance, but users might
infer from that that there's nothing in `M-n' if the message doesn't
appear.  And saying "M-n might reveal something" isn't very helpful
either.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no