Experimentally unbind M-o on the trunk

Experimentally unbind M-o on the trunk

[Gregory Heytings]

>
> That is, I propose that we remove the `M-o' binding on the trunk for one 
> month, and see how many (if any) complaints we get.
>

Perhaps replacing its binding with a message "The M-o key has been 
experimentally unbound, please M-x report-emacs-bug if you need it" would 
be even better?

Re: Experimentally unbind M-o on the trunk

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

>> That is, I propose that we remove the `M-o' binding on the trunk for
>> one month, and see how many (if any) complaints we get.
>>
>
> Perhaps replacing its binding with a message "The M-o key has been
> experimentally unbound, please M-x report-emacs-bug if you need it"
> would be even better?

Or perhaps refer to emacs-devel?  I'm not sure whether any choice here
would skew things one way or the other (i.e., what annoyance level do we
wish to get feedback on)?

Anyway, I had a look at that keymap for the first time ever, and:

Global Bindings Starting With M-o:
key             binding
---             -------

M-o ESC		Prefix Command
M-o b		facemenu-set-bold
M-o d		facemenu-set-default
M-o i		facemenu-set-italic
M-o l		facemenu-set-bold-italic
M-o o		facemenu-set-face
M-o u		facemenu-set-underline

M-o M-S		center-paragraph
M-o M-o		font-lock-fontify-block
M-o M-s		center-line

There's more commands there!  I had no idea -- I though all of `M-o' was
just a facemenu thing...

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

Re: Experimentally unbind M-o on the trunk

[Jean Louis]

* Lars Ingebrigtsen <larsi@gnus.org> [2021-02-09 18:25]:
> Gregory Heytings <gregory@heytings.org> writes:
> 
> >> That is, I propose that we remove the `M-o' binding on the trunk for
> >> one month, and see how many (if any) complaints we get.
> >>
> >
> > Perhaps replacing its binding with a message "The M-o key has been
> > experimentally unbound, please M-x report-emacs-bug if you need it"
> > would be even better?

No need for those annoyances.

Just unbind it, and bind it in enriched mode only. It is logical that
it belongs there.

Is there any other mode where face settings belong?

Jean

Re: Experimentally unbind M-o on the trunk

[Alfred M. Szmidt]

If M-o is to become unbound, how does one center a line or a
paragraph?  Those are on M-o M-s and M-o M-S respectively.

Re: Experimentally unbind M-o on the trunk

[Tassilo Horn]

Alfred M. Szmidt <ams@gnu.org> writes:

> If M-o is to become unbound, how does one center a line or a
> paragraph?  Those are on M-o M-s and M-o M-S respectively.

Using M-x, I guess, or bind it to a key of your liking if that's a
command important to your workflow.  FWIW, in my 15 years of emacs
usage, I've never had the need to center a pile of text in a text file.
(Here I've bound M-o to some home-grown `other-buffer' variant which I
use dozens of times daily.)

Bye,
Tassilo

Re: Experimentally unbind M-o on the trunk

[Jean Louis]

* Alfred M. Szmidt <ams@gnu.org> [2021-02-10 11:45]:
> If M-o is to become unbound, how does one center a line or a
> paragraph?  Those are on M-o M-s and M-o M-S respectively.

We have M-o as prefix and M-l to downcase the word. Maybe M-l could be
made as a new prefix and then:

M-l M-s could center the line

M-l l could downcase the word

then there is plethora of other options for M-l as prefix.

Jean

Re: Experimentally unbind M-o on the trunk

[Alfred M. Szmidt]

Sorry, I atleast have a hard time taking these suggestion to remap
long standing keybindings randomly seriously, likewise suggestions
that users should just resort to M-x or binding them themselves.

Might as well unbind all they keys and have a wizard query the user
the first time they start Emacs about what each interactive function
should be bound too.  

Re: Experimentally unbind M-o on the trunk

[Eli Zaretskii]

> From: "Alfred M. Szmidt" <ams@gnu.org>
> Date: Wed, 10 Feb 2021 10:12:20 -0500
> Cc: gregory@heytings.org, larsi@gnus.org, emacs-devel@gnu.org
> 
> Sorry, I atleast have a hard time taking these suggestion to remap
> long standing keybindings randomly seriously, likewise suggestions
> that users should just resort to M-x or binding them themselves.

Can you explain why you are so worried about Emacs changing the
default key bindings?  Given that it takes one line in your .emacs to
restore any binding you care for, why argue so much about the
defaults?

This question also goes to everyone else in this long dispute who
wants their precious key bindings preserved: why is such a long
discussion needed when it is so easy to restore, in your init file, a
binding you want preserved?

Re: Experimentally unbind M-o on the trunk

[Alfred M. Szmidt]

   > Sorry, I atleast have a hard time taking these suggestion to remap
   > long standing keybindings randomly seriously, likewise suggestions
   > that users should just resort to M-x or binding them themselves.

   Can you explain why you are so worried about Emacs changing the
   default key bindings?  Given that it takes one line in your .emacs to
   restore any binding you care for, why argue so much about the
   defaults?

Those who do wish to change the current behaviour of M-o (for example)
could also just rebind it in their .emacs file -- as you say, it is
only one line.  So why is that not also a solution here?

Why is it always users who have to explain themselves and never the
developers who change functionality that they don't even seem to use?

Re: Experimentally unbind M-o on the trunk

[Eli Zaretskii]

> From: "Alfred M. Szmidt" <ams@gnu.org>
> Cc: bugs@gnu.support, gregory@heytings.org, larsi@gnus.org,
> 	emacs-devel@gnu.org
> Date: Wed, 10 Feb 2021 11:47:03 -0500
> 
>    > Sorry, I atleast have a hard time taking these suggestion to remap
>    > long standing keybindings randomly seriously, likewise suggestions
>    > that users should just resort to M-x or binding them themselves.
> 
>    Can you explain why you are so worried about Emacs changing the
>    default key bindings?  Given that it takes one line in your .emacs to
>    restore any binding you care for, why argue so much about the
>    defaults?
> 
> Those who do wish to change the current behaviour of M-o (for example)
> could also just rebind it in their .emacs file -- as you say, it is
> only one line.  So why is that not also a solution here?

Because what is being discussed is a change that would enable us
_as_a_project_ to make some progress in the future.  We aren't
discussing someone's private wish to change keybindings because they
fancy a change for their own personal needs.  Wheres you are worried
about how _you_ will be able to invoke some commands when those
keybindings are changed.

> Why is it always users who have to explain themselves and never the
> developers who change functionality that they don't even seem to use?

How do you know I'm not using it?  As a matter of fact, several of the
keys that people here suggested to change are in my daily routine.  I
didn't even mention that because I see no reason to bother anyone with
my private bindings: I can always have them, no matter what Emacs does
by default.  That's why I asked the question: I cannot understand the
intensity of objections based on what this or that person are using
frequently.  This is Emacs: no default keybinding can ever lock you up
or out.

Re: Experimentally unbind M-o on the trunk

[Matt Armstrong]

"Alfred M. Szmidt" <ams@gnu.org> writes:

> Why is it always users who have to explain themselves and never the
> developers who change functionality that they don't even seem to use?

In abstract, there are many reasons for this classic pattern of
developer<->user interaction:

 - The developers are trying to make the software better overall, and
   this often requires change.

 - Sometimes there are no remaining active developers on a project that
   actually use a particular feature.

 - The developers are addressing the requests of *other* users, and it
   is not possible to make everybody perfectly happy.

 - It is impossible to read minds, so developers must ask users what
   they need to do and why.

 - Users often don't understand the software as deeply as the developer,
   so the developers ask for what the user wants to actually do, but not
   necessarily the way the user wants the solution expressed.

Re: Experimentally unbind M-o on the trunk

[Alan Mackenzie]

Hello, Eli.

On Wed, Feb 10, 2021 at 17:45:55 +0200, Eli Zaretskii wrote:
> > From: "Alfred M. Szmidt" <ams@gnu.org>
> > Date: Wed, 10 Feb 2021 10:12:20 -0500
> > Cc: gregory@heytings.org, larsi@gnus.org, emacs-devel@gnu.org

> > Sorry, I atleast have a hard time taking these suggestion to remap
> > long standing keybindings randomly seriously, likewise suggestions
> > that users should just resort to M-x or binding them themselves.

> Can you explain why you are so worried about Emacs changing the
> default key bindings?  Given that it takes one line in your .emacs to
> restore any binding you care for, why argue so much about the
> defaults?

> This question also goes to everyone else in this long dispute who
> wants their precious key bindings preserved: why is such a long
> discussion needed when it is so easy to restore, in your init file, a
> binding you want preserved?

Because we care about other people, in particular newbies.  The bindings
people are suggesting suppressing are all basic editing commands.  If
their bindings are taken from them, then they become inaccessible, und
unknowable, to all but a few old hands.  Newbies should also be able to
discover and use back-to-indentation, open-line, and so forth.

Another reason is that if somebody rebinds a much used basic command back
to its traditional key sequence, that blocks out all the potentially
useful commands which other people now feel free to bind to that key
sequence.

I also don't see that the case has been made for freeing up vast numbers
of key bindings for external packages.  If I've understood correctly,
these key sequences are wanted for things like
`switch-on-foo-minor-mode', where the reserved minor mode bindings are
not yet available.  It seems to me that these commands are precisely what
C-c <letter> key sequences are intended for.  Each user will have her own
set of minor modes she uses, that set will typically be small, so setting
her own set of bindings is reasonable to expect.  Beyond the basic
facilities, we shouldn't be trying to set up a universal set of bindings
for everybody.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Experimentally unbind M-o on the trunk

[Eli Zaretskii]

> Date: Wed, 10 Feb 2021 16:56:44 +0000
> Cc: "Alfred M. Szmidt" <ams@gnu.org>, gregory@heytings.org, larsi@gnus.org,
>   bugs@gnu.support, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > This question also goes to everyone else in this long dispute who
> > wants their precious key bindings preserved: why is such a long
> > discussion needed when it is so easy to restore, in your init file, a
> > binding you want preserved?
> 
> Because we care about other people, in particular newbies.

I doubt it.  Because the keybindings which are being discussed as
candidates for usurpation are those most newbies don't know about and
many never will.

> The bindings people are suggesting suppressing are all basic editing
> commands.

I'd say that's the exaggeration of the year.  (Although the year has
just started, so who knows what better exaggerations are yet in our
stars?)

> Another reason is that if somebody rebinds a much used basic command back
> to its traditional key sequence, that blocks out all the potentially
> useful commands which other people now feel free to bind to that key
> sequence.

No new bindings were suggested, mind you.  So I don't understand what
are those potentially useful commands you are already lamenting.
Should we perhaps wait at least until we hear what they are?

> I also don't see that the case has been made for freeing up vast numbers
> of key bindings for external packages.  If I've understood correctly,
> these key sequences are wanted for things like
> `switch-on-foo-minor-mode', where the reserved minor mode bindings are
> not yet available.

No, that's not the issue.  The main issue is the case of packages like
Magit which'd like to be able to bind keys without conflicting with
the core.

Re: Experimentally unbind M-o on the trunk

[andrés ramírez]

Hi. Guys.

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

    Eli> I doubt it.  Because the keybindings which are being discussed as candidates for usurpation
    Eli> are those most newbies don't know about and many never will.

Indeed. I have never will.

I spent 99% of my emacs time on the tty. I have never used any of the
commands on the M-o set. I have just tried:
--8<---------------cut here---------------start------------->8---
1 center-line
2 center paragraph
--8<---------------cut here---------------end--------------->8---

On my opinion those commands seem to be useful for quotation or for
writing prose (I could be wrong).
But on my personal case when I wan to quote something I use:
--8<---------------cut here---------------start------------->8---
1 mark the region
2 C-u shell-command-on-region and feeding at the prompt with "boxes -d boxquote -i box"
--8<---------------cut here---------------end--------------->8---

see the result below (on this particular case fill-paragraph was applied
before invoking shell-command-on-region):
,---- [  ]
| Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod
| tempor incididunt ut labore et dolore magna aliqua. Ut enimad minim
| veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea
| commodo consequat. Duis aute irure dolor in reprehenderit in voluptate
| velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint
| occaecat cupidatat non proident, sunt in culpa qui officia deserunt
| mollit anim id est laborum.
`----

That's the reason I have never used M-o all this long time. But YMMV.

On the contrary. What I have used when checking email from my phone
(using the phone as a mobile terminal 800x480) and for very long subjects is the
function "horizontal-recenter-derived" (which was based on
gnus-horizontal-recenter) .

I have an alias:
(defalias 'hr 'horizontal-recenter-derived)

--8<---------------cut here---------------start------------->8---
(defun horizontal-recenter-derived ()
  "Recenter the current buffer horizontally. based on gnus-horizontal-recenter"
  (interactive)
  (if (< (current-column) (/ (window-width) 2))
      (set-window-hscroll (get-buffer-window (current-buffer) t) 0)
    (let* ((orig (point))
	   (end (window-end (get-buffer-window (current-buffer) t)))
	   (max 0))
      (when end
	;; Find the longest line currently displayed in the window.
	(goto-char (window-start))
	(while (and (not (eobp))
		    (< (point) end))
	  (end-of-line)
	  (setq max (max max (current-column)))
	  (forward-line 1))
	(goto-char orig)
	;; Scroll horizontally to center (sort of) the point.
	(if (> max (window-width))
	    (set-window-hscroll
	     (get-buffer-window (current-buffer) t)
	     (min (- (current-column) (/ (window-width) 3))
		  (+ 2 (- max (window-width)))))
	  (set-window-hscroll (get-buffer-window (current-buffer) t) 0))
	max))))
        --8<---------------cut here---------------end--------------->8---

Hope it helps. Best Regards
ps: probably we the tty-frame-guys have a lot of bindings that just apply for
the X-frames that we never use.

RE: [External] : Re: Experimentally unbind M-o on the trunk

[Drew Adams]

> The bindings people are suggesting suppressing are all
> basic editing commands.  If their bindings are taken
> from them, then they become inaccessible, und
> unknowable, to all but a few old hands.  Newbies should
> also be able to discover and use back-to-indentation,
> open-line, and so forth.

Menus.  Apropos.

(This is not a comment about any specific key
proposals.  It's just to say that commands are
discoverable.  And, yes, discoverability has
room for improvement.)

And nothing prevents a 3rd-party library or
even Emacs itself, from providing one or more
commands that set up a given set of bindings.
Au choix.  That's different from binding those
keys by default.  And such key-set choices
could be available by commands on the Help menu.

There are other possibilities.

All of that said, I don't think we should willy
nilly remove default key bindings.  Discussion
and reasoned argument & decision are called for.
The point is that some keys might well be
candidates for freeing up.

I suggested also possible refactoring: using
prefix keys more, grouping related commands on
a common prefix.

And I suggested making commands repeatable that
are now non-repeatable but are currently bound to
repeatable keys (e.g. `C-a').  [This doesn't, in
general, free up keys, but it might in some cases,
e.g. having a single repeatable key where you can
reverse the direction on the fly (including at the
outset).]

> Another reason is that if somebody rebinds a much
> used basic command back to its traditional key
> sequence, that blocks out all the potentially
> useful commands which other people now feel free
> to bind to that key sequence.

I don't see that as a real problem.  That's just
deciding to rebind a key that's already bound to
something else (at least in some context, e.g.
some mode, after activating some set of keys, or
loading some library).

Caveat emptor.  Users can bind and unbind any
keys they like.  That's already the case.

> I also don't see that the case has been made
> for freeing up vast numbers of key bindings
> for external packages.

I don't think anyone has suggested that.
Certainly not vast numbers.

My own suggestion was to reserve, for 3rd-party
code, at least for a while - a moratorium,
those keys that currently do NOT have default
key bindings.  And there certainly are not vast
numbers of those.

> If I've understood correctly, these key
> sequences are wanted for things like
> `switch-on-foo-minor-mode', where the reserved
> minor mode bindings are not yet available.

No, I don't think so.  I don't think anyone
proposed default-binding such switch-keys-on
commands OR the bindings that such a command
would make - whether minor-mode or otherwise.

And I don't think anyone proposed reserving
such commands.

But maybe I've misunderstood the point you make, there.

> Each user will have her own set of minor modes
> she uses, that set will typically be small, so
> setting her own set of bindings is reasonable
> to expect.  Beyond the basic facilities, we
> shouldn't be trying to set up a universal set
> of bindings for everybody.

100% agreement about that last point.  (I
might well have misunderstood some of your
other points.)

Re: Experimentally unbind M-o on the trunk

[Jean Louis]

* Alan Mackenzie <acm@muc.de> [2021-02-10 20:05]:
> Because we care about other people, in particular newbies.  The bindings
> people are suggesting suppressing are all basic editing commands.  If
> their bindings are taken from them, then they become inaccessible, und
> unknowable, to all but a few old hands.  Newbies should also be able to
> discover and use back-to-indentation, open-line, and so forth.

It is good to take care of newbies in Emacs.

Yet if I am new I would not mind what somebody changed before me as
that I would not know so it would not matter.

Concerns with changs of key bindings impact those people who use
keyboard as extension of human body. That is why key binding is
sensitive subject rather for non-newbies.

The discussion developed as no cyborg likes surgical-like
interventions in their neural connections.

Re: Experimentally unbind M-o on the trunk

[Matt Armstrong]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Alfred M. Szmidt" <ams@gnu.org>
>> Date: Wed, 10 Feb 2021 10:12:20 -0500
>> Cc: gregory@heytings.org, larsi@gnus.org, emacs-devel@gnu.org
>> 
>> Sorry, I atleast have a hard time taking these suggestion to remap
>> long standing keybindings randomly seriously, likewise suggestions
>> that users should just resort to M-x or binding them themselves.
>
> Can you explain why you are so worried about Emacs changing the
> default key bindings?  Given that it takes one line in your .emacs to
> restore any binding you care for, why argue so much about the
> defaults?
>
> This question also goes to everyone else in this long dispute who
> wants their precious key bindings preserved: why is such a long
> discussion needed when it is so easy to restore, in your init file, a
> binding you want preserved?

I'd even take it up another level. Why are we satisfied with Emacs'
current approach to exposing command based functionality to users? What
we've got with Emacs today is a key binding resource exhaustion problem.
But is moving bindings around the only way to address the problem?

What if having a key binding was just one possible way to make a command
easy and convenient to find and invoke. What if there were other equally
good ways, and we all thought it would be strange to bind a precious key
to a command if it were rarely used in practice?

Case in point: if a command isn't bound to a key it doesn't show up in
help, so there is this pressure to bind everything that could possibly
be useful to some person some day to some key. What if instead help
showed all the interactive commands provided by the mode? What if M-x
were smarter about highlighting mode specific commands?

Perhaps exploring these kinds of ideas would be useful.

Re: Experimentally unbind M-o on the trunk

[Lars Ingebrigtsen]

Matt Armstrong <matt@rfc20.org> writes:

> What if instead help showed all the interactive commands provided by
> the mode? What if M-x were smarter about highlighting mode specific
> commands?

It's been discussed before -- somebody just has to implement one of the
various possibilities here.  The problem is that commands are only tied
very loosely to modes:

(defun foo-thing ()
  (interactive)
  ...)

will make `M-x fTAB' show `foo-thing' even if it's useless outside of
all other modes than `foo-mode'.  Conversely, `C-h m' in `foo-mode'
won't, as you mention, list `foo-thing' unless there's a binding for it.

My suggestion is to introduce a new form:

(defun foo-thing ()
  (command foo-mode)
  ...)

This would be just like `interactive', but will do the right thing in
`M-x fTAB' and `C-h m' in modes derived from `foo-mode'.  (It could also
be a list of mode, of course, but that'd be more rare, is my guess.)

A

  (declare (mode foo-mode))

form would also work, but it's a bit more verbose and noisy.

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

Smarter M-x that filters on major-mode

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Matt Armstrong <matt@rfc20.org> writes:
>
>> What if instead help showed all the interactive commands provided by
>> the mode? What if M-x were smarter about highlighting mode specific
>> commands?
>
> It's been discussed before -- somebody just has to implement one of the
> various possibilities here.  The problem is that commands are only tied
> very loosely to modes:
>
> (defun foo-thing ()
>   (interactive)
>   ...)
>
> will make `M-x fTAB' show `foo-thing' even if it's useless outside of
> all other modes than `foo-mode'.  Conversely, `C-h m' in `foo-mode'
> won't, as you mention, list `foo-thing' unless there's a binding for it.
>
> My suggestion is to introduce a new form:
>
> (defun foo-thing ()
>   (command foo-mode)
>   ...)
>
> This would be just like `interactive', but will do the right thing in
> `M-x fTAB' and `C-h m' in modes derived from `foo-mode'.  (It could also
> be a list of mode, of course, but that'd be more rare, is my guess.)

It would indeed be very useful to provide a mechanism to exclude
commands from M-x that are useless outside of their major mode.

I've had a related idea to make `M-X' (a.k.a. `M-S-x') run a version of
`M-x' that *includes* only commands that are specifically relevant to
the current major mode.  This would be used when I specifically want to
do something in my major mode, as opposed to looking at the gazillion
different entry points for things like calendar, gnus, or tetris.

I only just now discovered that my completion framework (ivy) has had
the exact same idea for M-S-x.  It filters all commands according to
some heuristics, seemingly only showing commands beginning with whatever
package prefix your mode is using.  It is not perfect, as it seems to
show commands not relevant to the current major mode, if they share the
prefix.  For example, when replying to emails I'm in
notmuch-message-mode and don't need to see commands used for navigating
my list of emails (notmuch-search-mode).

Anyways, these are just my thoughts.  I would encourage anyone to start
working on this.  The blacklisting for normal M-x discussed by Lars
above seems like a good starting point.

Re: Smarter M-x that filters on major-mode

[Stefan Monnier]

> It would indeed be very useful to provide a mechanism to exclude
> commands from M-x that are useless outside of their major mode.

Similarly, you may mark some commands so they're just never available to
`M-x`.  This could apply to some major and minor modes which are only
meant to be used "internally", or to commands which only work when
provided with a mouse event, or ...

That should be a very easy change to `execute-extended-command`.

> I've had a related idea to make `M-X' (a.k.a. `M-S-x') run a version of
> `M-x' that *includes* only commands that are specifically relevant to
> the current major mode.  This would be used when I specifically want to
> do something in my major mode, as opposed to looking at the gazillion
> different entry points for things like calendar, gnus, or tetris.

Yes, there's clearly a lot of room for improvement.
I moved that function to ELisp to make it easier to hack on it, and I'm
still hopeful that Someone™ will make use of it.


        Stefan

Re: Smarter M-x that filters on major-mode

[Yuan Fu]

> On Feb 10, 2021, at 10:44 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
>> It would indeed be very useful to provide a mechanism to exclude
>> commands from M-x that are useless outside of their major mode.
> 
> Similarly, you may mark some commands so they're just never available to
> `M-x`.  This could apply to some major and minor modes which are only
> meant to be used "internally", or to commands which only work when
> provided with a mouse event, or ...
> 
> That should be a very easy change to `execute-extended-command`.
> 
>> I've had a related idea to make `M-X' (a.k.a. `M-S-x') run a version of
>> `M-x' that *includes* only commands that are specifically relevant to
>> the current major mode.  This would be used when I specifically want to
>> do something in my major mode, as opposed to looking at the gazillion
>> different entry points for things like calendar, gnus, or tetris.
> 
> Yes, there's clearly a lot of room for improvement.
> I moved that function to ELisp to make it easier to hack on it, and I'm
> still hopeful that Someone™ will make use of it.
> 
> 
>        Stefan
> 
> 

Another idea that I once had is that to make a special M-x such that it only contains some selected commands, and as soon as there is only one candidate left, it is immediately executed (without pressing RET). This is somewhat between a keybinding and normal M-x.

Yuan

RE: [External] : Re: Smarter M-x that filters on major-mode

[Drew Adams]

> Another idea that I once had is that to make a special M-x such that it
> only contains some selected commands, and as soon as there is only one
> candidate left, it is immediately executed (without pressing RET). This
> is somewhat between a keybinding and normal M-x.

It's trivial to define a command like `M-x' that
limits the available command names using a predicate.
___

Option `icicle-top-level-when-sole-completion-flag'
does what you suggest for a sole matching candidate:

 Non-nil means to return to top level if only one
 matching completion. The sole completion is accepted.

Option `icicle-top-level-when-sole-completion-delay'
is the number of seconds to wait before doing that.
Editing the completion (typing or deleting a char)
before the delay expires prevents its automatic
acceptance.

RE: [External] : Re: Smarter M-x that filters on major-mode

[Drew Adams]

> > It would indeed be very useful to provide a
> > mechanism to exclude commands from M-x that
> > are useless outside of their major mode.

Commands that are useless outside of a particular
mode/package/etc. typically have some part
of their name that indicates that mode/pkg/etc.

A simple way of filtering out such names is more
useful than trying to otherwise guess association
of a mode/pkg/etc. with command names.  You can
often recognize such contexts by the command names.

Icicles lets you (1) match only names you want
to exclude, then (2) use `C-~' to remove them as
candidates.  (Repeat, matching different name
parts, to narrow further.)

> Similarly, you may mark some commands so they're
> just never available to `M-x`.  This could apply
> to some major and minor modes which are only
> meant to be used "internally", or to commands
> which only work when provided with a mouse event, or ...
> 
> That should be a very easy change to
> `execute-extended-command`.

No, that shouldn't happen by default, at least.
Not helpful and not needed.

There's a naming convention for "internal" -
simple to avoid.

Also, even if the main purpose of `M-x' is to
invoke a command, it provides sets of command
names that match your input at any time, and
some completion "systems" let you do more with
a set of matches than just reduce it to one
command and invoke that.

E.g., you can get the doc for particular matching
candidates, on the fly.  If `M-x' automatically
excludes some categories of command then those
commands are excluded also for such ancillary
purposes.

> > I've had a related idea to make `M-X' (a.k.a.
> > `M-S-x') run a version of `M-x' that *includes*
> > only commands that are specifically relevant to
> > the current major mode.

See above, about names being the way to tell
whether a command is relevant to a given mode.

Otherwise, you need some filter function that
knows/judges such relevance - and that might
itself be specific to the particular mode.

> > This would be used when I specifically want
> > to do something in my major mode, as opposed
> > to looking at the gazillion different entry
> > points for things like calendar, gnus, or tetris.

YAGNI.  Command names should themselves indicate
this kind of thing.  What you need is a good way
to filter command names.

> Yes, there's clearly a lot of room for improvement.
> I moved that function to ELisp to make it easier
> to hack on it, and I'm still hopeful that Someone™
> will make use of it.

I don't agree that `M-x' should try to be "smart"
in these ways - not without some user control (on
the fly, not just via user option).

Just which commands a particular user, at a
particular time, for whatever reason, wants to be
able to invoke with `M-x' is not something that's
accurately predefined.

Instead, it's smarter to leave it up to the user,
but provide ways to filter on the fly. E.g., show
me only commands of a particular kind (e.g. for
the current mode or whatever).
___

As one point of reference, in Icicles, during
`M-x' completion, you can use `M-i $' to toggle
whether candidates should be limited to commands
that are currently bound to keys.

That's the only on-the-fly filtering I've offered
for `M-x', but other filtering could be provided.
(E.g., exclude mouse-invoked commands, as you
mentioned.)  What's important is not to do any
such filtering in any hardcoded kind of way.  Let
users do it when they want.

`M-x' is a command that provides command-name
completion.  Yes, commands can be associated with
buffer modes, packages, keys, etc.  And such
associations could be used for command-name
filtering.

But the associations need to be defined (known)
somehow (explicitly or implicitly), in order to
be exploited.

Again, the command names themselves already
provide such associations to some extent.  Supple
interactive narrowing according just to name
matching goes a long way toward realizing what
you've suggested.

___

But by way of example wrt providing other,
non-name, filtering on the fly:

For commands that prompt for a _buffer_ name,
Icicles lets you use a prefix arg to limit
the buffer-name candidates to complete against,
in various ways:

* Plain ‘C-u’: only buffers whose mode is derived
  from the current buffer's mode are candidates

* ‘C-u C-u’ (double): only displayed buffers

* ‘C-u C-u C-u’ (triple): only buffers not displayed

* ‘-’ (plain ‘-’): only modified (unsaved) buffers

* = 0: buffers with the same mode as current buffer

* > 0: buffers visiting files

* < 0 (and not plain ‘-’): buffers associated with
      the selected frame

(Those are the default behaviors, but you can
change them with a user option.)
___

Besides those buffer-command prefix-arg behaviors,
which you need to decide on before you invoke the
command, you can also filter buffer candidates on
the fly during completion:

* ‘C-x F’: toggle whether to include cached files
  as candidates

* ‘C-x R’: toggle whether to include recently
  accessed files as candidates

* ‘C-x m’: only bookmarked buffers

* ‘C-x C-m -’: remove buffers whose major mode is
  derived from a given mode (for which you're
  prompted).  Repeat to remove more modes.

* ‘C-x C-m +’: (opposite of ‘C-x C-m -’.) keep
  only candidates with a derived major mode

* ‘C-x M -’: same as ‘C-x C-m -’, but exclude
  ancestor modes

* ‘C-x M +’: same as `C-x C-m +’, but exclude
  ancestor modes

* ‘C-x * -’: remove modified buffers

* ‘C-x * +’: keep only modified buffers

* ‘C-x i -’: remove indirect buffers

* ‘C-x i +’: keep only indirect buffers

* ‘C-x v -’: remove visible (displayed) buffers

* ‘C-x v +’: keep only visible (displayed) buffers
___

Similar functionality is available for commands
that use file-name completion.

https://www.emacswiki.org/emacs/Icicles_-_Buffer-Name_Input

Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Similarly, you may mark some commands so they're just never available to
> `M-x`.  This could apply to some major and minor modes which are only
> meant to be used "internally", or to commands which only work when
> provided with a mouse event, or ...

Yup -- and from menus.  We have some commands that don't make sense
outside of a menu context, and have had bug reports about them because
people have discovered them via `M-x TAB' and then complained when they
don't work.

What would the syntax for marking these commands be?  Perhaps a
`declare' form would be the best thing here?  These commands are a lot
rarer than normal mode-specific commands (by several orders of
magnitude, I think), so if we go with

  (command foo-mode "p")

for the normal case, then perhaps it doesn't make sense to clutter up
that simple syntax with something for this thing.

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

Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

I started tinkering with this -- I've now got

(defun foo (arg)
  (command foo-mode "p"))

working in the sense that it doesn't do anything.  :-)  That is, that's
now 100% equivalent to `interactive'.

But I'm wondering where to stash the mode.  Well, for uncompiled
functions, that's kinda obvious, but byte-compiled functions stash this
in the sixth slot in the bytecode object.

Would extending the object (and stash it in the seventh slot) make
sense?  It'd make the bytecode massively incompatible with previous
versions, but it generally is pretty incompatible.

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

Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Would extending the object (and stash it in the seventh slot) make
> sense?  It'd make the bytecode massively incompatible with previous
> versions, but it generally is pretty incompatible.

That was a rabbit hole I don't really want to go down --
`make-byte-code' has a

(make-byte-code ARGLIST BYTE-CODE CONSTANTS DEPTH &optional DOCSTRING
INTERACTIVE-SPEC &rest ELEMENTS)

signature, which makes it non-trivial to extend with another parameter,
especially with how it's called.

So instead I made INTERACTIVE-SPEC be a cons cell, where the first
element is the spec itself and the second is the modes list.

With that, I've now got a functioning Emacs, and I'm using
gnus-summary-mode as the test subject: `M-x gnusTAB' now gives me 200
fewer things to read through when issues in the Gnus group buffer.  :-)

I guess I could take this to a branch...  but...  the changes seem kinda
straighforward, so I'm not sure that's worth it, and by pushing directly
to the trunk, people can get started with
`C-M-% ^  (interactive RET   (command the-correct-mode RET'-ing as they
want, and then see `M-x TAB' grow progressively shorter each time...

Two things: 1) I'm slightly worried that this change will affect the native
branch (so I've added Andrea to the CCs), and 2) I'm not sure whether to
use `derived-mode-p' or not in the `M-x' default predicate:

(defun command-for-mode (symbol)
  "Say whether SYMBOL should be offered as a completion.
This is true if it's a command and the command modes match the current
major mode."
  (and (commandp symbol)
       (or (null (command-modes symbol))
           (member major-mode (command-modes symbol)))))

`derived-mode-p' would be more accurate, but is also kind of slow?
Hm...  pre-compute stuff?  Cache?  Hm...

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

Re: Smarter M-x that filters on major-mode

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 11 Feb 2021 12:00:20 +0100
> Cc: emacs-devel@gnu.org
> 
> I started tinkering with this -- I've now got
> 
> (defun foo (arg)
>   (command foo-mode "p"))
> 
> working in the sense that it doesn't do anything.  :-)  That is, that's
> now 100% equivalent to `interactive'.
> 
> But I'm wondering where to stash the mode.  Well, for uncompiled
> functions, that's kinda obvious, but byte-compiled functions stash this
> in the sixth slot in the bytecode object.

Would it make sense to store that info in the plist of the function's
symbol?

Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Would it make sense to store that info in the plist of the function's
> symbol?

That was my initial idea, but it would lead to this stuff in the .elc
files:

(byte-code "......." [function-put foo-command command-modes '(foo-mode)] 4)

And since more than 90% of the commands will eventually get this sort of
annotation (I didn't actually count), that seemed kinda inefficient.

Stashing it in the interactive spec slot of the byte code leads to a lot
less .elc code...

The byte-code format gets slightly incompatible, though, so that's the
drawback.  But we don't usually worry too much about that, so...

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

Re: Smarter M-x that filters on major-mode

[Stefan Monnier]

> And since more than 90% of the commands will eventually get this sort of
> annotation (I didn't actually count), that seemed kinda inefficient.

That's indeed possible, but I'm not sure it will be the case (it seems
like a lot of work to get there, unless we can come up with some way to
automatically infer most of those predicates somehow, or to specify
them "globally" by grouping in the source code commands that share the
same predicate, or something).

But since you're touching the `interactive-form` part, it's a good
opportunity to mention that some commands would benefit from being able
to specify not just how to build the arguments for interactive use but
also what to do with the result (such as how to display it).

So there's a case to be made that we should allow the `interactive-form`
to specify a generic wrapper: a function that takes a single argument
(the function to be called) and is then in charge of building the
arglist, calling the function, and do what it wants with the result.

I'm not sure how best to integrate this with the kind of predicates we're
discussing here...


        Stefan

Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> And since more than 90% of the commands will eventually get this sort of
>> annotation (I didn't actually count), that seemed kinda inefficient.
>
> That's indeed possible, but I'm not sure it will be the case (it seems
> like a lot of work to get there, unless we can come up with some way to
> automatically infer most of those predicates somehow, or to specify
> them "globally" by grouping in the source code commands that share the
> same predicate, or something).

I don't think anything automatic is possible -- in that case, automatic
filters would be fine.  I've gone over a bunch of Gnus files (and those
are as difficult as it gets, because there's a lot of Gnus modes), and
it's tedious, but not difficult.  And since this leads to immediate user
experience improvements, I'm hopeful that people will actually start
doing the markup.

> But since you're touching the `interactive-form` part, it's a good
> opportunity to mention that some commands would benefit from being able
> to specify not just how to build the arguments for interactive use but
> also what to do with the result (such as how to display it).
>
> So there's a case to be made that we should allow the `interactive-form`
> to specify a generic wrapper: a function that takes a single argument
> (the function to be called) and is then in charge of building the
> arglist, calling the function, and do what it wants with the result.

I'm not quite sure I follow you here...  the `interactive-form' function
just returns the interactive spec, and I've not changed that at all.
(I've changed how the function works internally, because the storage now
looks slightly different, but...)

> I'm not sure how best to integrate this with the kind of predicates we're
> discussing here...

I've also added a `read-extended-command-predicate' that users can tweak
to determine what they want to have included when they `M-x TAB', but
the default is "all commands, but not the ones that are tagged as
belonging to other modes than the current major mode".

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

Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I'm not quite sure I follow you here...  the `interactive-form' function
> just returns the interactive spec, and I've not changed that at all.
> (I've changed how the function works internally, because the storage now
> looks slightly different, but...)

(And this is now on the scratch/command branch, if you want to have a
peek.)

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

Re: Smarter M-x that filters on major-mode

[Óscar Fuentes]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I've also added a `read-extended-command-predicate' that users can tweak
> to determine what they want to have included when they `M-x TAB', but
> the default is "all commands, but not the ones that are tagged as
> belonging to other modes than the current major mode".

Please note that it is important to be able to filter out commands that
belong to inactive minor modes. Plus we have to take into account
derived modes.

Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Please note that it is important to be able to filter out commands that
> belong to inactive minor modes.

That would be nice, but I'm not quite sure what that'd look like.

> Plus we have to take into account derived modes.

That's taken into account.  I'm not sure whether the current
implementation is fast enough, but I guess we'll see as we get more and
more annotated commands.

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

Re: Smarter M-x that filters on major-mode

[Óscar Fuentes]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> Please note that it is important to be able to filter out commands that
>> belong to inactive minor modes.
>
> That would be nice, but I'm not quite sure what that'd look like.

When M-x is invoked, is it possible to build a list of active modes
(major and minor, including parent modes) and, for each command, check
if its declared mode in on that list?

>> Plus we have to take into account derived modes.
>
> That's taken into account.  I'm not sure whether the current
> implementation is fast enough, but I guess we'll see as we get more and
> more annotated commands.

Thank you.

Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

Óscar Fuentes <ofv@wanadoo.es> writes:

>>> Please note that it is important to be able to filter out commands that
>>> belong to inactive minor modes.
>>
>> That would be nice, but I'm not quite sure what that'd look like.
>
> When M-x is invoked, is it possible to build a list of active modes
> (major and minor, including parent modes) and, for each command, check
> if its declared mode in on that list?

Yes, I was thinking more about what it'd look like as markup. 

We now have

(defun foo2 (arg)
  (command c-mode "p")
  (message "%s 2" arg))

to mark a function as belonging in c-mode.  What would minor-mode markup
look like?  A `declare' form?  Or just put the minor mode name into the
major-mode slot?  Given a symbol, is there a quick way to determine
whether that's a major or a minor mode?

I'm just asking; I haven't actually thought about minor modes at all.  :-)

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

Re: Smarter M-x that filters on major-mode

[Jose A. Ortega Ruiz]

On Thu, Feb 11 2021, Lars Ingebrigtsen wrote:

> We now have
>
> (defun foo2 (arg)
>   (command c-mode "p")
>   (message "%s 2" arg))

You probably have already thought of it, and discarded it for a good
reason, but why not, instead of a new `command' form, just add a new
(optional) argument to `interactive'?

  (defun foo2 (arg)
   (interactive "p" c-mode)
   (message "%s 2" arg))

it could even accept more than one mode

  (defun foo2 (arg)
   (interactive "p" text-mode json-mode)
   (message "%s 2" arg))

and for users it'd be arguably easier to recognize what it means at a
glance (since we all know about `interactive').

i could even imagine a top level declaration like, say,
`(default-interactive-mode my-mode)' which would supply to all commands
in that .el that value for the optional arg (to easyly update packages
that define a mode and mostly commands just for it, something i at least
do very often), adding just a line to the file.  or it could be a local
variable and work a bit like lexical-binding...

;;; my-mode.el --- a very useful mode -*- interactive-mode: my-mode -*-

Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

"Jose A. Ortega Ruiz" <jao@gnu.org> writes:

> You probably have already thought of it, and discarded it for a good
> reason, but why not, instead of a new `command' form, just add a new
> (optional) argument to `interactive'?
>
>   (defun foo2 (arg)
>    (interactive "p" c-mode)
>    (message "%s 2" arg))

The argument to `interactive' is optional, so it'd be

  (defun foo2 ()
   (interactive nil c-mode)

in most of the cases, which seemed less than ideal.  But on the other
hand, not introducing a new keyword would perhaps help with reading
comprehension. 

> it could even accept more than one mode
>
>   (defun foo2 (arg)
>    (interactive "p" text-mode json-mode)
>    (message "%s 2" arg))
>
> and for users it'd be arguably easier to recognize what it means at a
> glance (since we all know about `interactive').

Yup.

Hm...  I don't know?  Extending `interactive' may be a better than
introducing a new directive.  Any opinions here?

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

Re: Smarter M-x that filters on major-mode

[jao]

On Fri, Feb 12 2021, Lars Ingebrigtsen wrote:

> "Jose A. Ortega Ruiz" <jao@gnu.org> writes:
>
>> You probably have already thought of it, and discarded it for a good
>> reason, but why not, instead of a new `command' form, just add a new
>> (optional) argument to `interactive'?
>>
>>   (defun foo2 (arg)
>>    (interactive "p" c-mode)
>>    (message "%s 2" arg))
>
> The argument to `interactive' is optional, so it'd be
>
>   (defun foo2 ()
>    (interactive nil c-mode)
>
> in most of the cases, which seemed less than ideal.  But on the other
> hand, not introducing a new keyword would perhaps help with reading
> comprehension.

it's perhaps more tricky, but it could also be

     (interactive 'c-mode)

which is distinguisable from a string or a form:

     (interactive "p")
     (interactive (list a b))

i.e., one adopts the convention that if the argument's value is a
symbol, it denotes a mode.  personally, i would like that option even
better, but i'd understand people might consider it a bit brittle.

Re: Smarter M-x that filters on major-mode

[Stefan Kangas]

jao <jao@gnu.org> writes:

>> The argument to `interactive' is optional, so it'd be
>>
>>   (defun foo2 ()
>>    (interactive nil c-mode)
>>
>> in most of the cases, which seemed less than ideal.  But on the other
>> hand, not introducing a new keyword would perhaps help with reading
>> comprehension.
>
> it's perhaps more tricky, but it could also be
>
>      (interactive 'c-mode)
>
> which is distinguisable from a string or a form:
>
>      (interactive "p")
>      (interactive (list a b))

FWIW, I like the new syntax more.  But this is all rather subjective.

One thing is that "command" is much more obvious to read than
"interactive", since it is after all about making "commands" and not
"interactives".

Re: Smarter M-x that filters on major-mode

[jao]

On Fri, Feb 12 2021, Stefan Kangas wrote:

> One thing is that "command" is much more obvious to read than
> "interactive", since it is after all about making "commands" and not
> "interactives".

with (probably literally) millions of `(interactive)' forms present in
code all around the world, i would contest that :)

Re: Smarter M-x that filters on major-mode

[Stefan Monnier]

There seems to be an assumption here that the defining info to hiding
a command (or not) is the current major mode.

While it's an important case, I think it'd be a mistake to design
a feature that can only use such tests.  There are many other useful
conditions that one might like to test, such as the activation of the
region, the existence of some other buffer, etc...


        Stefan


jao [2021-02-12 16:18:48] wrote:

> On Fri, Feb 12 2021, Lars Ingebrigtsen wrote:
>
>> "Jose A. Ortega Ruiz" <jao@gnu.org> writes:
>>
>>> You probably have already thought of it, and discarded it for a good
>>> reason, but why not, instead of a new `command' form, just add a new
>>> (optional) argument to `interactive'?
>>>
>>>   (defun foo2 (arg)
>>>    (interactive "p" c-mode)
>>>    (message "%s 2" arg))
>>
>> The argument to `interactive' is optional, so it'd be
>>
>>   (defun foo2 ()
>>    (interactive nil c-mode)
>>
>> in most of the cases, which seemed less than ideal.  But on the other
>> hand, not introducing a new keyword would perhaps help with reading
>> comprehension.
>
> it's perhaps more tricky, but it could also be
>
>      (interactive 'c-mode)
>
> which is distinguisable from a string or a form:
>
>      (interactive "p")
>      (interactive (list a b))
>
> i.e., one adopts the convention that if the argument's value is a
> symbol, it denotes a mode.  personally, i would like that option even
> better, but i'd understand people might consider it a bit brittle.

Re: Smarter M-x that filters on major-mode

[jao]

On Fri, Feb 12 2021, Stefan Monnier wrote:

> There seems to be an assumption here that the defining info to hiding
> a command (or not) is the current major mode.

hmm, not on my side at least.  but my expectation was that it'll happen
often enough, and i was thinking of ways of easing the transition for
those packages in which it happens.

> While it's an important case, I think it'd be a mistake to design
> a feature that can only use such tests.

fwiw, i wasn't proposing such a thing.  the "all these interactives are
for this major mode" flag/mechanism would be strictly opt-in.

> There are many other useful conditions that one might like to test,
> such as the activation of the region, the existence of some other
> buffer, etc...

indeed.

Re: Smarter M-x that filters on major-mode

[Dmitry Gutov]

On 12.02.2021 19:36, Stefan Monnier wrote:
> There seems to be an assumption here that the defining info to hiding
> a command (or not) is the current major mode.

"Is minor mode xyz active" should be a common predicate, at least.

Re: Smarter M-x that filters on major-mode

[Stefan Monnier]

>> There seems to be an assumption here that the defining info to hiding
>> a command (or not) is the current major mode.
> "Is minor mode xyz active" should be a common predicate, at least.

Indeed.  What I meant to say is that we should focus on designing the
general case of an arbitrary predicate first, and *then* figure out
whether we need to add special syntax/support for common cases like
matching a major mode or a minor mode or ...


        Stefan

Re: Smarter M-x that filters on major-mode

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> There seems to be an assumption here that the defining info to hiding
>>> a command (or not) is the current major mode.
>> "Is minor mode xyz active" should be a common predicate, at least.
>
> Indeed.  What I meant to say is that we should focus on designing the
> general case of an arbitrary predicate first, and *then* figure out
> whether we need to add special syntax/support for common cases like
> matching a major mode or a minor mode or ...

I'm worried about performance. IIRC I've seen 20000+ commands upon M-x
invocation...

RE: [External] : Re: Smarter M-x that filters on major-mode

[Drew Adams]

> I'm worried about performance. IIRC I've seen 20000+
> commands upon M-x invocation...

Even when you type some text to match?

Perhaps you're using some completion framework
that starts displaying candidates without waiting
for any input to match?  (Such behavior is fine,
if optional, but it could be annoying if not.)

Re: [External] : Re: Smarter M-x that filters on major-mode

[Óscar Fuentes]

Drew Adams <drew.adams@oracle.com> writes:

>> I'm worried about performance. IIRC I've seen 20000+
>> commands upon M-x invocation...
>
> Even when you type some text to match?
>
> Perhaps you're using some completion framework
> that starts displaying candidates without waiting
> for any input to match?

Yes. It is equivalent to M-x <TAB> with the default completion system.

But even if you wait until you type the first character, the filtering
could cause a perceptible lag.

RE: [External] : Re: Smarter M-x that filters on major-mode

[Drew Adams]

> >> I'm worried about performance. IIRC I've seen 20000+
> >> commands upon M-x invocation...
> >
> > Even when you type some text to match?
> >
> > Perhaps you're using some completion framework
> > that starts displaying candidates without waiting
> > for any input to match?
> 
> Yes. It is equivalent to M-x <TAB> with the default
> completion system.
> 
> But even if you wait until you type the first character,
> the filtering could cause a perceptible lag.

There are ways to deal with that.
Option for minimal # of chars before trying to match.
Option for minimal time period before doing so.
Option for delay before rematching automatically
  (updating automatically)
Option for threshold for when such things kick in
  (e.g. fewer than N candidates => no delay)
...

None of this is complicated.  Such things are really
part of any UI that provides automatic matching and
rematching - or at least they should be.

Pretty much anything automatic needs to provide
"governors", to mitigate the behavior, especially
in extreme situations (e.g. zillions of whatevers).

Re: [External] : Re: Smarter M-x that filters on major-mode

[Stefan Monnier]

>> Perhaps you're using some completion framework
>> that starts displaying candidates without waiting
>> for any input to match?
> Yes. It is equivalent to M-x <TAB> with the default completion system.
> But even if you wait until you type the first character, the filtering
> could cause a perceptible lag.

That is a concern, indeed, but there are many ways to attack the
problem:

- Arrange for the predicates to be "translucid", so you can test them by
  groups that share the same predicate in a way that's a lot more
  efficient (this will strongly depend on details).  I hope we don't
  have to go there.
- Delay the predicate filtering to the last stage and filter lazily, so
  you can stop as soon as you have found enough completions to fill the
  part displayed on screen.
- ...

In any case, this is all very hypothetical for now.
What we need is experience (and there is already some of that
experience, collected from the `smex` experiment).


        Stefan

Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

Óscar Fuentes <ofv@wanadoo.es> writes:

> I'm worried about performance. IIRC I've seen 20000+ commands upon M-x
> invocation...

Yeah, me too, and it's possible some caching/precomputing will have to
be done...  but in my tests on the branch, I'm not seeing any noticeable
slowdowns.  Of course, I've only annotated ~1000 commands yet.

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

Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> There seems to be an assumption here that the defining info to hiding
> a command (or not) is the current major mode.
>
> While it's an important case, I think it'd be a mistake to design
> a feature that can only use such tests.  There are many other useful
> conditions that one might like to test, such as the activation of the
> region, the existence of some other buffer, etc...

Commands bound to modes cover 97% of the cases, my stats dept. informs
me, so I think it's important to have a short, easy form to allow
annotating functions according to modes -- hence the
`interactive'/`command' bit: If there's any hope in having people
actually do markup in this way, it should be easy to do, and the
resulting code shouldn't be a chore to look at.

But for the remaining 3% of the cases, a more general mechanism is
needed, and that's why I added the (declare (completion PREDICATE))
thing, too.

That is

  (interactive "p" foo-mode)

is identical to

  (declare (completion completion-major-mode-p))
  (interactive "p")

in effect.  But the former is nicer to type and read, I think.

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

Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>   (declare (completion completion-major-mode-p))
>   (interactive "p")

Soory, I mean

  (declare (completion (lambda (s b) (completion-major-mode-p s b 'foo-mode))))

Or something.  :-)

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

RE: [External] : Re: Smarter M-x that filters on major-mode

[Drew Adams]

> > There seems to be an assumption here that the defining info
> > to hiding a command (or not) is the current major mode.
> >
> > While it's an important case, I think it'd be a mistake to design
> > a feature that can only use such tests.  There are many other useful
> > conditions that one might like to test, such as the activation of the
> > region, the existence of some other buffer, etc...

My thoughts too.

> Commands bound to modes cover 97% of the cases,
> my stats dept. informs me,

Really?  Could you please post what's behind those
stats?

And maybe say just what you mean by "commands
bound to modes".  Do you mean commands whose only
reasonable use is only within a given mode?

How did you measure this?

Re: [External] : Re: Smarter M-x that filters on major-mode

[Stefan Monnier]

>> Commands bound to modes cover 97% of the cases,
>> my stats dept. informs me,
> Really?  Could you please post what's behind those stats?

Cute!  ;-)


        Stefan

RE: [External] : Re: Smarter M-x that filters on major-mode

[Drew Adams]

> >> Commands bound to modes cover 97% of the cases,
> >> my stats dept. informs me,
> >
> > Really?  Could you please post what's behind those stats?
> 
> Cute!  ;-)

It wasn't a joke.  I'm curious, and a bit surprised
that 97% of commands are bound to modes (whatever
might be meant by "bound to modes").

Even just a general idea/description might help.
Seems surprising, to me.  I doubt that the
majority of commands I use are mode-specific
(but I could be wrong).

On the other hand, the undefined "bound to modes"
might be an escape clause (?).  Something like
`forward-sexp', for example, can act differently
in different modes.  Would it be considered an
example of a command "bound to modes"?

Re: [External] : Re: Smarter M-x that filters on major-mode

[Stefan Monnier]

>> >> Commands bound to modes cover 97% of the cases,
>> >> my stats dept. informs me,
>> > Really?  Could you please post what's behind those stats?
>> Cute!  ;-)
> It wasn't a joke.

You're confused: it was (and still is),


        Stefan

Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

I've now separated all the related changes into a series of hopefully
sensible patches, and pushed to the trunk.

To summarise:

(defun foo ()
  (interactive "p" foo-mode))

is now valid, and works for both major and minor modes.  Using this is,
of course, backwards incompatible, and moreover, produces bytecode
that's not backwards compatible either.  (If it's not used, the .elc
file will still be backwards compatible.)

The general form is:

(defun foo ()
  (declare (completion PREDICATE))
  (interactive "p"))

Where PREDICATE is a function, and can be pretty much anything.  It's
called with the symbol and the current buffer as predicates.  So that
can be used for mode filtering, too, but it's kinda cumbersome, so a
short version is also provided:

(defun foo ()
  (declare (modes foo-mode))
  (interactive "p"))

This expands to the first version, and if you're writing code that
should still work in older Emacs versions, these latter two forms has to
be used.

I've tagged up eww and gnus/gnus*.el, so to look at the effect, try

emacs -Q -l eww
M-x eww TAB

in a version before and after this patch set.

The new variable 'read-extended-command-predicate' controls what's
included, and the default value is to filter out commands that's not
applicable to the current buffer.

Now go fortheth and marketh uppeth.

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

Re: Smarter M-x that filters on major-mode

[Basil L. Contovounesios]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I've now separated all the related changes into a series of hopefully
> sensible patches, and pushed to the trunk.

Thanks!

I'm curious, though: if (interactive ARG MODES...) is neither forward
nor backward compatible, and is equivalent to
(declare (modes MODES...)), then why not allow only the latter syntax?
Or am I missing something?

-- 
Basil

Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

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

> I'm curious, though: if (interactive ARG MODES...) is neither forward
> nor backward compatible,

I'm not sure what you mean by "forward compatible" here...  Emacs 29
should be able to use it just fine?

> and is equivalent to (declare (modes MODES...)), then why not allow
> only the latter syntax?  Or am I missing something?

Since approx. 97% of commands will eventually have this markup, that
means that 97% of commands will start with

  (declare (modes foo-mode))
  (interactive "p")

and that seems like too much line noise.  We don't have to make Emacs
Lisp into Java.

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

Re: Smarter M-x that filters on major-mode

[Basil L. Contovounesios]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> "Basil L. Contovounesios" <contovob@tcd.ie> writes:
>
>> I'm curious, though: if (interactive ARG MODES...) is neither forward
>> nor backward compatible,
>
> I'm not sure what you mean by "forward compatible" here...  Emacs 29
> should be able to use it just fine?

Sorry, I just meant that 'interactive' will no longer be extensible,
whereas 'declare' is inherently extensible.

-- 
Basil

Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

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

> Sorry, I just meant that 'interactive' will no longer be extensible,
> whereas 'declare' is inherently extensible.

That's true.  I originally went with a new directive, `command', instead
of extending `interactive', partly because of that, but it then didn't
seem like a very compelling thing -- we haven't extended `interactive'
in...  er...  many decades, so the conclusion from that might be that
it's perhaps not likely that we'll want to further extend it.

On the other hand, if that's a commonly held worry, we could change the
signature from &optional form &rest modes to &optional form modes.

And finally, if it turns out that we super-duper do need to extend
`interactive' later, then we can just introduce `command' instead.

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

Re: Smarter M-x that filters on major-mode

[Sean Whitton]

Hello,

On Sun 14 Feb 2021 at 03:45PM +01, Lars Ingebrigtsen wrote:

> "Basil L. Contovounesios" <contovob@tcd.ie> writes:
>
>> Sorry, I just meant that 'interactive' will no longer be extensible,
>> whereas 'declare' is inherently extensible.
>
> That's true.  I originally went with a new directive, `command', instead
> of extending `interactive', partly because of that, but it then didn't
> seem like a very compelling thing -- we haven't extended `interactive'
> in...  er...  many decades, so the conclusion from that might be that
> it's perhaps not likely that we'll want to further extend it.
>
> On the other hand, if that's a commonly held worry, we could change the
> signature from &optional form &rest modes to &optional form modes.

I'd suggest going with this but making modes be a single symbol or a
list of symbols, since having just a single mode is going to be the most
common case.

-- 
Sean Whitton

Re: Smarter M-x that filters on major-mode

[Dmitry Gutov]

On 14.02.2021 16:23, Lars Ingebrigtsen wrote:

>> and is equivalent to (declare (modes MODES...)), then why not allow
>> only the latter syntax?  Or am I missing something?
> 
> Since approx. 97% of commands will eventually have this markup, that
> means that 97% of commands will start with
> 
>    (declare (modes foo-mode))
>    (interactive "p")
> 
> and that seems like too much line noise.  We don't have to make Emacs
> Lisp into Java.

Seeing how it looks more like a keyword argument than a type 
specification, maybe CL rather than Java?

'declare' is a pretty standard tool we have, so if the command already 
has some declarations, one might not end up having to add the extra line 
(this doesn't change things much now, but sometime in the future it 
might, when/if we add more declarations of this kind). Also, no 
enthusiastic package author will end up making their code incompatible 
with Emacs 27 by accident.

Re: Smarter M-x that filters on major-mode

[Alan Mackenzie]

Hello, Lars.

On Sun, Feb 14, 2021 at 15:23:31 +0100, Lars Ingebrigtsen wrote:
> "Basil L. Contovounesios" <contovob@tcd.ie> writes:

> > I'm curious, though: if (interactive ARG MODES...) is neither forward
> > nor backward compatible,

> I'm not sure what you mean by "forward compatible" here...  Emacs 29
> should be able to use it just fine?

> > and is equivalent to (declare (modes MODES...)), then why not allow
> > only the latter syntax?  Or am I missing something?

> Since approx. 97% of commands will eventually have this markup, that
> means that 97% of commands will start with

>   (declare (modes foo-mode))
>   (interactive "p")

> and that seems like too much line noise.  We don't have to make Emacs
> Lisp into Java.

Please stop.  Please just stop and rethink.

Filtering out stuff from an M-x search is a minor feature.  You're
proposing turning the structures of Emacs upside down in implementing
it.  This is disproportionate, and will bring unforeseen problems with
it.

`interactive' currently does one thing and does it well - it says how to
call a function interactively.  You're advocating adding unrelated stuff
into `interactive'.  That is ugly, horribly ugly.

You're proposing making the .elc format backward incompatible, all for
what?  For some minor feature to do with M-x.  A feature which not
everybody wants (I certainly don't), and not everybody will use.

You're proposing encouraging (or even "encouraging") people to make
their libraries backward incompatible, something which will meet
considerable resistance.  (Dmitry, I think, has already expressed an
unwillingness to make such changes to his packages.)

Also the DEFUN macro will need modifying.  This won't be pretty.

Please just leave `interactive' alone.  Please just leave the .elc
format alone.

There are other ways to do what this proposal is proposing (I've
forgotten exactly what this is) - why not just add a property called
`minor-modes' to the functions' symbols?  Or something like that?

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

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Smarter M-x that filters on major-mode

[Stefan Kangas]

Alan Mackenzie <acm@muc.de> writes:

> Filtering out stuff from an M-x search is a minor feature.  You're
> proposing turning the structures of Emacs upside down in implementing
> it.  This is disproportionate, and will bring unforeseen problems with
> it.
>
> `interactive' currently does one thing and does it well - it says how to
> call a function interactively.  You're advocating adding unrelated stuff
> into `interactive'.  That is ugly, horribly ugly.
>
> You're proposing making the .elc format backward incompatible, all for
> what?  For some minor feature to do with M-x.  A feature which not
> everybody wants (I certainly don't), and not everybody will use.

FWIW, I disagree:

- This feature is extremely useful, I think a big improvement in user
  experience and one of the things to be excited about for Emacs 28.

- This is a clean and natural expansion of `interactive'.

- I'm not sure what it means to turn things upside down.  I assume you
  mean that a horrible mess has been made?  If so, I must disagree with
  that, too.

Re: Smarter M-x that filters on major-mode

[Alan Mackenzie]

Hello, Stefan.

On Sun, Feb 14, 2021 at 10:11:47 -0600, Stefan Kangas wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > Filtering out stuff from an M-x search is a minor feature.  You're
> > proposing turning the structures of Emacs upside down in implementing
> > it.  This is disproportionate, and will bring unforeseen problems with
> > it.

> > `interactive' currently does one thing and does it well - it says how to
> > call a function interactively.  You're advocating adding unrelated stuff
> > into `interactive'.  That is ugly, horribly ugly.

> > You're proposing making the .elc format backward incompatible, all for
> > what?  For some minor feature to do with M-x.  A feature which not
> > everybody wants (I certainly don't), and not everybody will use.

> FWIW, I disagree:

> - This feature is extremely useful, I think a big improvement in user
>   experience and one of the things to be excited about for Emacs 28.

I'm not implying it isn't.  But at the same time it's still a minor
feature.  It doesn't come anywhere close in importance to things like
the mechanism for calling interactive functions, which is essential for
Emacs to work at all.  Yet it will disrupt these important things.

> - This is a clean and natural expansion of `interactive'.

How can you say this?  The new stuff going into `interactive' has
nothing to do with its current function.  See above.  Please answer this
point.

> - I'm not sure what it means to turn things upside down.

Sorry, that's a bit of English idiom.  It means moving things around a
lot, changing lots of things, usually with the implication that the
result won't have justified the extent of the required effort.

>   I assume you mean that a horrible mess has been made?  If so, I must
>   disagree with that, too.

No, see above.  But `interactive' will end up being used for two
entirely different purposes, unrelated to eachother.  That seems like a
mess to me.

Why do we need such deep, incompatible changes to implement this
feature?  Why can't it just be implemented using the normal
unobjectionable means like symbol properties?  This is what I don't
understand.  I feel at the moment that I'm going mad, seeing such far
reaching, destructive things going on, and everybody else just seems to
think these things normal, the sort of thing one does every day.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Smarter M-x that filters on major-mode

[Stefan Kangas]

Alan Mackenzie <acm@muc.de> writes:

>> - This is a clean and natural expansion of `interactive'.
>
> How can you say this?  The new stuff going into `interactive' has
> nothing to do with its current function.  See above.  Please answer this
> point.

Well, what is `interactive'?  According to the ELisp Manual:

 -- Special Form: interactive arg-descriptor
     This special form declares that a function is a command, and that
     it may therefore be called interactively (via ‘M-x’ or by entering
     a key sequence bound to it).

So `interactive' is exactly about showing it on `M-x'.  Now we add an
extension to that which says _in which modes_ `M-x' will show it (by
default).  That feels very natural to me.

>> - I'm not sure what it means to turn things upside down.
>
> Sorry, that's a bit of English idiom.  It means moving things around a
> lot, changing lots of things, usually with the implication that the
> result won't have justified the extent of the required effort.

OK, that is approximately what I understood.  But I put it in a bit more
blunt language that you did not intend to use.  I apologize if this
misrepresented your position, as that was not my intention.

Re: Smarter M-x that filters on major-mode

[Alan Mackenzie]

Hello, Stefan.

On Sun, Feb 14, 2021 at 17:33:30 -0600, Stefan Kangas wrote:
> Alan Mackenzie <acm@muc.de> writes:

> >> - This is a clean and natural expansion of `interactive'.

> > How can you say this?  The new stuff going into `interactive' has
> > nothing to do with its current function.  See above.  Please answer this
> > point.

> Well, what is `interactive'?  According to the ELisp Manual:

>  -- Special Form: interactive arg-descriptor
>      This special form declares that a function is a command, and that
>      it may therefore be called interactively (via ‘M-x’ or by entering
>      a key sequence bound to it).

> So `interactive' is exactly about showing it on `M-x'.  Now we add an
> extension to that which says _in which modes_ `M-x' will show it (by
> default).  That feels very natural to me.

No, it's not about "showing" the command.  It's about executing it.
Surely you see there's a difference, a substantial difference, between
searching for a command, or choosing one, and then executing it?  At the
very least, the new stuff proposed for `interactive' is MUCH more
loosely connected with the current stuff, than the current stuff with
itself.

I would further say that the new stuff for `interactive' isn't anything
to do the the command it's going into - it's to do with that command's
relationship with other entities.  So this change to `interactive' is
suboptimal from a software engineering viewpoint - when these
relationships change, lots of functions will need changing rather than
just the forms expressing those relationships.

I'm worried that Lars hasn't chosen to answer my post from yesterday
afternoon, and that he may be ploughing ahead with this, despite the
reservations expressed by several people.

Just to be entirely clear, I'm in favour of this new functionality for
M-x (provided, of course, that it is optional).  But the degree of
disruption caused to Emacs by the proposed way of implementation seems
quite out of proportion to what will be gained, and also seems quite
unnecessary.

> >> - I'm not sure what it means to turn things upside down.

> > Sorry, that's a bit of English idiom.  It means moving things around
> > a lot, changing lots of things, usually with the implication that
> > the result won't have justified the extent of the required effort.

> OK, that is approximately what I understood.  But I put it in a bit
> more blunt language that you did not intend to use.  I apologize if
> this misrepresented your position, as that was not my intention.

No problem!  If I use idiomatic English, I shouldn't expect it to be
understood all the time.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Smarter M-x that filters on major-mode

[Stefan Kangas]

Hi Alan,

Alan Mackenzie <acm@muc.de> writes:

>>  -- Special Form: interactive arg-descriptor
>>      This special form declares that a function is a command, and that
>>      it may therefore be called interactively (via ‘M-x’ or by entering
>>      a key sequence bound to it).
>
>> So `interactive' is exactly about showing it on `M-x'.  Now we add an
>> extension to that which says _in which modes_ `M-x' will show it (by
>> default).  That feels very natural to me.
>
> No, it's not about "showing" the command.  It's about executing it.

The difference between any function and an `interactive' command is that
the latter can be executed more conveniently: it can be bound to a key
or invoked with `M-x'.  IOW, both `interactive' and the new extension is
about making functions conveniently available for execution in various
contexts.  And yes, this includes "showing" it in `M-x'.

> Surely you see there's a difference, a substantial difference, between
> searching for a command, or choosing one, and then executing it?

Yes, of course.  You obviously might want to search for a function
without then also wanting to execute it.

However, `M-x' is _typically_ used to find and execute commands.
(We have other commands specifically intended for searching.)

IIUC, you have said that you use `M-x' to search for commands without
executing them, and at times prefer that to using the commands we have
specifically for searching.  That is a valid use-case, and precisely why
we should have an option to disable mode filtering.

But I don't see how that pertains to the relative cleanliness of making
this extension to `interactive'.  Perhaps I misunderstood the argument
you were trying to make.

Re: Smarter M-x that filters on major-mode

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sun, 14 Feb 2021 10:11:47 -0600
> Cc: "Basil L. Contovounesios" <contovob@tcd.ie>, emacs-devel@gnu.org
> 
> - This feature is extremely useful, I think a big improvement in user
>   experience and one of the things to be excited about for Emacs 28.
> 
> - This is a clean and natural expansion of `interactive'.
> 
> - I'm not sure what it means to turn things upside down.  I assume you
>   mean that a horrible mess has been made?  If so, I must disagree with
>   that, too.

I think the important question is: can we have this feature in a way
that has fewer downsides?  Backward incompatibility of byte code is
definitely a downside; if it can be avoided, that would be a net win,
I think.

Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I think the important question is: can we have this feature in a way
> that has fewer downsides?  Backward incompatibility of byte code is
> definitely a downside; if it can be avoided, that would be a net win,
> I think.

It can be avoided -- instead of stashing the modes in the byte code
signature, we could put them in (put ...) forms in the .elc files (like
`declare' does).

The downside is that this is slower and takes up a lot more room in the
.elc files, so it doesn't sound all that attractive as a solution in the
long term.

And if the .el file is incompatible (which they will be with the new
`interactive' syntax), does it make sense to keep the .elc files
compatible?  Yes, you can use the .elc files in Emacs 27, but not the
.el files?  It doesn't really seem like something to worry overmuch
about to me.

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

Re: Smarter M-x that filters on major-mode

[Basil L. Contovounesios]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> I think the important question is: can we have this feature in a way
>> that has fewer downsides?  Backward incompatibility of byte code is
>> definitely a downside; if it can be avoided, that would be a net win,
>> I think.
>
> It can be avoided -- instead of stashing the modes in the byte code
> signature, we could put them in (put ...) forms in the .elc files (like
> `declare' does).

FWIW, my vote's for something along those lines, as it's far less
intrusive, less controversial, more flexible, and more compatible.

Are its downsides really that severe?  Perhaps there are ways to
mitigate them?

Thanks,

-- 
Basil

Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

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

> FWIW, my vote's for something along those lines, as it's far less
> intrusive, less controversial, more flexible, and more compatible.

Like I said, I don't see why.  The .el files aren't compatible, so why
should the .elc files be?

Just like a lexically-bound .elc file doesn't work totally in older
Emacsen, neither does a lexically-bound .el file.  It's an analogous
situation.

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

Re: Smarter M-x that filters on major-mode

[Basil L. Contovounesios]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> "Basil L. Contovounesios" <contovob@tcd.ie> writes:
>
>> FWIW, my vote's for something along those lines, as it's far less
>> intrusive, less controversial, more flexible, and more compatible.
>
> Like I said, I don't see why.  The .el files aren't compatible, so why
> should the .elc files be?
>
> Just like a lexically-bound .elc file doesn't work totally in older
> Emacsen, neither does a lexically-bound .el file.  It's an analogous
> situation.

Yes, but a lexical-binding cookie makes no difference in Emacs 23,
whereas (interactive nil foo-mode) would be an error.  Hence my vote for
just the (declare (modes ...)) and/or symbol property approach.

-- 
Basil

Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

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

> Yes, but a lexical-binding cookie makes no difference in Emacs 23,
> whereas (interactive nil foo-mode) would be an error.

The code you load in Emacs 23 that's written for lexical binding often
won't work, though.  (I.e., if the code uses closures.)  So it's not
backwards compatible, just as code that uses "new" macros like
`with-current-buffer' isn't.

Emacs Lisp develops, and newer versions aren't backwards-compatible.
That's just how it is.  If you're maintaining code that's out of tree,
you have to avoid using the newest features.  There's nothing special
about the new `interactive' signature in that respect.  (And as Stefan K
shows, if you still want to use it in an in/out-of-tree package, he's
written a compat macro for that.)

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

Re: Smarter M-x that filters on major-mode

[Basil L. Contovounesios]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> "Basil L. Contovounesios" <contovob@tcd.ie> writes:
>
>> Yes, but a lexical-binding cookie makes no difference in Emacs 23,
>> whereas (interactive nil foo-mode) would be an error.
>
> The code you load in Emacs 23 that's written for lexical binding often
> won't work, though.  (I.e., if the code uses closures.)  So it's not
> backwards compatible, just as code that uses "new" macros like
> `with-current-buffer' isn't.

But 'declare' isn't a new macro, and lexical-binding is just a
file-local variable.  I'm not referring to business logic, but Elisp
infrastructure.

> Emacs Lisp develops, and newer versions aren't backwards-compatible.
> That's just how it is.  If you're maintaining code that's out of tree,
> you have to avoid using the newest features.  There's nothing special
> about the new `interactive' signature in that respect.  (And as Stefan K
> shows, if you still want to use it in an in/out-of-tree package, he's
> written a compat macro for that.)

The special thing about the new interactive spec is that, while it
itself is backward incompatible, it has an equivalent
(declare (modes ...)) form that is backward compatible.  So why not push
only the less intrusive and more flexible of the two?

I find that a far more appealing approach than using a compatibility
macro for something as fundamental as a command's interactive spec.

But that's just me,

-- 
Basil

Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

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

> The special thing about the new interactive spec is that, while it
> itself is backward incompatible, it has an equivalent
> (declare (modes ...)) form that is backward compatible.  So why not push
> only the less intrusive and more flexible of the two?

Why did we introduce the `when-let' when `let' + `when' exists?  Because
we thought `when-let' made the code clearer.

I think

(interactive "p" foo-mode)

is pretty clear, easy to understand and easy to write.

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

RE: [External] : Re: Smarter M-x that filters on major-mode

[Drew Adams]

> > why not push only the less intrusive
> > and more flexible of the two?
> 
> Why did we introduce the `when-let'
> when `let' + `when' exists?

Indeed, why?

> Because we thought `when-let' made
> the code clearer.

Two wrongs don't make a right? ;-)

Re: Smarter M-x that filters on major-mode

[Eric S Fraga]

On Monday, 15 Feb 2021 at 03:59, Lars Ingebrigtsen wrote:
> I think
>
> (interactive "p" foo-mode)
>
> is pretty clear, easy to understand and easy to write.

Although I don't contribute to Emacs development per se, and so I
apologise for the intrusion, I have 45 years of software development
experience.  This experience leads me to say that this is a very
compelling argument when considering long term maintenance and use of
code.

-- 
Eric S Fraga via Emacs 28.0.50 & org 9.4.4 on Debian bullseye/sid

Re: Smarter M-x that filters on major-mode

[Óscar Fuentes]

Alan Mackenzie <acm@muc.de> writes:

> For some minor feature to do with M-x.

This is your opinion. Speaking as a humble user, this is the UI feature
in Emacs 28 that will have the greatest impact in my workflow.

Furthermore, I would say that Emacs allowing you to invoke commands that
have nothing to do with the current context and which likely outcome is
to confuse the user or, worse, mess up things, is a serious QoI issue.

We accepted this as a given, but it is a glaring deficiency
nevertheless.

> A feature which not
> everybody wants (I certainly don't), and not everybody will use.

Like every other feature in Emacs.

Re: Smarter M-x that filters on major-mode

[Eli Zaretskii]

> Date: Sun, 14 Feb 2021 15:03:53 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: "Basil L. Contovounesios" <contovob@tcd.ie>, emacs-devel@gnu.org
> 
> Also the DEFUN macro will need modifying.

Why would we need to modify DEFUN?  Primitives don't belong to any
mode, so they don't need to be marked with a mode.  Am I missing
something?

Re: Smarter M-x that filters on major-mode

[Juri Linkov]

>> and is equivalent to (declare (modes MODES...)), then why not allow
>> only the latter syntax?  Or am I missing something?
>
> Since approx. 97% of commands will eventually have this markup, that
> means that 97% of commands will start with
>
>   (declare (modes foo-mode))
>   (interactive "p")
>
> and that seems like too much line noise.  We don't have to make Emacs
> Lisp into Java.

Such changes as below are not less line noise, and not less Java.
Instead of this, more Lisp-like solution would be like
removing redundant :group args from defcustom when there is
a defgroup before them.  The same way a package would declare
its group, then defuns of all package commands could either
add a corresponding 'declare' form, or put a command symbol's
property to the defgroup mode name.

@@ -274,45 +274,45 @@ bb-insert-board
     ))
 
 (defun bb-right (count)
-  (interactive "p")
+  (interactive "p" blackbox-mode)
   (while (and (> count 0) (< bb-x 8))
     (forward-char 2)
     (setq bb-x (1+ bb-x))
     (setq count (1- count))))
 
 (defun bb-left (count)
-  (interactive "p")
+  (interactive "p" blackbox-mode)
   (while (and (> count 0) (> bb-x -1))
     (backward-char 2)
     (setq bb-x (1- bb-x))
     (setq count (1- count))))
 
 (defun bb-up (count)
-  (interactive "p")
+  (interactive "p" blackbox-mode)
   (while (and (> count 0) (> bb-y -1))
     (with-no-warnings (previous-line))
     (setq bb-y (1- bb-y))
     (setq count (1- count))))
 
 (defun bb-down (count)
-  (interactive "p")
+  (interactive "p" blackbox-mode)
   (while (and (> count 0) (< bb-y 8))
     (with-no-warnings (next-line))
     (setq bb-y (1+ bb-y))
     (setq count (1- count))))
 
 (defun bb-eol ()
-  (interactive)
+  (interactive nil blackbox-mode)
   (setq bb-x 8)
   (bb-goto (cons bb-x bb-y)))
 
 (defun bb-bol ()
-  (interactive)
+  (interactive nil blackbox-mode)
   (setq bb-x -1)
   (bb-goto (cons bb-x bb-y)))
 
 (defun bb-romp ()
-  (interactive)
+  (interactive nil blackbox-mode)
   (cond
    ((and
      (or (= bb-x -1) (= bb-x 8))

Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> Such changes as below are not less line noise, and not less Java.
> Instead of this, more Lisp-like solution would be like
> removing redundant :group args from defcustom when there is
> a defgroup before them.  The same way a package would declare
> its group, then defuns of all package commands could either
> add a corresponding 'declare' form, or put a command symbol's
> property to the defgroup mode name.

Having a "all the rest of the commands in this file belongs to this
mode" is fragile and awkward, in my opinion.

And since you seem to think that

  (interactive "p" foo-mode)

is too much noise, and Dmitry thinks that it's not enough, then it seems
like I've arrived at the ideal compromise.

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

RE: [External] : Re: Smarter M-x that filters on major-mode

[Drew Adams]

> Having a "all the rest of the commands in this file
> belongs to this mode" is fragile and awkward, in my opinion.

+1.  Well put: fragile and awkward.  And not so apparent.

> And since you seem to think that
>   (interactive "p" foo-mode)
> is too much noise, and Dmitry thinks that it's not
> enough, then it seems like I've arrived at the ideal
> compromise.

Disagreement in different directions is no indication
of reasonableness.  That's a common fallacy, well
demonstrated by US journalism, which often feels it's
done its job just by letting two different, opposing
opinions be voiced.

RE: [External] : Re: Smarter M-x that filters on major-mode

[Drew Adams]

> Instead of this, more Lisp-like solution

I disagree that there is anything more Lisp-like
in what you suggest.  Neither more nor less
Lisp-like.  I don't think there's any relation
to lispiness here.

> would be like removing redundant :group args from
> defcustom when there is a defgroup before them.

And that's misguided, IMO.

It makes things less clear for a human reader,
particularly when multiple :group's apply to a
given option/face or when there are multiple
defgroup's in the file.

And besides being less clear visually, it can
be error prone to move definitions around (e.g.,
when they are kept in some non-dependency order
such as alphabetical).

These reasons against that practice are
admittedly not super-important.  Another argument
is that nothing much is gained by this shortcut.
Better to just declare all :group's explicitly.

Re: Smarter M-x that filters on major-mode

[Stefan Monnier]

> Since approx. 97% of commands will eventually have this markup, that
> means that 97% of commands will start with
>
>   (declare (modes foo-mode))
>   (interactive "p")
>
> and that seems like too much line noise.

FWIW, I think that having 97% of commands start with

    (interactive "p" foo-mode)

is also undesirable.  I'd much rather have those 97% start with

    (interactive)

and the remaining 3% can use the more verbose:

    (declare (completion t))
    (interactive)

That should also make it easier to share the exact same objects to
represent the predicates for those 97% instead of having each one be
a silly identical clones of the other.  IOW it'd be more efficient for
the coder, for the source code, and at run-time.


        Stefan

Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> FWIW, I think that having 97% of commands start with
>
>     (interactive "p" foo-mode)
>
> is also undesirable.  I'd much rather have those 97% start with
>
>     (interactive)
>
> and the remaining 3% can use the more verbose:
>
>     (declare (completion t))
>     (interactive)
>
> That should also make it easier to share the exact same objects to
> represent the predicates for those 97% instead of having each one be
> a silly identical clones of the other.  IOW it'd be more efficient for
> the coder, for the source code, and at run-time.

I think there's too much magic in Emacs already.  If a person writes a
function in some file, having that function work differently based on
where in the file it is, would be a disservice to everybody involved.
It'd be unpredictable what the person is writing, and when reading the
resulting code, it's the same problem.

Magic mark-up that works at a distance isn't fun to deal with.

(And you forgot the "p" in your preferred version.  :-))

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

Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Now go fortheth and marketh uppeth.

This little command may be helpful.

(global-set-key [(hyper l)] 'int-fix-command)
(defvar int-prev-mode nil)
(defun int-fix-command ()
  (interactive)
  (let ((mode nil)
	(regexp "(define-derived-mode \\([^ \t\n]+\\)\\|(defun \\([^ \t\n]+-mode\\) ")
	change)
    (if (not (re-search-forward "^ *\\((interactive\\)" nil t))
	(message "No more interactive in this file")
      (recenter nil t)
      (save-match-data
	(save-excursion
	  (when (or (re-search-backward regexp nil t)
		    (re-search-forward regexp nil t))
	    (setq mode (or (match-string 1) (match-string 2)))))
	(setq change (read-string "Change to: " (or mode int-prev-mode))))
      (when (plusp (length change))
	(setq mode change)
	(goto-char (match-beginning 1))
	(let ((form (read (current-buffer))))
	  (goto-char (match-beginning 1))
	  (forward-char 1)
	  (if (> (length form) 1)
	      (progn
		(forward-sexp 2)
		(insert " " mode))
	    (forward-sexp 1)
	    (insert " nil " mode)))
	(setq int-prev-mode mode)))))

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

Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

jao <jao@gnu.org> writes:

> it's perhaps more tricky, but it could also be
>
>      (interactive 'c-mode)
>
> which is distinguisable from a string or a form:
>
>      (interactive "p")
>      (interactive (list a b))
>
> i.e., one adopts the convention that if the argument's value is a
> symbol, it denotes a mode.  personally, i would like that option even
> better, but i'd understand people might consider it a bit brittle.

Hm...  It's possible, but it seems a bit hacky, I think.

I'm trying to remember why I came up with the `command' thing instead of
`interactive' the last time this was discussed, but I haven't found
it...  it's possible (back then) that I somehow imagined that
`interactive' took a &rest instead of an &optional, and that would make
it necessary to introduce a new form.

But that's wrong, obviously, so I think I'll just rework this stuff to
use `interactive', so it'll be

  (interactive nil foo-mode bar-mode)

all over the place instead of

  (command (foo-mode bar-mode))

That is, I think you're right that introducing a new form here doesn't
help much.

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

RE: [External] : Re: Smarter M-x that filters on major-mode

[Drew Adams]

> Any opinions here?

Yes.  Don't do any of this.  Just leave `M-x' alone.

I mentioned more useful possible extensions for `M-x'
(and not just `M-x'), which give users more, not less,
control over which commands are offered by completion.

The changes you're considering making are in the wrong
direction, IMHO.  And they aren't needed.

Please don't hard-code any filtering for `M-x',
however smart you might think that might be.

Re: [External] : Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

Drew Adams <drew.adams@oracle.com> writes:

> Please don't hard-code any filtering for `M-x',
> however smart you might think that might be.

There's no hard-coding of any filtering, so I'm not sure who you're
arguing with (or what about).

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

Re: Smarter M-x that filters on major-mode

[Stefan Monnier]

> What would the syntax for marking these commands be?  Perhaps a
> `declare' form would be the best thing here?

Yes, `declare` sounds like the right tool.
It can expand to the usual `define-symbol-prop`.

>   (command foo-mode "p")
>
> for the normal case, then perhaps it doesn't make sense to clutter up
> that simple syntax with something for this thing.

How 'bout

    (declare (M-x-pred EXP))

which turns into

    (define-symbol-prop '[SYM] (lambda () EXP))

so EXP can be (derived-mode-p 'foo-mode) or it can be nil, or ...


        Stefan

Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

I went ahead and pushed this to a new branch -- scratch/command.  Please
take a look if you're interested.

A "make extraclean" is needed if going to/from the branch -- the
bytecode isn't quite compatible.  Hm...  but it should be backwards
compatible at least; I'll fix that.

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

Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> How 'bout
>
>     (declare (M-x-pred EXP))
>
> which turns into
>
>     (define-symbol-prop '[SYM] (lambda () EXP))
>
> so EXP can be (derived-mode-p 'foo-mode) or it can be nil, or ...

I happened onto another possible use here while testing things -- making
commands available after loading some other package.  That is, we
currently have stuff like

(defun gnus-summary-thing ()
  (interactive)
  (require 'thing)
  (do-thing-stuff))

which just signals an error if `thing' doesn't exist.  Instead we could
do something like:

(defun gnus-summary-thing ()
  (interactive)
  (declare (M-x-pred (find-library "thing")))
  (require 'thing)
  (do-thing-stuff))

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

Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>   (declare (M-x-pred (find-library "thing")))

(Of course, that can make M-x arbitrarily slow, too, so perhaps there
should be some kind of limit to what people should put in there...)

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

Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> How 'bout
>
>     (declare (M-x-pred EXP))
>
> which turns into
>
>     (define-symbol-prop '[SYM] (lambda () EXP))
>
> so EXP can be (derived-mode-p 'foo-mode) or it can be nil, or ...

Found a new thing this could be used for -- buttons.  They usually have
a local keymap, and don't make sense unless executed with point on the
button.  Should be an easy enough predicate to add here...

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

Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

This all reminded me of a slightly related issue: All modes defined by
`define-derived-mode' are interactive.  Is there a reason for that?

I mean, most editing-related modes are definitely commands -- you want
to switch `prolog-mode' on and off as you wish.  But there's also a
number of modes that only make sense in certain special prepared buffers
(like `eww-history-mode', which is there just to provide a couple of
commands).

Would it make sense to introduce a keyword to `define-derived-mode' that
would allow saying :interactive nil?

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

Re: Smarter M-x that filters on major-mode

[Stefan Monnier]

> Would it make sense to introduce a keyword to `define-derived-mode' that
> would allow saying :interactive nil?

I don't see any benefit in making it not interactive.
But I do see a benefit in not listing it in `M-x` completion.


        Stefan

Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Would it make sense to introduce a keyword to `define-derived-mode' that
>> would allow saying :interactive nil?
>
> I don't see any benefit in making it not interactive.
> But I do see a benefit in not listing it in `M-x` completion.

To reverse the question: What's the benefit of marking these functions
as interactive when they're not meant to be used as commands?

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

Re: Smarter M-x that filters on major-mode

[Stefan Monnier]

>>> Would it make sense to introduce a keyword to `define-derived-mode' that
>>> would allow saying :interactive nil?
>> I don't see any benefit in making it not interactive.
>> But I do see a benefit in not listing it in `M-x` completion.
> To reverse the question: What's the benefit of marking these functions
> as interactive when they're not meant to be used as commands?

It's marginally less complexity in `define-derived-mode`.

And it obeys the "Major Mode Conventions" node which repeats over and
over "the major mode command": the fact that it is expected to be
a command is so obvious there that it's not even stated explicitly.


        Stefan

Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> To reverse the question: What's the benefit of marking these functions
>> as interactive when they're not meant to be used as commands?
>
> It's marginally less complexity in `define-derived-mode`.

It's very marginal indeed. 

> And it obeys the "Major Mode Conventions" node which repeats over and
> over "the major mode command": the fact that it is expected to be
> a command is so obvious there that it's not even stated explicitly.

That may have been the expectation, but that doesn't mean that we can't
improve things here.

I've had (several times) Emacs erase the contents of a buffer and
disable undo because I've typed the wrong `M-x foo-mode' command -- one
that's not meant for editing, but only exists to do stuff in a
specially-formatted buffer.

Also see what we did to `M-x shell-mode' after the nth complaint that
somebody had executed shell-mode instead of shell-script-mode.  Those
contortions would be unnecessary if we just left shell-mode
noninteractive.

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

Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> How 'bout
>
>     (declare (M-x-pred EXP))
>
> which turns into
>
>     (define-symbol-prop '[SYM] (lambda () EXP))
>
> so EXP can be (derived-mode-p 'foo-mode) or it can be nil, or ...

I started implementing this bit, but I'm not sure whether an EXP that
gets turned into a lambda with no parameters is the best design here...

That is, the common predicates I've encountered while doing markup in
the gnus*.el files are:

  -- based on major mode (needs the symbol name and the current buffer,
     but can probably assume we're in a specific buffer)

  -- buttons (needs the symbol name, and in addition to the major mode
     needs to look at properties at point)

  -- minor modes (needs to check whether the mode is on or off)

So I'm wondering whether this should be

     (declare (completion (lambda (buffer symbol) ...)))

but we'll have a number of standard predicates, so that'd normally be

     (declare (completion completion-in-major-mode-p))
     (declare (completion completion-on-button-p))
     (declare (completion completion-minor-mode-enabled-p))

or something along those lines...

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

Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> but we'll have a number of standard predicates, so that'd normally be
>
>      (declare (completion completion-in-major-mode-p))
>      (declare (completion completion-on-button-p))
>      (declare (completion completion-minor-mode-enabled-p))
>
> or something along those lines...

Er; that'd be (for minor modes)

(defun gnus-pick-start-reading (&optional catch-up)
[...]
  (declare (completion (lambda (s b)
			 (completion-minor-mode-active-p s b 'gnus-pick-mode))))

which is a mouthful...

On the other hand, this could go into the `command' spec, if only we had
a way to distinguish minor modes from major modes, which...  we don't
seem to have?  But we could have: `define-minor-mode' could `put' some
property on the mode symbol to say that, indeed, it's a minor mode.

Which could also conceivably be useful in other situations.

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

Re: Smarter M-x that filters on major-mode

[Robert Pluim]

>>>>> On Fri, 12 Feb 2021 11:29:19 +0100, Lars Ingebrigtsen <larsi@gnus.org> said:
    Lars> On the other hand, this could go into the `command' spec, if only we had
    Lars> a way to distinguish minor modes from major modes, which...  we don't
    Lars> seem to have?  But we could have: `define-minor-mode' could `put' some
    Lars> property on the mode symbol to say that, indeed, it's a minor mode.

'minor-mode-list'?

    Lars> Which could also conceivably be useful in other situations.

If you make changes here, could you arrange for some (buffer-local?)
symbol somewhere to be updated when a minor mode is activated?
Figuring out which minor modes are in effect is currently non-trivial.

Robert

Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> 'minor-mode-list'?

Oh, I thought that was an XEmacs compat thing, since it's added by this
function:

---
(defun add-minor-mode (toggle name &optional keymap after toggle-fun)
  "Register a new minor mode.

This is an XEmacs-compatibility function.  Use `define-minor-mode' instead.
---

Does this doc string mean that one shouldn't use `add-minor-mode'
directly, but only through `define-minor-mode'?  But that everything
that `add-minor-mode' does isn't XEmacs compat stuff?

>     Lars> Which could also conceivably be useful in other situations.
>
> If you make changes here, could you arrange for some (buffer-local?)
> symbol somewhere to be updated when a minor mode is activated?
> Figuring out which minor modes are in effect is currently non-trivial.

That does sound like a useful thing...  Since the major mode is
determined by the `major-mode' variable, what about a new
permanently-local variable `minor-modes'?  `define-minor-mode' would be
responsible for adding/removing itself to the variable.

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

Re: Smarter M-x that filters on major-mode

[Robert Pluim]

>>>>> On Fri, 12 Feb 2021 12:19:46 +0100, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Robert Pluim <rpluim@gmail.com> writes:
    >> 'minor-mode-list'?

    Lars> Oh, I thought that was an XEmacs compat thing, since it's added by this
    Lars> function:

    Lars> ---
    Lars> (defun add-minor-mode (toggle name &optional keymap after toggle-fun)
    Lars>   "Register a new minor mode.

    Lars> This is an XEmacs-compatibility function.  Use `define-minor-mode' instead.
    Lars> ---

    Lars> Does this doc string mean that one shouldn't use `add-minor-mode'
    Lars> directly, but only through `define-minor-mode'?  But that everything
    Lars> that `add-minor-mode' does isn't XEmacs compat stuff?

I think that docstring is misleading: define-minor-mode calls
add-minor-mode, and thus ends up updating minor-mode-list. It would be
nice if we could rely on that.

    Lars> Which could also conceivably be useful in other situations.
    >> 
    >> If you make changes here, could you arrange for some (buffer-local?)
    >> symbol somewhere to be updated when a minor mode is activated?
    >> Figuring out which minor modes are in effect is currently non-trivial.

    Lars> That does sound like a useful thing...  Since the major mode is
    Lars> determined by the `major-mode' variable, what about a new
    Lars> permanently-local variable `minor-modes'?  `define-minor-mode' would be
    Lars> responsible for adding/removing itself to the variable.

You mean the enable/disable function for the minor mode created by
define-minor-mode?

Robert

Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> I think that docstring is misleading: define-minor-mode calls
> add-minor-mode, and thus ends up updating minor-mode-list. It would be
> nice if we could rely on that.

Right.  I'll fix up the doc string.

>     Lars> That does sound like a useful thing...  Since the major mode is
>     Lars> determined by the `major-mode' variable, what about a new
>     Lars> permanently-local variable `minor-modes'?
>     Lars> `define-minor-mode' would be
>     Lars> responsible for adding/removing itself to the variable.
>
> You mean the enable/disable function for the minor mode created by
> define-minor-mode?

Yup.

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

Re: Smarter M-x that filters on major-mode

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1600 bytes --]

On Wed, Feb 10, 2021 at 08:50:10PM -0600, Stefan Kangas wrote:
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > Matt Armstrong <matt@rfc20.org> writes:
> >
> >> What if instead help showed all the interactive commands provided by
> >> the mode? What if M-x were smarter about highlighting mode specific
> >> commands?
> >
> > It's been discussed before -- somebody just has to implement one of the
> > various possibilities here.  The problem is that commands are only tied
> > very loosely to modes:
> >
> > (defun foo-thing ()
> >   (interactive)
> >   ...)
> >
> > will make `M-x fTAB' show `foo-thing' even if it's useless outside of
> > all other modes than `foo-mode'.  Conversely, `C-h m' in `foo-mode'
> > won't, as you mention, list `foo-thing' unless there's a binding for it.
> >
> > My suggestion is to introduce a new form:
> >
> > (defun foo-thing ()
> >   (command foo-mode)
> >   ...)
> >
> > This would be just like `interactive', but will do the right thing in
> > `M-x fTAB' and `C-h m' in modes derived from `foo-mode'.  (It could also
> > be a list of mode, of course, but that'd be more rare, is my guess.)
> 
> It would indeed be very useful to provide a mechanism to exclude
> commands from M-x that are useless outside of their major mode.

Nobody uses M-x in an explorative way?

IMO this is a bad idea for discoverability. What is (and what is not)
relevant to a mode is necessarily subject to a judgement call by
someone.

Some thought needs to go into how give users a way to escape that
confinement, I think.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

RE: [External] : Re: Smarter M-x that filters on major-mode

[Drew Adams]

> > It would indeed be very useful to provide a mechanism to exclude
> > commands from M-x that are useless outside of their major mode.
> 
> Nobody uses M-x in an explorative way?
> 
> IMO this is a bad idea for discoverability. What is (and what is not)
> relevant to a mode is necessarily subject to a judgement call by
> someone.
> 
> Some thought needs to go into how give users a way to escape that
> confinement, I think.

+1. Those are exactly 3 of the points I tried to make.

1. M-x is useful for more than invoking a single command.
2. Command relevance, even just for invocation, is
   relative, can be complicated, and cries out for human
   judgment (design, option, runtime, or all).
3. Users need to be able to control this themselves.

Re: Smarter M-x that filters on major-mode

[Óscar Fuentes]

<tomas@tuxteam.de> writes:

> Nobody uses M-x in an explorative way?
>
> IMO this is a bad idea for discoverability. What is (and what is not)
> relevant to a mode is necessarily subject to a judgement call by
> someone.
>
> Some thought needs to go into how give users a way to escape that
> confinement, I think.

I do use M-x in an explorative way all the time. I was the proponent of
the M-x filter when this was discussed a few years ago.

I don't want to see a zillion of irrelevant commands when I'm fishing
for interesting things on a given context.

This is about leaving out commands which only make sense when certain
minor or major mode is active. I can't see how this would hamper
learning by exploration.

Re: Smarter M-x that filters on major-mode

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 11 Feb 2021 20:03:01 +0100
> 
> I don't want to see a zillion of irrelevant commands when I'm fishing
> for interesting things on a given context.
> 
> This is about leaving out commands which only make sense when certain
> minor or major mode is active. I can't see how this would hamper
> learning by exploration.

Why filter them out? why not display them, but in the order that best
matches the user's intent, as Emacs perceives it?  That way, if the
guess is mostly right, the pertinent information is easy to find, but
if the guess is wrong, the information is still there, albeit a bit
further.

Re: Smarter M-x that filters on major-mode

[tomas]

[-- Attachment #1: Type: text/plain, Size: 802 bytes --]

On Thu, Feb 11, 2021 at 10:05:30PM +0200, Eli Zaretskii wrote:
> > From: Óscar Fuentes <ofv@wanadoo.es>
> > Date: Thu, 11 Feb 2021 20:03:01 +0100
> > 
> > I don't want to see a zillion of irrelevant commands when I'm fishing
> > for interesting things on a given context.
> > 
> > This is about leaving out commands which only make sense when certain
> > minor or major mode is active. I can't see how this would hamper
> > learning by exploration.
> 
> Why filter them out? why not display them, but in the order that best
> matches the user's intent, as Emacs perceives it?  That way, if the
> guess is mostly right, the pertinent information is easy to find, but
> if the guess is wrong, the information is still there, albeit a bit
> further.

Makes sense to me.

Thanks
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Why filter them out? why not display them, but in the order that best
> matches the user's intent, as Emacs perceives it?  That way, if the
> guess is mostly right, the pertinent information is easy to find, but
> if the guess is wrong, the information is still there, albeit a bit
> further.

That would also be nice (as an option), and with the tagging mechanism
in place, should be pretty easy to implement.

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

Re: Smarter M-x that filters on major-mode

[Jean Louis]

* tomas@tuxteam.de <tomas@tuxteam.de> [2021-02-11 11:41]:
> > It would indeed be very useful to provide a mechanism to exclude
> > commands from M-x that are useless outside of their major mode.
> 
> Nobody uses M-x in an explorative way?

Me, I use it all the time.

M-x *KEYWORD<TAB>

is what I mostly use to find keyboards. Sometimes I turn on ivy-mode
and just type a keyword with other keywords in combination to
research. I also forget names of my own commands like these:

rcd-update-locations-from-arc-1964-utm-36N-to-wgs-84
rcd-update-locations-from-dms-arc1960-tz-to-wgs84

So I have to find the right one to apply it.

> IMO this is a bad idea for discoverability. What is (and what is not)
> relevant to a mode is necessarily subject to a judgement call by
> someone.

The idea to narrow M-x commands only to mode relevant commands shall
be user option that may be turned on by the user, and definitely not
by default. 

Those global commands shall not be excluded if they do not belong to
specific mode.

It would be useful to avoid some interactive commands to apprea in M-x
and here I do not refer to just those not relevant to current
mode. I refer to those functions which cannot be otherwise invoked
alone but have to be designed as interactive for them to be called by
some key.

Example error when I bind non-interactive function to "/ f":

Debugger entered--Lisp error: (wrong-type-argument commandp hyperscope-filter)
  call-interactively(hyperscope-filter nil nil)
  command-execute(hyperscope-filter)

but if function is interactive that error does not appear.

Because the function works and is meant to work only under specific
conditions I would like to exclude that function from appearing in the
M-x list. Alone it does nothing, as it expects condition of derived
tabulated list.

If there is some way to do so now, and somebody knows about it, let me
know.

Jean

Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> I've had a related idea to make `M-X' (a.k.a. `M-S-x') run a version of
> `M-x' that *includes* only commands that are specifically relevant to
> the current major mode.

Ah, yes, hadn't thought of that, and that sounds very handy indeed.

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

Re: Smarter M-x that filters on major-mode

[Basil L. Contovounesios]

Stefan Kangas <stefankangas@gmail.com> writes:

> I only just now discovered that my completion framework (ivy) has had
> the exact same idea for M-S-x.  It filters all commands according to
> some heuristics, seemingly only showing commands beginning with whatever
> package prefix your mode is using.

With which command do you see this behaviour?  AFAIK, the Counsel
version of M-x only excludes commands with a no-counsel-M-x property,
and the Counsel version of C-h b does not by default exclude any key
sequence prefixes.

-- 
Basil

Re: Smarter M-x that filters on major-mode

[Stefan Kangas]

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

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> I only just now discovered that my completion framework (ivy) has had
>> the exact same idea for M-S-x.  It filters all commands according to
>> some heuristics, seemingly only showing commands beginning with whatever
>> package prefix your mode is using.
>
> With which command do you see this behaviour?  AFAIK, the Counsel
> version of M-x only excludes commands with a no-counsel-M-x property,
> and the Counsel version of C-h b does not by default exclude any key
> sequence prefixes.

Oops, turns out it is actually `smex-major-mode-commands'.  I should
have taken a look first, but I had forgotten that I had that package
installed.

Re: Smarter M-x that filters on major-mode

[Basil L. Contovounesios]

Stefan Kangas <stefankangas@gmail.com> writes:

> "Basil L. Contovounesios" <contovob@tcd.ie> writes:
>
>> Stefan Kangas <stefankangas@gmail.com> writes:
>>
>>> I only just now discovered that my completion framework (ivy) has had
>>> the exact same idea for M-S-x.  It filters all commands according to
>>> some heuristics, seemingly only showing commands beginning with whatever
>>> package prefix your mode is using.
>>
>> With which command do you see this behaviour?  AFAIK, the Counsel
>> version of M-x only excludes commands with a no-counsel-M-x property,
>> and the Counsel version of C-h b does not by default exclude any key
>> sequence prefixes.
>
> Oops, turns out it is actually `smex-major-mode-commands'.  I should
> have taken a look first, but I had forgotten that I had that package
> installed.

Ah yes, counsel-M-x also defers to amx/smex if those are installed.

-- 
Basil

Re: Experimentally unbind M-o on the trunk

[Yuri Khan]

On Thu, 11 Feb 2021 at 02:11, Matt Armstrong <matt@rfc20.org> wrote:

> What if having a key binding was just one possible way to make a command
> easy and convenient to find and invoke. What if there were other equally
> good ways, and we all thought it would be strange to bind a precious key
> to a command if it were rarely used in practice?
>
> Case in point: if a command isn't bound to a key it doesn't show up in
> help, so there is this pressure to bind everything that could possibly
> be useful to some person some day to some key. What if instead help
> showed all the interactive commands provided by the mode? What if M-x
> were smarter about highlighting mode specific commands?
>
> Perhaps exploring these kinds of ideas would be useful.

The mechanism you’re describing is called a menu.

Case in point: In almost every GUI program that follows the CUA
guidelines, you can invoke the File | Open command by pressing Alt+F
O. In some TUI programs you cannot use Alt+<letter> to open a
first-level menu, but you can do like F9 O C for Options |
Configuration. In Emacs, however, the actual GTK menu does not support
this kind of usage. (‘tmm-menubar’ does.)

Re: Experimentally unbind M-o on the trunk

[Matt Armstrong]

Yuri Khan <yuri.v.khan@gmail.com> writes:

> On Thu, 11 Feb 2021 at 02:11, Matt Armstrong <matt@rfc20.org> wrote:
>
>> What if having a key binding was just one possible way to make a command
>> easy and convenient to find and invoke. What if there were other equally
>> good ways, and we all thought it would be strange to bind a precious key
>> to a command if it were rarely used in practice?
>>
>> Case in point: if a command isn't bound to a key it doesn't show up in
>> help, so there is this pressure to bind everything that could possibly
>> be useful to some person some day to some key. What if instead help
>> showed all the interactive commands provided by the mode? What if M-x
>> were smarter about highlighting mode specific commands?
>>
>> Perhaps exploring these kinds of ideas would be useful.
>
> The mechanism you’re describing is called a menu.

Yes, in concept. I'm not sure it is clear how to use the classic GUI
menu mechanism to expose all possible useful Emacs interactive commands
in a given context.

I do keep the Emacs menu on, and lean on it to discover what a package
can do, expecially in packages I use infrequently. It tends to be good
at surfacing the basic commands, but not great at the power user stuff.

> Case in point: In almost every GUI program that follows the CUA
> guidelines, you can invoke the File | Open command by pressing Alt+F
> O. In some TUI programs you cannot use Alt+<letter> to open a
> first-level menu, but you can do like F9 O C for Options |
> Configuration. In Emacs, however, the actual GTK menu does not support
> this kind of usage. (‘tmm-menubar’ does.)

I think menus in the typical GUI sense have and even more severe issue
with limited space than key bindings do. Emacs' file menu includes
find-file, yet Emacs' key bindings expose all of these variants:

   C-x C-f         find-file
   C-x C-r         find-file-read-only
   C-x 4 f         find-file-other-window
   C-x 4 r         find-file-read-only-other-window
   C-x 5 f         find-file-other-frame
   C-x 5 r         find-file-read-only-other-frame
   C-x t f         find-file-other-tab
   C-x C-v         find-alternate-file

RE: [External] : Re: Experimentally unbind M-o on the trunk

[Drew Adams]

> I think menus in the typical GUI sense have and even more severe issue
> with limited space than key bindings do. Emacs' file menu includes
> find-file, yet Emacs' key bindings expose all of these variants:
> 
>    C-x C-f         find-file
>    C-x C-r         find-file-read-only
>    C-x 4 f         find-file-other-window
>    C-x 4 r         find-file-read-only-other-window
...

If you say "typical GUI" then yes, typically
menus are limited.

Menus don't have to be.  Just as you can have
zillions of command names, organized however
you like (e.g. those above all have to do with
visiting files, and start with `find-file'),
so you can have zillions of menus and menu
items in a menu tree or forest.

What makes a large command-name space usable
(navigable) is the power of _completion_.

Providing keyboard completion against menus,
even against all parts of menu paths, makes
the potential space of menus just as usable
and navigable - just as large - as that of
command names.
___

If you use library La Carte then you get
completion against entire paths to menu items,
which also means completion against menus at
any level (e.g. show all children of some
submenu).

If you use a completion feature such as
Icicles with La Carte than you can also
match against those paths in any number of
ways (regexp, fuzzy matching, whatever).

These tools also let you type input that
targets a particular menu item directly -
direct access, as opposed to drilling down
bit by bit.
___

https://www.emacswiki.org/emacs/LaCarte

https://www.emacswiki.org/emacs/Icicles

Re: Experimentally unbind M-o on the trunk

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Thu, 11 Feb 2021 11:55:29 +0700
> Cc: Eli Zaretskii <eliz@gnu.org>, Lars Magne Ingebrigtsen <larsi@gnus.org>, "Alfred M. Szmidt" <ams@gnu.org>, 
> 	Gregory Heytings <gregory@heytings.org>, Jean Louis <bugs@gnu.support>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> > Case in point: if a command isn't bound to a key it doesn't show up in
> > help, so there is this pressure to bind everything that could possibly
> > be useful to some person some day to some key. What if instead help
> > showed all the interactive commands provided by the mode? What if M-x
> > were smarter about highlighting mode specific commands?
> >
> > Perhaps exploring these kinds of ideas would be useful.
> 
> The mechanism you’re describing is called a menu.
> 
> Case in point: In almost every GUI program that follows the CUA
> guidelines, you can invoke the File | Open command by pressing Alt+F
> O.

The original suggestion was to make it easier to discover _unknown_
commands, whereas your menu analogy talks about invoking a _known_
command.  I don't see how this analogy helps, what did I miss?

Re: Experimentally unbind M-o on the trunk

[Matt Armstrong]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Yuri Khan <yuri.v.khan@gmail.com>
>> Date: Thu, 11 Feb 2021 11:55:29 +0700
>> Cc: Eli Zaretskii <eliz@gnu.org>, Lars Magne Ingebrigtsen <larsi@gnus.org>, "Alfred M. Szmidt" <ams@gnu.org>, 
>> 	Gregory Heytings <gregory@heytings.org>, Jean Louis <bugs@gnu.support>, 
>> 	Emacs developers <emacs-devel@gnu.org>
>> 
>> > Case in point: if a command isn't bound to a key it doesn't show up in
>> > help, so there is this pressure to bind everything that could possibly
>> > be useful to some person some day to some key. What if instead help
>> > showed all the interactive commands provided by the mode? What if M-x
>> > were smarter about highlighting mode specific commands?
>> >
>> > Perhaps exploring these kinds of ideas would be useful.
>> 
>> The mechanism you’re describing is called a menu.
>> 
>> Case in point: In almost every GUI program that follows the CUA
>> guidelines, you can invoke the File | Open command by pressing Alt+F
>> O.
>
> The original suggestion was to make it easier to discover _unknown_
> commands, whereas your menu analogy talks about invoking a _known_
> command.  I don't see how this analogy helps, what did I miss?

I think GUI menus help with discovering unknown commands by showing you
a list of them by category. I use Emacs menus this way, usually with
major modes I am unfamiliar with. Newer GUIs let you search for menu
items too.

The ideas Drew talked about elsewhere in this thread are similar, but
can typically handle more commands without overwhelming the user with
the possibilities (which I think was one of his points).

Re: Experimentally unbind M-o on the trunk

[Yuri Khan]

On Thu, 11 Feb 2021 at 21:02, Eli Zaretskii <eliz@gnu.org> wrote:

> > > Case in point: if a command isn't bound to a key it doesn't show up in
> > > help, so there is this pressure to bind everything that could possibly
> > > be useful to some person some day to some key. What if instead help
> > > showed all the interactive commands provided by the mode? What if M-x
> > > were smarter about highlighting mode specific commands?
> > >
> > > Perhaps exploring these kinds of ideas would be useful.
> >
> > The mechanism you’re describing is called a menu.
> >
> > Case in point: In almost every GUI program that follows the CUA
> > guidelines, you can invoke the File | Open command by pressing Alt+F
> > O.
>
> The original suggestion was to make it easier to discover _unknown_
> commands, whereas your menu analogy talks about invoking a _known_
> command.  I don't see how this analogy helps, what did I miss?

The discovery scenario is: I don’t know what I’m looking for, but I
can progressively narrow down the command space by choosing a submenu
at each step. Once I’ve found the command I need, I can execute it
right away and be done with it.

The next few times I need it, I vaguely know where (spatially) in the
menu it is. I then execute it by following the same path through the
menu.

If I use it frequently, I will notice the key binding displayed in the
right margin, memorize it, and switch to using it. At this point, the
menu has done its job.

However, not all commands have bindings. And a conventional
application makes every command quickly accessible via Alt+<letter>
<letter>…, or <Alt> <letter> <letter>…, or F10 <letter> <letter>…,
with all commands in every given submenu having unique mnemonics. As
an example, every time I log onto an unfamiliar ssh server and start
Midnight Commander, I know to press F9 o c t Enter F9 o p y Enter to
configure it to my liking.

Being able to execute commands via menu and mnemonics reduces the need
to bind commands. I will even go so far as to claim that such Emacs
keymaps as C-x v are poor man’s menus — they let the user execute
commands using long key sequences without the benefit of providing
discovery and visual reassurance. (Cue Drew pitching Icicles key
completion.)

Re: Experimentally unbind M-o on the trunk

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Thu, 11 Feb 2021 23:08:53 +0700
> Cc: Matt Armstrong <matt@rfc20.org>, Lars Magne Ingebrigtsen <larsi@gnus.org>, "Alfred M. Szmidt" <ams@gnu.org>, 
> 	Gregory Heytings <gregory@heytings.org>, Jean Louis <bugs@gnu.support>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> The discovery scenario is: I don’t know what I’m looking for, but I
> can progressively narrow down the command space by choosing a submenu
> at each step. Once I’ve found the command I need, I can execute it
> right away and be done with it.

That only works well if you can guess, up front, which top-level menu
item has the command you are looking for.  Which is not easy, except
for a few trivial operations, especially with very large and
feature-rich programs like Emacs.  Traversing the entire menu
structure looking for what you want is not my idea of good time, even
though I have much more patience doing that than most newbies
nowadays.

Of course, putting more command on our menus cannot possibly hurt,
quite the contrary, so I'm not arguing against that.  I just very much
doubt we will be able to put there any significant fraction of the
hundreds of important commands we have to really make a difference.
To say nothing of the fact that there's a fashion out there to turn
off the menu bar very early in the user's learning curve.

Therefore, the idea to make discovery easier by means other than the
menus is a good one -- provided that we can find a way of implementing
that in a convenient and unintrusive manner.

> I will even go so far as to claim that such Emacs keymaps as C-x v
> are poor man’s menus — they let the user execute commands using long
> key sequences without the benefit of providing discovery and visual
> reassurance.

??? Typing '?' or C-h in the middle of any key sequence should (and
usually does) provide discovery.

RE: [External] : Re: Experimentally unbind M-o on the trunk

[Drew Adams]

> That only works well if you can guess, up front, which top-level menu
> item has the command you are looking for.  Which is not easy, except
> for a few trivial operations, especially with very large and
> feature-rich programs like Emacs.  Traversing the entire menu
> structure looking for what you want is not my idea of good time, even
> though I have much more patience doing that than most newbies
> nowadays.

If you have completion against full menu paths,
as I mentioned with the example of La Carte,
and if you can match arbitrary parts of any
completion candidate, as I mentioned with the
example of Icicles, then it's not at all a
chore to get to _any_ part of the _complete_
menu-bar forest.

E.g., I see this if I type just `save' to the
prompt from `lacarte-execute-menu-command':

Buffers > Frames > SAVE                                                                           
Buffers > SAVE  %                                                                                 
Do Re Mi > Save Frame Configuration          (C-x t .)                                                     
File > Bookmarks > Here (This File/Buffer) >
  Save Bookmarks Here To Bookmark File...    (C-x x C-s)            
File > Bookmarks > Save Bookmarks As...      (C-x x w)                                                 
File > Bookmarks > Save Bookmarks            (C-x x s)                                                       
File > Open Recent > Save list now                                                                
File > Save As...                            (C-x C-w)                                                                       
Icicles > + Remove Saved Candidate Set...                                                         
Icicles > Add/Update Saved Candidate Set...                                                       
Icicles > Save String to Variable...                                                              
Options > Customize Emacs > Saved Options                                                         
Options > Icicles > Toggle > Highlighting Saved Candidates                                        
Options > Save Frame Configs (DoReMi)                                                             
Options > Save Options                                                                            
Options > Save Place in Files between Sessions                                                    
Tools > Spell Checking > Save Dictionary

(That's with substring completion.  And some of
those menus are from my code.)

That's a pretty darn quick way to search the entire
menu-bar forest, to see all menu items whose paths
contain the word "save".

And I can quickly narrow further, of course.

> Of course, putting more command on our menus cannot possibly hurt,
> quite the contrary, so I'm not arguing against that.  I just very much
> doubt we will be able to put there any significant fraction of the
> hundreds of important commands we have to really make a difference.

Not sure what kind of difference is being called for.
But you can add any number of menus and menu items,
without creating a user-access problem.  Users can
handle just as many commands with menus as they can
with just `M-x' or keyboard keys.  Provided they have
useful completion tools, that is.

> To say nothing of the fact that there's a fashion out there to
> turn off the menu bar very early in the user's learning curve.

That fashion might be related to current weak menu
support by Emacs - perhaps especially for 3rd-party
packages.

But sure, many developer users of Emacs (thus many
Emacs users) might not be accustomed to using menus
heavily.  They can learn, if menu support is improved,
especially access using completion.

> Typing '?' or C-h in the middle of any key sequence
> should (and usually does) provide discovery.

Yup.  very good.  Likewise, things like key completion
(Icicles), `keysee.el', and `which-key.el'.
___

https://www.emacswiki.org/emacs/KeySee

Re: [External] : Re: Experimentally unbind M-o on the trunk

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "bugs@gnu.support" <bugs@gnu.support>, "ams@gnu.org" <ams@gnu.org>,
>         "emacs-devel@gnu.org" <emacs-devel@gnu.org>,
>         "gregory@heytings.org"
> 	<gregory@heytings.org>,
>         "matt@rfc20.org" <matt@rfc20.org>, "larsi@gnus.org"
> 	<larsi@gnus.org>
> Date: Thu, 11 Feb 2021 17:28:41 +0000
> 
> E.g., I see this if I type just `save' to the
> prompt from `lacarte-execute-menu-command':
> 
> Buffers > Frames > SAVE                                                                           
> Buffers > SAVE  %                                                                                 
> Do Re Mi > Save Frame Configuration          (C-x t .)                                                     
> File > Bookmarks > Here (This File/Buffer) >
>   Save Bookmarks Here To Bookmark File...    (C-x x C-s)            
> File > Bookmarks > Save Bookmarks As...      (C-x x w)                                                 
> File > Bookmarks > Save Bookmarks            (C-x x s)                                                       
> File > Open Recent > Save list now                                                                
> File > Save As...                            (C-x C-w)                                                                       
> Icicles > + Remove Saved Candidate Set...                                                         
> Icicles > Add/Update Saved Candidate Set...                                                       
> Icicles > Save String to Variable...                                                              
> Options > Customize Emacs > Saved Options                                                         
> Options > Icicles > Toggle > Highlighting Saved Candidates                                        
> Options > Save Frame Configs (DoReMi)                                                             
> Options > Save Options                                                                            
> Options > Save Place in Files between Sessions                                                    
> Tools > Spell Checking > Save Dictionary
> 
> (That's with substring completion.  And some of
> those menus are from my code.)

How is this different from "M-x save- TAB"?

> That's a pretty darn quick way to search the entire
> menu-bar forest, to see all menu items whose paths
> contain the word "save".

The goal was not to search the menus, the goal was to discover
commands.  Menus were suggested as a means towards that end.  Let's
not confuse the two.

RE: [External] : Re: Experimentally unbind M-o on the trunk

[Drew Adams]

> > E.g., I see this if I type just `save' to the
> > prompt from `lacarte-execute-menu-command':
> >
> > Buffers > Frames > SAVE
> > Buffers > SAVE  %
> > Do Re Mi > Save Frame Configuration          (C-x t .)
> > File > Bookmarks > Here (This File/Buffer) >
> >   Save Bookmarks Here To Bookmark File...    (C-x x C-s)
> > File > Bookmarks > Save Bookmarks As...      (C-x x w)
> > File > Bookmarks > Save Bookmarks            (C-x x s)
> > File > Open Recent > Save list now
> > File > Save As...                            (C-x C-w)
> > Icicles > + Remove Saved Candidate Set...
> > Icicles > Add/Update Saved Candidate Set...
> > Icicles > Save String to Variable...
> > Options > Customize Emacs > Saved Options
> > Options > Icicles > Toggle > Highlighting Saved Candidates
> > Options > Save Frame Configs (DoReMi)
> > Options > Save Options
> > Options > Save Place in Files between Sessions
> > Tools > Spell Checking > Save Dictionary
> >
> > (That's with substring completion.  And some of
> > those menus are from my code.)
> 
> How is this different from "M-x save- TAB"?

I don't understand the question.  The context was
being able to efficiently use menus.

It's not about opposing use of menus to use of
command-names.  It's about showing that completion
of menus offers the same benefits as completion of
command names.

This was a response to your statement to the effect
that it's not possible to use menus efficiently,
particularly to be able to access something anywhere
in the entire menu forest (as opposed to within a
particular menu).

You had said, "That only works well if you can guess,
up front, which top-level menu item has the command
you are looking for."

I tried to show that that's not inherently the case.

> > That's a pretty darn quick way to search the entire
> > menu-bar forest, to see all menu items whose paths
> > contain the word "save".
> 
> The goal was not to search the menus, the goal was to discover
> commands.  Menus were suggested as a means towards that end.  Let's
> not confuse the two.

Your statement was in reply to this:

  The discovery scenario is: I don't know what I'm looking for, but I
  can progressively narrow down the command space by choosing a submenu
  at each step. Once I've found the command I need, I can execute it
  right away and be done with it.

I read that with found-the-command meaning just
getting access to the command.  I thought/think
Yuri was saying that menus are a good way to
discover how to do something.

Finding out the name of the command that corresponds
to a given menu item is something else.  I didn't
take that to be what Yuri meant by discovering the
command.

But that too can be helped with the same or similar
tools.

For example, with Icicles you can just hit a key to
get the command name of any of those menu completion
candidates.

In fact, you can see their full doc strings in *Help*,
on demand while menu-completing.  And even without
doing that, just by cycling among candidates you can
see short help about their commands in the mode line
of buffer *Completions*.

Re: Experimentally unbind M-o on the trunk

[Yuri Khan]

On Thu, 11 Feb 2021 at 23:58, Eli Zaretskii <eliz@gnu.org> wrote:

> > I will even go so far as to claim that such Emacs keymaps as C-x v
> > are poor man’s menus — they let the user execute commands using long
> > key sequences without the benefit of providing discovery and visual
> > reassurance.
>
> ??? Typing '?' or C-h in the middle of any key sequence should (and
> usually does) provide discovery.

Not really. In a fresh ‘emacs -Q’, when I press ‘C-x ?’, I get a help
buffer that has three logical pages and is 10.5 screenfuls long. In
the discovery scenario, which supposes I don’t know what I’m looking
for but will know when I see it, I have to scroll through all that
until I find the ‘C-x v d’ binding I was looking for. It says,
literally:

    C-x v d    vc-dir

so if I don’t already know vc- means version control, I may not
recognize that command as the one I want.

Also, importantly, when I ask for help, I cannot proceed to
immediately execute the command I found, nor continue the discovery. I
have to re-type the sequence from the start. (I can also click on the
blue underlined text, which does not execute the command but displays
extended help on it. Thanks, Emacs, how do I go back? There’s no ←
icon on the toolbar, and the History Back button on my mouse causes a
“<mouse-8> is undefined” message in the echo area, and the context
menu mouse button marks a region. (Out-of-character: Yes, I know about
‘l’ and clicking the (Help) button in the modeline. My character
doesn’t.))

Compare with the menu: Tools (which, while looking suspiciously like
the “everything else” bin, is likely to contain the functionality I
want) → Version Control (yes!) → VC Dir (somewhat poorly named but
okay). *This* is discovery.

On a semi-related note, how do I go back up from a submenu in ‘tmm-menubar’?

RE: [External] : Re: Experimentally unbind M-o on the trunk

[Drew Adams]

> how do I go back up from a submenu in ‘tmm-menubar’?

Can't answer for tmm-menubar.

But for La Carte, there's no up or down.  You can
always have a global view or a local view, just
by typing a pattern to complete against.

If you want to think in terms of going up, just
delete the part of your search pattern that
matches below the parent you want to go-up to.

Re: Experimentally unbind M-o on the trunk

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Fri, 12 Feb 2021 00:53:46 +0700
> Cc: Matt Armstrong <matt@rfc20.org>, Lars Magne Ingebrigtsen <larsi@gnus.org>, "Alfred M. Szmidt" <ams@gnu.org>, 
> 	Gregory Heytings <gregory@heytings.org>, Jean Louis <bugs@gnu.support>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> > ??? Typing '?' or C-h in the middle of any key sequence should (and
> > usually does) provide discovery.
> 
> Not really. In a fresh ‘emacs -Q’, when I press ‘C-x ?’, I get a help
> buffer that has three logical pages and is 10.5 screenfuls long.

Yes, and that's bad because...?

Of course, any patches that would succeed in somehow guessing what the
user is after, and presenting the alternatives in a smarter order --
any such patches will be very welcome.  But saying that there's no
discovery at all is a bit extreme, don't you think?

> In the discovery scenario, which supposes I don’t know what I’m
> looking for but will know when I see it, I have to scroll through
> all that until I find the ‘C-x v d’ binding I was looking for. It
> says, literally:
> 
>     C-x v d    vc-dir
> 
> so if I don’t already know vc- means version control, I may not
> recognize that command as the one I want.

It's easy to find examples that prove your point if you really want
to.  But similar issues happen with menus, although menu items are
usually longer, so such issues are more rare.  But they still exist.
For example, what is "Tools->Read Net News" about? are you sure a user
who doesn't know about Gnus will immediately understand what that
does?  Or how ab out "Edit->Paste from Kill menu"? or
"Options->Customize Emacs->Faces Matching...".  Etc. etc. -- lack of
basic knowledge always requires some kind of bootstrap-like process
until you know enough of the basics to be able to tell in advance what
you need to look for.

> Also, importantly, when I ask for help, I cannot proceed to
> immediately execute the command I found, nor continue the discovery. I
> have to re-type the sequence from the start.

You lost me here.  The list popped up when you type '?' shows what you
should type -- that's "proceed to immediately execute the command you
found".  You should retype it, yes, but what would you suggest
instead? ask the user to remember what was typed before the question
mark?

> (I can also click on the blue underlined text, which does not
> execute the command but displays extended help on it. Thanks, Emacs,
> how do I go back?

Back from where?  You didn't go anywhere, you were just shown help.
Just continue what you were typing.  Emacs isn't modal, at least not
normally, so "going back" from what it pops up makes little sense.

> There’s no ← icon on the toolbar

But there's that "[back]" button at the end of the help text...

> and the History Back button on my mouse causes a “<mouse-8> is
> undefined” message in the echo area, and the context menu mouse
> button marks a region. (Out-of-character: Yes, I know about ‘l’ and
> clicking the (Help) button in the modeline. My character doesn’t.))

Are we still discussing discoverability, or are we venting?  How is
the fact that your system has a misconfigured mouse relevant to the
issue at hand -- which was discoverability?

And again: patches to improve the UX are more than welcome.

> Compare with the menu: Tools (which, while looking suspiciously like
> the “everything else” bin, is likely to contain the functionality I
> want) → Version Control (yes!) → VC Dir (somewhat poorly named but
> okay). *This* is discovery.

Of course! you've cooked the example, so of course it serves you well.

Now try "C-x d" and tell me where you find some operation.

> On a semi-related note, how do I go back up from a submenu in ‘tmm-menubar’?

Why should anyone use tmm-menubar when we have menus on all types of
displays?  (And no, I don't know, I never used tmm-menubar.)

Re: Experimentally unbind M-o on the trunk

[Yuri Khan]

On Fri, 12 Feb 2021 at 02:26, Eli Zaretskii <eliz@gnu.org> wrote:

> > > ??? Typing '?' or C-h in the middle of any key sequence should (and
> > > usually does) provide discovery.
> >
> > Not really. In a fresh ‘emacs -Q’, when I press ‘C-x ?’, I get a help
> > buffer that has three logical pages and is 10.5 screenfuls long.
>
> Yes, and that's bad because...?

I’m ranting about a particular kind of discovery here, where you
progressively choose among a small number of possibilities. When
looking for C-x v d, I don’t need to know about 100+ characters I can
enter via C-x 8. Nor the 20+ commands starting with C-x C-k. In
progressive discovery, those would be collapsed to a “C-x 8: insert
special characters” and “C-x C-k: keyboard macros”.

> > Also, importantly, when I ask for help, I cannot proceed to
> > immediately execute the command I found, nor continue the discovery. I
> > have to re-type the sequence from the start.
>
> You lost me here.  The list popped up when you type '?' shows what you
> should type -- that's "proceed to immediately execute the command you
> found".  You should retype it, yes, but what would you suggest
> instead? ask the user to remember what was typed before the question
> mark?

You’re treating the act of typing a sequence of keys as an atomic
operation. For you, it probably is. You start from a known place,
navigate the three keymaps in a series of leaps, arrive at your
desired destination. A novice user does not think or work like that.
C-x, v, and d are three distinct jumps. After each jump, they want to
stop and look around, in order to decide where to head next. But the
act of looking around teleports them back to where they started.

> > (I can also click on the blue underlined text, which does not
> > execute the command but displays extended help on it. Thanks, Emacs,
> > how do I go back?
>
> Back from where?  You didn't go anywhere, you were just shown help.
> Just continue what you were typing.  Emacs isn't modal, at least not
> normally, so "going back" from what it pops up makes little sense.

Before I was shown help for, let’s say, ‘dired’, the same help buffer
contained a list of commands.

> > There’s no ← icon on the toolbar
>
> But there's that "[back]" button at the end of the help text...

Yes, and getting to that requires either knowing that it’s there, or
scrolling through the whole list.

> > and the History Back button on my mouse causes a “<mouse-8> is
> > undefined” message in the echo area, and the context menu mouse
> > button marks a region. (Out-of-character: Yes, I know about ‘l’ and
> > clicking the (Help) button in the modeline. My character doesn’t.))
>
> Are we still discussing discoverability, or are we venting?  How is
> the fact that your system has a misconfigured mouse relevant to the
> issue at hand -- which was discoverability?

Partly venting, yes. In what way is my mouse misconfigured? Are you
telling me there is a mouse button binding in ‘help-mode’ for
‘help-go-back’ but it’s assuming a different button than <mouse-8>?

> > On a semi-related note, how do I go back up from a submenu in ‘tmm-menubar’?
>
> Why should anyone use tmm-menubar when we have menus on all types of
> displays?  (And no, I don't know, I never used tmm-menubar.)

As I mentioned earlier, tmm-menubar has the desirable property of
supporting navigation through menus with mnemonic keys. The GTK menu
only lets me select items with the mouse or arrow keys.

Re: Experimentally unbind M-o on the trunk

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Fri, 12 Feb 2021 03:32:52 +0700
> Cc: Matt Armstrong <matt@rfc20.org>, Lars Magne Ingebrigtsen <larsi@gnus.org>, "Alfred M. Szmidt" <ams@gnu.org>, 
> 	Gregory Heytings <gregory@heytings.org>, Jean Louis <bugs@gnu.support>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> > > Not really. In a fresh ‘emacs -Q’, when I press ‘C-x ?’, I get a help
> > > buffer that has three logical pages and is 10.5 screenfuls long.
> >
> > Yes, and that's bad because...?
> 
> I’m ranting about a particular kind of discovery here, where you
> progressively choose among a small number of possibilities. When
> looking for C-x v d, I don’t need to know about 100+ characters I can
> enter via C-x 8.

Of course, you do: you typed "C-x", not "C-x v", so who knows what you
are looking for.

How did you know to type "C-x" anyway? why not "M-x" or "C-c"?

> In progressive discovery, those would be collapsed to a “C-x 8:
> insert special characters” and “C-x C-k: keyboard macros”.

Progressive discovery in Emacs begins with "M-x apropos", not with
"C-x".

> > But there's that "[back]" button at the end of the help text...
> 
> Yes, and getting to that requires either knowing that it’s there, or
> scrolling through the whole list.

If you actually _read_ the text that's presented to you, you _will_
get to the end.

> The GTK menu only lets me select items with the mouse or arrow keys.

Then it's a problem with GTK.  Consider using a different toolkit, or
report a bug against GTK.

Re: Experimentally unbind M-o on the trunk

[Yuri Khan]

On Fri, 12 Feb 2021 at 03:43, Eli Zaretskii <eliz@gnu.org> wrote:

> > The GTK menu only lets me select items with the mouse or arrow keys.
>
> Then it's a problem with GTK.  Consider using a different toolkit, or
> report a bug against GTK.

It’s not a problem with GTK. It’s a problem with the application
feeding it item strings without mnemonics marked up.

Re: Experimentally unbind M-o on the trunk

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Fri, 12 Feb 2021 11:38:27 +0700
> Cc: Matt Armstrong <matt@rfc20.org>, Lars Magne Ingebrigtsen <larsi@gnus.org>, "Alfred M. Szmidt" <ams@gnu.org>, 
> 	Gregory Heytings <gregory@heytings.org>, Jean Louis <bugs@gnu.support>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> On Fri, 12 Feb 2021 at 03:43, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > > The GTK menu only lets me select items with the mouse or arrow keys.
> >
> > Then it's a problem with GTK.  Consider using a different toolkit, or
> > report a bug against GTK.
> 
> It’s not a problem with GTK. It’s a problem with the application
> feeding it item strings without mnemonics marked up.

<Shrug> It works well on MS-Windows.  Patches for GTK are welcome, of
course.

Re: Experimentally unbind M-o on the trunk

[Yuri Khan]

On Thu, 11 Feb 2021 at 23:58, Eli Zaretskii <eliz@gnu.org> wrote:

> That only works well if you can guess, up front, which top-level menu
> item has the command you are looking for.  Which is not easy, except
> for a few trivial operations, especially with very large and
> feature-rich programs like Emacs.  Traversing the entire menu
> structure looking for what you want is not my idea of good time, even
> though I have much more patience doing that than most newbies
> nowadays.

Yet, traversing a hierarchical structure, trying to guess the correct
path, is exactly what I tend to do when looking for something. If the
hierarchy maps well to my guesses, I find things quickly and am happy.
If I have to use search, I feel disappointed.

I am not alone in this. We are a subset of computer users. We are the
same people who want to click a building on the map rather than type a
company name into the search box. (My pet theory is that this
preference to {search|find icons|traverse hierarchies} correlates to
the {auditory|visual|kinaesthetic} learning modality.)

Re: Experimentally unbind M-o on the trunk

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Fri, 12 Feb 2021 01:07:07 +0700
> Cc: Matt Armstrong <matt@rfc20.org>, Lars Magne Ingebrigtsen <larsi@gnus.org>, "Alfred M. Szmidt" <ams@gnu.org>, 
> 	Gregory Heytings <gregory@heytings.org>, Jean Louis <bugs@gnu.support>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> Yet, traversing a hierarchical structure, trying to guess the correct
> path, is exactly what I tend to do when looking for something. If the
> hierarchy maps well to my guesses, I find things quickly and am happy.
> If I have to use search, I feel disappointed.
> 
> I am not alone in this. We are a subset of computer users. We are the
> same people who want to click a building on the map rather than type a
> company name into the search box. (My pet theory is that this
> preference to {search|find icons|traverse hierarchies} correlates to
> the {auditory|visual|kinaesthetic} learning modality.)

Emacs has menus (and the tool bar) for those like you.  We are not
going to remove them, at least not on my watch.

But menus are not the only way to discover Emacs features, and at
least for some not the most efficient one.  The reason is simple: not
every command and variable can be found via menus.  By contrast, the
Help commands can find _any_ command, variable, face, symbol, and even
a more-or-less free-text subject discussed somewhere in the docs.  So
the coverage is much better than that of menus.

I of course agree that wading through the wealth of the potential hits
can be frustrating at times, if you don't know the right words or
phrases.  That is why we would like to improve these features, and
that is why any patches in this area will be very welcome.  But
dismissing the Emacs Help system because it sometimes overwhelms you
is not useful, because menus will never be able to replace the Help
system.

(And please consider voicing your opinions on Reddit, where there's a
consistent propaganda to turn off the menus, including for newbies who
may not know what is VC.)

Re: Experimentally unbind M-o on the trunk

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2021-02-10 18:46]:
> > From: "Alfred M. Szmidt" <ams@gnu.org>
> > Date: Wed, 10 Feb 2021 10:12:20 -0500
> > Cc: gregory@heytings.org, larsi@gnus.org, emacs-devel@gnu.org
> > 
> > Sorry, I atleast have a hard time taking these suggestion to remap
> > long standing keybindings randomly seriously, likewise suggestions
> > that users should just resort to M-x or binding them themselves.
> 
> Can you explain why you are so worried about Emacs changing the
> default key bindings?  Given that it takes one line in your .emacs to
> restore any binding you care for, why argue so much about the
> defaults?
> 
> This question also goes to everyone else in this long dispute who
> wants their precious key bindings preserved: why is such a long
> discussion needed when it is so easy to restore, in your init file, a
> binding you want preserved?

I do not even know literal names of commands run by some keys. And
some keys I am invoking while even knowing consciously what I am
doing. Some key commands I would not be able to tell somebody with
certainty without having keyboard in front of me. If I look at
keyboard I could also forget which command is doing what, so often I
will rather not look and just invoke it.

For me, a keyboard is extension part of my cyborg body, I think with
it, but not necessarily know all of its Emacs function names by memory.

When a key binding is missing I would not probably know what was it. I
would have a feeling something is missing but not necessarily remember
consciously what it would be.

It would be then hard to say which function to bind on which key.

Jean

Re: Experimentally unbind M-o on the trunk

[Eli Zaretskii]

> Date: Thu, 11 Feb 2021 08:15:44 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: "Alfred M. Szmidt" <ams@gnu.org>, gregory@heytings.org,
>   larsi@gnus.org, emacs-devel@gnu.org
> 
> > This question also goes to everyone else in this long dispute who
> > wants their precious key bindings preserved: why is such a long
> > discussion needed when it is so easy to restore, in your init file, a
> > binding you want preserved?
> 
> I do not even know literal names of commands run by some keys.

That's so easy to find out that I don't see how this factoid is of any
relevance to the issue at hand.

> When a key binding is missing I would not probably know what was it. I
> would have a feeling something is missing but not necessarily remember
> consciously what it would be.

You can always ask, if NEWS and other features don't help.

Re: Experimentally unbind M-o on the trunk

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2021-02-11 17:05]:
> > Date: Thu, 11 Feb 2021 08:15:44 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: "Alfred M. Szmidt" <ams@gnu.org>, gregory@heytings.org,
> >   larsi@gnus.org, emacs-devel@gnu.org
> > 
> > > This question also goes to everyone else in this long dispute who
> > > wants their precious key bindings preserved: why is such a long
> > > discussion needed when it is so easy to restore, in your init file, a
> > > binding you want preserved?
> > 
> > I do not even know literal names of commands run by some keys.
> 
> That's so easy to find out that I don't see how this factoid is of any
> relevance to the issue at hand.

For example I have used C-o so often in my life, daily, but only
recently from this mailing list found that it is bound to
`open-line'. I know what it does but I never called it "open line". I
hope that you get the concept. I have not been speaking about it or
telling anybody, I just know it intuitively. Probably I have learned
it in past and forgot consciously what I learned.

Would then surprisingly C-o disappear without me ever knowing that it
is `open-line' I would not be able in the new version of Emacs to just
by using my memory bind it to `open-line' as I was not aware of the
function `open-line' in the first place. In memory there is C-o but I
would not know by memory what is the name of the function to bind it
on the key.

In `mutt' email client there are similar commands bound to keys that I
use for many years. Similarly I would not know by memory which command
is bound to which key. I know T to tag messages but I do not know that
it's command is `tag-pattern' (I looked it up now just to know which
one it is).

For unbinding of the `M-o' I find it personally appropriate as it does
not have use globally. I think it works well only in the enriched
mode.

Unbinding C-z would give me problems if I would be surprised without
reading about it on this mailing list. So I feel that probably
thousands of users would be similarly surprised and they may not read
this mailing list. So I rather think that surprising changes impact
globally Emacs users. My personal use or adoption of new things in
Emacs I may consider sometimes easier than what global users would
consider.

I hope that from this you understand the concept of remembering the
functionality without remembering the literal names of a command.

Jean

Re: Experimentally unbind M-o on the trunk

[Eli Zaretskii]

> Date: Thu, 11 Feb 2021 21:55:40 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: ams@gnu.org, gregory@heytings.org, larsi@gnus.org,
>   emacs-devel@gnu.org
> 
> Would then surprisingly C-o disappear without me ever knowing that it
> is `open-line' I would not be able in the new version of Emacs to just
> by using my memory bind it to `open-line' as I was not aware of the
> function `open-line' in the first place. In memory there is C-o but I
> would not know by memory what is the name of the function to bind it
> on the key.

If this ever happens, you should be able to find the information by
searching NEWS for "C-o".

So I think you are inventing a problem that doesn't exist.

> I hope that from this you understand the concept of remembering the
> functionality without remembering the literal names of a command.

I hope you now realize that changes in bindings like that are not
catastrophes, and you can easily resurrect whatever binding you fancy,
using NEWS and other means to find out the names of the commands you
never bothered to discover.

(Btw, does this mean you never use "C-h k" to read about the commands
you invoke?  Never, ever?  Because if you do, the name of the command
is spelled out there, on the very first lines of the *Help* display.)

Re: Experimentally unbind M-o on the trunk

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2021-02-11 22:47]:
> (Btw, does this mean you never use "C-h k" to read about the commands
> you invoke?  Never, ever?  Because if you do, the name of the command
> is spelled out there, on the very first lines of the *Help*
> display.)

I use it very often, but I do not memorize names of functions bound to
keys. For example I used C-a so many times today but it is my first
time right now, during this writing to see that the function name is
literally `move-beginning-of-line'. I know that C-a moves cursor on
beginning of line but the name of function I never memorize. I know
what it does. That C-f moves cursor forward I know, but that function
is called `forward-char' I did not know it until now. If any of those
keys would suddenly disappear I would not be able to easily place 2
lines and set the commands on those keys.

If few essential keys would be removed that I use all the time, I
would most probably get lost or confused for reasons explained. Maybe
I would find it in NEWS, but I could as well doubt which key was where
due to muscle memories and not conscious memory or remembering of
literal function names on specific keys. Putting back keys where they
were would not be simple for me, far from simple, it would be complex
and if there would be many changed keys at once it would be a complete
disaster.

You said it is simple. Of course it is simple for you, as you are main
developer, you have different memorization of Emacs functions than
average user.

For the sake of users you should or could try understanding their way
of using Emacs and try looking from their own view points, not only
from your advanced view point.

Jean

Re: Experimentally unbind M-o on the trunk

[Eli Zaretskii]

> Date: Thu, 11 Feb 2021 23:20:17 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: ams@gnu.org, gregory@heytings.org, larsi@gnus.org,
>   emacs-devel@gnu.org
> 
> You said it is simple. Of course it is simple for you, as you are main
> developer, you have different memorization of Emacs functions than
> average user.

If you think that I remember by heart every single command and
variable in Emacs, then you are mistaken.  I don't, as my memory is
nowhere near what you seem to assume, and that is why I use the Emacs
Help system _a_lot_.

> For the sake of users you should or could try understanding their way
> of using Emacs and try looking from their own view points, not only
> from your advanced view point.

I'm an Emacs user just like you, so my POV is not very different.

Re: Experimentally unbind M-o on the trunk

[Eli Zaretskii]

> From: "Alfred M. Szmidt" <ams@gnu.org>
> Date: Wed, 10 Feb 2021 03:44:23 -0500
> Cc: larsi@gnus.org, emacs-devel@gnu.org
> 
> If M-o is to become unbound, how does one center a line or a
> paragraph?  Those are on M-o M-s and M-o M-S respectively.

You can always bind these commands back to those keys, if you use them
a lot, couldn't you?

Re: Experimentally unbind M-o on the trunk

[Jean Louis]

* Gregory Heytings <gregory@heytings.org> [2021-02-09 15:30]:
> > That is, I propose that we remove the `M-o' binding on the trunk for one
> > month, and see how many (if any) complaints we get.
> 
> Perhaps replacing its binding with a message "The M-o key has been
> experimentally unbound, please M-x report-emacs-bug if you need it" would be
> even better?

It is not about complaints only. The M-o key is for face menu and it
is better to rethink why is M-o globally set and why not only in the
specific mode where those face menus make sense.

The one problem with unbinding it I can see only with {M-o M-s} to
center the line. I find it convenient useful in any text mode. Apart
from line centering I think that M-o as prefix should not be globally
bound in the other text modes but enriched modes.

Many of my notes are in the enriched format that is stored in the
database, so the M-o shall REMAIN BOUND in the enriched mode, but
definitely need not be globally bound like it is now.

Jean

RE: [External] : Re: Experimentally unbind M-o on the trunk

[Drew Adams]

> The M-o key is for face menu and it is better to
> rethink why is M-o globally set and why not only in the
> specific mode where those face menus make sense.

Facemenu commands make sense in most modes (nearly all?).

That said, I too would suggest freeing up `M-o'.

And if it does get freed from being bound by default 
then I'd suggest reserving it for 3rd-party code.

RE: [External] : Re: Experimentally unbind M-o on the trunk

[Stefan Kangas]

Drew Adams <drew.adams@oracle.com> writes:

> That said, I too would suggest freeing up `M-o'.
>
> And if it does get freed from being bound by default
> then I'd suggest reserving it for 3rd-party code.

Why not use it for `other-window'?  Seems like a good idea, and arguably
a better choice than `C-x o' for such a common command.

Re: [External] : Re: Experimentally unbind M-o on the trunk

[Clément Pit-Claudel]

On 2/10/21 11:37 AM, Drew Adams wrote:
> Facemenu commands make sense in most modes (nearly all?).

Does it make sense in modes that use font-lock?  I see "Font-lock mode will override any faces you set in this buffer".

RE: [External] : Re: Experimentally unbind M-o on the trunk

[Drew Adams]

> > Facemenu commands make sense in most modes (nearly all?).
> 
> Does it make sense in modes that use font-lock?  I see "Font-lock mode
> will override any faces you set in this buffer".

1. Yes, some of the facemenu commands make sense
in font-locked buffers.

See menu Edit > Text Properties.  (Not all
commands on that menu are for facemenu, but
some are.)

2. What's more, facemenu could itself be improved
to (optionally?) affect also the value of
property `font-lock-face', as well as `face'.
(Haven't looked into that - just a thought.)

3. My little library facemenu+.el adds facemenu
commands that work well with `font-lock-mode'.
E.g.:

`facemenup-set-face-attribute'
`facemenup-set-face-attribute-at-mouse'
`facemenup-set-face-attribute-at-point'
`facemenup-set-face-bg-RGB-at-mouse'
`facemenup-set-face-bg-RGB-at-point'
`facemenup-set-face-bg-RGB-hex-at-mouse'
`facemenup-set-face-bg-RGB-hex-at-point'
`facemenup-set-face-fg-RGB-at-mouse'
`facemenup-set-face-fg-RGB-at-point'
`facemenup-set-face-fg-RGB-hex-at-mouse'
`facemenup-set-face-fg-RGB-hex-at-point'
___

https://www.emacswiki.org/emacs/FaceMenuPlus

https://www.emacswiki.org/emacs/download/facemenu%2b.el

Re: [External] : Re: Experimentally unbind M-o on the trunk

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2021-02-10 19:37]:
> > The M-o key is for face menu and it is better to
> > rethink why is M-o globally set and why not only in the
> > specific mode where those face menus make sense.
> 
> Facemenu commands make sense in most modes (nearly all?).

Did you mean they don't make sense?

> That said, I too would suggest freeing up `M-o'.
> 
> And if it does get freed from being bound by default 
> then I'd suggest reserving it for 3rd-party code.

RE: [External] : Re: Experimentally unbind M-o on the trunk

[Drew Adams]

> > > The M-o key is for face menu and it is better to
> > > rethink why is M-o globally set and why not only in the
> > > specific mode where those face menus make sense.
> >
> > Facemenu commands make sense in most modes (nearly all?).
> 
> Did you mean they don't make sense?

No, I meant they make sense - you can use them
to do what they do.

Re: [External] : Re: Experimentally unbind M-o on the trunk

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2021-02-11 09:18]:
> > > > The M-o key is for face menu and it is better to
> > > > rethink why is M-o globally set and why not only in the
> > > > specific mode where those face menus make sense.
> > >
> > > Facemenu commands make sense in most modes (nearly all?).
> > 
> > Did you mean they don't make sense?
> 
> No, I meant they make sense - you can use them
> to do what they do.

Let us say I am answering emails, there is mail-mode down, using M-o
to set bold face says font lock mode will override any faces you set
in this buffer. I do not find use of M-o in majority of modes. There
is use for centering of a line, but I can live without
it. Additionally I get many many of errors below.

Invalid face reference: mail-multiply-quoted-text-face [2 times]
Invalid face reference: mail-double-quoted-text-face [8 times]
Invalid face reference: mail-multiply-quoted-text-face [2 times]
Invalid face reference: mail-double-quoted-text-face [9 times]
Invalid face reference: mail-multiply-quoted-text-face [2 times]

I wish to understand how is that useful that face settings do work in
most of modes, but such cannot be saved in those same modes. Let us
say in fundamental mode, I can set bold on text, but what is the point
if I cannot save it as bold. Upon new opening of the file I do not see
any more my formatting.

How do you mean it that face settings are useful even if they cannot
be saved? Maybe for real time presentations?

Jean

RE: [External] : Re: Experimentally unbind M-o on the trunk

[Drew Adams]

> > > > > The M-o key is for face menu and it is better to
> > > > > rethink why is M-o globally set and why not only in the
> > > > > specific mode where those face menus make sense.
> > > >
> > > > Facemenu commands make sense in most modes (nearly all?).
> > >
> > > Did you mean they don't make sense?
> >
> > No, I meant they make sense - you can use them
> > to do what they do.

Sorry, let me clarify.  Perhaps I misspoke.

I didn't really mean to speak about what `M-o' does.
I meant to speak generally, about _facemenu_ -- that
is, the functionality provided by `facemenu.el', and
the part of that functionality that's presented, e.g.,
in menu Edit > Text Properties.

See, in particular, my reply to Clement's question
about font-locked buffers:

https://lists.gnu.org/archive/html/emacs-devel/2021-02/msg00640.html

You'll note that, with font-locking turned on, the
particular facemenu features that font-lock can
interfere with are inactive in the menu.  And you'll
note that if you try `M-o' in a font-locked buffer
you'll see this message:

  "Font-lock mode will override any faces you set
   in this buffer"
___

And BTW, I said elsewhere that I would not at all
be opposed to repurposing `M-o': use it for something
else or free it up for 3rd-party use.

I even think that the dialog of `M-o' is confusing.
The prompt doesn't really make clear what the input
possibilities are or what their consequences are.

And if the menu items equivalent to `M-o' inputs are
entirely inhibited when a buffer is font-locked, then
shouldn't `M-o' also be _unavailable_ in that context,
instead of letting you actually _make_ its buffer
changes and just informing you that those changes are
not seen currently because of font-locking? Yes, maybe.

But what should happen to `M-o' is another question,
different from whether (some) facemenu commands can be
used in many/most buffers/modes.  My reply was meant
to be about that more general question.  Facemenu is
more than just `M-o' or those particular menu items.
I was speaking about facemenu, not just its `M-o' part.

I think I made all of this clear in my reply to Clement.

> I wish to understand how is that useful that face
> settings do work in most of modes, but such cannot
> be saved in those same modes.

You're mixing up two things there.

 1. For the first part, see above, and my reply to Clement.

 2. Wrt saving: Saving is what _enriched-mode_ is about,
    it's not what facemenu is about.

Changing text properties (`face', `font-lock-face',
or other properties) is one thing.  Saving face
changes persistently is something else again.
Facemenu is not enriched-mode, and vice versa.

> Let us say in fundamental mode, I can set bold on text,
> but what is the point if I cannot save it as bold.

And that is yet a 3rd point/question.  That's your
confusion or too-narrow view, I think.  Those are
different things, so they naturally have some
different uses.

There are any number of reasons why you might make
some temporary changes in a buffer or, more generally,
in an Emacs session.  You don't necessarily want to
persistently save every change you make.  (That's a
generic "you" - perhaps you, Jean, actually do want
that; dunno.)

Have you ever increased the font size in a buffer
to be able to read/see something easier, without
wanting that change to be saved as your persistent
default font size?  Depending on how you make that
font-size change, it could be a change to the
`default' face.

> How do you mean it that face settings are useful even if
> they cannot be saved? Maybe for real time presentations?

See above.  And yes, presentations are another good
example.

Smarter M-x that filters on major-mode

[Boruch Baum]

> Matt Armstrong <matt@rfc20.org> writes:
>
>> What if instead help showed all the interactive commands provided by
>> the mode? What if M-x were smarter about highlighting mode specific
>> commands?

I remember a version of this discussion a few months ago, which led me
to write and publish what you may be looking for[1]. It defaults to
collecting all commands for the current major mode, but is designed to
handle other customized scenarios, too.

[1] https://github.com/Boruch-Baum/emacs-key-assist

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0