command mode-specificity [was: scratch/command 064f146 1/2: Change...]

command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Drew Adams]

> I believe many (most?) commands will remain
> unmarked, because they make sense in any mode.

That was my guess also.

I couldn't get a response when I asked for
reasons why it was expected that 97% of
commands are mode-specific.  (Stefan even
characterized asking for that to be only
a joke.)

Maybe you and I are missing something, here?
I'd really like to know what's behind the
"stat" that 97% of commands are mode-specific.

If that figure is accurate, or even anything
close to it, that might make me change my
opinion on a few things, and even make me
change the default behavior of some code I
write.

Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Stefan Monnier]

> I couldn't get a response when I asked for
> reasons why it was expected that 97% of
> commands are mode-specific.  (Stefan even
> characterized asking for that to be only
> a joke.)

Drew?  Hello?  I never said your question was a joke.
I said it was cute, because it showed you didn't catch that the 97%
figure was a joke.


        Stefan

RE: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Drew Adams]

> > I couldn't get a response when I asked for
> > reasons why it was expected that 97% of
> > commands are mode-specific.  (Stefan even
> > characterized asking for that to be only
> > a joke.)
> 
> Drew?  Hello?  I never said your question was a joke.
> I said it was cute, because it showed you didn't
> catch that the 97% figure was a joke.

Sorry, Stefan.  I misunderstood.  Your replies
were short and a bit too cryptic for me.  Mille
excuses.

When I said that my question wasn't a joke, and
you replied "it was (and still is)", I thought
you were speaking about my question.

Of course I guessed that the "my stats dept"
part of Lars's post was cute, a joke.  But I
didn't guess that his 97% was also a joke.

Assuming you're right (Lars hasn't spoken up),
what's the real answer?  Do you have the same
feeling as Eli and I, that most commands usable
in most contexts are not mode-specific?
___

If that's really the case, or if most of you/us
think it is, then why have we gone down this
road so precipitously?  I don't understand that.

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Lars Ingebrigtsen]

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

> Of course I guessed that the "my stats dept"
> part of Lars's post was cute, a joke.  But I
> didn't guess that his 97% was also a joke.

Yes, it was.  But now I've done some mark-ups, so I can actually have my
stats dept.  do some stats...

In gnus/*.el, there's 1018 interactive commands.  Of those, I've tagged
660 interactive commands as being mode-specific.

In eww, there 44 interactive commands, 34 are marked as being
mode-specific.  So it's about 50-75%.

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

RE: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Drew Adams]

> > Of course I guessed that the "my stats dept"
> > part of Lars's post was cute, a joke.  But I
> > didn't guess that his 97% was also a joke.
> 
> Yes, it was.  But now I've done some mark-ups, so I can actually have
> my stats dept. do some stats...
> 
> In gnus/*.el, there's 1018 interactive commands.  Of those,
> I've tagged 660 interactive commands as being mode-specific.
> 
> In eww, there 44 interactive commands, 34 are marked as being
> mode-specific.  So it's about 50-75%.

Only for two libraries (gnus and eww).  That
doesn't tell us much - a sample of 2.

I still have my hunch - but will gladly be proven
wrong.

I'll gladly be proven wrong, and so know the truth.
But I won't be glad to _be_ wrong about this.  It
doesn't seem right that most commands would - or
should - be mode-specific.

I'd also be interested in knowing what differences
there are, if any, between major and minor modes,
in this regard.
___

FWIW:

I just counted, for Bookmark+ commands: 24.6% of the
total are specific to the bookmark-list buffer, and
so to its mode.  An additional 2 bookmark commands
(out of the 665 total) are also mode-specific, for
Info mode and grep mode, respectively.  All the rest
(>75%) are not specific to any mode - you can use
them in any mode, anywhere.

I won't bother to try counting my other libraries.
My code might not be typical, of course.  But I
still am curious about the general case.  Can you
provide more than a sample of just 2 libraries?

And if you can, do you think that 3rd-party code is
likely, or unlikely, to follow the same pattern (and
why)?

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Lars Ingebrigtsen]

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

> I won't bother to try counting my other libraries.
> My code might not be typical, of course.  But I
> still am curious about the general case.  Can you
> provide more than a sample of just 2 libraries?

5x5.el: 21 commands, 6 non-mode-specific ones.

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

RE: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Drew Adams]

> > Can you provide more than a sample of just 2 libraries?
> 
> 5x5.el: 21 commands, 6 non-mode-specific ones.

I hear "3" libraries.  Do we have a bid for "4"?  More?

Anecdotal cherries are interesting, but...

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Lars Ingebrigtsen]

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

>> > Can you provide more than a sample of just 2 libraries?
>> 
>> 5x5.el: 21 commands, 6 non-mode-specific ones.
>
> I hear "3" libraries.  Do we have a bid for "4"?  More?
>
> Anecdotal cherries are interesting, but...

Go ahead and pick your own cherries.

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

RE: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Drew Adams]

> >> > Can you provide more than a sample of just 2 libraries?
> >>
> >> 5x5.el: 21 commands, 6 non-mode-specific ones.
> >
> > I hear "3" libraries.  Do we have a bid for "4"?  More?
> >
> > Anecdotal cherries are interesting, but...
> 
> Go ahead and pick your own cherries.

I'm not the one claiming that this new (proposed?
already added?) feature is needed, and that most
commands are mode-specific.  My guess is that it's
not needed and most commands are not mode-specific.

You're the one proposing a change.  What's the
evidence for the need for it?

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Óscar Fuentes]

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

>> >> > Can you provide more than a sample of just 2 libraries?
>> >>
>> >> 5x5.el: 21 commands, 6 non-mode-specific ones.
>> >
>> > I hear "3" libraries.  Do we have a bid for "4"?  More?
>> >
>> > Anecdotal cherries are interesting, but...
>> 
>> Go ahead and pick your own cherries.
>
> I'm not the one claiming that this new (proposed?
> already added?) feature is needed, and that most
> commands are mode-specific.  My guess is that it's
> not needed and most commands are not mode-specific.
>
> You're the one proposing a change.  What's the
> evidence for the need for it?

How do you expect to *prove* to you that I will benefit from the change?

Is there some sort of accepted dialectics for that purpose?

I explained many times, now and on the previous discussion about this
feature long time ago, why it would be so helpful to me that I will be
happy to devote many hours to tag as many commands as possible.

Then you handwave away common-sense arguments as irrelevant or
conflicting with some sort of imagined scenario, or because it goes
against some personal habits of abusing a feature (M-x for remembering
commands instead of C-h a? Seriously? And why that is an impediment for
improving M-x to better function for its stated purpose?)

You don't see a benefit on this feature *for you*. Fair enough. You are
uneasy with the changes on `interactive'. I wholeheartedly sympathize
with you here, for the reasons you expressed and some more. But please
don't come with "what's the evidence for the need of it?", because you
are sending a clear signal about being utterly uninterested on other's
opinions.

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 17 Feb 2021 01:35:29 +0100
> 
> I explained many times, now and on the previous discussion about this
> feature long time ago, why it would be so helpful to me that I will be
> happy to devote many hours to tag as many commands as possible.

No one is arguing that having this filtering as an optional behavior
can be useful.  The argument, at least from my side, was that I don't
think it can, in its current too radical shape, be the default,
because it is both backward-incompatible and provides no "fire
escape".

If the implementation were to change, such that it didn't actually
remove commands from the list of completion candidate, then perhaps we
could make this the default (but even then I'm not sure).

> Then you handwave away common-sense arguments as irrelevant or
> conflicting with some sort of imagined scenario, or because it goes
> against some personal habits of abusing a feature (M-x for remembering
> commands instead of C-h a? Seriously?

Please cool down.  One person's must-have feature is another person's
"imagined scenario" or "personal habits of abusing".  User options
exist in Emacs because we try not to be too judgmental, and let each
one have their preferences.

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Dmitry Gutov]

On 17.02.2021 17:47, Eli Zaretskii wrote:
> If the implementation were to change, such that it didn't actually
> remove commands from the list of completion candidate, then perhaps we
> could make this the default (but even then I'm not sure).

What if we remove them from the list of completions, but still allow 
them if the user typed one out explicitly and pressed RET?

Like this:

diff --git a/lisp/simple.el b/lisp/simple.el
index 215f4399f4..b2ae560c45 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -1967,7 +1967,9 @@ read-extended-command
  	     '(metadata
  	       (affixation-function . read-extended-command--affixation)
  	       (category . command))
-           (complete-with-action action obarray string pred)))
+           (complete-with-action action obarray string
+                                 (unless (eq action 'lambda)
+                                   pred))))
         (lambda (sym)
           (and (commandp sym)
                (funcall read-extended-command-predicate sym buffer)))

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Stefan Monnier]

> What if we remove them from the list of completions, but still allow them if
> the user typed one out explicitly and pressed RET?

Yes, clearly, we should allow executing those commands via M-x, we only
want to avoid having those drown the other completions.

A second step would be to still list them (maybe with an annotation like
"?" or "⁈") if the list of completions would otherwise be empty.


        Stefan

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 17 Feb 2021 17:59:26 +0200
> 
> On 17.02.2021 17:47, Eli Zaretskii wrote:
> > If the implementation were to change, such that it didn't actually
> > remove commands from the list of completion candidate, then perhaps we
> > could make this the default (but even then I'm not sure).
> 
> What if we remove them from the list of completions, but still allow 
> them if the user typed one out explicitly and pressed RET?

It's an improvement, IMO.  But I'm not sure people who want the
feature as it's implemented now will agree to this "relaxation",
because it allows one to invoke "irrelevant" commands.  I will let
others speak for themselves, though.

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Dmitry Gutov]

On 17.02.2021 18:17, Eli Zaretskii wrote:
> It's an improvement, IMO.  But I'm not sure people who want the
> feature as it's implemented now will agree to this "relaxation",
> because it allows one to invoke "irrelevant" commands.  I will let
> others speak for themselves, though.

FWIW, I like the idea of this feature, just not some details of its 
implementation. And the modification in behavior which the patch I sent 
added was also requested previously by others.

So perhaps you want to reconsider the change of default at this time?

It's reasonable to default the new feature to off in the Emacs 28 
release, but keeping it on for a few upcoming months at least should 
help us iron out the kinks and maybe even resolve our differences, 
rather than swiping them under the carpet.

That would be in line with previous discussions about enabling 
experimental features on master for a while to collect feedback.

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Eli Zaretskii]

> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 17 Feb 2021 21:52:49 +0200
> 
> So perhaps you want to reconsider the change of default at this time?

I already did.

> It's reasonable to default the new feature to off in the Emacs 28 
> release, but keeping it on for a few upcoming months at least should 
> help us iron out the kinks and maybe even resolve our differences, 
> rather than swiping them under the carpet.
> 
> That would be in line with previous discussions about enabling 
> experimental features on master for a while to collect feedback.

The feature is there, available for testing with a simple
customization.  I didn't delete the feature.  It is normal for us to
introduce new features as opt-in; the reverse is unusual, and in this
case I don't see why we would make such an unusual step.  The feature
is quite minor.

Making it on by default is still on the table, but IMO it's premature,
if not plain wrong, to make such decisions before we see the feature
in its more-or-less final form.  The discussion doesn't seem to be
anywhere near winding up, and neither are new and useful ideas about
it.

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Dmitry Gutov]

On 17.02.2021 22:21, Eli Zaretskii wrote:

> The feature is there, available for testing with a simple
> customization.  I didn't delete the feature.  It is normal for us to
> introduce new features as opt-in; the reverse is unusual, and in this
> case I don't see why we would make such an unusual step.  The feature
> is quite minor.

It's somewhat unusual in that it depends on network effects (on package 
maintainers to actually tag their commands) to work well.

The chance of keeping it the default can be an encouragement to work out 
the kinks and reach some compromises, too.

> Making it on by default is still on the table, but IMO it's premature,
> if not plain wrong, to make such decisions before we see the feature
> in its more-or-less final form.  The discussion doesn't seem to be
> anywhere near winding up, and neither are new and useful ideas about
> it.

I hope you're right, and this doesn't result in one side losing interest 
(because the feature is off and doesn't bother their work anymore) and 
the other side not wanting to change much anymore because of "it's 
optional, we like how it works already, and if you don't, you don't have 
to use it" line of thinking.

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Date: Wed, 17 Feb 2021 01:35:29 +0100
>> 
>> I explained many times, now and on the previous discussion about this
>> feature long time ago, why it would be so helpful to me that I will be
>> happy to devote many hours to tag as many commands as possible.
>
> No one is arguing that having this filtering as an optional behavior
> can be useful.  The argument, at least from my side, was that I don't
> think it can, in its current too radical shape, be the default,
> because it is both backward-incompatible and provides no "fire
> escape".
>
> If the implementation were to change, such that it didn't actually
> remove commands from the list of completion candidate, then perhaps we
> could make this the default (but even then I'm not sure).

As I said several times, that would nullify the feature to a great
extent. The user would still see a long-ish list of candidates, and then
have to notice where the "applicable" commands end and the rest begin,
hence some type of cue would be needed, and then each completion
framework would need to implement the cue.

>> Then you handwave away common-sense arguments as irrelevant or
>> conflicting with some sort of imagined scenario, or because it goes
>> against some personal habits of abusing a feature (M-x for remembering
>> commands instead of C-h a? Seriously?
>
> Please cool down.  One person's must-have feature is another person's
> "imagined scenario" or "personal habits of abusing".  User options
> exist in Emacs because we try not to be too judgmental, and let each
> one have their preferences.

My message came across as somewhat harsher than intended, but please
realize that when one gives detailed explanations about something, again
and again, and is sistematically confronted with responses such as "you
need to demonstrate (an unspecified goal based on some vague criteria)",
"I use M-x for something else and wont adapt my workflow", "this is
madness", etc, it is quite frustrating. And then when you try to
understand the details of the opposition, the best answer you can get is
something akin to "because reasons."

For all I care, the feature can be released as disabled by default, as I
don't want to impose nothing on anybody.

RE: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Drew Adams]

> No one is arguing that having this filtering as an optional behavior
> can be useful.  The argument, at least from my side, was that I don't
> think it can, in its current too radical shape, be the default,
> because it is both backward-incompatible and provides no "fire
> escape".

+1.  Exactly.  Useful new behavior should
generally be optional and opt-in.

> If the implementation were to change, such that it didn't actually
> remove commands from the list of completion candidate, then perhaps we
> could make this the default (but even then I'm not sure).

There's no hurry to decide on a new default
behavior, especially for a brand-new feature.

Provide the behavior (in vanilla Emacs or a
3rd-party library), and see how much traction
it gains among users.  Emacs can always switch
to it as the new default behavior later, if
that seems to make sense.

RE: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Drew Adams]

> > I'm not the one claiming that this new (proposed?
> > already added?) feature is needed, and that most
> > commands are mode-specific.  My guess is that it's
> > not needed and most commands are not mode-specific.
> >
> > You're the one proposing a change.  What's the
> > evidence for the need for it?
> 
> How do you expect to *prove* to you that I will
> benefit from the change?

How does one usually convince Emacs Dev to make
some change?  Reasoned argument, examples, use
cases...?  In the case of a claim that most
commands are mode-specific, maybe actually show
that somehow?

It's standard Emacs Dev practice, I believe, for
those proposing a change give supporting reasons.
Change requires more support than status quo.

That's my impression, at least.  It's also my
preference.

If changes were typically made willy nilly, with
no discussion or reasons presented, and if the
burden of convincing were on those NOT promoting
some change, we'd have more churn and more
dissatisfaction all 'round.  Don't you agree?

> Is there some sort of accepted dialectics for that purpose?

Respectful discourse?

> I explained many times, now and on the previous
> discussion about this feature long time ago, why
> it would be so helpful to me that I will be
> happy to devote many hours to tag as many
> commands as possible.

I don't have any problem with the _possibility_
for someone to tag something any way they want,
or with someone providing some code that _lets_
users take advantage of such tags.

The problem isn't with providing new possibilities
for users.  The problem is with changing what
already exists - the default behavior.

I've argued in _favor_ of users being able to
more easily filter completion candidates.
That's not a problem.

Add something to Emacs as an option, then wait
and see how much it's taken up by users.  If
it turns out that zillions think it should take
more prominence, or even become new default
behavior, then that'll get done.  That's not
the same as just flipping default behavior for
one's favorite shiny new thing.

One good way such new-feature change can take
place is for someone to code it up in a
3rd-party library, and for users in the wider
world to start using it.  Later, after we've
seen what that experiment's given, think about
maybe doing the same or something similar in
vanilla Emacs.

> Then you handwave away common-sense arguments
> as irrelevant or conflicting with some sort
> of imagined scenario,

I have no idea what you're talking about there.
Specifics, please.

> or because it goes against some personal habits
> of abusing a feature

One person's "abuse" of some existing Emacs
behavior/feature is another person's handy use
case.

To be quite clear, I doubt that any of what's
being discussed about this new behavior will
affect me much, personally.  For example, I use
Icicles, which has its own replacement for `M-x'.

(Of course, if code changes are incompatible
then I will perhaps have to modify some of my
code accordingly.  But as a _user_ my guess is
that I won't be affected much, if at all.)

My concern is for Emacs, not just for my own
use of it.

The burden of convincing is on those who intend
to _change_ the existing behavior.  This is
normal.

Someone might think their change is wonderful,
but it might remove or negatively impact Emacs
uses by others.  Is that not something to take
into consideration?

> (M-x for remembering commands instead of C-h a?

I, for one, said nothing about M-x for
remembering commands.  I have no idea what
you're on about, here.

> Seriously? And why that is an impediment for
> improving M-x to better function for its stated
> purpose?)

Again, no idea what you're taking about.  The
burden of convincing to make some change (e.g.
to "improve M-x to better function" is on the
promoter of the change.  That general rule has
nothing to do with me.

> You don't see a benefit on this feature *for you*.
> Fair enough. You are uneasy with the changes on
> `interactive'.

Again, what I've written about this reflects
what I think (so far) _for Emacs_.  It's not
really about my personal use of Emacs.  I live
in my own little Icicles world, somewhat
insulated from your `M-x' etc.  But I care about
Emacs - beyond my own habits and use of it.

Pretty much everything has benefits and
drawbacks. See above.  Propose something that's
optional and opt-in, and I expect there will be
little contest.

> I wholeheartedly sympathize with you here, for
> the reasons you expressed and some more. But
> please don't come with "what's the evidence for
> the need of it?", 

Why?  That's standard procedure, no?  Propose a
change and convince people that it would be a
good thing - better done than not done.

> because you are sending a clear signal about
> being utterly uninterested on other's opinions.

No, I don't think I am.

But I do think that an attitude of not needing
to give reasons in favor of some desired change,
in particular an incompatible or default change,
kinda qualifies as showing disinterest and
disrespect for longstanding Emacs behavior, and
thus for its users.

I don't even need to express my opinion about
a proposed change.  It's up to those promoting
it to convince others that the change is needed
or a great idea.  I'm not convinced, in this
case, but I don't decide anything here.

It's not me you need to convince.  That said,
I will say that I - for one - am not convinced.

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Yuan Fu]

> On Feb 16, 2021, at 5:15 PM, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> 
> Drew Adams <drew.adams@oracle.com> writes:
> 
>> I won't bother to try counting my other libraries.
>> My code might not be typical, of course.  But I
>> still am curious about the general case.  Can you
>> provide more than a sample of just 2 libraries?
> 
> 5x5.el: 21 commands, 6 non-mode-specific ones.
> 
> -- 
> (domestic pets only, the antidote for overdose, milk.)
>   bloggy blog: http://lars.ingebrigtsen.no
> 

My understanding is that, because gnus, eww and 5x5 are self-contained “applications”, it makes sense that most of their commands only make sense in the corresponding major mode. Likewise for org-mode, python-mode, etc. General text editing commands and other utility commands would makes sense regardless of the major mode, for example, bookmark, help, debug-on-entry, load-theme, fill-paragraph.

So it all comes down to how many commands are from standalone applications and major modes and how many from generic utility packages.

Yuan

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  Eli Zaretskii
>  <eliz@gnu.org>,  "emacs-devel@gnu.org" <emacs-devel@gnu.org>,
>   "stefankangas@gmail.com" <stefankangas@gmail.com>,  "dgutov@yandex.ru"
>  <dgutov@yandex.ru>
> Date: Tue, 16 Feb 2021 21:53:05 +0100
> 
> In gnus/*.el, there's 1018 interactive commands.  Of those, I've tagged
> 660 interactive commands as being mode-specific.
> 
> In eww, there 44 interactive commands, 34 are marked as being
> mode-specific.  So it's about 50-75%.

That assumes these files are representative, but that is not at all
sure.

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Óscar Fuentes]

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

> Assuming you're right (Lars hasn't spoken up),
> what's the real answer?  Do you have the same
> feeling as Eli and I, that most commands usable
> in most contexts are not mode-specific?

I would say that *all* commands *usable in most contexts* are not
mode-specific.

Almost by definition.

Lars Ingebrigtsen <larsi@gnus.org> writes:

> In gnus/*.el, there's 1018 interactive commands.  Of those, I've tagged
> 660 interactive commands as being mode-specific.

That number looks surprisingly low to me. Maybe it's because some
limitation on the tagging system or because Gnus is a bit of a
"transversal" package, like Org and Calc.

OTOH, I expect that almost all commands defined in packages such as
C-Mode (and almost every other programming mode) are mode-specific.

RE: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Drew Adams]

> > Assuming you're right (Lars hasn't spoken up),
> > what's the real answer?  Do you have the same
> > feeling as Eli and I, that most commands usable
> > in most contexts are not mode-specific?
> 
> I would say that *all* commands *usable in most
> contexts* are not mode-specific.
> 
> Almost by definition.

Fair enough. ;-)  It was a clumsy way to summarize.

How about just "most commands are not mode-specific"?

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Óscar Fuentes]

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

>> > Assuming you're right (Lars hasn't spoken up),
>> > what's the real answer?  Do you have the same
>> > feeling as Eli and I, that most commands usable
>> > in most contexts are not mode-specific?
>> 
>> I would say that *all* commands *usable in most
>> contexts* are not mode-specific.
>> 
>> Almost by definition.
>
> Fair enough. ;-)  It was a clumsy way to summarize.
>
> How about just "most commands are not mode-specific"?

That's not my experience.

Whenever I use M-x (and I do it a lot, since on my setup it is often
more ergonomic and faster than remembering and pressing shortcuts) I see
on the list of completions lots of commands that have nothing to do with
what I'm doing. This forces me to write more characters on the prompt to
further refine the candidates and remember to not use certain inputs
which bring in lots of irrelevant candidates just because the naming
scheme they follow.

Even worse: for any given input to M-x, the list of completions greatly
vary depending on what I previously did on the Emacs session (as
features are loaded and inject their commands.)

RE: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Drew Adams]

> > How about just "most commands are not mode-specific"?
> 
> That's not my experience.

Stats, please.

> Whenever I use M-x (and I do it a lot, since on my setup it is often
> more ergonomic and faster than remembering and pressing shortcuts) I
> see on the list of completions lots of commands that have nothing to do
> with what I'm doing.

That provides zero info about whether most commands
are mode-specific.  Sorry.

What that indicates is that there are lots of
commands (maybe even most commands) that are not
relevant to what you're currently doing.

That's a completely different ball game.

`M-x TAB' _of course_ shows zillions of commands
that most likely have nothing to do with what
you're currently doing.  And?

Likewise `M-x f TAB', but less so most likely.

> This forces me to write more characters on the
> prompt to further refine the candidates

Well, yes.

If you're in mode `foo', it's likely that many
commands relevant for that mode start with `foo',
in which case `M-x foo TAB' might get you on
your way.  But yes, Emacs doesn't currently
guess "what you're doing", i.e., just what you
have in mind.

> and remember to not use certain inputs which
> bring in lots of irrelevant candidates just
> because the naming scheme they follow.

> Even worse: for any given input to M-x, the
> list of completions greatly vary depending
> on what I previously did on the Emacs session
> (as features are loaded and inject their commands.)

Yes, and we can look for features that might
help with such problems.  And if you find one
such, I encourage you to write it up in a
library and put it out there for people to try.

Time will tell how useful the feature is, and
you'll likely even get useful feedback to
improve it.

All of that is positive.  Emacs can always use
improvement, including in command selection.

You don't have to convince anyone here that
`M-x' is a fairly blunt hammer.  The convincing
that's called for is to support a given
proposed solution/improvement.

You argue that filtering out some set of
commands at the outset is an improvement.

Counter arguments were provide for not doing
such filtering - with that particular filter,
_by default_.  Counter arguments mentioned
interactive ways to filter, or to sort instead
of filtering.

I don't think anyone is against letting you
filter in the way you think best.  It's about
what behavior Emacs `M-x' should have, by
default, no?

RE: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Stefan Kangas]

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

>> > How about just "most commands are not mode-specific"?
>>
>> That's not my experience.
>
> Stats, please.

I don't think such stats exist until we get more experience tagging
things up.  See Lars' and Stefan M's recent posts where we have the
figures 50-75 % and 90 %, respectively.

We will get more such stats soon, I hope.

PS. Lars' stats department is still sayin' 97 %, though.  Not sure
    what's up with those guys, but they also produced some interesting
    stats here:  https://lars.ingebrigtsen.no/2019/10/11/2x10/
    (Search for "I'm from finance" and you will find it.)

RE: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Drew Adams]

> >> > How about just "most commands are not mode-specific"?
> >> That's not my experience.
> > Stats, please.
> 
> I don't think such stats exist until we get more experience tagging
> things up.  See Lars' and Stefan M's recent posts where we have the
> figures 50-75 % and 90 %, respectively.

As we usually do, just add a new feature optionally
and opt-in.  Time will tell whether to give it more
authority (e.g. turn it on by default).  Users are
the test ground and the whole point of any proposed
improvement.

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Yuan Fu]

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



> On Feb 17, 2021, at 1:40 PM, Stefan Kangas <stefankangas@gmail.com> wrote:
> 
> Drew Adams <drew.adams@oracle.com> writes:
> 
>>>> How about just "most commands are not mode-specific"?
>>> 
>>> That's not my experience.
>> 
>> Stats, please.
> 
> I don't think such stats exist until we get more experience tagging
> things up.  See Lars' and Stefan M's recent posts where we have the
> figures 50-75 % and 90 %, respectively.
> 
> We will get more such stats soon, I hope.
> 
> PS. Lars' stats department is still sayin' 97 %, though.  Not sure
>    what's up with those guys, but they also produced some interesting
>    stats here:  https://lars.ingebrigtsen.no/2019/10/11/2x10/
>    (Search for "I'm from finance" and you will find it.)
> 

FWIW, I randomly selected 100 commands among all 1285 (from gnus, org, and other packages I have loaded at the time) and tagged them. Among them 64 are  mode-specific commands. If my stat classes and wikipedia didn’t fail me, we have 95% confidence that the proportion of mode-specific commands is between 54.6% and 73.4%. (p = 0.64, n=100, using confidence interval of binomial distribution)

Command selection code:

(let ((command-list (seq-filter #'commandp obarray))
      elt sample)
  (dotimes (_ 100)
    (setq elt (seq-random-elt command-list))
    (setq command-list (remove elt command-list))
    (push elt sample))
  (dolist (x sample)
    (print x)))


[-- Attachment #2: tagged-commands.txt --]
[-- Type: text/plain, Size: 2434 bytes --]

n gnus-article-edit-mode
s gnus-uu-digest-mail-forward
n vc-git-grep
s edebug-visit-eval-list
n global-sidebar-mode
s shell-dynamic-complete-filename
s org-agenda-filter-by-regexp
s org-columns-content
s dired-do-copy-regexp
s 2C-associate-buffer
s gnus-summary-insert-cached-articles
n vc-dir-search
s gnus-start-date-timer
n yas-global-mode
s org-remove-inline-images
n ghelp-describe-1
s vc-dir-mark-registered-files
s rmail-forward
s org-update-checkbox-count
s zeft-previous
s gnus-uu-decode-unshar-and-save-view
s calendar-beginning-of-week
s comint-kill-region
n highlight-changes-mode
n magit-commit-squash
s company-other-backend
n make-face-italic
s rmail-summary
s org-todo
n iscroll-forward-line
n counsel-unicode-char
s package-menu-mark-upgrades
n finder-by-keyword
n ert-delete-all-tests
s counsel-down-directory
n magit-commit-create
s org-agenda-bulk-unmark-all
n pdf-virtual-view-mode
n org-backward-paragraph
s org-indent-drawer
s org-agenda-refile
s bibtex-empty-field
s sage-shell-sagetex:compile-current-file
n hs-toggle-hiding
n org-table-cut-region
s magit-next-line
s yas-prev-field
s bookmark-bmenu-backup-unmark
s ghelp-switch-to-page
s pr-customize
s org-babel-examplify-region
n org-bibtex-search
s Info-mouse-follow-link
n ns-popup-font-panel
s bookmark-bmenu-other-window
s org-agenda-date-earlier-minutes
s org-metaleft
s diff-hunk-next
s diary-chinese-insert-entry
s org-agenda-date-later-hours
s calendar-forward-month
n winner-undo
n calendar
s org-texinfo-export-to-texinfo
n isolate-long-change
s org-agenda-clockreport-mode
n custom-theme-visit-theme
s bibtex-pop-next
n common-lisp-mode
s Buffer-menu-unmark-all-buffers
n project-eshell
s gnus-article-fill-cited-article
s org-agenda-set-property
s gnus-article-highlight-citation
s org-agenda-filter-remove-all
n turn-on-rxt-mode
n edebug-toggle-disable-breakpoint
s gnus-group-news
s gnus-summary-followup-to-mail
s counsel-org-agenda-headlines
s yas--minor-mode-menu
s ert-results-toggle-printer-limits-for-test-at-point
s org-update-dblock
n epa-list-secret-keys
s org-agenda-limit-interactively
n yas-tryout-snippet
s org-columns-move-right
n counsel-compile-edit-command
n flymake-disabled-backends
s tab-bar-handle-mouse
n org-table-insert-hline
s package-menu-describe-package
s shell-forward-command
s org-babel-result-hide-all
n ns-paste-secondary
s iimg-export
s org-paste-subtree
s widget-end-of-line
n lm-synopsis
n epa-insert-keys

[-- Attachment #3: loaded-features.txt --]
[-- Type: text/plain, Size: 3403 bytes --]

gnus
nnheader
gnus-util
rmail
rmail-loaddefs
rfc2047
rfc2045
ietf-drums
mail-utils
mm-util
mail-prsvr
ffap
tramp
tramp-loaddefs
trampver
tramp-integration
files-x
tramp-compat
shell
parse-time
ls-lisp
etags
fileloop
generator
ob-ditaa
ob-plantuml
ol-bibtex
bibtex
iso8601
org-crypt
org-habit
org-agenda
org-clock
org-colview
org-refile
bklink
quanjiao
iscroll
iimg
zeft
pulse
cl-print
face-remap
cus-edit
misearch
multi-isearch
server
bug-reference
bookmark
executable
vc-mtn
vc-hg
vc-git
vc-bzr
vc-src
vc-sccs
vc-svn
vc-cvs
vc-rcs
add-log
form-feed
checkdoc
lisp-mnt
diff-hl
vc-dir
vc
vc-dispatcher
diff-mode
hideshow
company-dabbrev-code
company-dabbrev
company-files
company-capf
keyfreq
minibuf-eldef
so-long
cus-load
kinsoku
jka-compr
cyberpunk-theme
light-theme
theme-util
no-littering
svg
dom
xml
ghelp
ghelp-eglot
ghelp-helpful
ghelp-builtin
derived
outline+
color-outline
pause
utility
transform
which-func
ivy-xref
yasnippet
eglot
array
filenotify
jsonrpc
ert
pp
ewoc
debug
flymake-proc
flymake
warnings
flycheck
flyspell
ispell
expand-region
text-mode-expansions
the-org-mode-expansions
er-basic-expansions
thingatpt
expand-region-core
expand-region-custom
ws-butler
minions
savehist
buffer-move
windmove
hl-todo
highlight-parentheses
rainbow-delimiters
elec-pair
winner
aggressive-indent
recentf-ext
recentf
tree-widget
wid-edit
which-key
company
helpful
imenu
trace
edebug
backtrace
info-look
f
dash-functional
help-fns
radix-tree
elisp-refs
s
dash
org
ob
ob-tangle
ob-ref
ob-lob
ob-table
ob-exp
org-macro
org-footnote
org-src
ob-comint
org-pcomplete
pcomplete
org-list
org-faces
org-entities
time-date
noutline
outline
org-version
ob-emacs-lisp
ob-core
ob-eval
org-table
ol
org-keys
org-compat
org-macs
org-loaddefs
format-spec
find-func
cal-menu
calendar
cal-loaddefs
counsel
xdg
advice
xref
project
dired
dired-loaddefs
compile
text-property-search
comint
ansi-color
swiper
cl-extra
help-mode
ivy
delsel
ring
ivy-faces
ivy-overlay
colir
color
finder-inf
edmacro
kmacro
proof-site
proof-autoloads
rx
info
tex-site
lunary
luna-key
luna-load-package
pcase
cowboy
package
easymenu
browse-url
url
url-proxy
url-privacy
url-expand
url-methods
url-history
url-cookie
url-domsuf
url-util
mailcap
url-handlers
url-parse
auth-source
cl-seq
eieio
eieio-core
eieio-loaddefs
password-cache
json
map
url-vars
lunary-ui
easy-mmode
cl-macs
subr-x
cl-loaddefs
cl-lib
luna-local
luna-f
seq
byte-opt
gv
bytecomp
byte-compile
cconv
iso-transl
tooltip
cus-start
eldoc
electric
uniquify
ediff-hook
vc-hooks
lisp-float-type
mwheel
term/ns-win
ns-win
ucs-normalize
mule-util
term/common-win
tool-bar
dnd
fontset
image
regexp-opt
fringe
tabulated-list
replace
newcomment
text-mode
elisp-mode
lisp-mode
prog-mode
register
page
tab-bar
menu-bar
rfn-eshadow
isearch
timer
select
scroll-bar
mouse
jit-lock
font-lock
syntax
facemenu
font-core
term/tty-colors
frame
minibuffer
cl-generic
cham
georgian
utf-8-lang
misc-lang
vietnamese
tibetan
thai
tai-viet
lao
korean
japanese
eucjp-ms
cp51932
hebrew
greek
romanian
slovak
czech
european
ethiopic
indian
cyrillic
chinese
composite
charscript
charprop
case-table
epa-hook
jka-cmpr-hook
help
simple
abbrev
obarray
cl-preloaded
nadvice
button
loaddefs
faces
cus-face
macroexp
files
window
text-properties
overlay
sha1
md5
base64
format
env
code-pages
mule
custom
widget
hashtable-print-readable
backquote
threads
kqueue
cocoa
ns
lcms2
multi-tty
make-network-process
emacs

[-- Attachment #4: Type: text/plain, Size: 8 bytes --]



Yuan

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Lars Ingebrigtsen]

Yuan Fu <casouri@gmail.com> writes:

> If my stat classes and wikipedia didn’t fail me, we have 95%
> confidence that the proportion of mode-specific commands is between
> 54.6% and 73.4%. (p = 0.64, n=100, using confidence interval of
> binomial distribution)

:-)  Excellent.

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

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Stefan Monnier]

> OTOH, I expect that almost all commands defined in packages such as
> C-Mode (and almost every other programming mode) are mode-specific.

Tho things can get murky: e.g. when dealing with multi-language buffers,
or with commands like `diff-refine-hunk` (which I often use in Gnus's
article buffers).
IOW when you have one "language's" text in a buffer that's not using the
corresponding major mode.


        Stefan

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Óscar Fuentes]

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

>> OTOH, I expect that almost all commands defined in packages such as
>> C-Mode (and almost every other programming mode) are mode-specific.
>
> Tho things can get murky: e.g. when dealing with multi-language buffers,
> or with commands like `diff-refine-hunk` (which I often use in Gnus's
> article buffers).
> IOW when you have one "language's" text in a buffer that's not using the
> corresponding major mode.

Absolutely. I observed these details when the feature was first proposed
time ago. That's the reason why tagging the commands is not an automatic
task at all, even for the hacker who wrote them.

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Lars Ingebrigtsen]

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

> Tho things can get murky: e.g. when dealing with multi-language buffers,
> or with commands like `diff-refine-hunk` (which I often use in Gnus's
> article buffers).

That's not a mode-specific command, so tagging it as such would be an
error...

Multi-language buffers are an interesting problem, though.  But...  they
work by switching `major-mode' around, don't they?  In which case,
things should pretty much work automatically.  (I'm thinking of
mhtml-mode.)

> IOW when you have one "language's" text in a buffer that's not using the
> corresponding major mode.

I'm trying to think of cases where this would be a problem, but I'm
having problems coming up with an example.

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

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Stefan Monnier]

>> Tho things can get murky: e.g. when dealing with multi-language buffers,
>> or with commands like `diff-refine-hunk` (which I often use in Gnus's
>> article buffers).
> That's not a mode-specific command, so tagging it as such would be an
> error...

The point was that it's not necessarily obvious that it's not mode-specific.

> Multi-language buffers are an interesting problem, though.  But...  they
> work by switching `major-mode' around, don't they?  In which case,
> things should pretty much work automatically.  (I'm thinking of
> mhtml-mode.)

That's my hope as well.  There's also org-babel, BTW.

>> IOW when you have one "language's" text in a buffer that's not using the
>> corresponding major mode.
> I'm trying to think of cases where this would be a problem, but I'm
> having problems coming up with an example.

It should only be a problem if some commands are tagged
too optimistically.


        Stefan

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Lars Ingebrigtsen]

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

>>> Tho things can get murky: e.g. when dealing with multi-language buffers,
>>> or with commands like `diff-refine-hunk` (which I often use in Gnus's
>>> article buffers).
>> That's not a mode-specific command, so tagging it as such would be an
>> error...
>
> The point was that it's not necessarily obvious that it's not mode-specific.

Indeed -- tagging commands as mode-specific is not a mechanical task (or
something that can be inferred heuristically), but requires actually
giving each command some consideration.

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

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Stefan Monnier]

>>>> Tho things can get murky: e.g. when dealing with multi-language buffers,
>>>> or with commands like `diff-refine-hunk` (which I often use in Gnus's
>>>> article buffers).
>>> That's not a mode-specific command, so tagging it as such would be an
>>> error...
>> The point was that it's not necessarily obvious that it's not mode-specific.
> Indeed -- tagging commands as mode-specific is not a mechanical task (or
> something that can be inferred heuristically), but requires actually
> giving each command some consideration.

I think it would be good to try and clarify what should be the
criterion, and not in terms of "should be listed in M-x" since that
inherently depends on opinions, but rather in more technical terms that
depend on what the command does.
[ A bit like with docstrings: we like docstrings that say what the
  function does rather than when/where it's meant to be used.  ]

Maybe something like "would inevitably signal an error"?


        Stefan

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Lars Ingebrigtsen]

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

> I think it would be good to try and clarify what should be the
> criterion, and not in terms of "should be listed in M-x" since that
> inherently depends on opinions, but rather in more technical terms that
> depend on what the command does.
> [ A bit like with docstrings: we like docstrings that say what the
>   function does rather than when/where it's meant to be used.  ]
>
> Maybe something like "would inevitably signal an error"?

I don't think there's any hard and fast criterion that can be used,
though.  For instance, there was one mode I tagged up that had a
`foo-quit' command, which just buried the buffer.  Now, that's a command
that can work anywhere...  but the reason it exists is presumably
because the person who wrote it either missed out on inheriting from
`special-mode', or didn't know you can bind `bury-buffer' directly, or
whatever.

In any case, it's not a command that anybody not using `foo' will (or
should) be using, so I'd say (and I did say) that it's a mode-specific
command.

Now, lots of commands do, indeed, signal an error outside the proper
mode, or completely mess things up outside the proper mode, and those
are no-brainers.

I'd planned on writing a little essay for the lispref manual about this,
once I'd gotten some more experience, because it's not immediately
obvious what's the right thing to do until you've evaluated a few
instances.

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

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Stefan Monnier]

>> I think it would be good to try and clarify what should be the
>> criterion, and not in terms of "should be listed in M-x" since that
>> inherently depends on opinions, but rather in more technical terms that
>> depend on what the command does.
>> [ A bit like with docstrings: we like docstrings that say what the
>>   function does rather than when/where it's meant to be used.  ]
>>
>> Maybe something like "would inevitably signal an error"?
>
> I don't think there's any hard and fast criterion that can be used,
> though.

That's what I suspect also, but I think we need to try and "formalize"
this at least to the extent possible, so we can decide whether a given
problem is due to a tagging-error or to an incorrect expectation on the
side of the user of that tagging info.

> For instance, there was one mode I tagged up that had a
> `foo-quit' command, which just buried the buffer.  Now, that's a command
> that can work anywhere...  but the reason it exists is presumably
> because the person who wrote it either missed out on inheriting from
> `special-mode', or didn't know you can bind `bury-buffer' directly, or
> whatever.

I know exactly what you mean ;-)

[ BTW, the better course of action in those cases is of course to mark
  those commands obsolete and derive from special-mode (or at least to
  align the code&behavior as much as possible with that of
  special-mode).  ]

> Now, lots of commands do, indeed, signal an error outside the proper
> mode, or completely mess things up outside the proper mode, and those
> are no-brainers.
>
> I'd planned on writing a little essay for the lispref manual about this,
> once I'd gotten some more experience, because it's not immediately
> obvious what's the right thing to do until you've evaluated a few
> instances.

Great, looking forward to it.  BTW, I think you can already put
something in it and refine it later on; for the benefit of other people
who might want to help the tagging process.


        Stefan

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Lars Ingebrigtsen]

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

> [ BTW, the better course of action in those cases is of course to mark
>   those commands obsolete and derive from special-mode (or at least to
>   align the code&behavior as much as possible with that of
>   special-mode).  ]

Indeed.

>> I'd planned on writing a little essay for the lispref manual about this,
>> once I'd gotten some more experience, because it's not immediately
>> obvious what's the right thing to do until you've evaluated a few
>> instances.
>
> Great, looking forward to it.  BTW, I think you can already put
> something in it and refine it later on; for the benefit of other people
> who might want to help the tagging process.

I've written up a new node about this stuff now.

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

RE: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Drew Adams]

> > I don't think there's any hard and fast criterion that can be used,
> > though.
> 
> That's what I suspect also, but I think we need to try and "formalize"
> this at least to the extent possible, so we can decide whether a given
> problem is due to a tagging-error or to an incorrect expectation on the
> side of the user of that tagging info.

+1.  If this feature is to be meaningful and
useful (whether it's on by default or not),
people should understand what it's about -
when it should be used.  Some guidelines are
called for, even if no hard-&-fast rule
suffices.

RE: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Drew Adams]

> > I think it would be good to try and clarify what should be the
> > criterion, and not in terms of "should be listed in M-x" since that
> > inherently depends on opinions, but rather in more technical terms
> > that depend on what the command does.
> > [ A bit like with docstrings: we like docstrings that say what the
> >   function does rather than when/where it's meant to be used.  ]
> >
> > Maybe something like "would inevitably signal an error"?
> 
> I don't think there's any hard and fast
> criterion that can be used, though.

Which is what some of us have been saying...

So we're back to the question of what you mean
by "commands meant for this specific mode" and
"commands bound to modes".

No answer, so far.  OK, you've said it's a
judgment call.  That sounds reasonable.  But
what criteria are you using when weighing?

And why not let users do the judging, including
at the time of completion?  Why decide for them?

> it's not immediately obvious what's the right
> thing to do until you've evaluated a few
> instances.

It sounds like the concept of command relevance
for a mode is itself not well understood/defined.

We're back to one person's filter-it-out is
another's keep-it-in, no?

Put differently, as already said, things are not
cut-and-dried.

Whether a command should be a completion candidate
depends on the user and the current context.  It's
not something for some developer to decide at
command definition time. No predefined filtering
"per mode" makes general sense, at least not as
default behavior.

RE: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Drew Adams]

> I think it would be good to try and clarify what should be the
> criterion, and not in terms of "should be listed in M-x" since that
> inherently depends on opinions, but rather in more technical terms that
> depend on what the command does.

Thank you.  That is _exactly_ what I meant when
I asked (more than once), what was meant by
"commands meant for this specific mode" and
"commands bound to modes".  (I got no answer.)

> Maybe something like "would inevitably signal an error"?

+1.  That's clear and useful.

(Whether or not such a criterion should filter
by default is another story.  But at least
getting this criterion nailed down would be
a blessing for the discussion.)

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 17 Feb 2021 15:19:09 +0100
> Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
> 
> Indeed -- tagging commands as mode-specific is not a mechanical task (or
> something that can be inferred heuristically), but requires actually
> giving each command some consideration.

Wouldn't need constant maintenance, to adjust tagging as things
change due to Emacs development?

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Indeed -- tagging commands as mode-specific is not a mechanical task (or
>> something that can be inferred heuristically), but requires actually
>> giving each command some consideration.
>
> Wouldn't need constant maintenance, to adjust tagging as things
> change due to Emacs development?

"Constant" maintenance?  No.

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

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: monnier@iro.umontreal.ca,  ofv@wanadoo.es,  emacs-devel@gnu.org
> Date: Wed, 17 Feb 2021 20:30:48 +0100
> 
> > Wouldn't need constant maintenance, to adjust tagging as things
> > change due to Emacs development?
> 
> "Constant" maintenance?  No.

What happens when a command that was only relevant to a single mode is
extended to become more widely used?  Wouldn't we need to remove the
tagging?  And if we do need to do it, how will we manage not to forget
updating the tagging?

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Wouldn't need constant maintenance, to adjust tagging as things
>> > change due to Emacs development?
>> 
>> "Constant" maintenance?  No.
>
> What happens when a command that was only relevant to a single mode is
> extended to become more widely used?  Wouldn't we need to remove the
> tagging?  And if we do need to do it, how will we manage not to forget
> updating the tagging?

Probably we shall get accustomed to update the tagging, first thing.
IMHO it would be a good thing, as its benefits go further than the
tagging maintenance.

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> What happens when a command that was only relevant to a single mode is
> extended to become more widely used?  Wouldn't we need to remove the
> tagging?  And if we do need to do it, how will we manage not to forget
> updating the tagging?

The tagging is right there in the `interactive' spec (and not somewhere
else (in a plist, for instance)), which is one of the reasons that I
want the syntax to be easy and clear -- it makes it much less likely
that somebody will forget to change the tagging in cases like this.
(But I don't think that we will, in practice, see all that much of this.
Nobody is going to suddenly use commands from 5x5.el in dired.el.)

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

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: monnier@iro.umontreal.ca,  ofv@wanadoo.es,  emacs-devel@gnu.org
> Date: Thu, 18 Feb 2021 12:33:45 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > What happens when a command that was only relevant to a single mode is
> > extended to become more widely used?  Wouldn't we need to remove the
> > tagging?  And if we do need to do it, how will we manage not to forget
> > updating the tagging?
> 
> The tagging is right there in the `interactive' spec (and not somewhere
> else (in a plist, for instance)), which is one of the reasons that I
> want the syntax to be easy and clear -- it makes it much less likely
> that somebody will forget to change the tagging in cases like this.

When a command changes, it doesn't necessarily mean its interactive
spec or the list of arguments changes.  In fact, we try very hard not
to make such changes, for compatibility's sake.

> (But I don't think that we will, in practice, see all that much of this.
> Nobody is going to suddenly use commands from 5x5.el in dired.el.)

Who said I had 5x5.el in mind?  That's a classic strawman.

Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Lars Ingebrigtsen]

(This is just a note to remind myself to fix up the "(declare (modes"
(and possibly the "(declare (completion") thing -- it doesn't actually
work for ;;;###autoload yet.  `make-autoload' has to be tweaked to peek
at `declare' in addition to `interactive'.  I'll fix that bit up
tomorrow.)

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

Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> (This is just a note to remind myself to fix up the "(declare (modes"
> (and possibly the "(declare (completion") thing -- it doesn't actually
> work for ;;;###autoload yet.  `make-autoload' has to be tweaked to peek
> at `declare' in addition to `interactive'.  I'll fix that bit up
> tomorrow.)

Tomorrow arrived a day late, but I've now changed (declare (modes to be
more equivalent to interactive.

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

Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Stefan Monnier]

>> (This is just a note to remind myself to fix up the "(declare (modes"
>> (and possibly the "(declare (completion") thing -- it doesn't actually
>> work for ;;;###autoload yet.  `make-autoload' has to be tweaked to peek
>> at `declare' in addition to `interactive'.  I'll fix that bit up
>> tomorrow.)

If the `declare` expands to something like `put` then there's already
a mechanism in place to control whether that `put` should be autoloaded
or not (and by default, they're autoloaded).

See for example:

    (defalias 'byte-run--set-debug
      #'(lambda (name _args spec)
          (list 'progn :autoload-end
                (list 'put (list 'quote name)
                      ''edebug-form-spec (list 'quote spec)))))

where the `:autoload-end` indicates that the `put` should not be copied
to the loaddefs/autoloads file.


        Stefan

Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Lars Ingebrigtsen]

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

> If the `declare` expands to something like `put` then there's already
> a mechanism in place to control whether that `put` should be autoloaded
> or not (and by default, they're autoloaded).

Yes, I typed the wrong thing in my reminder to myself, but I fixed it
correctly.  :-)

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

Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Dmitry Gutov]

On 20.02.2021 15:30, Lars Ingebrigtsen wrote:
> Tomorrow arrived a day late, but I've now changed (declare (modes to be
> more equivalent to interactive.

Have you considered making 'interactive' more equivalent to (declare 
(modes as well? That can speed up `command-modes`, for example.

As well as make it only one execution path to worry about.

Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 20.02.2021 15:30, Lars Ingebrigtsen wrote:
>> Tomorrow arrived a day late, but I've now changed (declare (modes to be
>> more equivalent to interactive.
>
> Have you considered making 'interactive' more equivalent to (declare
> (modes as well? That can speed up `command-modes`, for example.

The performance differences aren't very compelling, one way or another.
It'll slow down `command-modes' for byte-compiled code, for instance
(but not a lot).

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

Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Dmitry Gutov]

On 21.02.2021 15:10, Lars Ingebrigtsen wrote:
> It'll slow down `command-modes' for byte-compiled code, for instance
> (but not a lot).

Since you need to check for modes both inside the function bytecode and 
inside the function symbol properties, maybe not?

In the end, the average cost should depend on whether you are allowed to 
skip the symbol property lookup if the bytecode is already tagged (I 
figure you might not, but there can be different opinions on that), and 
which percentage of all commands are tagged.

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> (But I don't think that we will, in practice, see all that much of this.
>> Nobody is going to suddenly use commands from 5x5.el in dired.el.)
>
> Who said I had 5x5.el in mind?  That's a classic strawman.

It's a typical example of a mode that has mode-based tagging.

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

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: monnier@iro.umontreal.ca,  ofv@wanadoo.es,  emacs-devel@gnu.org
> Date: Fri, 19 Feb 2021 13:09:11 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> (But I don't think that we will, in practice, see all that much of this.
> >> Nobody is going to suddenly use commands from 5x5.el in dired.el.)
> >
> > Who said I had 5x5.el in mind?  That's a classic strawman.
> 
> It's a typical example of a mode that has mode-based tagging.

Not when the issue is modes whose scope may become wider than it is
today.

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Alan Mackenzie]

Hello, Lars.

On Thu, Feb 18, 2021 at 12:33:45 +0100, Lars Ingebrigtsen wrote:
> Eli Zaretskii <eliz@gnu.org> writes:

> > What happens when a command that was only relevant to a single mode is
> > extended to become more widely used?  Wouldn't we need to remove the
> > tagging?  And if we do need to do it, how will we manage not to forget
> > updating the tagging?

> The tagging is right there in the `interactive' spec (and not somewhere
> else (in a plist, for instance)), which is one of the reasons that I
> want the syntax to be easy and clear -- it makes it much less likely
> that somebody will forget to change the tagging in cases like this.
> (But I don't think that we will, in practice, see all that much of this.
> Nobody is going to suddenly use commands from 5x5.el in dired.el.)

What about commands used by a small number of modes, but that set of
modes is only known at runtime?

Are we supposed to amend a command's interactive spec at runtime?

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

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Óscar Fuentes]

Alan Mackenzie <acm@muc.de> writes:

> What about commands used by a small number of modes, but that set of
> modes is only known at runtime?
>
> Are we supposed to amend a command's interactive spec at runtime?

No.

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Alan Mackenzie]

Hello, Óscar/

On Thu, Feb 18, 2021 at 17:55:50 +0100, Óscar Fuentes wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > What about commands used by a small number of modes, but that set of
> > modes is only known at runtime?

> > Are we supposed to amend a command's interactive spec at runtime?

> No.

What, then?  Do you have a positive suggestion?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Óscar Fuentes]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Óscar/
>
> On Thu, Feb 18, 2021 at 17:55:50 +0100, Óscar Fuentes wrote:
>> Alan Mackenzie <acm@muc.de> writes:
>
>> > What about commands used by a small number of modes, but that set of
>> > modes is only known at runtime?
>
>> > Are we supposed to amend a command's interactive spec at runtime?
>
>> No.
>
> What, then?  Do you have a positive suggestion?

It would be nice to update the info at runtime, but IMO it is beyond
what is reasonable to ask.

This feature works on the pretense that if a command has a real
potential for being used outside of its mode, it shall not be annotated
as mode-specific. The scenario you described indicates that the
application realm of the command is open-ended.

In the future the system can be expanded so a mode can declare that it
uses specific commands (or all of them) from some other mode, but that
is not required now for the filtering to be effective.

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Alan Mackenzie]

Hello, Óscar.

On Thu, Feb 18, 2021 at 18:20:26 +0100, Óscar Fuentes wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > On Thu, Feb 18, 2021 at 17:55:50 +0100, Óscar Fuentes wrote:
> >> Alan Mackenzie <acm@muc.de> writes:

> >> > What about commands used by a small number of modes, but that set of
> >> > modes is only known at runtime?

> >> > Are we supposed to amend a command's interactive spec at runtime?

> >> No.

> > What, then?  Do you have a positive suggestion?

> It would be nice to update the info at runtime, but IMO it is beyond
> what is reasonable to ask.

In other words, this is a flaw in the idea of abusing the interactive
spec for miscellaneous information.

> This feature works on the pretense that if a command has a real
> potential for being used outside of its mode, it shall not be annotated
> as mode-specific. The scenario you described indicates that the
> application realm of the command is open-ended.

Not particularly.  I was thinking of commands such as
c-toggle-comment-style, whose realm is strictly constrained.

> In the future the system can be expanded so a mode can declare that it
> uses specific commands (or all of them) from some other mode, but that
> is not required now for the filtering to be effective.

No, not from some other mode.  We're talking about commands shared by a
set of modes known only at runtime.  If the list of modes cannot be
updated at runtime, this is a deficiency in the design.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Robert Pluim]

>>>>> On Thu, 18 Feb 2021 17:35:44 +0000, Alan Mackenzie <acm@muc.de> said:

    Alan> No, not from some other mode.  We're talking about commands shared by a
    Alan> set of modes known only at runtime.  If the list of modes cannot be
    Alan> updated at runtime, this is a deficiency in the design.

Iʼm having a hard time thinking of an example, eg you might not know
which of the modes provided by the cc-mode package the user actually
uses, but adding all of them to the relevant commands can be done
beforehand. Can you expand?

Robert

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Yuan Fu]

> On Feb 18, 2021, at 12:55 PM, Robert Pluim <rpluim@gmail.com> wrote:
> 
>>>>>> On Thu, 18 Feb 2021 17:35:44 +0000, Alan Mackenzie <acm@muc.de> said:
> 
>    Alan> No, not from some other mode.  We're talking about commands shared by a
>    Alan> set of modes known only at runtime.  If the list of modes cannot be
>    Alan> updated at runtime, this is a deficiency in the design.
> 
> Iʼm having a hard time thinking of an example, eg you might not know
> which of the modes provided by the cc-mode package the user actually
> uses, but adding all of them to the relevant commands can be done
> beforehand. Can you expand?


Does the current implementation allow a user to modify the tagging? It is possible that the author tagged a command as mode-specific but a user want to use it elsewhere, or the author tagged a command wrong. 

Yuan

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Robert Pluim]

>>>>> On Thu, 18 Feb 2021 13:15:18 -0500, Yuan Fu <casouri@gmail.com> said:

    Yuan> Does the current implementation allow a user to modify the tagging? It
    Yuan> is possible that the author tagged a command as mode-specific but a
    Yuan> user want to use it elsewhere, or the author tagged a command wrong.

The user can always override the author's specification by putting a
completion-predicate on the command in question (this would be a good
use for the 'always' function people have been discussing in a
different thread).

Robert

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Fri, 19 Feb 2021 09:47:29 +0100
> Cc: Óscar Fuentes <ofv@wanadoo.es>,
>  Alan Mackenzie <acm@muc.de>, emacs-devel <emacs-devel@gnu.org>
> 
> The user can always override the author's specification by putting a
> completion-predicate on the command in question (this would be a good
> use for the 'always' function people have been discussing in a
> different thread).

If by "user" you really mean users, not Lisp programmers, then I think
the above is too obscure for a user-level feature.  If we want to
expose this functionality to users, we will need an interactive
user-level command to produce such effects in a convenient and
user-friendly fashion.

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Robert Pluim]

>>>>> On Fri, 19 Feb 2021 10:55:00 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Date: Fri, 19 Feb 2021 09:47:29 +0100
    >> Cc: Óscar Fuentes <ofv@wanadoo.es>,
    >> Alan Mackenzie <acm@muc.de>, emacs-devel <emacs-devel@gnu.org>
    >> 
    >> The user can always override the author's specification by putting a
    >> completion-predicate on the command in question (this would be a good
    >> use for the 'always' function people have been discussing in a
    >> different thread).

    Eli> If by "user" you really mean users, not Lisp programmers, then I think
    Eli> the above is too obscure for a user-level feature.  If we want to
    Eli> expose this functionality to users, we will need an interactive
    Eli> user-level command to produce such effects in a convenient and
    Eli> user-friendly fashion.

So

    M-x make-command-globally-available RET
    <name of command> RET

and

    M-x make-command-locally-available RET
    <display major and minor modes in effect>
    <select one> (or more?) RET

I donʼt think customize would be suitable for this.

Robert

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: ofv@wanadoo.es,  acm@muc.de,  casouri@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 19 Feb 2021 12:21:30 +0100
> 
>     Eli> If by "user" you really mean users, not Lisp programmers, then I think
>     Eli> the above is too obscure for a user-level feature.  If we want to
>     Eli> expose this functionality to users, we will need an interactive
>     Eli> user-level command to produce such effects in a convenient and
>     Eli> user-friendly fashion.
> 
> So
> 
>     M-x make-command-globally-available RET
>     <name of command> RET
> 
> and
> 
>     M-x make-command-locally-available RET
>     <display major and minor modes in effect>
>     <select one> (or more?) RET

Yes, something like that.

> I donʼt think customize would be suitable for this.

I'll leave that to Custom wizards.

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Alan Mackenzie]

Hello, Robert.

On Thu, Feb 18, 2021 at 18:55:59 +0100, Robert Pluim wrote:
> >>>>> On Thu, 18 Feb 2021 17:35:44 +0000, Alan Mackenzie <acm@muc.de> said:

>     Alan> No, not from some other mode.  We're talking about commands shared by a
>     Alan> set of modes known only at runtime.  If the list of modes cannot be
>     Alan> updated at runtime, this is a deficiency in the design.

> Iʼm having a hard time thinking of an example, eg you might not know
> which of the modes provided by the cc-mode package the user actually
> uses, but adding all of them to the relevant commands can be done
> beforehand. Can you expand?

No, it can't be done.  There is no list of "all" CC Mode packages.
They're largely created and distributed by third parties, i.e. they're
outside the orbit of Emacs development.  There is no complete list of
them.

For this facility to be general, the list of modes MUST be changeable at
runtime.

> Robert

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Óscar Fuentes]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Robert.
>
> On Thu, Feb 18, 2021 at 18:55:59 +0100, Robert Pluim wrote:
>> >>>>> On Thu, 18 Feb 2021 17:35:44 +0000, Alan Mackenzie <acm@muc.de> said:
>
>>     Alan> No, not from some other mode.  We're talking about commands shared by a
>>     Alan> set of modes known only at runtime.  If the list of modes cannot be
>>     Alan> updated at runtime, this is a deficiency in the design.
>
>> Iʼm having a hard time thinking of an example, eg you might not know
>> which of the modes provided by the cc-mode package the user actually
>> uses, but adding all of them to the relevant commands can be done
>> beforehand. Can you expand?
>
> No, it can't be done.  There is no list of "all" CC Mode packages.
> They're largely created and distributed by third parties, i.e. they're
> outside the orbit of Emacs development.  There is no complete list of
> them.

AFAIR those modes derive from c-mode, right? It that is so, the commands
are automatically applicable to them.

> For this facility to be general, the list of modes MUST be changeable at
> runtime.

Why at runtime? (apart that compile-time and run-time is a somewhat
diffuse distinction for Elisp) Can't the mode have declarations like
thos I mentioned?

But apart from that, I see no big problem about changing the list of
modes at runtime, although I don't know the current implementation, so I
hope someone else can clarify this.

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Alan Mackenzie]

Hello, Óscar.

On Thu, Feb 18, 2021 at 20:32:16 +0100, Óscar Fuentes wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > Hello, Robert.

> > On Thu, Feb 18, 2021 at 18:55:59 +0100, Robert Pluim wrote:
> >> >>>>> On Thu, 18 Feb 2021 17:35:44 +0000, Alan Mackenzie <acm@muc.de> said:

> >>     Alan> No, not from some other mode.  We're talking about commands shared by a
> >>     Alan> set of modes known only at runtime.  If the list of modes cannot be
> >>     Alan> updated at runtime, this is a deficiency in the design.

> >> Iʼm having a hard time thinking of an example, eg you might not know
> >> which of the modes provided by the cc-mode package the user actually
> >> uses, but adding all of them to the relevant commands can be done
> >> beforehand. Can you expand?

> > No, it can't be done.  There is no list of "all" CC Mode packages.
> > They're largely created and distributed by third parties, i.e.
> > they're outside the orbit of Emacs development.  There is no complete
> > list of them.

> AFAIR those modes derive from c-mode, right? It that is so, the
> commands are automatically applicable to them.

Not in the sense of define-derived-mode, no.  csharp Mode isn't a "sort
of Java Mode", so it wouldn't make sense to use define-derived-mode here.
So the commands aren't automatically applicable to these modes.

> > For this facility to be general, the list of modes MUST be changeable at
> > runtime.

> Why at runtime? (apart that compile-time and run-time is a somewhat
> diffuse distinction for Elisp) Can't the mode have declarations like
> thos I mentioned?

At runtime, meaning at the time when the user builds or loads csharp
Mode.  This is not the build time of Emacs as a whole.

I'm not sure which declarations you mean, but it isn't reasonable to
expect third party maintainers to change their source code for this.

> But apart from that, I see no big problem about changing the list of
> modes at runtime, although I don't know the current implementation, so
> I hope someone else can clarify this.

The current implementation is that the lists of modes has been
shoe-horned onto the `interactive' form.  This may be a candidate for
going into read-only memory, I don't know.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Eli Zaretskii]

> Date: Thu, 18 Feb 2021 20:14:18 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: emacs-devel@gnu.org
> 
> > AFAIR those modes derive from c-mode, right? It that is so, the
> > commands are automatically applicable to them.
> 
> Not in the sense of define-derived-mode, no.

Then you could put the 'completion-predicate' property on the symbols
of relevant CC mode commands, and write a predicate that would DTRT
with CC mode commands in modes like java-mode.

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Eli Zaretskii]

> Date: Thu, 18 Feb 2021 17:35:44 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: emacs-devel@gnu.org
> 
> > It would be nice to update the info at runtime, but IMO it is beyond
> > what is reasonable to ask.
> 
> In other words, this is a flaw in the idea of abusing the interactive
> spec for miscellaneous information.

No, this issue is common to _any_ implementation of tagging commands
with relevant mode, not just the implementation via the interactive
spec.

> > In the future the system can be expanded so a mode can declare that it
> > uses specific commands (or all of them) from some other mode, but that
> > is not required now for the filtering to be effective.
> 
> No, not from some other mode.  We're talking about commands shared by a
> set of modes known only at runtime.  If the list of modes cannot be
> updated at runtime, this is a deficiency in the design.

I don't think this problem is real, because the idea is that commands
which are relevant only to a _single_ mode will be tagged by that
mode.  Commands which are useful in several modes will remain
untagged.

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Alan Mackenzie]

Hello, Eli.

On Thu, Feb 18, 2021 at 21:42:57 +0200, Eli Zaretskii wrote:
> > Date: Thu, 18 Feb 2021 17:35:44 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: emacs-devel@gnu.org

> > > It would be nice to update the info at runtime, but IMO it is beyond
> > > what is reasonable to ask.

> > In other words, this is a flaw in the idea of abusing the interactive
> > spec for miscellaneous information.

> No, this issue is common to _any_ implementation of tagging commands
> with relevant mode, not just the implementation via the interactive
> spec.

If the tagging information were on, say, a symbol property, there would
be no great problem in updating it at run time.

> > > In the future the system can be expanded so a mode can declare that it
> > > uses specific commands (or all of them) from some other mode, but that
> > > is not required now for the filtering to be effective.

> > No, not from some other mode.  We're talking about commands shared by a
> > set of modes known only at runtime.  If the list of modes cannot be
> > updated at runtime, this is a deficiency in the design.

> I don't think this problem is real, because the idea is that commands
> which are relevant only to a _single_ mode will be tagged by that
> mode.  Commands which are useful in several modes will remain
> untagged.

So CC Mode, and in particular, third party modes derived from it, will
remain outside the scope of this feature?  That surely cannot be the
intention?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Eli Zaretskii]

> Date: Thu, 18 Feb 2021 19:57:59 +0000
> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > In other words, this is a flaw in the idea of abusing the interactive
> > > spec for miscellaneous information.
> 
> > No, this issue is common to _any_ implementation of tagging commands
> > with relevant mode, not just the implementation via the interactive
> > spec.
> 
> If the tagging information were on, say, a symbol property, there would
> be no great problem in updating it at run time.

The main problem that bothered me in this sub-thread was not the
update itself, it's the need to be aware that an update is needed.
There's no way to automate that decision, so we cannot program the
build process to warn about possibly changed relevance criteria.  It
will have to be a human decision, and those are easily forgotten.

> > I don't think this problem is real, because the idea is that commands
> > which are relevant only to a _single_ mode will be tagged by that
> > mode.  Commands which are useful in several modes will remain
> > untagged.
> 
> So CC Mode, and in particular, third party modes derived from it, will
> remain outside the scope of this feature?  That surely cannot be the
> intention?

No, CC mode and its descendants are one mode for the purpose of this
discussion, because the filtering checks whether the current major
mode is the one recorded in the tag _or_its_descendants_.

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Lars Ingebrigtsen]

Alan Mackenzie <acm@muc.de> writes:

> What about commands used by a small number of modes, but that set of
> modes is only known at runtime?
>
> Are we supposed to amend a command's interactive spec at runtime?

Did you have any examples in mind here?

But if such commands exist, then they do not sound like they should be
tagged as mode-specific.

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

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Dmitry Gutov]

On 19.02.2021 14:10, Lars Ingebrigtsen wrote:
> Did you have any examples in mind here?
> 
> But if such commands exist, then they do not sound like they should be
> tagged as mode-specific.

Alan mentioned c-toggle-comment-style, which should work in any CC major 
mode.

But the list of those modes is not known in advance when 
c-toggle-comment-style is defined, and they don't "derive" from a 
particular major mode either.

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Alan mentioned c-toggle-comment-style, which should work in any CC
> major mode.
>
> But the list of those modes is not known in advance when
> c-toggle-comment-style is defined, and they don't "derive" from a
> particular major mode either.

Then that command doesn't sound like it should be tagged with any modes.

But is there a reason the modes don't derive from a common ancestor?

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

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Dmitry Gutov]

On 19.02.2021 14:57, Lars Ingebrigtsen wrote:
> Then that command doesn't sound like it should be tagged with any modes.

At least in theory, if the way "modes" tag set is transparent, these 
tags could be updated each time when a new CC Mode is loaded.

> But is there a reason the modes don't derive from a common ancestor?

That's not for me to answer.

Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Yuan Fu]

> On Feb 17, 2021, at 6:20 AM, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
>> Tho things can get murky: e.g. when dealing with multi-language buffers,
>> or with commands like `diff-refine-hunk` (which I often use in Gnus's
>> article buffers).
> 
> That's not a mode-specific command, so tagging it as such would be an
> error...
> 
> Multi-language buffers are an interesting problem, though.  But...  they
> work by switching `major-mode' around, don't they?  In which case,
> things should pretty much work automatically.  (I'm thinking of
> mhtml-mode.)
> 
>> IOW when you have one "language's" text in a buffer that's not using the
>> corresponding major mode.
> 
> I'm trying to think of cases where this would be a problem, but I'm
> having problems coming up with an example.

Org-time-stamp comes to my mind. Presumably it is intended to work in Org Mode only, but I use it in other places to insert a timestamp. Is there a way to easily override the scope setting for a command? And if a new user tries to use org-time-stamp and couldn’t find it in M-x, how could he know the problem is because of this scope setting?

Yuan