bug#36525: M-x default when cursor on top of a M-x command in INFO

bug#36525: M-x default when cursor on top of a M-x command in INFO

[積丹尼 Dan Jacobson]

1. Do (info "(emacs) Coding Systems")

2. Put the cursor on top of
‘M-x list-coding-systems’

3. Hit M-x

Wouldn't it be great if we saw that it was now the default in the minibuffer?

That way we could just hit RET to run it.

Currently C-h C-f knows what the cursor is on, but not M-x (ESC x).

bug#36525: M-x default when cursor on top of a M-x command in INFO

[Drew Adams]

> 2. Put the cursor on top of
> ‘M-x list-coding-systems’
> 3. Hit M-x
> 
> Wouldn't it be great if we saw that it was now
> the default in the minibuffer?
> 
> That way we could just hit RET to run it.
> 
> Currently C-h C-f knows what the cursor is on,
> but not M-x (ESC x).

A better way to handle this is to have a key
(Icicles uses `M-.') that pulls text from the
buffer into the minibuffer, appending it to
whatever input text might already be there.

This is much more general than just pulling
in a command name from an Info buffer.

But it also means that users should be given
some way to control over _which_ text from the
buffer should be inserted into the minibuffer.
There are several reasonable possibilities.

As food for thought, Icicles handles this as
described here:

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

Summary:

Repeated `M-.' can have two different behaviors.
You can choose (by an option) which one to use.

1. Repeating `M-.' cycles through alternative
   bits of text from the buffer.  Each time you
   hit `M-.' consecutively it inserts a different 
   string of text (replacing the previously
   inserted one).

   You can configure (user option) which kinds
   of text to grab.  By default the kinds are:

   . `non-nil-symbol-name-nearest-point'
   . `word-nearest-point'
   . `list-nearest-point-as-string'
   . Same (nearest list), but 2 levels up.
   . Same (nearest list), but 3 levels up.
   . `ffap-guesser' (but first deactivate a
     large active region)
   . `thing-at-point-url-at-point'

2. Repeating `M-.' grabs another thing of the
   chosen kind.  By default it is the next
   word (using `forward-word').

IOW, you can either (1) keep using `M-.' to
insert _additional_ text things of a kind you
choose with an option setting or (2) use `M-.'
to cycle to get one thing of a kind that you
choose on the fly.

[Note that for your example, either (1) or (2)
does what you request: `list-coding-system'
is added to the minibuffer.  `forward-word'
and `non-nil-symbol-name-nearest-point' both
grab that text.]

Whether vanilla Emacs would allow flexibility
to this degree is not so important as at
least having Emacs have a key that grabs
_something_ from the buffer text and appends
it to minibuffer input.  Choice #2 above is
pretty simple to realize - give users an
option to specify which kind of text thing
they want to insert.

Alternatively, Emacs itself could provide
some context-sensitive DWIM to determine the
kind of text thing to grab.  (As one user,
I prefer to control that choice myself, but
I'm sure that some others would be OK with
Emacs choosing.)

bug#36525: M-x default when cursor on top of a M-x command in INFO

[積丹尼 Dan Jacobson]

Well all I know is that if emacs currently suggests for C-h f then it
should for M-x ... (speaking for the beginner using vanilla emacs.)

bug#36525: M-x default when cursor on top of a M-x command in INFO

[Juri Linkov]

> A better way to handle this is to have a key
> (Icicles uses `M-.') that pulls text from the
> buffer into the minibuffer, appending it to
> whatever input text might already be there.
>
> Summary:
>
> Repeated `M-.' can have two different behaviors.
> You can choose (by an option) which one to use.
> [...]
>
> Whether vanilla Emacs would allow flexibility
> to this degree is not so important as at
> least having Emacs have a key that grabs
> _something_ from the buffer text and appends
> it to minibuffer input.  Choice #2 above is
> pretty simple to realize - give users an
> option to specify which kind of text thing
> they want to insert.

Do you think `M-.' is a suitable key for vanilla Emacs?
Its global keybinding is `xref-find-definitions',
but is this command useful in the minibuffer?
Or could be taken for grabbing text from the buffer
to the minibuffer?

bug#36525: M-x default when cursor on top of a M-x command in INFO

[Drew Adams]

> > A better way to handle this is to have a key
> > (Icicles uses `M-.') that pulls text from the
> > buffer into the minibuffer, appending it to
> > whatever input text might already be there.
> >
> > Summary:
> >
> > Repeated `M-.' can have two different behaviors.
> > You can choose (by an option) which one to use.
> > [...]
> >
> > Whether vanilla Emacs would allow flexibility
> > to this degree is not so important as at
> > least having Emacs have a key that grabs
> > _something_ from the buffer text and appends
> > it to minibuffer input.  Choice #2 above is
> > pretty simple to realize - give users an
> > option to specify which kind of text thing
> > they want to insert.
> 
> Do you think `M-.' is a suitable key for vanilla Emacs?
> Its global keybinding is `xref-find-definitions',
> but is this command useful in the minibuffer?
> Or could be taken for grabbing text from the buffer
> to the minibuffer?

Default key choice preferences are somewhat
of a mine field for discussion...

Dunno whether `xref-find-definitions' is
usable from the active minibuffer.  I'm
not familiar with it.  Perhaps so, with
non-nil `enable-recursive-minibuffers'.

I will point out that `M-.' is a repeatable
key.  And a repeatable key is good for a
command that is repeatable, such as doing
something to/with consecutive bits of text
(e.g. "things") from a buffer.

Is `xref-find-definitions' a repeatable
command (i.e. by holding the key pressed)?
On the other hand, in the old days `M-.'
was bound to `find-tag', which was not
repeatable (unless perhaps with non-nil
`enable-recursive-minibuffers').

In Icicle (minor) mode, where `M-.' is
bound to a command that inserts buffer
text into the minibuffer, I've never
noticed any conflict between that and
the global binding of `M-.'.  That may be
some evidence that it would be OK to use
it for something similar in the vanilla
Emacs minibuffer.

---

All of that said, I'd suggest that,
_other things being equal_, keys like
`M-.' should not be bound globally to
commands that can't benefit from holding
them down to repeat the action.

`M-.' was bound to `find-tag' eons ago,
before there were so many default key
bindings, so many modes, so many libraries,
and so many commands that are repeatable.

It's not as if repeatable key bindings
are as scarce as berkelium, but there's
also no great reason to "waste" them on
non-repeatable commands.  Habit does
matter to some extent, though, which I
suppose is why `M-.' is still bound to a
find command.

bug#36525: M-x default when cursor on top of a M-x command in INFO

[Juri Linkov]

> I will point out that `M-.' is a repeatable
> key.  And a repeatable key is good for a
> command that is repeatable, such as doing
> something to/with consecutive bits of text
> (e.g. "things") from a buffer.

A keybinding doesn't need to be a single key
to be repeatable.  ‘C-x e e e’ is repeatable.

bug#36525: M-x default when cursor on top of a M-x command in INFO

[Drew Adams]

> > I will point out that `M-.' is a repeatable
> > key.  And a repeatable key is good for a
> > command that is repeatable, such as doing
> > something to/with consecutive bits of text
> > (e.g. "things") from a buffer.
> 
> A keybinding doesn't need to be a single key
> to be repeatable.  ‘C-x e e e’ is repeatable.

Agreed 100%.  In general, I put most of my
repeatable keys on a prefix key.

I don't argue that a key sequence to grab
stuff from the buffer and insert it into the
minibuffer needs to be a single key.

I do think that a repeatable key sequence,
especially one that is a single key (such as
`M-.') should generally not be wasted on a
non-repeatable command (such as, presumably,
`xref-find-definitions').

Such a general rule (in my mind) can have
exceptions, of course, and there's no urgency to
try to rebind all such non-repeatable commands,
to liberate their keys for repeatable commands.

bug#36525: M-x default when cursor on top of a M-x command in INFO

[Juri Linkov]

>> > I will point out that `M-.' is a repeatable
>> > key.  And a repeatable key is good for a
>> > command that is repeatable, such as doing
>> > something to/with consecutive bits of text
>> > (e.g. "things") from a buffer.
>>
>> A keybinding doesn't need to be a single key
>> to be repeatable.  ‘C-x e e e’ is repeatable.
>
> Agreed 100%.  In general, I put most of my
> repeatable keys on a prefix key.
>
> I don't argue that a key sequence to grab
> stuff from the buffer and insert it into the
> minibuffer needs to be a single key.

Then a key sequence like ‘C-x M-. M-. M-.’
could be used to copy text from the buffer
to the minibuffer.  And then why not let it
be copied to any buffer, not just the minibuffer.
For instance, select the active region in one buffer,
switch to another window, and pull text from the region
in other window - without adding it to the kill-ring.

bug#36525: M-x default when cursor on top of a M-x command in INFO

[Drew Adams]

> Then a key sequence like ‘C-x M-. M-. M-.’
> could be used to copy text from the buffer
> to the minibuffer.

Of course.  As could `M-.'  Or other key
sequences.

> And then why not let it be copied to any buffer, 
> not just the minibuffer.

Why?

By "copied to" I guess you mean pasted to,
since that's what was talked about wrt the
minibuffer: copied from the current buffer,
pasted into the minibuffer.

In the minibuffer case the two buffers
involved are well-defined.  There's no
navigating.

> For instance, select the active region in one buffer,
> switch to another window, and pull text from the region
> in other window - without adding it to the kill-ring.

There are any number of things that could
be done.  Why do that one in particular?
Do you see it as being particularly useful?

There's a buffer that's current when you
enter the minibuffer.  It's generally where
you might be interested in grabbing some
text at point.  (It, and its window point,
were likely the focus of attention before
entering the minibuffer.)

Since you're now editing in the minibuffer,
that's generally where you want to paste it.

This is a particular use case, even if the
choice of _what_ you might want to grab
near point allows lots of possibilities.

I don't see the point of what you describe,
but feel free to develop it some more.

So far, I can't imagine using it.  (How
often do I want to copy+paste without using
the kill ring?  Rarely.)

In a scenario like you describe, if I had
to go to another window, select some text,
and then paste it into the first (or yet
another) window, I'd probably use the mouse
to select the text.  (And I have non-nil
`mouse-drag-copy-region', so it would still
use the kill ring.)

Or if I wanted to avoid adding to the kill
ring I'd select the text as the secondary
selection and paste that.

Maybe describe a bit more what you have in
mind?  Maybe try it out?

bug#36525: M-x default when cursor on top of a M-x command in INFO

[Basil L. Contovounesios]

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

> 1. Do (info "(emacs) Coding Systems")
>
> 2. Put the cursor on top of
> ‘M-x list-coding-systems’
>
> 3. Hit M-x
>
> Wouldn't it be great if we saw that it was now the default in the minibuffer?

Try M-n.
This runs next-history-element; see (info "(emacs) Minibuffer History").

-- 
Basil

bug#36525: M-x default when cursor on top of a M-x command in INFO

[積丹尼 Dan Jacobson]

>>>>> "BLC" == Basil L Contovounesios <contovob@tcd.ie> writes:
>> 2. Put the cursor on top of
>> ‘M-x list-coding-systems’
>> 
>> 3. Hit M-x
>> 
>> Wouldn't it be great if we saw that it was now the default in the minibuffer?

BLC> Try M-n.
BLC> This runs next-history-element; see (info "(emacs) Minibuffer History").

Ah ha...
So how about instead of the user typing M-x M-n, he just types M-x for
the exact same effect.
Now all he has to do is either hit RET, or replace the text with what he
wants instead.

bug#36525: M-x default when cursor on top of a M-x command in INFO

[Stefan Kangas]

積丹尼 Dan Jacobson <jidanni@jidanni.org>:
> So how about instead of the user typing M-x M-n, he just types M-x for
> the exact same effect.
> Now all he has to do is either hit RET, or replace the text with what he
> wants instead.

I would guess that the more common use case is that you want to run a
command with another name than the text currently at point.

Best regards,
Stefan Kangas

bug#36525: M-x default when cursor on top of a M-x command in INFO

[積丹尼 Dan Jacobson]

SK> I would guess that the more common use case is that you want to run a
SK> command with another name than the text currently at point.
OK, but these days (I've got ffap enabled) I already have the habit of
moving the cursor off of anything that looks like a URL etc.

I.e., these days the user should expect "smart suggestions"... with the
price that if he wants a blank area where the suggestion would be, then
he should "take his cursor elsewhere". But that would be more work then
just holding down the DEL key to clean off the suggestion.

bug#36525: M-x default when cursor on top of a M-x command in INFO

[Stefan Kangas]

積丹尼 Dan Jacobson <jidanni@jidanni.org>:
> SK> I would guess that the more common use case is that you want to run a
> SK> command with another name than the text currently at point.
> OK, but these days (I've got ffap enabled) I already have the habit of
> moving the cursor off of anything that looks like a URL etc.
>
> I.e., these days the user should expect "smart suggestions"... with the
> price that if he wants a blank area where the suggestion would be, then
> he should "take his cursor elsewhere". But that would be more work then
> just holding down the DEL key to clean off the suggestion.

This is why I don't use ffap.el personally.  I don't think it's good
to force this behaviour on the user by default.

Best regards,
Stefan Kangas

bug#36525: M-x default when cursor on top of a M-x command in INFO

[Basil L. Contovounesios]

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

> SK> I would guess that the more common use case is that you want to run a
> SK> command with another name than the text currently at point.
> OK, but these days (I've got ffap enabled) I already have the habit of
> moving the cursor off of anything that looks like a URL etc.

That this habit works for you does not mean that it should be imposed on
everyone else.

> I.e., these days the user should expect "smart suggestions"...

Does M-n not provide smart suggestions?

> with the price that if he wants a blank area where the suggestion
> would be, then he should "take his cursor elsewhere". But that would
> be more work then just holding down the DEL key to clean off the
> suggestion.

Yes, and I don't think it is warranted, so I think this report should be
closed as notabug/wontfix.

Thanks,

-- 
Basil

bug#36525: M-x default when cursor on top of a M-x command in INFO

[Sebastian Urban]

> Yes, and I don't think it is warranted, so I think this report
> should be closed as notabug/wontfix.

I'm a bit late to the party, but... perhaps doing it how "describe"
commands do it would be better, i.e. in minibuffer:

    M-x (default list-coding-systems) |

where '|' is cursor position.  No evasive manoeuvres to avoid
automatic inserting, no deleting if we want to run different command,
no additional key (like 'M-n') - just RET if you agree, or write
different command.  But I must say that it looks a bit stranger than
in case of "describe" commands.  Maybe just make it optional
behaviour, controlled by variable (nil/t).  Of course, in this case,
'M-n' should avoid first value, because it'll be inside parentheses,
and skip to the next one.

bug#36525: M-x default when cursor on top of a M-x command in INFO

[Basil L. Contovounesios]

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

>>>>>> "BLC" == Basil L Contovounesios <contovob@tcd.ie> writes:
>>> 2. Put the cursor on top of
>>> ‘M-x list-coding-systems’
>>> 
>>> 3. Hit M-x
>>> 
>>> Wouldn't it be great if we saw that it was now the default in the minibuffer?
>
> BLC> Try M-n.
> BLC> This runs next-history-element; see (info "(emacs) Minibuffer History").
>
> Ah ha...
> So how about instead of the user typing M-x M-n, he just types M-x for
> the exact same effect.
> Now all he has to do is either hit RET, or replace the text with what he
> wants instead.

Inserting text in the minibuffer is intrusive and discouraged;
see (info "(elisp) Initial Input").

Making M-x interpret empty input as the symbol at point changes
long-standing behaviour of a central feature and makes it easier to make
a mistake.  IMO typing M-n is not only good enough, but better, since it
works across all standard minibuffer reading functions.

You can always write a custom command to default to the command name at
point without needing to change M-x for everyone.

-- 
Basil

bug#36525: M-x default when cursor on top of a M-x command in INFO

[Lars Ingebrigtsen]

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

>> Ah ha...
>> So how about instead of the user typing M-x M-n, he just types M-x for
>> the exact same effect.
>> Now all he has to do is either hit RET, or replace the text with what he
>> wants instead.
>
> Inserting text in the minibuffer is intrusive and discouraged;
> see (info "(elisp) Initial Input").

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