GNU bug report logs - #47215
28.0.50; Let M-x switch between M-x and M-X

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 47215 in the body.
You can then email your comments to 47215 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Felician Nemeth <felician.nemeth <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; Let M-x switch between M-x and M-X
Date: Wed, 17 Mar 2021 18:56:28 +0100

I wish there was a convenient way to switch back and forth between
execute-extended-command and execute-extended-command-for-buffer.  I
think M-x would be an ideal binding for this as it is easy to press and
more useful than the current "Command attempted to use minibuffer while
in minibuffer".

I'd imagine this feature being somewhat analogous to how ido-find-file
falls back to find-file after C-f.

Thank you.

Message #8 received at 47215 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Felician Nemeth <felician.nemeth <at> gmail.com>
Cc: 47215 <at> debbugs.gnu.org
Subject: Re: bug#47215: 28.0.50; Let M-x switch between M-x and M-X
Date: Thu, 18 Mar 2021 06:08:29 +0100

Felician Nemeth <felician.nemeth <at> gmail.com> writes:

> I wish there was a convenient way to switch back and forth between
> execute-extended-command and execute-extended-command-for-buffer.  I
> think M-x would be an ideal binding for this as it is easy to press and
> more useful than the current "Command attempted to use minibuffer while
> in minibuffer".
>
> I'd imagine this feature being somewhat analogous to how ido-find-file
> falls back to find-file after C-f.

Yes, being able to move from `execute-extended-command-for-buffer' to
`execute-extended-command' makes sense, but I'm not sure the other
direction is as useful.  And while there's only two of these commands
today, I think it's likely that (in the future) that we'll grow more of
these.

I'm not quite sure how to implement this, though -- we basically end up
in `completing-read', and `execute-extended-command-for-buffer' would
have to define an `M-x' binding there, I guess...  and then somehow call
`read-extended-command' with the text already in the minibuffer.

Anybody got an idea as to how to implement this without rewriting
`read-extended-command' completely?

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

Message #11 received at 47215 <at> debbugs.gnu.org (full text, mbox):

From: Felician Nemeth <felician.nemeth <at> gmail.com>
To: 47215 <at> debbugs.gnu.org
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#47215: 28.0.50; Let M-x switch between M-x and M-X
Date: Sun, 04 Apr 2021 19:51:17 +0200

>> I wish there was a convenient way to switch back and forth between
>> execute-extended-command and execute-extended-command-for-buffer.  I
>> think M-x would be an ideal binding for this as it is easy to press and
>> more useful than the current "Command attempted to use minibuffer while
>> in minibuffer".
>>
>> I'd imagine this feature being somewhat analogous to how ido-find-file
>> falls back to find-file after C-f.
>
> Yes, being able to move from `execute-extended-command-for-buffer' to
> `execute-extended-command' makes sense, but I'm not sure the other
> direction is as useful.  And while there's only two of these commands
> today, I think it's likely that (in the future) that we'll grow more of
> these.

I think cycling makes even more sense when there are more than two of
these execute-extended-commands.  Currently, going from
`execute-extended-command' to `execute-extended-command-for-buffer'
would be useful for me because I can type M-x M-x more easily than type
M-X.

> I'm not quite sure how to implement this, though -- we basically end up
> in `completing-read', and `execute-extended-command-for-buffer' would
> have to define an `M-x' binding there, I guess...  and then somehow call
> `read-extended-command' with the text already in the minibuffer.
>
> Anybody got an idea as to how to implement this without rewriting
> `read-extended-command' completely?

The execute-extended-commands have two undocumented optional arguments
(command-name and typed).  What are they used for?

Anyway, following the fallback logic of `ido-find-file', I was able to
rebind `M-x' and save the content of the minibuffer with a non-standard
exit from `execute-extended-command'.  Maybe the ugly code below can
give ideas to someone more knowledgeable.


(defun my-exit ()
  (interactive)
  (throw 'cycle (cons 'cycle (minibuffer-contents))))

(let ((minibuffer-local-completion-map minibuffer-local-completion-map)
      ret)
  (define-key minibuffer-local-completion-map (kbd "M-x") 'my-exit)
  (setq ret (catch 'cycle
	      (execute-extended-command nil)))
  (if (eq 'cycle (car ret))
      (message "Should switch to M-X with %s" (cdr ret))
    ret))


Thanks.

Message #14 received at 47215 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Felician Nemeth <felician.nemeth <at> gmail.com>
Cc: 47215 <at> debbugs.gnu.org
Subject: Re: bug#47215: 28.0.50; Let M-x switch between M-x and M-X
Date: Sun, 04 Apr 2021 21:52:21 +0200

Felician Nemeth <felician.nemeth <at> gmail.com> writes:

>> I'm not quite sure how to implement this, though -- we basically end up
>> in `completing-read', and `execute-extended-command-for-buffer' would
>> have to define an `M-x' binding there, I guess...  and then somehow call
>> `read-extended-command' with the text already in the minibuffer.
>>
>> Anybody got an idea as to how to implement this without rewriting
>> `read-extended-command' completely?
>
> The execute-extended-commands have two undocumented optional arguments
> (command-name and typed).  What are they used for?
>
> Anyway, following the fallback logic of `ido-find-file', I was able to
> rebind `M-x' and save the content of the minibuffer with a non-standard
> exit from `execute-extended-command'.  Maybe the ugly code below can
> give ideas to someone more knowledgeable.

Thanks -- I was wondering more about the situation where you've typed

M-X foo|bar

(| for point)

and then hit `M-x' because you want to switch to the other mode.
Ideally, `M-x' should do that, and also preserve the text the user has
typed, and the cursor position.  I don't see an obvious simple way to do
that... 

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

Message #17 received at 47215 <at> debbugs.gnu.org (full text, mbox):

From: Felician Nemeth <felician.nemeth <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 47215 <at> debbugs.gnu.org
Subject: Re: bug#47215: 28.0.50; Let M-x switch between M-x and M-X
Date: Sat, 10 Apr 2021 19:56:49 +0200

[Message part 1 (text/plain, inline)]

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Felician Nemeth <felician.nemeth <at> gmail.com> writes:
>
>>> I'm not quite sure how to implement this, though -- we basically end up
>>> in `completing-read', and `execute-extended-command-for-buffer' would
>>> have to define an `M-x' binding there, I guess...  and then somehow call
>>> `read-extended-command' with the text already in the minibuffer.
>>>
>>> Anybody got an idea as to how to implement this without rewriting
>>> `read-extended-command' completely?
>>
>> The execute-extended-commands have two undocumented optional arguments
>> (command-name and typed).  What are they used for?
>>
>> Anyway, following the fallback logic of `ido-find-file', I was able to
>> rebind `M-x' and save the content of the minibuffer with a non-standard
>> exit from `execute-extended-command'.  Maybe the ugly code below can
>> give ideas to someone more knowledgeable.
>
> Thanks -- I was wondering more about the situation where you've typed
>
> M-X foo|bar
>
> (| for point)
>
> and then hit `M-x' because you want to switch to the other mode.
> Ideally, `M-x' should do that, and also preserve the text the user has
> typed, and the cursor position.  I don't see an obvious simple way to do
> that... 

I've discovered that the initial-input argument of `completing-read` can
be written as (STRING . POSITION).  The attached patch makes use of it
and shows a simple implementation of my original wish.

However, the patch creates code duplication.  Also, I don't know how it
copes with recursive editing: maybe it's not a good idea to rebind M-x
when `enable-recursive-minibuffers' is t.  Finally, the docstring says
initial-input is deprecated.

I'm happy to work on the patch if you guide me to the right direction,
but this time I'd rather receive a fish instead of being taught how to
fish :)

[m-x.patch (#("text/x-diff", attachment)]

Message #20 received at 47215 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Felician Nemeth <felician.nemeth <at> gmail.com>
Cc: 47215 <at> debbugs.gnu.org
Subject: Re: bug#47215: 28.0.50; Let M-x switch between M-x and M-X
Date: Sun, 11 Apr 2021 19:36:24 +0200

Felician Nemeth <felician.nemeth <at> gmail.com> writes:

> I've discovered that the initial-input argument of `completing-read` can
> be written as (STRING . POSITION).  The attached patch makes use of it
> and shows a simple implementation of my original wish.

Nice; your patch works very smoothly -- using `M-x' to switch here feels
very natural.

> However, the patch creates code duplication.

I think that can be fixed by refactoring out most of the interactive
spec of `execute-extended-command-for-buffer' and then reusing it.

> Also, I don't know how it copes with recursive editing: maybe it's not
> a good idea to rebind M-x when `enable-recursive-minibuffers' is t.

A lot of people have `enable-recursive-minibuffers' bound, though, which
is an argument against using `M-x' as the keystroke to switch between
modes.

> Finally, the docstring says initial-input is deprecated.

I think this use case demonstrates that perhaps we should slightly
un-deprecate initial-input -- instead of deprecating it, we could
instead just discourage the usage.

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

Message #23 received at 47215 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Felician Nemeth
 <felician.nemeth <at> gmail.com>
Cc: "47215 <at> debbugs.gnu.org" <47215 <at> debbugs.gnu.org>
Subject: RE: [External] : bug#47215: 28.0.50; Let M-x switch between M-x and
 M-X
Date: Sun, 11 Apr 2021 18:29:05 +0000

> > Finally, the docstring says initial-input is deprecated.
> 
> I think this use case demonstrates that perhaps we should slightly
> un-deprecate initial-input -- instead of deprecating it, we could
> instead just discourage the usage.

It never should have been deprecated - quite unwise.
Arguments against deprecation went unheeded/ignored.
___

The Icicles doc for `completing-read' has always said:

 If INITIAL-INPUT is non-nil, insert it in the minibuffer initially,
 with point positioned at the end.  If it is (STRING . POSITION), the
 initial input is STRING, but point is placed at zero-indexed position
 POSITION in STRING.  (This is different from `read-from-minibuffer'
 and related functions, which use one-indexing for POSITION.)

 INITIAL-INPUT is considered deprecated by vanilla Emacs, but not by
 Icicles.  If INITIAL-INPUT is nil and DEF is non-nil, the user can use
 `next-history-element' to yank DEF into the minibuffer.
___

As for your `M-x' changes and the addition of `M-X':
they too aren't positive, IMO, but I'll leave it to
time and others for that to be realized.  (I already
mentioned better approaches in the "Smarter M-x"
thread.)

Message #26 received at 47215 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Felician Nemeth <felician.nemeth <at> gmail.com>
Cc: 47215 <at> debbugs.gnu.org
Subject: Re: bug#47215: 28.0.50; Let M-x switch between M-x and M-X
Date: Fri, 24 Jun 2022 20:18:01 +0200

Felician Nemeth <felician.nemeth <at> gmail.com> writes:

> I've discovered that the initial-input argument of `completing-read` can
> be written as (STRING . POSITION).  The attached patch makes use of it
> and shows a simple implementation of my original wish.
>
> However, the patch creates code duplication.  Also, I don't know how it
> copes with recursive editing: maybe it's not a good idea to rebind M-x
> when `enable-recursive-minibuffers' is t.  Finally, the docstring says
> initial-input is deprecated.

I've now reworked your patch (a lot 😀) to avoid the duplication and
moved the cycling command to 'M-X' to avoid disruption.  But perhaps a
different key might also make sense...

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

Message #31 received at 47215 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 47215 <at> debbugs.gnu.org, Felician Nemeth <felician.nemeth <at> gmail.com>
Subject: Re: bug#47215: 28.0.50; Let M-x switch between M-x and M-X
Date: Fri, 24 Jun 2022 21:55:07 +0300

>> I've discovered that the initial-input argument of `completing-read` can
>> be written as (STRING . POSITION).  The attached patch makes use of it
>> and shows a simple implementation of my original wish.
>>
>> However, the patch creates code duplication.  Also, I don't know how it
>> copes with recursive editing: maybe it's not a good idea to rebind M-x
>> when `enable-recursive-minibuffers' is t.  Finally, the docstring says
>> initial-input is deprecated.
>
> I've now reworked your patch (a lot 😀) to avoid the duplication and
> moved the cycling command to 'M-X' to avoid disruption.  But perhaps a
> different key might also make sense...

Are you sure nobody might want to see a list of minibuffer commands?
I don't use this, but can imagine someone typing `M-x M-X TAB' to list
all minibuffer commands:

  22 possible completions:
  abort-minibuffers
  abort-recursive-edit (C-])
  context-menu-open (<menu>)
  exit-minibuffer
  file-cache-minibuffer-complete
  isearch-backward (C-r)
  isearch-forward (C-s)
  minibuffer-beginning-of-buffer
  minibuffer-choose-completion
  minibuffer-complete
  minibuffer-complete-and-exit
  minibuffer-complete-word
  minibuffer-completion-help
  minibuffer-next-completion
  minibuffer-previous-completion
  next-history-element
  next-line-or-history-element
  next-matching-history-element
  previous-history-element
  previous-line-or-history-element
  previous-matching-history-element
  switch-to-completions

Or maybe there exists another way to do the same?

Message #34 received at 47215 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 47215 <at> debbugs.gnu.org, Felician Nemeth <felician.nemeth <at> gmail.com>
Subject: Re: bug#47215: 28.0.50; Let M-x switch between M-x and M-X
Date: Fri, 24 Jun 2022 21:00:07 +0200

Juri Linkov <juri <at> linkov.net> writes:

>> I've now reworked your patch (a lot 😀) to avoid the duplication and
>> moved the cycling command to 'M-X' to avoid disruption.  But perhaps a
>> different key might also make sense...
>
> Are you sure nobody might want to see a list of minibuffer commands?
> I don't use this, but can imagine someone typing `M-x M-X TAB' to list
> all minibuffer commands:

Suggestions for a different key binding welcome.

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.