Current mode command discovery

Current mode command discovery

[Lars Ingebrigtsen]

Now that we have mode markup, should there be a command like `M-x', but
instead lists only those commands that are specifically relevant to the
current buffer?

This would only be commands that have been marked for the current major
mode and any active minor modes, I guess?

If so, should that be bound to something, and if so, what?

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

Re: Current mode command discovery

[Sean Whitton]

Hello,

On Sun 14 Feb 2021 at 06:19PM +01, Lars Ingebrigtsen wrote:

> Now that we have mode markup, should there be a command like `M-x', but
> instead lists only those commands that are specifically relevant to the
> current buffer?
>
> This would only be commands that have been marked for the current major
> mode and any active minor modes, I guess?
>
> If so, should that be bound to something, and if so, what?

Given that it's about the current buffer, putting it under the new C-x x
map would seem appropriate.

C-x x x would be mnemonic with M-x.

-- 
Sean Whitton

Re: Current mode command discovery

[Lars Ingebrigtsen]

Sean Whitton <spwhitton@spwhitton.name> writes:

> Given that it's about the current buffer, putting it under the new C-x x
> map would seem appropriate.
>
> C-x x x would be mnemonic with M-x.

Hm, yes, that makes sense, but it feels a bit foreign somehow...  Might
just take some getting used to, though.

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

Re: Current mode command discovery

[Gregory Heytings]

>
> Now that we have mode markup, should there be a command like `M-x', but 
> instead lists only those commands that are specifically relevant to the 
> current buffer?
>
> This would only be commands that have been marked for the current major 
> mode and any active minor modes, I guess?
>
> If so, should that be bound to something, and if so, what?
>

M-X, aka M-S-x?

Re: Current mode command discovery

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

>> If so, should that be bound to something, and if so, what?
>
> M-X, aka M-S-x?

Hm!  Do we do that with any other `M-' letter bindings?  That is, have a
different binding for upper- and lower-case meta letters?  We do have
pretty complex bindings like `C-M-%' (which requires holding down four
keys at the same time), though...

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

Re: Current mode command discovery

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Gregory Heytings <gregory@heytings.org> writes:
>
>>> If so, should that be bound to something, and if so, what?
>>
>> M-X, aka M-S-x?
>
> Hm!  Do we do that with any other `M-' letter bindings?  That is, have a
> different binding for upper- and lower-case meta letters?  We do have
> pretty complex bindings like `C-M-%' (which requires holding down four
> keys at the same time), though...

From a quick look, we have these in emacs -Q:

C-M-S-l         recenter-other-window
C-M-S-v         scroll-other-window-down

And this, but I'm not sure if it should count:

C-S-<backspace>

(FWIW, I like the proposed M-S-x binding.  I believe that's what I
proposed in the other thread, as well.)

Re: Current mode command discovery

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

>From a quick look, we have these in emacs -Q:
>
> C-M-S-l         recenter-other-window
> C-M-S-v         scroll-other-window-down

OK, so there's some precedence here (but not a lot).

> (FWIW, I like the proposed M-S-x binding.  I believe that's what I
> proposed in the other thread, as well.)

Yes, `M-S-x' seems like a natural variation.

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

Re: Current mode command discovery

[Dmitry Gutov]

On 16.02.2021 14:38, Lars Ingebrigtsen wrote:
>> (FWIW, I like the proposed M-S-x binding.  I believe that's what I
>> proposed in the other thread, as well.)
> Yes, `M-S-x' seems like a natural variation.

That is also what smex recommends for smex-major-mode-commands.

Re: Current mode command discovery

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sun, 14 Feb 2021 18:19:17 +0100
> 
> Now that we have mode markup, should there be a command like `M-x', but
> instead lists only those commands that are specifically relevant to the
> current buffer?

Like I said before: instead of removing what seems irrelevant, make
them appear after the relevant parts.  Otherwise we will lose
information when we guess wrong (which is an easy mistake to make,
since the assumption that the user always wants only the commands from
the current major mode is not always true).

> This would only be commands that have been marked for the current major
> mode and any active minor modes, I guess?

What about primitives? they are relevant in any mode.

Re: Current mode command discovery

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Like I said before: instead of removing what seems irrelevant, make
> them appear after the relevant parts.

That could also be an option, but I think having a command that shows
"now, what are the commands meant for this specific mode" would be nice.

>> This would only be commands that have been marked for the current major
>> mode and any active minor modes, I guess?
>
> What about primitives? they are relevant in any mode.

I'm not quite sure what you mean by primitives?  `M-x TAB' will (after
we've completed all the markups) list all commands that aren't specific
for some mode, and are therefore possibly relevant (i.e., that you could
want to execute right now).  That includes `M-x transpose-regions' as
well as `M-x rmail'...

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

Re: Current mode command discovery

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Sun, 14 Feb 2021 18:56:11 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Like I said before: instead of removing what seems irrelevant, make
> > them appear after the relevant parts.
> 
> That could also be an option, but I think having a command that shows
> "now, what are the commands meant for this specific mode" would be nice.
> 
> >> This would only be commands that have been marked for the current major
> >> mode and any active minor modes, I guess?
> >
> > What about primitives? they are relevant in any mode.
> 
> I'm not quite sure what you mean by primitives?

I mean: would "the command that shows 'now, what are the commands
meant for this specific mode'" also show primitives like
transpose-regions?  If you are going to only display commands marked
for the current major-mode, I guess the answer is NO, and that is IMO
sub-optimal, because primitives (and other non mode-specific commands,
like find-file) are always relevant.

Re: Current mode command discovery

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I mean: would "the command that shows 'now, what are the commands
> meant for this specific mode'" also show primitives like
> transpose-regions?

No, not in this new, theoretical command.

> If you are going to only display commands marked
> for the current major-mode, I guess the answer is NO, and that is IMO
> sub-optimal, because primitives (and other non mode-specific commands,
> like find-file) are always relevant.

What you're describing here is just what `M-x' does, though?  `M-x' will
always list all non-mode-specific commands.

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

Re: Current mode command discovery

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Mon, 15 Feb 2021 04:04:30 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I mean: would "the command that shows 'now, what are the commands
> > meant for this specific mode'" also show primitives like
> > transpose-regions?
> 
> No, not in this new, theoretical command.

So people are supposed to invoke that new theoretical command only
when they already know the command is from the current major mode?

> > If you are going to only display commands marked
> > for the current major-mode, I guess the answer is NO, and that is IMO
> > sub-optimal, because primitives (and other non mode-specific commands,
> > like find-file) are always relevant.
> 
> What you're describing here is just what `M-x' does, though?  `M-x' will
> always list all non-mode-specific commands.

I thought you wanted to modify how M-x works.  Isn't that what this
discussion was about?  Or is it _only_ about that new command?  Or
both?

Re: Current mode command discovery

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> So people are supposed to invoke that new theoretical command only
> when they already know the command is from the current major mode?

I'm not sure I understand what you mean.

The question I asked is whether people would find it useful to have an
M-x-like command that only lists commands that are specifically tagged
as being applicable to the current buffer's modes.

It'd be a different way of getting an over for the mode-specific
commands than `C-h m'.

> I thought you wanted to modify how M-x works.  Isn't that what this
> discussion was about?  Or is it _only_ about that new command?  Or
> both?

This thread is only about this theoretical new command.

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

Re: Current mode command discovery

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Tue, 16 Feb 2021 13:04:13 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > So people are supposed to invoke that new theoretical command only
> > when they already know the command is from the current major mode?
> 
> I'm not sure I understand what you mean.
> 
> The question I asked is whether people would find it useful to have an
> M-x-like command that only lists commands that are specifically tagged
> as being applicable to the current buffer's modes.
> 
> It'd be a different way of getting an over for the mode-specific
> commands than `C-h m'.

"C-h m" shows the mode's keybindings, and is a "help" command.  That
"M-x-like command" you are talking about is NOT a help command, it's a
command that executes other commands.  Thus, to use this new command,
the user should know, up front, that he or she wants to _invoke_ some
command from the set of those applicable to the current modes.  I'm
wondering how will users know that.

By contrast, "C-h m" is typically invoked when users are looking for
information about the current mode, not because they necessarily want
to invoke some command.

> > I thought you wanted to modify how M-x works.  Isn't that what this
> > discussion was about?  Or is it _only_ about that new command?  Or
> > both?
> 
> This thread is only about this theoretical new command.

Then how about if we stop mentioning M-x in this thread?  It is
utterly confusing to mention M-x when we actually are talking about
something else.  Some of the suggestions voiced here made me nervous
because I thought people were suggesting changes in how M-x works; now
I'm relieved to learn that no change to M-x's MO was meant.

Re: Current mode command discovery

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Thus, to use this new command, the user should know, up front, that he
> or she wants to _invoke_ some command from the set of those applicable
> to the current modes.  I'm wondering how will users know that.

When I'm in some new and strange mode, and I know that I want to do
something with the data there, then getting a list of those commands,
and then being able to execute them seems convenient.

As has been pointed out several times, various packages already exist
that does exactly this -- but badly, since they basically guess at what
commands are applicable.

So I think it's established that this is something that (some) people
want.

> By contrast, "C-h m" is typically invoked when users are looking for
> information about the current mode, not because they necessarily want
> to invoke some command.

I use `C-h m' (and `C-h b') all the time to find a mode specific
command, but can quite recall what it's called, or what key it's bound
to.  This new command would make that process more efficient.

>> This thread is only about this theoretical new command.
>
> Then how about if we stop mentioning M-x in this thread?  It is
> utterly confusing to mention M-x when we actually are talking about
> something else.  Some of the suggestions voiced here made me nervous
> because I thought people were suggesting changes in how M-x works; now
> I'm relieved to learn that no change to M-x's MO was meant.

It's a new M-x-like command, but with a different predicate.  I don't
think you'll find people are going to stop mentioning M-x here.

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

Re: Current mode command discovery

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Tue, 16 Feb 2021 17:28:38 +0100
> Cc: emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Thus, to use this new command, the user should know, up front, that he
> > or she wants to _invoke_ some command from the set of those applicable
> > to the current modes.  I'm wondering how will users know that.
> 
> When I'm in some new and strange mode, and I know that I want to do
> something with the data there, then getting a list of those commands,
> and then being able to execute them seems convenient.

Strangely enough, when _I_ am in some new and strange mode, I read its
documentation, and if that's not enough, read its code.  To each one
their own...

> > Then how about if we stop mentioning M-x in this thread?  It is
> > utterly confusing to mention M-x when we actually are talking about
> > something else.  Some of the suggestions voiced here made me nervous
> > because I thought people were suggesting changes in how M-x works; now
> > I'm relieved to learn that no change to M-x's MO was meant.
> 
> It's a new M-x-like command, but with a different predicate.  I don't
> think you'll find people are going to stop mentioning M-x here.

Too bad.

Re: Current mode command discovery

[Basil L. Contovounesios]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Cc: emacs-devel@gnu.org
>> Date: Tue, 16 Feb 2021 13:04:13 +0100
>> 
>> This thread is only about this theoretical new command.
>
> Then how about if we stop mentioning M-x in this thread?  It is
> utterly confusing to mention M-x when we actually are talking about
> something else.  Some of the suggestions voiced here made me nervous
> because I thought people were suggesting changes in how M-x works; now
> I'm relieved to learn that no change to M-x's MO was meant.

Hasn't the default M-x behaviour already changed thanks to
read-extended-command-predicate?

IIUC, this theoretical new command would be like that, but it would
additionally exclude commands that don't have an extended interactive
spec.  Is that correct?

-- 
Basil

Re: Current mode command discovery

[Lars Ingebrigtsen]

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

> IIUC, this theoretical new command would be like that, but it would
> additionally exclude commands that don't have an extended interactive
> spec.  Is that correct?

Yup.

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

Re: Current mode command discovery

[Eli Zaretskii]

> From: "Basil L. Contovounesios" <contovob@tcd.ie>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  emacs-devel@gnu.org
> Date: Tue, 16 Feb 2021 18:08:17 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Lars Ingebrigtsen <larsi@gnus.org>
> >> Cc: emacs-devel@gnu.org
> >> Date: Tue, 16 Feb 2021 13:04:13 +0100
> >> 
> >> This thread is only about this theoretical new command.
> >
> > Then how about if we stop mentioning M-x in this thread?  It is
> > utterly confusing to mention M-x when we actually are talking about
> > something else.  Some of the suggestions voiced here made me nervous
> > because I thought people were suggesting changes in how M-x works; now
> > I'm relieved to learn that no change to M-x's MO was meant.
> 
> Hasn't the default M-x behaviour already changed thanks to
> read-extended-command-predicate?

It seems like indeed M-x behavior has changed.  So my fears were not
unfounded, sadly.  This is an incompatible behavior change, and it
should IMO be OFF by default.  Worse, NEWS doesn't call out this
behavior of M-x completion, and neither does the manual, at least not
clearly enough (the reference to read-extended-command-predicate is
too vague and doesn't mention completion).

I'm very uneasy about this change.

Re: Current mode command discovery

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> It seems like indeed M-x behavior has changed.  So my fears were not
> unfounded, sadly.  This is an incompatible behavior change, and it
> should IMO be OFF by default.  Worse, NEWS doesn't call out this
> behavior of M-x completion,

It does.

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

Re: Current mode command discovery

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: "Basil L. Contovounesios" <contovob@tcd.ie>,  emacs-devel@gnu.org
> Date: Tue, 16 Feb 2021 19:37:49 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > It seems like indeed M-x behavior has changed.  So my fears were not
> > unfounded, sadly.  This is an incompatible behavior change, and it
> > should IMO be OFF by default.  Worse, NEWS doesn't call out this
> > behavior of M-x completion,
> 
> It does.

In "Incompatible Editing Changes in Emacs 28.1"?

Re: Current mode command discovery

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> In "Incompatible Editing Changes in Emacs 28.1"?

No, in "Editing Changes in Emacs 28.1"...  But that section is perhaps a
better one?  Feel free to move it (and expand upon it) if you wish.

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

Re: Current mode command discovery

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: contovob@tcd.ie,  emacs-devel@gnu.org
> Date: Tue, 16 Feb 2021 19:57:02 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > In "Incompatible Editing Changes in Emacs 28.1"?
> 
> No, in "Editing Changes in Emacs 28.1"...  But that section is perhaps a
> better one?  Feel free to move it (and expand upon it) if you wish.

I'd prefer to make the feature opt-in, see my other message.  Then
NEWS entry won't need to be moved.

Re: Current mode command discovery

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> No, in "Editing Changes in Emacs 28.1"...  But that section is perhaps a
>> better one?  Feel free to move it (and expand upon it) if you wish.
>
> I'd prefer to make the feature opt-in, see my other message.  Then
> NEWS entry won't need to be moved.

What the default completion predicate should be is totally up for
discussion, and we could take a poll.  (Cries of horror ensue.)

But I'd prefer to have the new predicate as the default in the
development version for the time being, to see if that'll spur people
into doing mode tagging.

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

Re: Current mode command discovery

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: contovob@tcd.ie,  emacs-devel@gnu.org
> Date: Tue, 16 Feb 2021 20:33:18 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> No, in "Editing Changes in Emacs 28.1"...  But that section is perhaps a
> >> better one?  Feel free to move it (and expand upon it) if you wish.
> >
> > I'd prefer to make the feature opt-in, see my other message.  Then
> > NEWS entry won't need to be moved.
> 
> What the default completion predicate should be is totally up for
> discussion, and we could take a poll.  (Cries of horror ensue.)

The current master already makes the behavior incompatible, so I'm not
sure I understand how would you like to have a discussion about
something that is already a "fait accompli".

Moreover, I thought I _was_ discussing how to make this filtering less
radical and dangerous, but all I got in response was "don't worry, we
are talking about this theoretical non-existing command, not about
changing how M-x behaves".  And now it turns out it _was_ about M-x
after all.

> But I'd prefer to have the new predicate as the default in the
> development version for the time being, to see if that'll spur people
> into doing mode tagging.

My problem is not with the lack of tagging, my problem is that there's
no "fire escape" when a command I want to invoke was filtered out by
this new feature: M-x says "[No match]" and that's it, although the
command does exists and "C-h f" will happily tell me about it.
Imagine user confusion and frustration when a command that is known to
Help cannot be invoked!  My suggestion to change the sorting order
instead of actually filtering out candidates would at least avoid that
danger.

Re: Current mode command discovery

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> What the default completion predicate should be is totally up for
>> discussion, and we could take a poll.  (Cries of horror ensue.)
>
> The current master already makes the behavior incompatible, so I'm not
> sure I understand how would you like to have a discussion about
> something that is already a "fait accompli".

I'm not sure what you mean?  What's a fait accompli here?

> Moreover, I thought I _was_ discussing how to make this filtering less
> radical and dangerous, but all I got in response was "don't worry, we
> are talking about this theoretical non-existing command, not about
> changing how M-x behaves".  And now it turns out it _was_ about M-x
> after all.

This thread was not about M-x until you made it be about M-x.  The
default filtering in M-x was discussed in a different thread.

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

Re: Current mode command discovery

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Tue, 16 Feb 2021 21:55:06 +0100
> Cc: contovob@tcd.ie, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> What the default completion predicate should be is totally up for
> >> discussion, and we could take a poll.  (Cries of horror ensue.)
> >
> > The current master already makes the behavior incompatible, so I'm not
> > sure I understand how would you like to have a discussion about
> > something that is already a "fait accompli".
> 
> I'm not sure what you mean?  What's a fait accompli here?

The filtering.  It's on master.

> > Moreover, I thought I _was_ discussing how to make this filtering less
> > radical and dangerous, but all I got in response was "don't worry, we
> > are talking about this theoretical non-existing command, not about
> > changing how M-x behaves".  And now it turns out it _was_ about M-x
> > after all.
> 
> This thread was not about M-x until you made it be about M-x.  The
> default filtering in M-x was discussed in a different thread.

I apologize for confusing threads, but it should have been clear that
everything I say in the "wrong" thread was directly related to the
discussions in the "right" thread.

Re: Current mode command discovery

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> I'm not sure what you mean?  What's a fait accompli here?
>
> The filtering.  It's on master.

It's the default value of a defcustom.  I don't see what's so faited
about that accompli?  It can be changed trivially at any time.

>> This thread was not about M-x until you made it be about M-x.  The
>> default filtering in M-x was discussed in a different thread.
>
> I apologize for confusing threads, but it should have been clear that
> everything I say in the "wrong" thread was directly related to the
> discussions in the "right" thread.

It was perhaps not strategically sound to introduce a thread about a new
subject (a new command) while discussing M-x somewhere else.  I'll add a
disclaimer about not talking about M-x when discussing this new command,
then.

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

Re: Current mode command discovery

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: contovob@tcd.ie,  emacs-devel@gnu.org
> Date: Wed, 17 Feb 2021 12:11:46 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I'm not sure what you mean?  What's a fait accompli here?
> >
> > The filtering.  It's on master.
> 
> It's the default value of a defcustom.  I don't see what's so faited
> about that accompli?  It can be changed trivially at any time.

Fair enough.  So I went ahead and made such a change.

> >> This thread was not about M-x until you made it be about M-x.  The
> >> default filtering in M-x was discussed in a different thread.
> >
> > I apologize for confusing threads, but it should have been clear that
> > everything I say in the "wrong" thread was directly related to the
> > discussions in the "right" thread.
> 
> It was perhaps not strategically sound to introduce a thread about a new
> subject (a new command) while discussing M-x somewhere else.  I'll add a
> disclaimer about not talking about M-x when discussing this new command,
> then.

TIA

Re: Current mode command discovery

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I have nothing against the idea of recording somehow when a M-x
command is meaningful only in certain major modes.  And I have not
followed the specific proposals -- I figured all of you can make
a good decision about them without my help.

But I have one general comment: this is a support feature rather than
an editing feature.  Emacs is already excellent in its support
features.  How about improving what Emacs can do in editing?

For instance, modularizing the various packages that depend on Org
mode, so that they are independent features (though they can still use
Org format if that's useful in them).

For instance, extending the ability to have more kinds of formatting
features in text being edited, taking steps towards reaching WYSIWYG
some day.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Current mode command discovery

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> Imagine user confusion and frustration when a command that is known to
> Help cannot be invoked!

Why would the user wish to invoke a command that makes no sense on the
context he is working on? On the best case, the command will just throw
an error. At worse, it will mess up things.

> My suggestion to change the sorting order instead of actually
> filtering out candidates would at least avoid that danger.

The danger you are talking about is saving the user from having to
search among thousands of irrelevant commands and/or firing himself on
the foot. After all, we also hide the menus of modes when they are not
active on the current buffer.

Re: Current mode command discovery

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 17 Feb 2021 00:32:09 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Imagine user confusion and frustration when a command that is known to
> > Help cannot be invoked!
> 
> Why would the user wish to invoke a command that makes no sense on the
> context he is working on?

Because whoever marked it "nonsensical" made a mistake?  Or because
time passed, things have changed, and what made no sense back then may
make sense now, and Emacs maintainers missed that or couldn't keep up?

IOW, let's not assume that the marking is perfect.  It's done by us,
and we can make mistakes.

> > My suggestion to change the sorting order instead of actually
> > filtering out candidates would at least avoid that danger.
> 
> The danger you are talking about is saving the user from having to
> search among thousands of irrelevant commands and/or firing himself on
> the foot.

If you are talking about display of completion candidates, we could
make display of those "irrelevant" command optional, with some
suitable gesture (like another TAB, perhaps?).  But please don't
forget that completion is also invoked when you type RET to exit the
minibuffer and run the command, and it's at that point that hard
removal of some commands could be harmful.

> After all, we also hide the menus of modes when they are not active
> on the current buffer.

Menus only show a small fraction of the commands.  More importantly, a
command that doesn't appear in the menus still can be invoked, so the
user does have a "fire escape" in that case.

Re: Current mode command discovery

[tomas]

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

On Wed, Feb 17, 2021 at 05:38:49PM +0200, Eli Zaretskii wrote:

[...]

> > Why would the user wish to invoke a command that makes no sense on the
> > context he is working on?
> 
> Because whoever marked it "nonsensical" made a mistake?  Or because
> time passed, things have changed, and what made no sense back then may
> make sense now, and Emacs maintainers missed that or couldn't keep up?

Thanks, Eli.

Cheers
 - t

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

Re: Current mode command discovery

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Because whoever marked it "nonsensical" made a mistake?  Or because
> time passed, things have changed, and what made no sense back then may
> make sense now, and Emacs maintainers missed that or couldn't keep up?
>
> IOW, let's not assume that the marking is perfect.  It's done by us,
> and we can make mistakes.

Any code can have bugs.  That doesn't stop us from writing code or
designing systems.

If there's a bug, we fix the bug.

But it's extremely unlikely that the tagging of, say, `eww-readable'
will change.

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

Re: Current mode command discovery

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 17 Feb 2021 18:49:42 +0100
> Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Because whoever marked it "nonsensical" made a mistake?  Or because
> > time passed, things have changed, and what made no sense back then may
> > make sense now, and Emacs maintainers missed that or couldn't keep up?
> >
> > IOW, let's not assume that the marking is perfect.  It's done by us,
> > and we can make mistakes.
> 
> Any code can have bugs.  That doesn't stop us from writing code or
> designing systems.
> 
> If there's a bug, we fix the bug.

What do you tell a user who cannot invoke a command?  "Wait for the
next release"?

That's why "fire escapes" are useful: they are Plan B for when the
unexpected strikes.

> But it's extremely unlikely that the tagging of, say, `eww-readable'
> will change.

Unexpected problems are always unexpected, they cannot be known in
advance.  Therefore, examples don't help, because examples always talk
about something we considered and made a decision about.  Whereas
"fire escapes" are about risk management, not about design.

Re: Current mode command discovery

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> What do you tell a user who cannot invoke a command?  "Wait for the
> next release"?

No?  The default is to hide no commands (since earlier today)?  So I'm
not sure what you're asking here.

So bugs in this area are inconsequential compared to other bugs.  Where
they do have to wait for the next release.

> That's why "fire escapes" are useful: they are Plan B for when the
> unexpected strikes.

Of course.  There's been fire escapes
(`read-extended-command-predicate') in this since the first patch, so,
again, I'm not sure why you're bringing that up.

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

Re: Current mode command discovery

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Imagine user confusion and frustration when a command that is known to
>> > Help cannot be invoked!
>> 
>> Why would the user wish to invoke a command that makes no sense on the
>> context he is working on?
>
> Because whoever marked it "nonsensical" made a mistake?  Or because
> time passed, things have changed, and what made no sense back then may
> make sense now, and Emacs maintainers missed that or couldn't keep up?
>
> IOW, let's not assume that the marking is perfect.  It's done by us,
> and we can make mistakes.

Yes, aka bugs. Why would we cripple a feature because it can contain
bugs?

>> After all, we also hide the menus of modes when they are not active
>> on the current buffer.
>
> Menus only show a small fraction of the commands.  More importantly, a
> command that doesn't appear in the menus still can be invoked, so the
> user does have a "fire escape" in that case.

The user has many fire scapes: he can edit the function, use M-: or,
simply, disable the filtering. Or implement the gesture you suggested on
the paragraph I didn't quote, although that is not my preferred solution
because those gestures tend to be hard to discover and remember.

Nobody is suggesting that the filtering should be mandatory. Maybe we
can argue about the default, but that's all (FWIW, I'm in favor of
making it optional in 28 and consider it as the default for 29)

Re: Current mode command discovery

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 17 Feb 2021 19:00:22 +0100
> 
> > IOW, let's not assume that the marking is perfect.  It's done by us,
> > and we can make mistakes.
> 
> Yes, aka bugs. Why would we cripple a feature because it can contain
> bugs?

Because if and when this particular kind of a bug hits, it will have
dire consequences.

IOW, we are talking about risk management here: a low-probability
event with high cost, if and when it happens.

> The user has many fire scapes: he can edit the function, use M-: or,
> simply, disable the filtering.

Many users won't know how to do any of these.

> Nobody is suggesting that the filtering should be mandatory. Maybe we
> can argue about the default, but that's all

The default is _all_ I was arguing about.  the rest were suggestions
for making this feature more balanced IMO, but I'm okay with those
suggestions slip, if no one else thinks they are useful.

Re: Current mode command discovery

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I have not been following this discussion, and the following
suggestion might have been rejected already, or might have some
obvious flaw.  I post it because it sounds like this idea
has not been considered.


It seems that the aim is to help people find M-x commands that make
sense in the current major mode, by excluding from completion those
that don't make sense.  If so, why should that interfere with invoking
a command by typing its name?

I suggest making RET let you execute any valid command if you have
entered its exact name.

In addition, if you do completion and the existing input string
matches nothing that is marked as meaningful, I suggest it could
complete based on the commands that are not marked as meaningful.

Another idea: If you have made a listing of possible completions from
names marked meaningful, typing TAB or ? could replace that with a
full list of possible completions (meaningful or not), and each
successive TAB or ?  could toggle between the two.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Current mode command discovery

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Fri, 19 Feb 2021 00:41:15 -0500
> Cc: emacs-devel@gnu.org
> 
> I suggest making RET let you execute any valid command if you have
> entered its exact name.

This has been suggested, but unfortunately the code on master was not
modified to do that yet, and I didn't see any enthusiasm for making
such a change.

> In addition, if you do completion and the existing input string
> matches nothing that is marked as meaningful, I suggest it could
> complete based on the commands that are not marked as meaningful.
> 
> Another idea: If you have made a listing of possible completions from
> names marked meaningful, typing TAB or ? could replace that with a
> full list of possible completions (meaningful or not), and each
> successive TAB or ?  could toggle between the two.

Something like that was also suggested.  Again, none of that is
currently on master, so I wonder whether it looks like a good idea to
people.  (I personally do like it, but then I was saying from the
get-go that the current code of the feature is too radical.)

Re: Current mode command discovery

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> This has been suggested, but unfortunately the code on master was not
> modified to do that yet, and I didn't see any enthusiasm for making
> such a change.

Oh, I thought it sounded like a good idea?  I may have forgotten to say
so, though.  (And if I remember correctly, everybody who did chime in
agreed that something like that would be nice.)

A variation on that would be to query the user first when they type in
a mode-specific command (that belong to a different mode) -- "You've
asked to execute `5x5-solve-rotate-left' which is specific to
`5x5-mode'.  Really execute?"

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

Re: Current mode command discovery

[chad]

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

On Fri, Feb 19, 2021 at 4:53 AM Lars Ingebrigtsen <larsi@gnus.org> wrote:

>
> A variation on that would be to query the user first when they type in
> a mode-specific command (that belong to a different mode) -- "You've
> asked to execute `5x5-solve-rotate-left' which is specific to
> `5x5-mode'.  Really execute?"
>

It reminds me of the disabled-command-function machinery, or at least the
concept. Maybe there's a decent way to leverage the two concepts into a
similar UI pattern?

~Chad

[-- Attachment #2: Type: text/html, Size: 850 bytes --]

Re: Current mode command discovery

[Stefan Monnier]

> It reminds me of the disabled-command-function machinery, or at least the
> concept. Maybe there's a decent way to leverage the two concepts into a
> similar UI pattern?

Talking about integration with other pre-existing functionality: how
'bout merging the new command enable functionality with the
`menu-enable` symbol property?


        Stefan

RE: [External] : Re: Current mode command discovery

[Drew Adams]

> Talking about integration with other pre-existing functionality:
> how 'bout merging the new command enable functionality with the
> `menu-enable` symbol property?

Speaking of a symbol property...

IMHO, all of the shenanigans undertaken recently
to provide command enabling/filtering should be
replaced by simply using a property on command
symbols.  (Maybe more than one property, if you
really need something complex for some reason.)

That is, _IF_ this is to be done at all.

This is about association between a command and
certain contexts (modes, for example) in which
the command is considered relevant/enabled, or
not (or more or less so).

This isn't intended for anonymous commands, IIUC.
And for named commands the simple, flexible way
to handle such an association is using a property
on the command's symbol.

That gives libraries the ability to create or
modify such an association.  It gives commands
the ability to do it.  And it even gives users
the ability to do it.  Super flexible, simple -
can be done anywhere, in any context, at any time.
Can be done temporarily.

Why we would instead realize such an association
using an `interactive' form or a `declare' form,
I can't fathom.  That essentially hard-codes it
in source code.  Not so easy to modify, by any
party.

How did we get so far down this rabbit hole so
quickly?

I realize that this has already been suggested.
The threads are long and rambling, and I may well
have missed something, but I don't recall any
good reason given for rejecting this approach.

Re: [External] : Re: Current mode command discovery

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "ofv@wanadoo.es" <ofv@wanadoo.es>, Lars Ingebrigtsen <larsi@gnus.org>,
>         EMACS development team <emacs-devel@gnu.org>,
>         Eli Zaretskii <eliz@gnu.org>, Richard Stallman <rms@gnu.org>
> Date: Fri, 19 Feb 2021 23:19:43 +0000
> 
> > Talking about integration with other pre-existing functionality:
> > how 'bout merging the new command enable functionality with the
> > `menu-enable` symbol property?
> 
> Speaking of a symbol property...
> 
> IMHO, all of the shenanigans undertaken recently
> to provide command enabling/filtering should be
> replaced by simply using a property on command
> symbols.  (Maybe more than one property, if you
> really need something complex for some reason.)

This was suggested long ago as one of the alternatives for the
extension of 'interactive'.  Lars still doesn't think it is better (I
disagree).

> I realize that this has already been suggested.
> The threads are long and rambling, and I may well
> have missed something, but I don't recall any
> good reason given for rejecting this approach.

Lars gave his reasons, but I don't consider them to be good enough.

RE: [External] : Re: Current mode command discovery

[Drew Adams]

> > Speaking of a symbol property...
> >
> > IMHO, all of the shenanigans undertaken recently
> > to provide command enabling/filtering should be
> > replaced by simply using a property on command
> > symbols.  (Maybe more than one property, if you
> > really need something complex for some reason.)
> 
> This was suggested long ago as one of the alternatives for the
> extension of 'interactive'.

Yes, I know.

> Lars still doesn't think it is better (I disagree).

Yes, I know.

> > I realize that this has already been suggested.
> > The threads are long and rambling, and I may well
> > have missed something, but I don't recall any
> > good reason given for rejecting this approach.
> 
> Lars gave his reasons, but I don't consider them
> to be good enough.

A succinct relisting of those reasons would be
good, IMO.  I, for one, completely missed them.

There's nothing I'm aware of that's better suited
for this than using a symbol property.  Simple;
flexible; usable by any party, anywhere, anytime.
No mess, no fuss.  No source code changes (except
to get & test the property).

What's going on instead -- has been, still is,
incomplete, and will need updating forever --
seems complicated, error prone, time-consuming, 
overengineered, and simply not necessary.
IMHO.  (But what do I know?)

RE: [External] : Re: Current mode command discovery

[Drew Adams]

> > > Speaking of a symbol property...
> > >
> > > IMHO, all of the shenanigans undertaken recently
> > > to provide command enabling/filtering should be
> > > replaced by simply using a property on command
> > > symbols.  (Maybe more than one property, if you
> > > really need something complex for some reason.)

Eli> Lars still doesn't think it is better (I disagree).

> > > I realize that this has already been suggested.
> > > The threads are long and rambling, and I may well
> > > have missed something, but I don't recall any
> > > good reason given for rejecting this approach.
> >
Eli> Lars gave his reasons, but I don't consider
Eli> them to be good enough.
> 
> A succinct relisting of those reasons would be
> good, IMO.  I, for one, completely missed them.
> 
> There's nothing I'm aware of that's better suited
> for this than using a symbol property.  Simple;
> flexible; usable by any party, anywhere, anytime.
> No mess, no fuss.  No source code changes (except
> to get & test the property).
> 
> What's going on instead -- has been, still is,
> incomplete, and will need updating forever --
> seems complicated, error prone, time-consuming,
> overengineered, and simply not necessary.
> IMHO.  (But what do I know?)

Is it really too late to turn this bombing mission
around & reconsider?  Can we, instead of modifying
zillions of Emacs source files, with judgments made
at code-defining time, just use a symbol property,
which anyone and any library can modify as needed?

This seems like an ocean liner where a paddle-boat
is called for, at most.  Une véritable usine à gaz.

The closer you look into trying to implement the
current approach, the more complications you're
finding.

But the main problem is that decisions about what
modes a command gets associated with are being
made centrally, and in source code no less.  How
is that the right approach?

All that's needed, IMO, is the same thing we do
with `delete-selection-mode' or `thing-at-point':
associate whatever we want/need with a command
by attaching a property to its symbol.

Why are we making this so utterly complicated?

I haven't seen a good reason yet.  That whole
"WHY this way?" part seems to have been elided or
glossed over for this gigantic enterprise.

Can't we please reconsider this endeavor - the
how, at least?

Re: Current mode command discovery

[Lars Ingebrigtsen]

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

>> It reminds me of the disabled-command-function machinery, or at least the
>> concept. Maybe there's a decent way to leverage the two concepts into a
>> similar UI pattern?

Yes, that makes sense.  If we do add a "Really execute this command from
this other mode?" thing, then being able to permanently disable the
warning, like with disabled commands, would be nice.

> Talking about integration with other pre-existing functionality: how
> 'bout merging the new command enable functionality with the
> `menu-enable` symbol property?

That does seem natural, doesn't it?

However, I'm not quite sure about the proposed usages for using
completion-predicate for commands that are currently not usable.  In
menus, the commands are still there -- they're just greyed out, so you
can tell that if you just do something (mysterious), then they'll be
enabled.

In `M-x' completion, that's not really a natural...  thing?  (Unless
using a display method that displays all completions, no matter what the
predicate, but sort/display/colour them differently, as Eli suggested.)

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

Re: Current mode command discovery

[Stefan Monnier]

>>> It reminds me of the disabled-command-function machinery, or at least the
>>> concept. Maybe there's a decent way to leverage the two concepts into a
>>> similar UI pattern?
>
> Yes, that makes sense.  If we do add a "Really execute this command from
> this other mode?" thing, then being able to permanently disable the
> warning, like with disabled commands, would be nice.
>
>> Talking about integration with other pre-existing functionality: how
>> 'bout merging the new command enable functionality with the
>> `menu-enable` symbol property?
>
> That does seem natural, doesn't it?
>
> However, I'm not quite sure about the proposed usages for using
> completion-predicate for commands that are currently not usable.  In
> menus, the commands are still there -- they're just greyed out, so you
> can tell that if you just do something (mysterious), then they'll be
> enabled.
>
> In `M-x' completion, that's not really a natural...  thing?  (Unless
> using a display method that displays all completions, no matter what the
> predicate, but sort/display/colour them differently, as Eli suggested.)

I think that goes back to my point about defining what the
"completion-predicate" means.  I don't think it should mean "don't list
me in M-x" but something more like "doesn't make sense to use now in
this way".  Then the UI is free to decide to still show it but greyed
out, or to not show it at all, or to show it but "further down" or
something, and different UIs can make different choices.
[ BTW, maybe the predicate should take an extra arg indicating telling
whether we want to know if the command would be meaningful when run
from `M-x` or when run from a menu or when run from a key (in case we
want to "grey out" bindings in things like `<prefix> C-h`).  ]

It makes sense for M-x to "not list it at all" yet for the menu bar to
still show it (as greyed out) because the circumstances are different
(the fact that the entry is present in the menu is proof that the
command is sometimes relevant, just not currently).


        Stefan

Re: Current mode command discovery

[Lars Ingebrigtsen]

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

> It makes sense for M-x to "not list it at all" yet for the menu bar to
> still show it (as greyed out) because the circumstances are different
> (the fact that the entry is present in the menu is proof that the
> command is sometimes relevant, just not currently).

Thinking about this some more, I think the `menu-enable' thing is
about a different thing than the completion predicate.

But it is something we could be exploring doing something about, because
it seems like there's an opportunity to do some cleanup in this area.

The issue is: We have a bunch of commands that are available in most
modes, but that can't be executed "right now" -- you have to do
something else for them to become enabled.  I think it would be a
mistake to filter these out in any way -- that would just hinder command
discovery.

But we have this information spread out over a range of mechanisms
today.

* The `menu-enable' symbol property -- a predicate that says whether the
  command is useable

* The :enable thing in menu items

* Some thing in tool bars, I think?

* `disabled' in the symbol

* In the code itself

* "*" in `interactive' specs

And probably more.

All of these are ways to say that the command exists, but can't be
executed right now.  We could introduce one new mechanism that replaces
all this spread-out information in one place, where it belongs:

(defun kill-region (...)
  (declare (inhibited (lambda ()
                        (and (not (region-active-p))
                             "The region is not active"))))
  ...)

Or something along those lines.

This predicate could be used in the menu/tool bar, and also in `M-x TAB'
listings -- it would list `kill-region', but say (Inhibited: The region
is not active")) afterwards, or something like that.

(So the `inhibited' predicate would return a string that explains why
the command isn't usable right now.)

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

RE: [External] : Re: Current mode command discovery

[Drew Adams]

> * The :enable thing in menu items

Don't forget :filter (which can also apply to commands bound to keyboard keys).

> All of these are ways to say that the command exists, but can't be
> executed right now.  We could introduce one new mechanism that replaces
> all this spread-out information in one place, where it belongs:
> 
> (defun kill-region (...)
>   (declare (inhibited (lambda ()
>                         (and (not (region-active-p))
>                              "The region is not active"))))...)
> Or something along those lines.

Again, a lispy way to attach such info (and not just info saying why a command can't be invoked right ow) to a named function is to just use symbol properties.  Why do you insist on modifying source code this way?

It's not like these are declarations for the byte-compiler.  There's no need to hard-code this info in the source code.

Or even if you insist on doing it there, just use `put'.  That lets anyone do it anywhere: users, anyone, anytime.

RE: [External] : Re: Current mode command discovery

[Drew Adams]

> > how 'bout merging the new command enable functionality
> > with the `menu-enable` symbol property?
> 
> That does seem natural, doesn't it?

Using a symbol property?
Yep.  Natural, simple, flexible,...  ;-)

Re: Current mode command discovery

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> I suggest making RET let you execute any valid command if you have
>> entered its exact name.
>
> This has been suggested, but unfortunately the code on master was not
> modified to do that yet, and I didn't see any enthusiasm for making
> such a change.

It makes a great deal of sense.

If the user both remembers and types out the exact command name, I think
it's safe to assume that her intention is to run it.

RE: [External] : Re: Current mode command discovery

[Drew Adams]

> If you are talking about display of completion candidates, we
> could make display of those "irrelevant" command optional,

How about making their nondisplay optional?
How about making the _new_ behavior optional,
instead of changing the default behavior at
the same time a new possibility is added?

(+1 for the rest of what you said in that msg.)

Re: Current mode command discovery

[Jean Louis]

* Óscar Fuentes <ofv@wanadoo.es> [2021-02-17 02:33]:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Imagine user confusion and frustration when a command that is known to
> > Help cannot be invoked!
> 
> Why would the user wish to invoke a command that makes no sense on the
> context he is working on? On the best case, the command will just throw
> an error. At worse, it will mess up things.

For consideration let me also mention, that:

- I am developing my commands in such a way that they are related to
  the specific package and to specific derived mode, but that such
  commands shall mostly work outside of the mode as well.

  The mechanism to exclude commands belonging to specific mode shall
  be perfect as not to exclude such commands which may be used both
  globally and mode-specifically.

  Example is my command `cf-tabulates-notes' that could maybe later be
  renamed to `cf-notes' as that one will recognize if it is inside of
  the derived mode and show notes to specific person, but may as well
  be invoked outside of the mode in any other mode, and ask user for
  the person or account to which notes are related to.

- It is not logical to have commands being shown in M-x that cannot be
  anyway invoked in some mode, let us say like:
  `Buffer-menu-backup-unmark' or `Buffer-menu-delete', etc. it is all
  clear that such commands do not belong to every mode.

  Yet I hope that mechanism for discovery of commands that may be
  considered useless in some modes will be good enough as not to
  disable those mode related commands that also work globally,
  including those global commands that are not mode related.

Jean

Re: Current mode command discovery

[Robert Pluim]

>>>>> On Tue, 16 Feb 2021 21:24:12 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Lars Ingebrigtsen <larsi@gnus.org>
    >> Cc: contovob@tcd.ie,  emacs-devel@gnu.org
    >> Date: Tue, 16 Feb 2021 19:57:02 +0100
    >> 
    >> Eli Zaretskii <eliz@gnu.org> writes:
    >> 
    >> > In "Incompatible Editing Changes in Emacs 28.1"?
    >> 
    >> No, in "Editing Changes in Emacs 28.1"...  But that section is perhaps a
    >> better one?  Feel free to move it (and expand upon it) if you wish.

    Eli> I'd prefer to make the feature opt-in, see my other message.  Then
    Eli> NEWS entry won't need to be moved.

That entry says:

    ** New user option 'read-extended-command-predicate'.
    This option controls how 'M-x TAB' performs completions.  The default
    predicate excludes modes for which the command is not applicable.

Iʼm failing to parse that second sentence. After spelunking, I think
you mean something like:

"The default predicate includes commands applicable to the modes
(major and minor) active in the current buffer".

The spelunking I had to do:

C-h v read-extended-command-predicate, I get:

    read-extended-command-predicate is a variable defined in `simple.el'.
    Its value is `completion-default-include-p'

With no description of what completion-default-include-p does, so then
I have to do

C-h f completion-default-include-p

to get to:

    completion-default-include-p is a compiled Lisp function in
    `simple.el'.

    (completion-default-include-p SYMBOL BUFFER)

    Say whether SYMBOL should be offered as a completion.
    If there's a `completion-predicate' for SYMBOL, the result from
    calling that predicate is called.  If there isn't one, this
    predicate is true if the command SYMBOL is applicable to the
    major mode in BUFFER, or any of the active minor modes in
    BUFFER.

OK, thatʼs clear, but we check 'completion-predicate' as well? Thatʼs
not in NEWS.

Robert

Re: Current mode command discovery

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> OK, thatʼs clear, but we check 'completion-predicate' as well? Thatʼs
> not in NEWS.

Good catch.  I've now added the bit about the predicate to that NEWS
item, as well.

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

RE: [External] : Re: Current mode command discovery

[Drew Adams]

> "now, what are the commands meant for this specific mode"

What's your definition of the commands "meant" for
a specific mode?  Do you mean commands that are
useless outside of that mode?  I asked this before
but got no answer.

If the answer is yes, then this is, essentially,
like using a :filter with an extended menu binding,
even one that's used only for keyboard key bindings:
a filter that enables the command only for one or
more specific mode(s).

(See bugs #24237 and #45329.)
___

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24237

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45329

Re: Current mode command discovery

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Now that we have mode markup, should there be a command like `M-x', but
>> instead lists only those commands that are specifically relevant to the
>> current buffer?
>
> Like I said before: instead of removing what seems irrelevant, make
> them appear after the relevant parts.  Otherwise we will lose
> information when we guess wrong (which is an easy mistake to make,
> since the assumption that the user always wants only the commands from
> the current major mode is not always true).

That defeats the purpose of the feature, which is showing what is
relevant and ignore the rest.

Listing the irrelevant commands would only serve to confuse and overload
the user.

Those who insist on using M-x to discover things while working on random
buffers (something that seems quite bizarre to me, to be honest) still
can disable the filtering or, better, learn to use the Emacs help
system.

>> This would only be commands that have been marked for the current major
>> mode and any active minor modes, I guess?
>
> What about primitives? they are relevant in any mode.

Here I think that Lars is proposing an special command that just shows
those commands marked as related to the current active modes. Regular
M-x will still show the commands which are relevant in general, on
addition to the specific ones.

Re: Current mode command discovery

[Alan Mackenzie]

Hello, Óscar

On Sun, Feb 14, 2021 at 20:53:18 +0100, Óscar Fuentes wrote:
> Eli Zaretskii <eliz@gnu.org> writes:

> >> Now that we have mode markup, should there be a command like `M-x', but
> >> instead lists only those commands that are specifically relevant to the
> >> current buffer?

> > Like I said before: instead of removing what seems irrelevant, make
> > them appear after the relevant parts.  Otherwise we will lose
> > information when we guess wrong (which is an easy mistake to make,
> > since the assumption that the user always wants only the commands from
> > the current major mode is not always true).

> That defeats the purpose of the feature, which is showing what is
> relevant and ignore the rest.

> Listing the irrelevant commands would only serve to confuse and overload
> the user.

For the way I use M-x, I absolutely need what you call "irrelevant"
commands.  Suggesting that these "confuse and overload" me is not a nice
thing to do.

> Those who insist on using M-x to discover things while working on
> random buffers (something that seems quite bizarre to me, to be honest)
> still can disable the filtering or, better, learn to use the Emacs help
> system.

Ditto for this paragraph.  My memory is imperfect, and that includes
memory of command names.  I routinely find exact names from hazy half
memories by typing in M-x, the bits I think I remember, the occasional
asterisk, and hit the TAB key.  This works reasonably well.  And for this
process, I don't want to have to switch to, or create a "relevant"
buffer.  I will certainly be disabling this filtering.  As for learning
to use the help system, that's hardly a serious suggestion.

> >> This would only be commands that have been marked for the current major
> >> mode and any active minor modes, I guess?

> > What about primitives? they are relevant in any mode.

> Here I think that Lars is proposing an special command that just shows
> those commands marked as related to the current active modes. Regular
> M-x will still show the commands which are relevant in general, in
> addition to the specific ones.

There are around 11,380 commands in just the Emacs Lisp sources.  I'm not
sure it's practical to classify that number of commands as relevant for
all the scenarios the new feature is intended for.  It's a great deal of
work.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Current mode command discovery

[tomas]

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

On Sun, Feb 14, 2021 at 08:25:14PM +0000, Alan Mackenzie wrote:

[...]

> For the way I use M-x, I absolutely need what you call "irrelevant"
> commands.  Suggesting that these "confuse and overload" me is not a nice
> thing to do.

That's something I feel uneasy about, too. Whatever (however smart) selection
criteria, I fear, won't match my (possibly weird) preferred criteria. Sometimes
I learn by seeing "irrelevant" options, and I do care for that.

Besides, I much prefer to hone my search skill rather than being limited by
(however well-meaning) filtering. Empowerment and that.

Cheers
 - t

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

Re: Current mode command discovery

[Stefan Kangas]

<tomas@tuxteam.de> writes:

> On Sun, Feb 14, 2021 at 08:25:14PM +0000, Alan Mackenzie wrote:
>
> [...]
>
>> For the way I use M-x, I absolutely need what you call "irrelevant"
>> commands.  Suggesting that these "confuse and overload" me is not a nice
>> thing to do.
>
> That's something I feel uneasy about, too. Whatever (however smart) selection
> criteria, I fear, won't match my (possibly weird) preferred criteria. Sometimes
> I learn by seeing "irrelevant" options, and I do care for that.

Those use-cases would be covered by an option to turn this filtering
off, right?

RE: [External] : Re: Current mode command discovery

[Drew Adams]

> Besides, I much prefer to hone my search skill rather than being
> limited by (however well-meaning) filtering. Empowerment and that.

Indeed.

Only you know what do-what-I-mean really means for
_you_ in any given context.  What you (we all) need
are good ways to hone completion candidate sets on
the fly, not someone's predefined, hard-wired idea
of one-size-fits-all "DWIM".

Re: Current mode command discovery

[Philip Kaludercic]

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

Alan Mackenzie <acm@muc.de> writes:

> Hello, Óscar
>
> On Sun, Feb 14, 2021 at 20:53:18 +0100, Óscar Fuentes wrote:
>> Eli Zaretskii <eliz@gnu.org> writes:
>
>> >> Now that we have mode markup, should there be a command like `M-x', but
>> >> instead lists only those commands that are specifically relevant to the
>> >> current buffer?
>
>> > Like I said before: instead of removing what seems irrelevant, make
>> > them appear after the relevant parts.  Otherwise we will lose
>> > information when we guess wrong (which is an easy mistake to make,
>> > since the assumption that the user always wants only the commands from
>> > the current major mode is not always true).
>
>> That defeats the purpose of the feature, which is showing what is
>> relevant and ignore the rest.
>
>> Listing the irrelevant commands would only serve to confuse and overload
>> the user.
>
> For the way I use M-x, I absolutely need what you call "irrelevant"
> commands.  Suggesting that these "confuse and overload" me is not a nice
> thing to do.

What might be interesting is to filter out commands that have to be used
with a certain major or minor mode.  E.g. do python-mode commands have
to be shown when I'm in a c-mode buffer?

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

Re: Current mode command discovery

[Óscar Fuentes]

Alan Mackenzie <acm@muc.de> writes:

>> Listing the irrelevant commands would only serve to confuse and overload
>> the user.
>
> For the way I use M-x, I absolutely need what you call "irrelevant"
> commands.  Suggesting that these "confuse and overload" me is not a nice
> thing to do.

How often do you need to consult a command about foo-mode while working
on a buffer with baz-mode ?

>> Those who insist on using M-x to discover things while working on
>> random buffers (something that seems quite bizarre to me, to be honest)
>> still can disable the filtering or, better, learn to use the Emacs help
>> system.
>
> Ditto for this paragraph.  My memory is imperfect, and that includes
> memory of command names.  I routinely find exact names from hazy half
> memories by typing in M-x, the bits I think I remember, the occasional
> asterisk, and hit the TAB key.  This works reasonably well.  And for this
> process, I don't want to have to switch to, or create a "relevant"
> buffer.  I will certainly be disabling this filtering.  As for learning
> to use the help system, that's hardly a serious suggestion.

Why using M-x is more convenient for you than using C-h a, C-h f or some
other facility?

I'm trying to understand the mindset of those like you that use M-x for
exploring features or remembering commands. I use M-x for both purposes
all the time, but almost always I want to do something with that
command, which implies that I'm working on a context where the command
that I'm interested on will pass the filter. Thus, the filtering is a
great improvement.

>> >> This would only be commands that have been marked for the current major
>> >> mode and any active minor modes, I guess?
>
>> > What about primitives? they are relevant in any mode.
>
>> Here I think that Lars is proposing an special command that just shows
>> those commands marked as related to the current active modes. Regular
>> M-x will still show the commands which are relevant in general, in
>> addition to the specific ones.
>
> There are around 11,380 commands in just the Emacs Lisp sources.  I'm not
> sure it's practical to classify that number of commands as relevant for
> all the scenarios the new feature is intended for.  It's a great deal of
> work.

Almost all commands fall into two categories: specific to some mode
(which means that they only work if the mode is active) or general. I
see no problem classifying the commands that way.

I'm skeptic about other uses for the filtering that were mentioned, such
as adding predicates that test if a region is active, etc. That looks as
anti-feature to me. There are times when a menu entry should be hidden
and times where it should be grayed out (inactive). Likewise, a command
should not be hidden when it is related to the current context but a
detail makes it inapplicable. Just allow it to be invoked and throw an
user-error informing the user about what's wrong.

Re: Current mode command discovery

[tomas]

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

On Sun, Feb 14, 2021 at 10:39:10PM +0100, Óscar Fuentes wrote:
> Alan Mackenzie <acm@muc.de> writes:
> 
> >> Listing the irrelevant commands would only serve to confuse and overload
> >> the user.
> >
> > For the way I use M-x, I absolutely need what you call "irrelevant"
> > commands.  Suggesting that these "confuse and overload" me is not a nice
> > thing to do.
> 
> How often do you need to consult a command about foo-mode while working
> on a buffer with baz-mode ?

Sorry. I think I'm out of this discussion. I very much hope there's
a way to opt out of that filtering, if it is ever implemented.

Cheers
 - t

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

RE: [External] : Re: Current mode command discovery

[Drew Adams]

> > How often do you need to consult a command about foo-mode while
> > working on a buffer with baz-mode ?
> 
> Sorry. I think I'm out of this discussion. I very much hope there's
> a way to opt out of that filtering, if it is ever implemented.

Thanks for hanging in there as long as you did.

I sympathize.  It's hard to turn or stop a
steamroller.  (And in this case it seems to
be a speeding steamroller.)

RE: [External] : Re: Current mode command discovery

[Drew Adams]

> There are times when a menu entry should be hidden
> and times where it should be grayed out (inactive).
> Likewise, a command

Stop right there.  Exactly that.  Sometimes we
want to _show_ a menu item or submenu, but dim
it, to show that it's available and can be
enabled in some contexts.

We annotate command names in *Completions* with
their key bindings for exactly this kind of purpose.
We don't just change `M-x' so it will no longer
show commands that aren't (or are) bound to keys.
Why would we?

Except that this is about filtering _completion_
candidates, not just filtering the commands you
can invoke currently.

We let you filter completion candidates by
typing text to match.  Why wouldn't we also let
you filter candidates also by hitting particular
keys that filter particular classes of candidates
(in this case, commands).

As for dimming a menu item that's not currently
enabled - same here: you might well want to see
all command names in *Completions*, but have some
highlighted or dimmed so you know they can't
be invoked in the current mode (for one example).

Let users control which candidates get displayed.
Let them include commands that make no sense in
the current mode.  But let them filter those out,
or sort them last, or show them dimmed, or...

We should be increasing, not decreasing, user
control over the current set of candidates.

RE: [External] : Re: Current mode command discovery

[Drew Adams]

> > Like I said before: instead of removing what seems
> > irrelevant, make them appear after the relevant parts.
> > Otherwise we will lose information when we guess wrong
> > (which is an easy mistake to make, since the assumption
> > that the user always wants only the commands from the
> > current major mode is not always true).
> 
> That defeats the purpose of the feature, which is
> showing what is relevant and ignore the rest.
> Listing the irrelevant commands would only serve
> to confuse and overload the user.

I can speak from experience to say this isn't true.

And I think that completion that prepares candidates
in a particular sort order is quickly picked up by
users - think of fuzzy match sort-score order, for
example.

In Icicles different groups of candidates can be
highlighted differently.  That too can help.

And I think (?) that Emacs added grouped completion
candidates, with group headings in *Completions*
(but I haven't really followed that thread).

What _is_ true is that when more completions are
matched and displayed, that costs processing time.
(But so does filtering them out.)

These things call for both UI and performance
consideration.

> Those who insist on using M-x to discover things
> while working on random buffers (something that
> seems quite bizarre to me, to be honest) still
> can disable the filtering or, better, learn to
> use the Emacs help system.

I know how to use the Emacs help system quite well,
thank you very much.  I also know that being able
to get help on the fly for a given set of things,
and being able to redefine that set on the fly,
are useful - and not just for discovery.

Add to that additional possible actions on
candidates, besides just invocation and help,
and you begin to see why the completion "system"
introduced by Icicles (Helm, Ivy, etc.) are so
useful.

It's about on-the-fly (re-)defining a set of
things, and being able to apply various operations
to any subset of them (including single-candidate
subsets).

This is why I argued to let users filter command
candidates (for `M-x', for example), to limit to
various kinds of commands, including those for
buffers in a given mode.

Give _users_ immediate control, letting them
change which candidates are available on the fly.
We already _do_ that, but the control we give
them, so far, is just over name matching.  There
are umpteen other ways to filter sets of commands
(and other candidates), besides just by name.
___


FWIW, I've even applied this to Isearch, as well.
With `isearch+.el', besides being able to match
buffer text by your text input (search pattern),
you can add and remove filter predicates on the
fly, during Isearch.

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

RE: [External] : Re: Current mode command discovery

[Drew Adams]

> Like I said before: instead of removing what
> seems irrelevant, make them appear after the
> relevant parts.  Otherwise we will lose
> information when we guess wrong (which is an
> easy mistake to make, since the assumption
> that the user always wants only the commands
> from the current major mode is not always true).

I agree.

(But I would say less relevant, not irrelevant.
Even a command you can't invoke can be relevant
for use by `M-x', especially - but not only -
with a completion framework that lets `M-x' do
more than just invoke.)

FWIW -

The approach you describe is similar to the one
taken for key completion in library keysee.el
or Icicles.  You can sort by any of these orders:

 * By key name alphabetically, prefix keys first
 * By key name alphabetically, local keys first
 * By command name alphabetically
 * Off - no sorting

And with either library sortie.el or Icicles you
can hit a key (`C-,' by default) to cycle during
completion among whatever sort orders are available.
___


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

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

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

Re: Current mode command discovery

[Dmitry Gutov]

On 14.02.2021 19:19, Lars Ingebrigtsen wrote:
> This would only be commands that have been marked for the current major
> mode and any active minor modes, I guess?

BTW, you might be interested in this alternative approach (see 
smex-major-mode-commands):

https://github.com/nonsequitur/smex/blob/master/smex.el#L120-L129

No (declare ...) or incompatible changes to 'interactive' necessary. Of 
course, it doesn't support arbitrary predicates. OTOH, it should 
reliably be fast enough.

Re: Current mode command discovery

[Óscar Fuentes]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 14.02.2021 19:19, Lars Ingebrigtsen wrote:
>> This would only be commands that have been marked for the current major
>> mode and any active minor modes, I guess?
>
> BTW, you might be interested in this alternative approach (see
> smex-major-mode-commands):
>
> https://github.com/nonsequitur/smex/blob/master/smex.el#L120-L129
>
> No (declare ...) or incompatible changes to 'interactive' necessary.
> Of course, it doesn't support arbitrary predicates. OTOH, it should
> reliably be fast enough.

That only works with major modes, which IMO is enough to disqualify it,
but on addition it uses crude heuristics for detecting the commands
related to the major mode.

Re: Current mode command discovery

[Dmitry Gutov]

On 14.02.2021 22:00, Óscar Fuentes wrote:
> That only works with major modes, which IMO is enough to disqualify it,

Extending the implementation to minor modes should be straightforward.

> but on addition it uses crude heuristics for detecting the commands
> related to the major mode.

It's fairly crude, but do you imagine any frequent cases where it would 
lead to false positives? Any false negatives can be augmented with 
special (declare ...) instructions. But if we take that approach as a 
basis, fewer commands might such annotations.

Re: Current mode command discovery

[Óscar Fuentes]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 14.02.2021 22:00, Óscar Fuentes wrote:
>> That only works with major modes, which IMO is enough to disqualify it,
>
> Extending the implementation to minor modes should be straightforward.
>
>> but on addition it uses crude heuristics for detecting the commands
>> related to the major mode.
>
> It's fairly crude, but do you imagine any frequent cases where it
> would lead to false positives?

AFAIU it fails for commands that are defined outside of the source file
that `provide's the feature. This happens with large packages, which
incidentally are the ones that define more commands. So the heuristics
fails precisely where the filtering is most needed.

> Any false negatives can be augmented
> with special (declare ...) instructions. But if we take that approach
> as a basis, fewer commands might such annotations.

Yes, it would save many annotations, but not enough to use it as a basis
(see above). Also, commands within a feature that are intended as
generally applicable require an annotation too (to leave them out of the
filtering.)

The approach has its merits, but it looks a bit too fragile to me.

Re: Current mode command discovery

[Dmitry Gutov]

On 14.02.2021 22:49, Óscar Fuentes wrote:

> AFAIU it fails for commands that are defined outside of the source file
> that `provide's the feature. This happens with large packages, which
> incidentally are the ones that define more commands. So the heuristics
> fails precisely where the filtering is most needed.

IME only a minority of packages are like that. Which possibly means that 
the majority of the commands are defined in packages which will satisfy 
the current logic of that implementation.

But those that don't, should be easy enough to augment by adding (mode 
-> (extra-package-1, extra-package-2, ...)) mapping somewhere.

This will still result in an order of magnitude fewer annotations than 
doing them for each command.

>> Any false negatives can be augmented
>> with special (declare ...) instructions. But if we take that approach
>> as a basis, fewer commands might such annotations.
> 
> Yes, it would save many annotations, but not enough to use it as a basis
> (see above). Also, commands within a feature that are intended as
> generally applicable require an annotation too (to leave them out of the
> filtering.)

Yes, sure. This might actually require some special support inside 
'declare', so that the command later could avoid scanning the whole 
obarray (if we care about that).

> The approach has its merits, but it looks a bit too fragile to me.

I like it because the implementation without annotations should already 
work well enough for one to be able to get the feel of the feature 
(meaning, it will likely work better than the current new feature for 
quite some time, if one takes third-party packages without annotations 
into account).

And fixing the misbehaving cases can be done gradually, sort of like 
progressive improvement.

Re: Current mode command discovery

[Stefan Kangas]

Dmitry Gutov <dgutov@yandex.ru> writes:

> This will still result in an order of magnitude fewer annotations than
> doing them for each command.

Why do you think such annotations are a problem?

At least with annotations you don't have to guess if some heuristics
will work, it is immediately clear from reading the code what will
happen.

> I like it because the implementation without annotations should already
> work well enough for one to be able to get the feel of the feature
> (meaning, it will likely work better than the current new feature for
> quite some time, if one takes third-party packages without annotations
> into account).

I for one think the feature is already useful.  But it will get more
useful over time, of course.

Re: Current mode command discovery

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> At least with annotations you don't have to guess if some heuristics
> will work, it is immediately clear from reading the code what will
> happen.

Yup.  Having to skip back to some obscure incantation to guess what's
going on is just annoying.

And then you'd have to annotate the commands that should not be part of
the incantation, which isn't good design.

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

Re: Current mode command discovery

[Dmitry Gutov]

On 15.02.2021 01:18, Stefan Kangas wrote:
>> This will still result in an order of magnitude fewer annotations than
>> doing them for each command.
> Why do you think such annotations are a problem?

Not so much for me, but people we complaining about "extra ceremony" and 
decided that the reduction in said ceremony was worth changing the 
'interactive' in a backward-incompatible way.

Re: Current mode command discovery

[Matt Armstrong]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Now that we have mode markup, should there be a command like `M-x',
> but instead lists only those commands that are specifically relevant
> to the current buffer?
>
> This would only be commands that have been marked for the current
> major mode and any active minor modes, I guess?
>
> If so, should that be bound to something, and if so, what?

Lars, my mail from Wednesday might have nudged you into action on
this. Regardless, at the time I said:

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

So, maybe include the list in `describe-mode' output? Or invent a new
`describe-extended-commands' command and bind that to C-h <something>?

Like a command line, commands like M-x are great for invoking the
commands you know about. Even though I mentioned M-x above, improving
help might be a better starting point.

Re: Current mode command discovery

[Lars Ingebrigtsen]

Matt Armstrong <matt@rfc20.org> writes:

>> 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?
>
> So, maybe include the list in `describe-mode' output?

Yes, I implemented that idea, too -- it's on the trunk.  (The current
implementation just lists all mode-specific commands that aren't bound
to a key in the mode's map.)

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

Re: Current mode command discovery

[Óscar Fuentes]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Now that we have mode markup, should there be a command like `M-x', but
> instead lists only those commands that are specifically relevant to the
> current buffer?
>
> This would only be commands that have been marked for the current major
> mode and any active minor modes, I guess?

That would be very interesting, but AFAIU with the current
implementation it has some problems.

It would miss some candidates which belong to the current mode although
they are not marked as mode-specific because they are also applicable to
other contexts. This would be confusing for the user.

So we need a mechanism for saying `foo-bar-command' belongs to
`foo-mode', but it is not specific of that mode.

Re: Current mode command discovery

[Dmitry Gutov]

On 17.02.2021 04:20, Óscar Fuentes wrote:
> It would miss some candidates which belong to the current mode although
> they are not marked as mode-specific because they are also applicable to
> other contexts. This would be confusing for the user.

If it's applicable to other contexts, we just don't mark it as 
mode-specific. Right?

Or we find a way to enumerate those other contexts.

Re: Current mode command discovery

[Lars Ingebrigtsen]

Note: THIS IS NOT A DISCUSSION ABOUT M-X.

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

> That would be very interesting, but AFAIU with the current
> implementation it has some problems.
>
> It would miss some candidates which belong to the current mode although
> they are not marked as mode-specific because they are also applicable to
> other contexts. This would be confusing for the user.
>
> So we need a mechanism for saying `foo-bar-command' belongs to
> `foo-mode', but it is not specific of that mode.

Yes, that's a problem.

Hm...  there's two obvious sources if information about what commands
"belong" to a mode: There's the key bindings, and then there's the new
mode tagging.  We could perhaps use both in this new command?  I.e., if
somebody has gone to the trouble to add a command to the keymap of the
mode, then it's probably pretty useful for that mode?

A more serious problem that this brings up is the problem with
non-mode-specific predicates: They don't convey any information about
why the predicate is t/nil.  Say you have

(defun foo-spiffy-command ()
  (declare (predicate my-clever-predicate-p))
  (interactive))

When listing mode-specific commands, and this predicate returns t,
should it be included?  Yes?  No?  There's no way of saying, really...

So: Tagging by mode conveys more information to the system than just
having predicates, and we can use that.  This also means that

  (declare (modes ...))

should be implemented differently than it is today (which is just
slapping a predicate onto the symbol-plist).

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

Re: Current mode command discovery

[Dmitry Gutov]

On 17.02.2021 13:30, Lars Ingebrigtsen wrote:
> Note: THIS IS NOT A DISCUSSION ABOUT M-X.
> 
> Óscar Fuentes <ofv@wanadoo.es> writes:
> 
>> That would be very interesting, but AFAIU with the current
>> implementation it has some problems.
>>
>> It would miss some candidates which belong to the current mode although
>> they are not marked as mode-specific because they are also applicable to
>> other contexts. This would be confusing for the user.
>>
>> So we need a mechanism for saying `foo-bar-command' belongs to
>> `foo-mode', but it is not specific of that mode.
> 
> Yes, that's a problem.
> 
> Hm...  there's two obvious sources if information about what commands
> "belong" to a mode: There's the key bindings, and then there's the new
> mode tagging.  We could perhaps use both in this new command?  I.e., if
> somebody has gone to the trouble to add a command to the keymap of the
> mode, then it's probably pretty useful for that mode?

If someone annotated a command with applicability conditions, we should 
probably combine them with 'or' (like if it has both (declare (modes 
...)) and (declare (completion ...))). Having a command belong to a 
keymap could be a new implicit applicability condition.

> A more serious problem that this brings up is the problem with
> non-mode-specific predicates: They don't convey any information about
> why the predicate is t/nil.  Say you have
> 
> (defun foo-spiffy-command ()
>    (declare (predicate my-clever-predicate-p))
>    (interactive))
> 
> When listing mode-specific commands, and this predicate returns t,
> should it be included?  Yes?  No?  There's no way of saying, really...
> 
> So: Tagging by mode conveys more information to the system than just
> having predicates, and we can use that.  This also means that
> 
>    (declare (modes ...))
> 
> should be implemented differently than it is today (which is just
> slapping a predicate onto the symbol-plist).

Moving the checking logic inside the read-extended-command-predicate 
implementation seems logical. (declare (modes ...)) would just add a tag 
to the command, with natural possibility to add other tags, which a 
different read-extended-command-predicate could use.

Re: Current mode command discovery

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Moving the checking logic inside the read-extended-command-predicate
> implementation seems logical.

I'm not sure I understand what you mean here...  that's where the
checking is done today?

> (declare (modes ...)) would just add a tag to the command, with
> natural possibility to add other tags, which a different
> read-extended-command-predicate could use.

Yeah, I think so too -- (declare (modes ...)) should have the same
effect as `interactive "p" ...', not create a predicate.  Probably.

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

Re: Current mode command discovery

[Dmitry Gutov]

On 17.02.2021 19:52, Lars Ingebrigtsen wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> Moving the checking logic inside the read-extended-command-predicate
>> implementation seems logical.
> 
> I'm not sure I understand what you mean here...  that's where the
> checking is done today?

Bad phrasing, I guess.

I'm referring to the same thing you do below: that byte-run--set-modes 
just sets the 'completion-predicate' property, instead of setting some 
transparent tag which any read-extended-command-predicate could 
interpret according to its own particular intent.

>> (declare (modes ...)) would just add a tag to the command, with
>> natural possibility to add other tags, which a different
>> read-extended-command-predicate could use.
> 
> Yeah, I think so too -- (declare (modes ...)) should have the same
> effect as `interactive "p" ...', not create a predicate.  Probably.

Or both (interactive "p" ...) and (declare (modes ...)) should do 
something similar to what (declare (completion ...)) does (except use a 
different property).

I'm curious to know whether the change in performance will be at all 
noticeable.

Re: Current mode command discovery

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Bad phrasing, I guess.
>
> I'm referring to the same thing you do below: that byte-run--set-modes
> just sets the 'completion-predicate' property, instead of setting some
> transparent tag which any read-extended-command-predicate could
> interpret according to its own particular intent.

Oh, OK.

> Or both (interactive "p" ...) and (declare (modes ...)) should do
> something similar to what (declare (completion ...)) does (except use
> a different property).
>
> I'm curious to know whether the change in performance will be at all
> noticeable.

I guess the main performance difference is in loading the .elc files --
parsing and applying all the `put's.

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

Re: Current mode command discovery

[Dmitry Gutov]

On 18.02.2021 12:14, Lars Ingebrigtsen wrote:
> I guess the main performance difference is in loading the .elc files --
> parsing and applying all the `put's.

Hm. Are you saying that the use of (declare (completion ...)) form 
currently requires us to parse all .elc files?

Re: Current mode command discovery

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 18.02.2021 12:14, Lars Ingebrigtsen wrote:
>> I guess the main performance difference is in loading the .elc files --
>> parsing and applying all the `put's.
>
> Hm. Are you saying that the use of (declare (completion ...)) form
> currently requires us to parse all .elc files?

No -- I'm saying that I guess the M-x completion performance difference
is probably very small between the two approaches.  The current approach
is to stash the data in the bytecode object and retrieving it with
`command-modes' vs. doing `get' on the symbol.  `command-modes' is O(1)
and `get' is O(n), but the n is so small on typical symbols that I doubt
there's much of a measurable difference.  And `get' has a bytecode
opcode, so it may even be faster for all I know.

But I haven't measured.

The disadvantage in using a `put' for this data is mainly in that it
makes .elc files larger (and therefore slower to load).

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

Re: Current mode command discovery

[Dmitry Gutov]

On 18.02.2021 16:06, Lars Ingebrigtsen wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> On 18.02.2021 12:14, Lars Ingebrigtsen wrote:
>>> I guess the main performance difference is in loading the .elc files --
>>> parsing and applying all the `put's.
>>
>> Hm. Are you saying that the use of (declare (completion ...)) form
>> currently requires us to parse all .elc files?
> 
> No -- I'm saying that I guess the M-x completion performance difference
> is probably very small between the two approaches.  The current approach
> is to stash the data in the bytecode object and retrieving it with
> `command-modes' vs. doing `get' on the symbol.  `command-modes' is O(1)
> and `get' is O(n), but the n is so small on typical symbols that I doubt
> there's much of a measurable difference.  And `get' has a bytecode
> opcode, so it may even be faster for all I know.

All right.

> But I haven't measured.
> 
> The disadvantage in using a `put' for this data is mainly in that it
> makes .elc files larger (and therefore slower to load).

The difference will probably be higher in autoload files (which will 
require separate 'put' forms to be added, right?).

If it were up to me, I'd see if it's possible to reuse some slots in 
autoload byte-compiled form in a backward-compatible fashion, and then 
consider, depending on the actual performance difference, maybe do break 
it in some future version of Emacs. It's not as important as 
source-level compatibility, IMO.

Re: Current mode command discovery

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

>> But I haven't measured.
>> The disadvantage in using a `put' for this data is mainly in that it
>> makes .elc files larger (and therefore slower to load).
>
> The difference will probably be higher in autoload files (which will
> require separate 'put' forms to be added, right?).

If we're using `put' -- yup.  Stashing the modes in the interactive spec
in autoload files (which Emacs 28 currently does) is quite efficient.

However, this may be a smaller issue than you'd think.  Most things that
are tagged as ;;;###autoload won't be mode-specific: They are
autoloadable exactly because they can be called from anywhere in Emacs.

The exception here is larger packages (like Gnus) that spread commands
over a number of files.  Then it's common to ;;;###autoload commands
even if they aren't global commands.  This is arguable the wrong way to
use ;;;###autoload -- instead, say, gnus-sum.el should declare these
functions instead.

Currently, with the filter predicate, "emacs -Q" `M-x gnusTAB' will
diplay ~50 completions.  Without the predicate, you get ~65 completions.

So mode-tagging autoloaded commands is going to be a thing, but it's not
a huge thing.

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

Re: Current mode command discovery

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 19 Feb 2021 13:23:10 +0100
> Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
> 
> However, this may be a smaller issue than you'd think.  Most things that
> are tagged as ;;;###autoload won't be mode-specific: They are
> autoloadable exactly because they can be called from anywhere in Emacs.

That's not necessarily true.  We also use ;;;###autoload as the means
to load a mode when some command is invoked.

Re: Current mode command discovery

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> However, this may be a smaller issue than you'd think.  Most things that
>> are tagged as ;;;###autoload won't be mode-specific: They are
>> autoloadable exactly because they can be called from anywhere in Emacs.
>
> That's not necessarily true.  We also use ;;;###autoload as the means
> to load a mode when some command is invoked.

I'm not quite sure what you're mean here?  We use ;;;###autoload on
functions that aren't commands; yes.  But a (major) mode can't (by
definition) be a mode-specific command.

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

Re: Current mode command discovery

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  ofv@wanadoo.es,  emacs-devel@gnu.org
> Date: Fri, 19 Feb 2021 13:34:48 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> However, this may be a smaller issue than you'd think.  Most things that
> >> are tagged as ;;;###autoload won't be mode-specific: They are
> >> autoloadable exactly because they can be called from anywhere in Emacs.
> >
> > That's not necessarily true.  We also use ;;;###autoload as the means
> > to load a mode when some command is invoked.
> 
> I'm not quite sure what you're mean here?

What I mean is this: we do sometimes mark mode-specific commands as
autoloaded, for the reason I explained.  Unlike what you said, which
is that most things that we autoload are NOT mode-specific.

> We use ;;;###autoload on functions that aren't commands; yes.  But a
> (major) mode can't (by definition) be a mode-specific command.

I don't see how this is relevant.

Re: Current mode command discovery

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> What I mean is this: we do sometimes mark mode-specific commands as
> autoloaded, for the reason I explained.  Unlike what you said, which
> is that most things that we autoload are NOT mode-specific.

I think you're just saying the same thing I did?  I said that most
commands that are ;;;###autoloaded aren't mode-specific.  You say that
some ;;;###autoloaded commands are mode-specific.

I think we're in violent agreement here, unless you somehow interpret
"most" as being "all".

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

Re: Current mode command discovery

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 19 Feb 2021 13:59:26 +0100
> Cc: ofv@wanadoo.es, emacs-devel@gnu.org, dgutov@yandex.ru
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > What I mean is this: we do sometimes mark mode-specific commands as
> > autoloaded, for the reason I explained.  Unlike what you said, which
> > is that most things that we autoload are NOT mode-specific.
> 
> I think you're just saying the same thing I did?  I said that most
> commands that are ;;;###autoloaded aren't mode-specific.  You say that
> some ;;;###autoloaded commands are mode-specific.
> 
> I think we're in violent agreement here, unless you somehow interpret
> "most" as being "all".

Unless "most" means 95% percent or so, and we can disregard the
remaining 5%, how is it useful to know that "most" autoloaded commands
are not mode-specific?  We will need to handle both those that are and
those that aren't, so the fact that commands that are mode-specific
and yet are autoloaded are a minority doesn't help, does it?

Re: Current mode command discovery

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Unless "most" means 95% percent or so, and we can disregard the
> remaining 5%, how is it useful to know that "most" autoloaded commands
> are not mode-specific?  We will need to handle both those that are and
> those that aren't, so the fact that commands that are mode-specific
> and yet are autoloaded are a minority doesn't help, does it?

Of course we need to handle them -- that's never been a topic here.

Dmitry asked whether using `put' as the mode specifier would increase
the size of the autoload files significantly (as opposed to how I
implemented it, which is to stick them in the interactive spec slot),
and I said that based on initial tagging, that's not really much of a
concern one way or another, because most ;;;###autoload functions are
global.

I.e., changing the implementation to use `put' won't blow the size of
loaddefs.el up.

So the minority status of ;;;###autoloaded mode-specific commands was
the entire point.

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

Re: Current mode command discovery

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: ofv@wanadoo.es,  emacs-devel@gnu.org,  dgutov@yandex.ru
> Date: Fri, 19 Feb 2021 14:45:59 +0100
> 
> Dmitry asked whether using `put' as the mode specifier would increase
> the size of the autoload files significantly (as opposed to how I
> implemented it, which is to stick them in the interactive spec slot),
> and I said that based on initial tagging, that's not really much of a
> concern one way or another, because most ;;;###autoload functions are
> global.
> 
> I.e., changing the implementation to use `put' won't blow the size of
> loaddefs.el up.
> 
> So the minority status of ;;;###autoloaded mode-specific commands was
> the entire point.

A minority out of the number of commands we have can still be a
substantial number, though.

Re: Current mode command discovery

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> A minority out of the number of commands we have can still be a
> substantial number, though.

True.  We've only done tagging in a few modes so far, so we won't have
reliable data until we've done a bunch more.  But the tendency, so far,
is that there aren't that many of these.

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

Re: Current mode command discovery

[Dmitry Gutov]

On 19.02.2021 14:30, Eli Zaretskii wrote:
> That's not necessarily true.  We also use ;;;###autoload as the means
> to load a mode when some command is invoked.

I think that means that such commands don't need to be tagged (since 
they can be called before the mode is even defined).

Re: Current mode command discovery

[Eli Zaretskii]

> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 19 Feb 2021 14:35:12 +0200
> 
> On 19.02.2021 14:30, Eli Zaretskii wrote:
> > That's not necessarily true.  We also use ;;;###autoload as the means
> > to load a mode when some command is invoked.
> 
> I think that means that such commands don't need to be tagged (since 
> they can be called before the mode is even defined).

You mean, they _should_not_ be tagged, yes?

Re: Current mode command discovery

[Dmitry Gutov]

On 19.02.2021 14:43, Eli Zaretskii wrote:
>>> That's not necessarily true.  We also use ;;;###autoload as the means
>>> to load a mode when some command is invoked.
>> I think that means that such commands don't need to be tagged (since
>> they can be called before the mode is even defined).
> You mean, they_should_not_  be tagged, yes?

Yes. Thus they won't slow down the loading of loaddefs, which was the 
concern.

Re: Current mode command discovery

[Dmitry Gutov]

On 19.02.2021 14:23, Lars Ingebrigtsen wrote:
> However, this may be a smaller issue than you'd think.  Most things that
> are tagged as ;;;###autoload won't be mode-specific: They are
> autoloadable exactly because they can be called from anywhere in Emacs.

Thank you. That makes me optimistic about this approach.

Re: Current mode command discovery

[Matt Armstrong]

To your original queston of "should we build a command like this?" I
suspect it just needs to be prototyped to see how it feels.

I have many times totally failed to appreciate how useful a thing could
be *before* I tried it out.

I know that, personally, I have't felt I wanted such a thing so far.
Command name prefixes in M-x do a pretty good job (for me).


Lars Ingebrigtsen <larsi@gnus.org> writes:


[...]

> Hm...  there's two obvious sources if information about what commands
> "belong" to a mode: There's the key bindings, and then there's the new
> mode tagging.  We could perhaps use both in this new command?  I.e., if
> somebody has gone to the trouble to add a command to the keymap of the
> mode, then it's probably pretty useful for that mode?

A third possible signal is the command name prefix.

A fourth signal could be a new 'all mode annotation that means
"generally useful" regardless of mode.

I say "signal" because I'm not sure what you're imagining: a
exploration/discoverability tool or a menu of stuff absolutely known to
work here commands.



[...]

> So: Tagging by mode conveys more information to the system than just
> having predicates, and we can use that.  This also means that
>
>   (declare (modes ...))
>
> should be implemented differently than it is today (which is just
> slapping a predicate onto the symbol-plist).

Declarative programming for the win.

Could the (declare (modes ...)) and the new (interactive ... modes) be
unified?  I understand that they do different things today, but they're
both called "modes" and the difference is pretty subtle.  If they stay
separate, perhaps rename to (declare (completion-modes ...))?

Re: Current mode command discovery

[Lars Ingebrigtsen]

Matt Armstrong <matt@rfc20.org> writes:

> To your original queston of "should we build a command like this?" I
> suspect it just needs to be prototyped to see how it feels.
>
> I have many times totally failed to appreciate how useful a thing could
> be *before* I tried it out.

That's true.

> A third possible signal is the command name prefix.

No, heuristics are to be avoided.  There's always too many corner cases
for that to be satisfactory, which approx. three hundred previous
completion frameworks that have tried shows...

> A fourth signal could be a new 'all mode annotation that means
> "generally useful" regardless of mode.

All untagged commands are presumed to be somewhat generally useful, so
that doesn't limit it much.  :-)

> Could the (declare (modes ...)) and the new (interactive ... modes) be
> unified?  I understand that they do different things today, but they're
> both called "modes" and the difference is pretty subtle.  If they stay
> separate, perhaps rename to (declare (completion-modes ...))?

I think I've argued enough against "(declare (modes" as the only tagging
mechanism now?

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

Re: Current mode command discovery

[Matt Armstrong]

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

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> Could the (declare (modes ...)) and the new (interactive ... modes)
>> be unified?  I understand that they do different things today, but
>> they're both called "modes" and the difference is pretty subtle.  If
>> they stay separate, perhaps rename to (declare (completion-modes
>> ...))?
>
> I think I've argued enough against "(declare (modes" as the only
> tagging mechanism now?

I was just confused.  I didn't realize they were the same thing.

Your recent commit to commands.texi fixed my conception, thanks.

P.S. typo in that commit, fixup patch attached.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: fix typo --]
[-- Type: text/x-patch, Size: 1060 bytes --]

From 470910f58ffb151cd5221dbe3b30dc16a59b2063 Mon Sep 17 00:00:00 2001
From: Matt Armstrong <matt@rfc20.org>
Date: Wed, 17 Feb 2021 14:23:23 -0800
Subject: [PATCH] * doc/lispref/commands.texi (Command Modes): Fix typo.

---
 doc/lispref/commands.texi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/lispref/commands.texi b/doc/lispref/commands.texi
index 85376cc459..e171c3e168 100644
--- a/doc/lispref/commands.texi
+++ b/doc/lispref/commands.texi
@@ -597,8 +597,8 @@ Command Modes
 @subsection Specifying Modes For Commands
 
 Many commands in Emacs are general, and not tied to any specific mode.
-For instance, @kbd{M-x kill-region} can be used pretty in pretty much
-any mode that has editable text, and commands that display information
+For instance, @kbd{M-x kill-region} can be used in pretty much any
+mode that has editable text, and commands that display information
 (like @kbd{M-x list-buffers}) can be used in pretty much any context.
 
 Many other commands, however, are specifically tied to a mode, and
-- 
2.30.0

Re: Current mode command discovery

[Lars Ingebrigtsen]

Matt Armstrong <matt@rfc20.org> writes:

> P.S. typo in that commit, fixup patch attached.

Thanks; applied now.

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

Re: Current mode command discovery

[Stefan Kangas]

Matt Armstrong <matt@rfc20.org> writes:

> I say "signal" because I'm not sure what you're imagining: a
> exploration/discoverability tool or a menu of stuff absolutely known to
> work here commands.

My hope is that `M-x' will eventually be more like the latter, while
`M-X' will be more like "immediately relevant to this mode".

Re: Current mode command discovery

[Matt Armstrong]

Stefan Kangas <stefankangas@gmail.com> writes:

> Matt Armstrong <matt@rfc20.org> writes:
>
>> I say "signal" because I'm not sure what you're imagining: a
>> exploration/discoverability tool or a menu of stuff absolutely known to
>> work here commands.
>
> My hope is that `M-x' will eventually be more like the latter, while
> `M-X' will be more like "immediately relevant to this mode".

Yes, I like that idea.

Re: Current mode command discovery

[Jean Louis]

* Lars Ingebrigtsen <larsi@gnus.org> [2021-02-17 14:33]:
> Note: THIS IS NOT A DISCUSSION ABOUT M-X.
> 
> Óscar Fuentes <ofv@wanadoo.es> writes:
> 
> > That would be very interesting, but AFAIU with the current
> > implementation it has some problems.
> >
> > It would miss some candidates which belong to the current mode although
> > they are not marked as mode-specific because they are also applicable to
> > other contexts. This would be confusing for the user.
> >
> > So we need a mechanism for saying `foo-bar-command' belongs to
> > `foo-mode', but it is not specific of that mode.
> 
> Yes, that's a problem.
> 
> Hm...  there's two obvious sources if information about what commands
> "belong" to a mode: There's the key bindings, and then there's the new
> mode tagging.  We could perhaps use both in this new command?  I.e., if
> somebody has gone to the trouble to add a command to the keymap of the
> mode, then it's probably pretty useful for that mode?

For your consideration, many of commands I program are useful globally
but bound to specific keymap and mostly useful in specific mode. It is
useful in that mode, it appears in the menu, but is also useful
globally.

If I wish to see all SMS messages sent and received, I may invoke such
command in mode, on the line specific to person with some ID number
like 123 would be SMS messages related to 123, but invoked globally I
could see the latest messages list and simply respond or send new
messages from there.

Maybe consider advising package authors how to designate commands
related to specific modes. My idea about that is that you invoke new
variable automatically when defining the mode and that authors or
users if not authors, can add function names in a list to that
variable.

That way some users can extend the package and simply add new
functions to the same mode, so those functions would be appearing in
that mode, even if outside of scope of the mode.

Jean

Re: Current mode command discovery

[Jean Louis]

* Óscar Fuentes <ofv@wanadoo.es> [2021-02-17 05:21]:
> So we need a mechanism for saying `foo-bar-command' belongs to
> `foo-mode', but it is not specific of that mode.

1. A new variable can be introduced automatically when defining a
   mode, similarly how it is already done.

2. Package author OR user, could then just add function names as list
   items to that variable.

3. M-x and Emacs can then know that specific commands belong to
   foo-mode.

Re: Current mode command discovery

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Now that we have mode markup, should there be a command like `M-x', but
> instead lists only those commands that are specifically relevant to the
> current buffer?
>
> This would only be commands that have been marked for the current major
> mode and any active minor modes, I guess?
>
> If so, should that be bound to something, and if so, what?

I've now added a first attempt at this to the trunk now.

Click on a completion to select it.  In an eww buffer, it gives the
following commands to complete over.  Which seems reasonable...  ish.

Peculiarities that we might consider:

`ignore' shows up here, because we've bound `h' to `ignore' as a way to
disable that key binding.  That doesn't sound kinda non-ideal -- it
should be unbound instead.

`erc-track-switch-buffer' is a global minor mode?  Why?  All the minor
modes defined by erc are global, it seems like, which is kinda odd.

Uhm...  OK, I think that's it.  It doesn't seem like a bad list for a
first implementation.

The command name is really bad, though:
`execute-extended-command-for-buffer'.  Suggestions for a better name
are welcome.

Oh, and it's bound to `M-S-x' (for now).

In this buffer, type RET to select the completion near point.  

Possible completions are:
beginning-of-buffer (<) 	describe-mode (?)
digit-argument (9) 	end-of-buffer (>)
erc-track-switch-buffer (C-c C-@) 	eww (G)
eww-add-bookmark (b) 	eww-back-url (l)
eww-beginning-of-text 	eww-browse-with-external-browser (&)
eww-change-select 	eww-copy-page-url (w)
eww-download (d) 	eww-end-of-text
eww-follow-link 	eww-forward-url (r)
eww-list-bookmarks (B) 	eww-list-buffers (S)
eww-list-histories (H) 	eww-next-bookmark (M-n)
eww-next-url (n) 	eww-open-in-new-buffer (M-RET)
eww-previous-bookmark (M-p) 	eww-previous-url (p)
eww-readable (R) 	eww-reload (g)
eww-select-file 	eww-set-character-encoding (E)
eww-submit 	eww-switch-to-buffer (s)
eww-toggle-checkbox 	eww-toggle-colors (M-C)
eww-toggle-fonts (F) 	eww-toggle-paragraph-direction (D)
eww-top-url (t) 	eww-up-url (u)
eww-view-source (v) 	ignore (h)
negative-argument (-) 	org-eww-copy-for-org-mode (C-c C-x C-w)
quit-window (q) 	scroll-down-command (DEL)
scroll-up-command (SPC) 	shr-next-link (TAB)
shr-previous-link (C-M-i) 	url-cookie-list (C)

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

Re: Current mode command discovery

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sat, 20 Feb 2021 15:18:11 +0100
> 
> I've now added a first attempt at this to the trunk now.

Thanks, but why is it not documented in the user manual?  It's a
command, so the user manual, not the ELisp manual, is the preferred
place for its documentation.

Re: Current mode command discovery

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Thanks, but why is it not documented in the user manual?  It's a
> command, so the user manual, not the ELisp manual, is the preferred
> place for its documentation.

I had a feeling I'd forgotten something.

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

Re: Current mode command discovery

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sat, 20 Feb 2021 15:31:53 +0100
> Cc: emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Thanks, but why is it not documented in the user manual?  It's a
> > command, so the user manual, not the ELisp manual, is the preferred
> > place for its documentation.
> 
> I had a feeling I'd forgotten something.

I've now tried this new command.

  emacs -Q
  M-S-x

This shows "M-x" prompt, whereas I expected either "M-X" or "M-S-x".

  TAB

This shows the following *help* buffer:

  Click on a completion to select it.
  In this buffer, type RET to select the completion near point.

  Possible completions are:
  backward-delete-char-untabify (DEL)		completion-at-point (C-M-i)
  edebug-defun (edebug-eval-top-level-form)
  eval-defun (C-M-x)				eval-print-last-sexp (C-j)
  indent-pp-sexp (C-M-q)

That's it.  All of it.  Is that the intent?

Re: Current mode command discovery

[Alfred M. Szmidt]

   I've now tried this new command.

     emacs -Q
     M-S-x

Should be noted that M-S-x is tricky to get working on console -- far
more tricky than s-x or similar in my experience.

Re: Current mode command discovery

[Gregory Heytings]

>
> Should be noted that M-S-x is tricky to get working on console -- far 
> more tricky than s-x or similar in my experience.
>

M-S-x works out of the box without any particular configuration on Debian 
GNU/Linux, both in a console and in a terminal.

Re: Current mode command discovery

[Alfred M. Szmidt]

   > Should be noted that M-S-x is tricky to get working on console -- far 
   > more tricky than s-x or similar in my experience.

   M-S-x works out of the box without any particular configuration on Debian 
   GNU/Linux, both in a console and in a terminal.

My experience doesn't include Debian, so I am glad it works for you
and you do not have any issues with it.

Re: Current mode command discovery

[Gregory Heytings]

>>> Should be noted that M-S-x is tricky to get working on console -- far 
>>> more tricky than s-x or similar in my experience.
>>
>> M-S-x works out of the box without any particular configuration on 
>> Debian GNU/Linux, both in a console and in a terminal.
>
> My experience doesn't include Debian, so I am glad it works for you and 
> you do not have any issues with it.
>

I doesn't work only for me: Debian and Debian-derived distributions 
dominate the "market" AFAIK.  And you did not specify what distribution 
you use, your statement was a general one.

Re: Current mode command discovery

[Andreas Schwab]

On Feb 20 2021, Alfred M. Szmidt wrote:

> Should be noted that M-S-x is tricky to get working on console

M-X works on any terminal.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Current mode command discovery

[Alfred M. Szmidt]

   > Should be noted that M-S-x is tricky to get working on console

   M-X works on any terminal.

M-S-x does not work in _any_ terminal, there are plenty of dumb ass
terminals in embedded systems (sometimes custom, sometimes BSD,
sometimes GNU, sometimes some other Unix) that are capable of running
Emacs just fine where it does not work and it is a pain to setup.

That is what _my_ experience is, I am happy for you and others that it
works for you, but lets stop pretending that everyone runs the exact
same thing, and everything works the exact same way for everyone.

Re: Current mode command discovery

[Stefan Monnier]

>    > Should be noted that M-S-x is tricky to get working on console
>    M-X works on any terminal.
> M-S-x does not work in _any_ terminal,

Indeed the treatment of "shift" in input events is surprisingly delicate
and messy.  We should make sure that both events get mapped to the same
command, indeed, regardless of this new keybinding.  In the terminals
I use hitting "meta + shift + x" sends Emacs "ESC X" which leads Emacs
to find the intended command without any trouble.  Which terminals have
you found which do differently?

This said, I don't think it's very important: `M-X` is bound to a new
command whose importance has not been demonstrated yet: maybe it'll
prove to be super convenient, and maybe it'll be just one more
experiment which didn't pan out.  So if it's difficult to access its
default binding in some setups, I'm not too worried.  We have many other
default bindings of reasonably important commands which are probably
a lot harder to access depending on your keyboard layout (like `M-C-%`)


        Stefan

Re: Current mode command discovery

[Alfred M. Szmidt]

   >    > Should be noted that M-S-x is tricky to get working on console
   >    M-X works on any terminal.
   > M-S-x does not work in _any_ terminal,

   Indeed the treatment of "shift" in input events is surprisingly delicate
   and messy.  We should make sure that both events get mapped to the same
   command, indeed, regardless of this new keybinding.  In the terminals
   I use hitting "meta + shift + x" sends Emacs "ESC X" which leads Emacs
   to find the intended command without any trouble.  Which terminals have
   you found which do differently?

I've mostly managed to avoided the issue.  But the majority of times
I've had them is when you connect to a remote system over a serial
line using cu or similar dumb program (the termcap to be something
dumb / exotic, and vt100 does not work).  Various terminal servers
(Moxa...)  also have had issues in how they handle shift when combined
with bucky keys, specially the older ones.

   This said, I don't think it's very important: `M-X` is bound to a
   new command whose importance has not been demonstrated yet: maybe
   it'll prove to be super convenient, and maybe it'll be just one
   more experiment which didn't pan out.  So if it's difficult to
   access its default binding in some setups, I'm not too worried.

Maybe, maybe not -- it was just a data point for someone to consider.

(But since everything is some Debian connected to a ANY terminal by
Andreas Schwab ltd ... do those support s-x and h-x? ;-)

Re: Current mode command discovery

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

These changes seem radical to me.  Shouldn't they be released as a
library that can be loaded, not as part of the default command set
of Emacs?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Current mode command discovery

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sun, 21 Feb 2021 01:15:31 -0500
> Cc: larsi@gnus.org, ams@gnu.org, schwab@linux-m68k.org, eliz@gnu.org,
>  emacs-devel@gnu.org
> 
> These changes seem radical to me.  Shouldn't they be released as a
> library that can be loaded, not as part of the default command set
> of Emacs?

Maybe we should indeed put them on subr-x or somesuch.

Re: Current mode command discovery

[Gregory Heytings]

>>> Should be noted that M-S-x is tricky to get working on console
>>
>> M-X works on any terminal.
>
> M-S-x does not work in _any_ terminal, there are plenty of dumb ass 
> terminals in embedded systems (sometimes custom, sometimes BSD, 
> sometimes GNU, sometimes some other Unix) that are capable of running 
> Emacs just fine where it does not work and it is a pain to setup.
>
> That is what _my_ experience is, I am happy for you and others that it 
> works for you, but lets stop pretending that everyone runs the exact 
> same thing, and everything works the exact same way for everyone.
>

A few days ago you claimed that the super key works in consoles and 
terminals, in spite of the fact that it doesn't work out of the box 
anywhere.  And now you claim that M-S-x doesn't work in consoles and 
terminals, in spite of the fact that it works out of the box almost 
everywhere...

Yes, there are rare exceptions, but I just tried various Emacs versions on 
various operating systems, including an Emacs 20 on a twenty years old 
Tru64, and M-S-x just works.

Re: Current mode command discovery

[Alfred M. Szmidt]

   A few days ago you claimed that the super key works in consoles and 
   terminals, in spite of the fact that it doesn't work out of the box 
   anywhere.  

The super modifier works out of the box using 'C-x @ s' (with some
limitations where you cannot combine s- with h-).

   And now you claim that M-S-x doesn't work in consoles and 
   terminals, in spite of the fact that it works out of the box almost 
   everywhere...

I wrote that it is a pain to setup correctly, and that it doesn't work
-- both in my experience.  What your experience is not mine, and it
would be nice if you stopped pretending that you know anything about
it.

Re: Current mode command discovery

[Gregory Heytings]

>> A few days ago you claimed that the super key works in consoles and 
>> terminals, in spite of the fact that it doesn't work out of the box 
>> anywhere.
>
> The super modifier works out of the box using 'C-x @ s' (with some 
> limitations where you cannot combine s- with h-).
>

If you still believe that this is "using the super modifier", then you 
should agree that M-S-x works out of the box in any terminal: "C-x @ m 
S-x".

>
> What your experience is not mine, and it would be nice if you stopped 
> pretending that you know anything about it.
>

I do not pretend I know anything about your experience, I replied to your 
unreserved statement "M-S-x is tricky to get working on console".

Re: Current mode command discovery

[Alfred M. Szmidt]

   ... then you should agree that M-S-x works out of the box in any
   terminal: "C-x @ m S-x".

And nothing what I wrote claimed anything else -- yes you can input
the M-S-x key sequence in other ways.  But getting M-S-x to work in
some situations can be extra tricky compared to say faking hyper/super
using another key that can be sent or using C-x @ -- the shift key
often needs extra care, that is all.

It is also why it is often the case to avoid using shift (other than
being slightly confusing to the user when using caps-lock) when
combining it with other buckies, because of encountered trickyness in
some terminals or even just where the keyboard cannot do too many
modifiers at the same time or has other issues with ghosting.

Re: Current mode command discovery

[Andreas Schwab]

On Feb 20 2021, Alfred M. Szmidt wrote:

>    > Should be noted that M-S-x is tricky to get working on console
>
>    M-X works on any terminal.
>
> M-S-x does not work in _any_ terminal,

ESC X works on any terminal.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Current mode command discovery

[Alfred M. Szmidt]

I (~20 YEARS AGO) HACKED EMACS ON A TEKTRONIX 4010 TO ALLOW ME TO DRAW
VECTOR GRAPHICS ON  THE DISPLAY FROM EMACS USING A  LOGO / TURTLE LIKE
LANGUAGE -- WHILE IT HAD A SHIFT KEY, IT ONLY WORKED FOR THE FIRST ROW
OF KEYS SINCE ALL LETTERS WHERE UPPER CASE.  IT DID NOT HAVE AN ESCAPE
KEY, YOU HAD TO TYPE CONTROL SHIFT K X TO GET M-X.

SO YOU MIGHT BE RIGHT IN THAT  MAYBE IT IS ACTUALLY M-X <LOWER CASE X>
THAT IS  UNTYPABLE ON THE  ANY TERMINAL ...   BUT LETS NOW  SHIFT THIS
DISCUSSION...

Re: Current mode command discovery

[Jean Louis]

* Alfred M. Szmidt <ams@gnu.org> [2021-02-20 23:18]:
>    > Should be noted that M-S-x is tricky to get working on console
> 
>    M-X works on any terminal.
> 
> M-S-x does not work in _any_ terminal, there are plenty of dumb ass
> terminals in embedded systems (sometimes custom, sometimes BSD,
> sometimes GNU, sometimes some other Unix) that are capable of running
> Emacs just fine where it does not work and it is a pain to setup.
> 
> That is what _my_ experience is, I am happy for you and others that it
> works for you, but lets stop pretending that everyone runs the exact
> same thing, and everything works the exact same way for everyone.

To add user report to it, on Hyperbola GNU/Linux-libre OS:

I have tried M-S-x on Emacs GUI, and it is not detected by C-h k in
the Emacs version from 2021-02-20.

in XTerm, the shift is not detected, M-S-x is detected as M-x

in console (tty) it is not detected, M-S-x is detected as M-x

Re: Current mode command discovery

[Andreas Schwab]

On Feb 28 2021, Jean Louis wrote:

> in XTerm, the shift is not detected, M-S-x is detected as M-x
>
> in console (tty) it is not detected, M-S-x is detected as M-x

That's because M-X isn't bound.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Current mode command discovery

[Alfred M. Szmidt]

   > in XTerm, the shift is not detected, M-S-x is detected as M-x
   >
   > in console (tty) it is not detected, M-S-x is detected as M-x

   That's because M-X isn't bound.

M-X get translated to M-x.

Re: Current mode command discovery

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I've now tried this new command.
>
>   emacs -Q
>   M-S-x
>
> This shows "M-x" prompt, whereas I expected either "M-X" or "M-S-x".

Ah, yes, that should be fixed...

>   TAB
>
> This shows the following *help* buffer:
>
>   Click on a completion to select it.
>   In this buffer, type RET to select the completion near point.
>
>   Possible completions are:
>   backward-delete-char-untabify (DEL)		completion-at-point (C-M-i)
>   edebug-defun (edebug-eval-top-level-form)
>   eval-defun (C-M-x)				eval-print-last-sexp (C-j)
>   indent-pp-sexp (C-M-q)
>
> That's it.  All of it.  Is that the intent?

Yup.  Well, `lisp-interaction-mode' hasn't been tagged up, so you're
basically getting `C-h m' in `M-x'-like form.  I'm not sure `M-S-x' in
the *scratch* buffer will ever include more than that, but this command
is (well, will be) more useful for command discovery in more specialised
modes.

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

Re: Current mode command discovery

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 20 Feb 2021 15:51:18 +0100
> 
> >   Click on a completion to select it.
> >   In this buffer, type RET to select the completion near point.
> >
> >   Possible completions are:
> >   backward-delete-char-untabify (DEL)		completion-at-point (C-M-i)
> >   edebug-defun (edebug-eval-top-level-form)
> >   eval-defun (C-M-x)				eval-print-last-sexp (C-j)
> >   indent-pp-sexp (C-M-q)
> >
> > That's it.  All of it.  Is that the intent?
> 
> Yup.  Well, `lisp-interaction-mode' hasn't been tagged up, so you're
> basically getting `C-h m' in `M-x'-like form.  I'm not sure `M-S-x' in
> the *scratch* buffer will ever include more than that, but this command
> is (well, will be) more useful for command discovery in more specialised
> modes.

Really?  I thought the intent was to filter _out_ those commands that
are not relevant.  If the intent is to filter _in_, then won't this
omit many important commands?

IOW, what is the use case for completing _only_ on the commands that
were tagged as being relevant for the current major mode?

Re: Current mode command discovery

[Dmitry Gutov]

On 20.02.2021 17:23, Eli Zaretskii wrote:
> Really?  I thought the intent was to filter_out_  those commands that
> are not relevant.

I think that's the idea of the new feature for 'M-x', not 'M-X'.

RE: [External] : Re: Current mode command discovery

[Drew Adams]

> > Really?  I thought the intent was to filter_out_  those commands that
> > are not relevant.
> 
> I think that's the idea of the new feature for 'M-x', not 'M-X'.

Have we seen a complete, succinct, description
of the two "features" (which both apparently
filter)?

Could someone please post that description,
apart from these long, convoluted threads?

RE: [External] : Re: Current mode command discovery

[Drew Adams]

> > > Really?  I thought the intent was to filter_out_  those commands
> > > that are not relevant.
> >
> > I think that's the idea of the new feature for 'M-x', not 'M-X'.
> 
> Have we seen a complete, succinct, description
> of the two "features" (which both apparently
> filter)?
> 
> Could someone please post that description,
> apart from these long, convoluted threads?

ping.

Re: Current mode command discovery

[Kévin Le Gouguec]

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

>> Have we seen a complete, succinct, description
>> of the two "features" (which both apparently
>> filter)?
>> 
>> Could someone please post that description,
>> apart from these long, convoluted threads?
>
> ping.

I believe the NEWS file on the master branch has been kept up-to-date:

https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS

Here are all the relevant snippets I could think of (apologies if I got
confused and cited things that are irrelevant to this thread):

> ** New command 'execute-extended-command-for-buffer'.
> This new command, bound to 'M-S-x', works like
> 'execute-extended-command', but limits the set of commands to the
> commands that have been determined to be particularly useful with the
> current mode.

> ** New user option 'read-extended-command-predicate'.
> This option controls how 'M-x' performs completion of commands when
> you type TAB.  By default, any command that matches what you have
> typed is considered a completion candidate, but you can customize this
> option to exclude commands that are not applicable to the current
> buffer's major and minor modes, and respect the command's completion
> predicate (if any).

> ** New forms to declare how completion should happen has been added.
> '(declare (completion PREDICATE))' can be used as a general predicate
> to say whether the command should be present when completing with
> 'M-x TAB'.  '(declare (modes MODE...))' can be used as a short-hand
> way of saying that the command should be present when completing from
> buffers in major modes derived from MODE..., or, if it's a minor mode,
> whether that minor mode is enabled in the current buffer.

> ** The 'interactive' syntax has been extended to allow listing applicable modes.
> Forms like '(interactive "p" dired-mode)' can be used to annotate the
> commands as being applicable for modes derived from 'dired-mode',
> or if the mode is a minor mode, that the current buffer has that
> minor mode activated.  Note that using this form will create byte code
> that is not compatible with byte code in previous Emacs versions.

RE: [External] : Re: Current mode command discovery

[Drew Adams]

> > Have we seen a complete, succinct, description
> > of the two "features" (which both apparently
> > filter)?
> >
> > Could someone please post that description,
> > apart from these long, convoluted threads?
> >
> I believe the NEWS file on the master branch has been kept up-to-date:
> 
> https://urldefense.com/v3/__https://git.savannah.gnu.org/cgit/emacs.git
> /tree/etc/NEWS__;!!GqivPVa7Brio!MbL7drkVlsbDK4CmZc61-V9hngoLnSJgmc-
> UKRC65sOOHceASdzWB6ma_FTFY8ad$

Thanks.

> > ** New command 'execute-extended-command-for-buffer'.
> > This new command, bound to 'M-S-x', works like
> > 'execute-extended-command', but limits the set of commands to the
> > commands that have been determined to be particularly useful with the
> > current mode.

We still have no description (let alone a spec) of
what "particularly useful" for a mode should mean.

It's admitted that this is a judgment call, but no
criteria for judgment have been given, AFAIK, except
for Stefan's NOT-useful-if-always-raises-error.  And
that was said by others not to be a real criterion.

So that new command seems particularly undefined...

However, the particularly useful objections raised
so far have been wrt the implementation: hard-coding
the association of command & mode(s) in source code.

> > ** New user option 'read-extended-command-predicate'.
> > This option controls how 'M-x' performs completion of commands when
> > you type TAB.  By default, any command that matches what you have
> > typed is considered a completion candidate, but you can customize
> > this option to exclude commands that are not applicable to the current
> > buffer's major and minor modes, and respect the command's completion
> > predicate (if any).

I see.  But which way does the predicate go?
Does it filter out or filter in?  I guess that
description doesn't help with that basic question,
and you have to use `C-h v' to find out.

How does this predicate relate to or interact with
the tampering with `interactive' (new, second arg)
in the source code?  Is the predicate an additional
test?  An overriding test?

> > ** New forms to declare how completion should happen has been added.

(Grammar problem in that sentence: plural subject,
singular verb.)

> > '(declare (completion PREDICATE))' can be used as a general predicate
> > to say whether the command should be present when completing with
> > 'M-x TAB'.  '(declare (modes MODE...))' can be used as a short-hand
> > way of saying that the command should be present when completing from
> > buffers in major modes derived from MODE..., or, if it's a minor
> > mode, whether that minor mode is enabled in the current buffer.

So the first one applies only when no input is typed
at the `M-x' prompt - just `TAB'?  No effect otherwise?

Or is that also true of the second one (using `modes')?

How does the `M-x TAB' filtering interact with filtering
by the new option (above)?  (Same question posed above.)

> > ** The 'interactive' syntax has been extended to allow listing
> > applicable modes.
> > Forms like '(interactive "p" dired-mode)' can be used to annotate the
> > commands as being applicable for modes derived from 'dired-mode',
> > or if the mode is a minor mode, that the current buffer has that
> > minor mode activated.  Note that using this form will create byte
> > code that is not compatible with byte code in previous Emacs versions.

This sounds like a repeat of what is said in the previous
entry (except for the last sentence).  Is that right?  If
so, why have both?
___

And again, why go through all that, and make users go
through all of it, instead of just putting a property
on a command symbol to indicate the same thing(s?)?

Re: Current mode command discovery

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Really?  I thought the intent was to filter _out_ those commands that
> are not relevant.  If the intent is to filter _in_, then won't this
> omit many important commands?

This is still the thread about the new command, and has nothing to do
with the `M-x' command.  :-)

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

Re: Current mode command discovery

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> This shows "M-x" prompt, whereas I expected either "M-X" or "M-S-x".

Oh, the prompt is from:

	       ;; This isn't strictly correct if `execute-extended-command'
	       ;; is bound to anything else (e.g. [menu]).
	       ;; It could use (key-description (this-single-command-keys)),
	       ;; but actually a prompt other than "M-x" would be confusing,
	       ;; because "M-x" is a well-known prompt to read a command
	       ;; and it serves as a shorthand for "Extended command: ".
	       "M-x ")

in `read-extended-command'.  Hm.  Anybody got an opinion on what the
best fix here would be?  The obvious fix is to do what the comment says,
which would also make this be more consistent if the user has rebound
the command.

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

Re: Current mode command discovery

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 20 Feb 2021 15:57:13 +0100
> 
> 	       ;; This isn't strictly correct if `execute-extended-command'
> 	       ;; is bound to anything else (e.g. [menu]).
> 	       ;; It could use (key-description (this-single-command-keys)),
> 	       ;; but actually a prompt other than "M-x" would be confusing,
> 	       ;; because "M-x" is a well-known prompt to read a command
> 	       ;; and it serves as a shorthand for "Extended command: ".
> 	       "M-x ")
> 
> in `read-extended-command'.  Hm.  Anybody got an opinion on what the
> best fix here would be?  The obvious fix is to do what the comment says,
> which would also make this be more consistent if the user has rebound
> the command.

Or you could kludge it by looking at the modifiers.

Re: Current mode command discovery

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> 	       ;; because "M-x" is a well-known prompt to read a command
>> 	       ;; and it serves as a shorthand for "Extended command: ".
>> 	       "M-x ")
>> 
>> in `read-extended-command'.  Hm.  Anybody got an opinion on what the
>> best fix here would be?  The obvious fix is to do what the comment says,
>> which would also make this be more consistent if the user has rebound
>> the command.
>
> Or you could kludge it by looking at the modifiers.

It's possible, but that's certainly adding one kludge on top of another.
Are there any drawbacks to just using (key-description
(this-single-command-keys)) here and normalising this command in this
regard?

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

Re: Current mode command discovery

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Sun, 21 Feb 2021 16:44:06 +0100
> 
> > Or you could kludge it by looking at the modifiers.
> 
> It's possible, but that's certainly adding one kludge on top of another.

No, it'd be the continuation of the same kludge.

> Are there any drawbacks to just using (key-description
> (this-single-command-keys)) here and normalising this command in this
> regard?

My advice is not to do that.  There be dragons, and how important is
that, anyway?

Re: Current mode command discovery

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> It's possible, but that's certainly adding one kludge on top of another.
>
> No, it'd be the continuation of the same kludge.

Potato, potato.

>> Are there any drawbacks to just using (key-description
>> (this-single-command-keys)) here and normalising this command in this
>> regard?
>
> My advice is not to do that.  There be dragons, and how important is
> that, anyway?

Do you see any dragons in particular, or are you just thinking in
general here?  The comment in the code doesn't point to any dragons, but
only that it'll confuse people to see anything other than `M-x' here.
(Which I don't find compelling.)

If you don't see any particular dragons here, I think we should just
give it a try and see whether this leads to any problems.  If they do,
it's simple to revert.

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

Re: Current mode command discovery

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Sun, 21 Feb 2021 18:46:48 +0100
> 
> > My advice is not to do that.  There be dragons, and how important is
> > that, anyway?
> 
> Do you see any dragons in particular, or are you just thinking in
> general here?

It's not me, it's my gray hair.

> If you don't see any particular dragons here, I think we should just
> give it a try and see whether this leads to any problems.  If they do,
> it's simple to revert.

Making changes, discovering they bring more trouble than they are
worth, debugging the problems, then reverting takes time and precious
energy.  The gains, OTOH, are minuscule, if they even exist.  I don't
know how you, but to me the decision looks a no-brainer.

Re: Current mode command discovery

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Making changes, discovering they bring more trouble than they are
> worth, debugging the problems, then reverting takes time and precious
> energy.  The gains, OTOH, are minuscule, if they even exist.  I don't
> know how you, but to me the decision looks a no-brainer.

It does indeed not look that way to me -- I've now pushed what I think
you were suggesting?  It looks a bit error-prone to me, so perhaps you
had something different in mind.

(For instance, if the user has bound the command to anything else
involving a shift command, then they'll (probably, depending on the
differences between last-command-event and this-single-command-keys) get
"M-X" now.)

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

Re: Current mode command discovery

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Mon, 22 Feb 2021 15:34:59 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Making changes, discovering they bring more trouble than they are
> > worth, debugging the problems, then reverting takes time and precious
> > energy.  The gains, OTOH, are minuscule, if they even exist.  I don't
> > know how you, but to me the decision looks a no-brainer.
> 
> It does indeed not look that way to me -- I've now pushed what I think
> you were suggesting?

No, that's exactly what I had in mind.

> (For instance, if the user has bound the command to anything else
> involving a shift command, then they'll (probably, depending on the
> differences between last-command-event and this-single-command-keys) get
> "M-X" now.)

Yes, but we had the same problem with M-x for eons.

RE: [External] : Re: Current mode command discovery

[Drew Adams]

> ;; This isn't strictly correct if `execute-extended-command'
> ;; is bound to anything else (e.g. [menu]).
> ;; It could use (key-description (this-single-command-keys)),
> ;; but actually a prompt other than "M-x" would be confusing,
> ;; because "M-x" is a well-known prompt to read a command
> ;; and it serves as a shorthand for "Extended command: ".
> 
> Anybody got an opinion on what the best fix here would be?
> The obvious fix is to do what the comment says, which would
> also make this be more consistent if the user has rebound
> the command.

Opinion?  Sure.  Do what Icicles does (or similar):
use a prompt that _prompts what to enter_, instead of
just echoing the key sequence that invoked the command.

Just "M-x " as prompt doesn't even _look_ like it's
prompting - there's not even a colon (:), let alone
some indication of what you're being prompted to type.
That "prompt" looks like just a keystroke echo.

In Icicles there are two different commands (which is
what you're also doing now - you intend one command
for `M-x' and one for `M-S-x'):

1. `icicle-execute-extended-command' - `M-x'
   Like vanilla Emacs (but a multi-command etc.).

2. `icicle-command-abbrev' - `M-ESC C-x' (`ESC ESC C-x')
   Read command name or its abbreviation; read command
   args; invoke command.

Their prompts are:

1. "Execute command: "
2. "Command or abbrev: "

So instead of using "M-x " as prompt, use something
like "Execute command: ".

Re: Current mode command discovery

[Stefan Monnier]

> `ignore' shows up here, because we've bound `h' to `ignore' as a way to
> disable that key binding.  That doesn't sound kinda non-ideal -- it
> should be unbound instead.

Then make `ignore` have a scoring function that always returns
a low value.


        Stefan

Re: Current mode command discovery

[Lars Ingebrigtsen]

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

>> `ignore' shows up here, because we've bound `h' to `ignore' as a way to
>> disable that key binding.  That doesn't sound kinda non-ideal -- it
>> should be unbound instead.
>
> Then make `ignore` have a scoring function that always returns
> a low value.

That would be

(defun ignore (...)
  (declare (completion ignore)))

Isn't that ironic?

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

Re: Current mode command discovery

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Now that we have mode markup, should there be a command like `M-x', but
>> instead lists only those commands that are specifically relevant to the
>> current buffer?
>>
>> This would only be commands that have been marked for the current major
>> mode and any active minor modes, I guess?
>>
>> If so, should that be bound to something, and if so, what?
>
> I've now added a first attempt at this to the trunk now.

Looks like a good first attempt!

With the short list presented by `M-S-x', it does seem more important
that the commands that show up are highly relevant.  In `list-bookmark',
I see some stuff in the completion list that I wonder about:

- `digit-argument'.  Should it be in `M-x', or is it more like
  `mwheel-scroll'?  Should it be in `M-S-x'?

- `negative-argument', I can see why one would keep it in `M-x', I
  guess, but in `M-S-x'?

- Finally, `forward-button' and `backward-button'.  But I can't find who
  binds it?  In any case, it doesn't seem relevant to this mode.
  I guess it should be the responsibility of the mode to unbind any such
  commands.

> Peculiarities that we might consider:
>
> `ignore' shows up here, because we've bound `h' to `ignore' as a way to
> disable that key binding.  That doesn't sound kinda non-ideal -- it
> should be unbound instead.

True.  But it would be good to find a general solution (third-party
developers will use it even if we fix eww).

One idea is to a special list of commands that `M-S-x' specifically
always ignores (and add `ignore' to it).

> The command name is really bad, though:
> `execute-extended-command-for-buffer'.  Suggestions for a better name
> are welcome.

Naming is hard... here are some ideas (none of them very good):

- execute-extended-command-here
- execute-extended-command-narrow
- execute-extended-command-mode
- execute-extended-command-local

(BTW, why is `execute-extended-command' not just `execute-command'?
I'm not suggesting that we change it, it just seems like a strange choice.)

Re: Current mode command discovery

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sat, 20 Feb 2021 09:37:57 -0600
> 
> (BTW, why is `execute-extended-command' not just `execute-command'?

This is explained in the tutorial.

Re: Current mode command discovery

[Stefan Monnier]

>> (BTW, why is `execute-extended-command' not just `execute-command'?
> This is explained in the tutorial.

I think that just tries to give a mnemonic way to remember the
`M-x` binding (and it seems contrived at that, since it could as well
be "eXecute a named command").


        Stefan "who nevertheless doesn't see the need to rename it"

Re: Current mode command discovery

[Dmitry Gutov]

On 20.02.2021 18:05, Eli Zaretskii wrote:
> This is explained in the tutorial.

"Named eXtended commands are commands...", that part?

Re: Current mode command discovery

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Kangas <stefankangas@gmail.com>
>> Date: Sat, 20 Feb 2021 09:37:57 -0600
>>
>> (BTW, why is `execute-extended-command' not just `execute-command'?
>
> This is explained in the tutorial.

Yes, it does gives some explanation:

    "Named eXtended commands are commands which are used even less
    frequently, or commands which are used only in certain modes."

(I still don't see why it's not just called `execute-command'.
It includes all commands, AFAICT.  Oh, well.)

Re: Current mode command discovery

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sat, 20 Feb 2021 10:23:58 -0600
> Cc: larsi@gnus.org, emacs-devel@gnu.org
> 
> > This is explained in the tutorial.
> 
> Yes, it does gives some explanation:
> 
>     "Named eXtended commands are commands which are used even less
>     frequently, or commands which are used only in certain modes."
> 
> (I still don't see why it's not just called `execute-command'.
> It includes all commands, AFAICT.  Oh, well.)

Because there are NON-extended commands, the ones invoked by simple
keys like C-f and M-f.

Re: Current mode command discovery

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> Because there are NON-extended commands, the ones invoked by simple
> keys like C-f and M-f.

Yes, I understand that.  But both `forward-char' and `forward-word' can
be invoked with `e-e-c', so there is no distinction in practice.

(To be clear, I agree with Stefan M that there is no need to rename it.)

Re: Current mode command discovery

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sat, 20 Feb 2021 11:25:54 -0600
> Cc: larsi@gnus.org, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Because there are NON-extended commands, the ones invoked by simple
> > keys like C-f and M-f.
> 
> Yes, I understand that.  But both `forward-char' and `forward-word' can
> be invoked with `e-e-c', so there is no distinction in practice.

You distinguish between "commands" and "keys"?  Emacs doesn't.  C-f is
a _command_, not (just) a key.

Re: Current mode command discovery

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > You distinguish between "commands" and "keys"?  Emacs doesn't.  C-f is
  > a _command_, not (just) a key.

Using our terminology carefully, C-f is not a command.  C-f is a key,
and it is bound to the command forward-char.

I'm often sloppy about this, and I suppose everyone is.  But when
these distinctions matter, let's follow the definitions.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Current mode command discovery

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: stefankangas@gmail.com, larsi@gnus.org, emacs-devel@gnu.org
> Date: Sun, 21 Feb 2021 01:18:11 -0500
> 
>   > You distinguish between "commands" and "keys"?  Emacs doesn't.  C-f is
>   > a _command_, not (just) a key.
> 
> Using our terminology carefully, C-f is not a command.  C-f is a key,
> and it is bound to the command forward-char.
> 
> I'm often sloppy about this, and I suppose everyone is.  But when
> these distinctions matter, let's follow the definitions.

I never perceived this as a sloppiness.  Since the first time I've
read the tutorial, the notion of C-f etc. being a kind of command was
very clear to me.  The tutorial has this all over the place.  Here's a
typical example, of which there are many:

  The following commands are useful for viewing screenfuls:

	  C-v	Move forward one screenful
	  M-v	Move backward one screenful
	  C-l	Clear screen and redisplay all the text,

It even says right at the beginning:

  Emacs commands generally involve the CONTROL key (often labeled CTRL)
  or the META key (usually labeled ALT).  Rather than writing that

Later it says:

  * EXTENDING THE COMMAND SET
  ---------------------------

  There are many, many more Emacs commands than could possibly be put
  on all the control and meta characters.  Emacs gets around this with
  the X (eXtend) command.  This comes in two flavors:

	  C-x	Character eXtend.  Followed by one character.
	  M-x	Named command eXtend.  Followed by a long name.

Take away the notion that C-f is a command, not only a key, and the
above explanation of "command extension" has no basis, except perhaps
as a historical curiosity.

So I think we should maintain that C-f etc. is a command as well as a
key sequence.

RE: [External] : Re: Current mode command discovery

[Drew Adams]

> Since the first time I've read the tutorial, the
> notion of C-f etc. being a kind of command was
> very clear to me.  The tutorial has this all over
> the place.  Here's a typical example, of which
> there are many:
> 
>   The following commands are useful for viewing screenfuls:
> 	  C-v	Move forward one screenful
> 	  M-v	Move backward one screenful
> 	  C-l	Clear screen and redisplay all the text,

Yes, that's all over the tutorial.  It's not all
over Emacs, however - and rightfully so.

A tutorial need not present all distinctions in an
exact way.  The point there is to give users the
idea that when they use the key `C-v' they are, in
effect, invoking a command to scroll the text.

I personally think that even for the tutorial it
would help users to introduce the concept of key
binding, and tell them that each key you press is,
in general, bound to a command, which is a function
that gets invoked when you press the key.

I mention that pretty early on, when I present
Emacs to newbies.  I think it's an important
notion to grasp.  That, together with the fact
that you (anyone) can easily _change_ which
command is invoked by a given key, pretty much
gets across the basic idea and mechanics of Emacs.

Newbies are of course often used to the idea that
an app lets them change some "hot key" bindings -
set some "keyboard shortcuts".

But the fact that in Emacs _every_ key - every
action - is configurable with key bindings, is
something newbies are typically not used to.

It's not _essential_ that this be introduced in
the tutorial, but I think it would help.  It's
key to understanding Emacs that even when you
type a key such as `a', and the result might be
to insert the letter `a', you are invoking a
char-insertion command that is bound to the key.
___

Whether the tutorial or some other help support
glosses over the difference between a key and a
command it's bound to is something different
from whether in fact there _is_ a difference
between a key and a command.

IOW, we might, for pedagogical reasons, decide to
gloss over this distinction in some presentation.
That doesn't mean there's no distinction.

RE: [External] : Re: Current mode command discovery

[Drew Adams]

>> You distinguish between "commands" and "keys"?
>> Emacs doesn't.  C-f is a _command_, not (just) a key.
> 
> Using our terminology carefully, C-f is not a command.
> C-f is a key, and it is bound to the command forward-char.
> 
> I'm often sloppy about this, and I suppose everyone is.
> But when these distinctions matter, let's follow the
> definitions.

Exactly what I would have said.

Commands can be bound to keys (or vice versa).
We speak of key bindings.

And we use this terminology _"when these
distinctions matter"_.  Good point.

That's much/most of the time.  But in some cases
(e.g. the Emacs tutorial) we apparently decided
at some point that these distinctions didn't
matter for its presentation.  That doesn't mean
that there's no difference between a key and a
command.

Re: Current mode command discovery

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > You distinguish between "commands" and "keys"?  Emacs doesn't.  C-f is
  > a _command_, not (just) a key.

Using our terminology carefully, C-f is not a command.  C-f is a key,
and it is bound to the command forward-char.

I'm often sloppy about this, and I suppose everyone is.  But when
these distinctions matter, let's follow the definitions.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Current mode command discovery

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> With the short list presented by `M-S-x', it does seem more important
> that the commands that show up are highly relevant.  In `list-bookmark',
> I see some stuff in the completion list that I wonder about:
>
> - `digit-argument'.  Should it be in `M-x', or is it more like
>   `mwheel-scroll'?  Should it be in `M-S-x'?
>
> - `negative-argument', I can see why one would keep it in `M-x', I
>   guess, but in `M-S-x'?

Yes, these don't seem useful to list, and they'll appear in all the
modes...  however, perhaps they should have a `ignore' completion
predicate.  That is,

`M-x digit-argument'

never seems to actually do anything?  Are there cases where doing that
would do anything useful?

> - Finally, `forward-button' and `backward-button'.  But I can't find who
>   binds it?  In any case, it doesn't seem relevant to this mode.
>   I guess it should be the responsibility of the mode to unbind any such
>   commands.

It's from this:

(defvar tabulated-list-mode-map
  (let ((map (make-sparse-keymap)))
    (set-keymap-parent map (make-composed-keymap
                            button-buffer-map
                            special-mode-map))

I don't know the logic behind binding the button commands in all
tabulated list modes -- do tabulated lists usually have buttons in them?
Sounds pretty odd...

>> `ignore' shows up here, because we've bound `h' to `ignore' as a way to
>> disable that key binding.  That doesn't sound kinda non-ideal -- it
>> should be unbound instead.
>
> True.  But it would be good to find a general solution (third-party
> developers will use it even if we fix eww).

Actually, I had bound `h' to `ignore' here locally, because I was always
hitting `h' in eww buffers.  :-) 

> One idea is to a special list of commands that `M-S-x' specifically
> always ignores (and add `ignore' to it).

Since it's never useful to `M-x ignore', adding completion predicate to
it would probably be fine.

> Naming is hard... here are some ideas (none of them very good):
>
> - execute-extended-command-here
> - execute-extended-command-narrow
> - execute-extended-command-mode
> - execute-extended-command-local

Hm...  those doesn't seem all that much more logical.

> (BTW, why is `execute-extended-command' not just `execute-command'?
> I'm not suggesting that we change it, it just seems like a strange choice.)

I don't know, but perhaps we don't have to keep the
"execute-extended-command" bit in this new command?  So we could go for
a different name like...  `execute-relevant-command'...

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

Re: Current mode command discovery

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sun, 21 Feb 2021 13:55:39 +0100
> Cc: emacs-devel@gnu.org
> 
> > - `digit-argument'.  Should it be in `M-x', or is it more like
> >   `mwheel-scroll'?  Should it be in `M-S-x'?
> >
> > - `negative-argument', I can see why one would keep it in `M-x', I
> >   guess, but in `M-S-x'?
> 
> Yes, these don't seem useful to list, and they'll appear in all the
> modes...  however, perhaps they should have a `ignore' completion
> predicate.  That is,
> 
> `M-x digit-argument'
> 
> never seems to actually do anything?  Are there cases where doing that
> would do anything useful?

Careful: the completion predicate is not just for M-x, it is also for
"C-h x" and other commands that complete on functions and commands.

Re: Current mode command discovery

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> never seems to actually do anything?  Are there cases where doing that
>> would do anything useful?
>
> Careful: the completion predicate is not just for M-x, it is also for
> "C-h x" and other commands that complete on functions and commands.

Hm...  that's certainly a wrinkle here.  On the other hand,
`C-h f digit-argument' would work as always.

The four commands under discussion here (see the bug report) all have in
common that nobody would actually `M-x' them, because they do nothing if
you do that.  (I think?  I'm not 100% sure about `digit-argument'.)  So
they're commands because they're bound to keys only.

So I'm leaning towards being fine with `C-h x ignorTAB' not expanding to
`ignore'.  Probably.

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

Re: Current mode command discovery

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 21 Feb 2021 16:47:45 +0100
> 
> > Careful: the completion predicate is not just for M-x, it is also for
> > "C-h x" and other commands that complete on functions and commands.
> 
> Hm...  that's certainly a wrinkle here.  On the other hand,
> `C-h f digit-argument' would work as always.

Is "C-h x" the only command to use this, in addition to M-x?

> The four commands under discussion here (see the bug report) all have in
> common that nobody would actually `M-x' them, because they do nothing if
> you do that.  (I think?  I'm not 100% sure about `digit-argument'.)  So
> they're commands because they're bound to keys only.
> 
> So I'm leaning towards being fine with `C-h x ignorTAB' not expanding to
> `ignore'.  Probably.

"C-h x" is a command we introduced for newbies, and then we proceed
confusing them with commands that cannot be shown with "C-h x"?  is
that reasonable and consistent?

Re: Current mode command discovery

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Hm...  that's certainly a wrinkle here.  On the other hand,
>> `C-h f digit-argument' would work as always.
>
> Is "C-h x" the only command to use this, in addition to M-x?

I don't know.

> "C-h x" is a command we introduced for newbies, and then we proceed
> confusing them with commands that cannot be shown with "C-h x"?  is
> that reasonable and consistent?

Filtering away `undefined' and `ignore' from completions for newbies
sounds like a good idea to me: They aren't commands that can be used in
`M-x'.

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

Re: Current mode command discovery

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 21 Feb 2021 18:44:21 +0100
> 
> > "C-h x" is a command we introduced for newbies, and then we proceed
> > confusing them with commands that cannot be shown with "C-h x"?  is
> > that reasonable and consistent?
> 
> Filtering away `undefined' and `ignore' from completions for newbies
> sounds like a good idea to me: They aren't commands that can be used in
> `M-x'.

I think filtering out commands such as 'undefined' and 'ignore', that
are really just internal implementation details, is okay.  But I
wasn't talking about those, I was talking about digit-argument, which
are full-fledged commands.

We can invent some database for augmenting the results of mechanically
constructing the list of completion candidates by some criteria such
as key bindings etc.  This database could, for example, tell us to
remove 'undefined' and 'ignore' from the list.  Or we may consider
these problems as an indication that perhaps the criteria used for
this are not smart enough to produce useful lists without clutter, and
we should rethink.

Re: Current mode command discovery

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> > "C-h x" is a command we introduced for newbies, and then we proceed
>> > confusing them with commands that cannot be shown with "C-h x"?  is
>> > that reasonable and consistent?
>> 
>> Filtering away `undefined' and `ignore' from completions for newbies
>> sounds like a good idea to me: They aren't commands that can be used in
>> `M-x'.
>
> I think filtering out commands such as 'undefined' and 'ignore', that
> are really just internal implementation details, is okay.  But I
> wasn't talking about those, I was talking about digit-argument, which
> are full-fledged commands.

Yes, I'm really unsure about `digit-argument' (and
`negative-argument').  On the one hand, you can't `M-x' them in any
meaningful way?  (Or can you?  I'm not even sure about that.)  On the
other hand, they are commands that people will see popping up in many
contexts, so keeping them in `M-x' completion might make sense from that
point of view?

I'm kinda leaning towards the latter.  Anybody else have an opinion here?

> We can invent some database for augmenting the results of mechanically
> constructing the list of completion candidates by some criteria such
> as key bindings etc.  This database could, for example, tell us to
> remove 'undefined' and 'ignore' from the list.

The database here is constructed here by '(declare (completion ...))'.

> Or we may consider these problems as an indication that perhaps the
> criteria used for this are not smart enough to produce useful lists
> without clutter, and we should rethink.

I don't think we've come up against anything yet that seems to indicate
that marking commands this way is problematic -- we just have to hash
out what our criteria is.

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

Re: Current mode command discovery

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 21 Feb 2021 19:21:23 +0100
> 
> Yes, I'm really unsure about `digit-argument' (and
> `negative-argument').  On the one hand, you can't `M-x' them in any
> meaningful way?  (Or can you?  I'm not even sure about that.)  On the
> other hand, they are commands that people will see popping up in many
> contexts, so keeping them in `M-x' completion might make sense from that
> point of view?

Invoking them via M-x may not make a lot of sense, but asking for help
on them definitely does.  So I think we need to have a way of removing
them from some completions, but not from others.

Re: Current mode command discovery

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Invoking them via M-x may not make a lot of sense, but asking for help
> on them definitely does.  So I think we need to have a way of removing
> them from some completions, but not from others.

That makes sense.  Hm...

So far, the issue seems to be about only two commands, so perhaps it
makes sense to just accept that "filtering for commands that might make
sense to M-S-x" (or conversely, "filtering out commands that do not make
sense to M-x") won't be a 100% solution.

Or we could add a special mechanism for just `digit-argument' and
`negative-argument', but that does seem awfully hacky.

Perhaps we should avoid making a decision here and see whether other,
similar problems appear -- we won't really know until we've gain more
experience with these mechanisms.

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

Re: Current mode command discovery

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sun, 21 Feb 2021 19:37:57 +0100
> Cc: stefankangas@gmail.com, emacs-devel@gnu.org
> 
> Or we could add a special mechanism for just `digit-argument' and
> `negative-argument', but that does seem awfully hacky.
> 
> Perhaps we should avoid making a decision here and see whether other,
> similar problems appear -- we won't really know until we've gain more
> experience with these mechanisms.

Yes, we could wait until more evidence comes in.