Smarter M-x that filters on major-mode

Smarter M-x that filters on major-mode

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

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

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

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

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

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

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

[Stefan Monnier]

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

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

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

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

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


        Stefan

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

[Yuan Fu]

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

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

Yuan

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

[tomas]

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

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

Nobody uses M-x in an explorative way?

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

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

Cheers
 - t

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

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

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

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

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

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

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

[Lars Ingebrigtsen]

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

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

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

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

  (command foo-mode "p")

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

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

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

[Lars Ingebrigtsen]

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

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

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

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

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

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

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

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

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

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

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

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

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

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

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

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

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

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

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

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

[Eli Zaretskii]

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

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

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

[Stefan Monnier]

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

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

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

How 'bout

    (declare (M-x-pred EXP))

which turns into

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

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


        Stefan

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

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

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

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

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

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

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

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

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

[Lars Ingebrigtsen]

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

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

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

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

[Stefan Monnier]

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

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

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

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

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


        Stefan

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

[Lars Ingebrigtsen]

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

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

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

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

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

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

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

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

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

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

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

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

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

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

[Lars Ingebrigtsen]

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

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

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

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

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

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

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

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

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

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

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

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

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

[Lars Ingebrigtsen]

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

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

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

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

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

[Óscar Fuentes]

<tomas@tuxteam.de> writes:

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

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

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

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

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

[Óscar Fuentes]

Lars Ingebrigtsen <larsi@gnus.org> writes:

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

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

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

[Lars Ingebrigtsen]

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

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

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

> Plus we have to take into account derived modes.

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

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

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

[Eli Zaretskii]

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

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

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

[tomas]

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

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

Makes sense to me.

Thanks
 - t

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

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

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

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

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

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

[Óscar Fuentes]

Lars Ingebrigtsen <larsi@gnus.org> writes:

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

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

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

Thank you.

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

[Lars Ingebrigtsen]

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

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

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

We now have

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

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

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

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

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

[Lars Ingebrigtsen]

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

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

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

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

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

[Jose A. Ortega Ruiz]

On Thu, Feb 11 2021, Lars Ingebrigtsen wrote:

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

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

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

it could even accept more than one mode

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

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

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

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

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

[Stefan Monnier]

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

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


        Stefan

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

[Jean Louis]

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

Me, I use it all the time.

M-x *KEYWORD<TAB>

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

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

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

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

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

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

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

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

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

but if function is interactive that error does not appear.

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

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

Jean

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

[Lars Ingebrigtsen]

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

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

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

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

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

[Lars Ingebrigtsen]

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

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

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

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

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

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

Yup.

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

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

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

[Lars Ingebrigtsen]

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

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

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

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

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

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

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

So I'm wondering whether this should be

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

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

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

or something along those lines...

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

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

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

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

Er; that'd be (for minor modes)

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

which is a mouthful...

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

Which could also conceivably be useful in other situations.

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

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

[Robert Pluim]

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

'minor-mode-list'?

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

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

Robert

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

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> 'minor-mode-list'?

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

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

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

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

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

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

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

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

[Stefan Monnier]

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

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

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


        Stefan

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

[Robert Pluim]

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

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

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

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

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

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

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

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

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

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

Robert

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

[jao]

On Fri, Feb 12 2021, Lars Ingebrigtsen wrote:

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

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

     (interactive 'c-mode)

which is distinguisable from a string or a form:

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

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

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

[Basil L. Contovounesios]

Stefan Kangas <stefankangas@gmail.com> writes:

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

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

-- 
Basil

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

[Stefan Kangas]

jao <jao@gnu.org> writes:

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

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

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

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

[Stefan Kangas]

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

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

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

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

[Stefan Monnier]

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

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


        Stefan


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

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

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

[Basil L. Contovounesios]

Stefan Kangas <stefankangas@gmail.com> writes:

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

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

-- 
Basil

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

[jao]

On Fri, Feb 12 2021, Stefan Monnier wrote:

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

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

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

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

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

indeed.

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

[jao]

On Fri, Feb 12 2021, Stefan Kangas wrote:

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

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

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

[Dmitry Gutov]

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

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

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

[Stefan Monnier]

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

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


        Stefan

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

[Óscar Fuentes]

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

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

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

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

[Lars Ingebrigtsen]

jao <jao@gnu.org> writes:

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

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

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

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

  (interactive nil foo-mode bar-mode)

all over the place instead of

  (command (foo-mode bar-mode))

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

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

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

[Lars Ingebrigtsen]

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

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

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

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

That is

  (interactive "p" foo-mode)

is identical to

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

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

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

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

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

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

Soory, I mean

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

Or something.  :-)

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

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

[Lars Ingebrigtsen]

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

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

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

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

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

[Lars Ingebrigtsen]

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

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

It's very marginal indeed. 

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

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

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

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

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

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

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

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

Right.  I'll fix up the doc string.

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

Yup.

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

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

[Lars Ingebrigtsen]

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

To summarise:

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

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

The general form is:

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

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

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

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

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

emacs -Q -l eww
M-x eww TAB

in a version before and after this patch set.

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

Now go fortheth and marketh uppeth.

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

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

[Basil L. Contovounesios]

Lars Ingebrigtsen <larsi@gnus.org> writes:

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

Thanks!

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

-- 
Basil

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

[Lars Ingebrigtsen]

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

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

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

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

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

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

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

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

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

[Basil L. Contovounesios]

Lars Ingebrigtsen <larsi@gnus.org> writes:

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

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

-- 
Basil

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

[Lars Ingebrigtsen]

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

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

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

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

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

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

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

[Dmitry Gutov]

On 14.02.2021 16:23, Lars Ingebrigtsen wrote:

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

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

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

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

[Alan Mackenzie]

Hello, Lars.

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

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

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

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

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

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

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

Please stop.  Please just stop and rethink.

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

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

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

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

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

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

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

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

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Now go fortheth and marketh uppeth.

This little command may be helpful.

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

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

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

[Stefan Kangas]

Alan Mackenzie <acm@muc.de> writes:

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

FWIW, I disagree:

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

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

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

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

[Óscar Fuentes]

Alan Mackenzie <acm@muc.de> writes:

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

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

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

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

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

Like every other feature in Emacs.

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

[Alan Mackenzie]

Hello, Stefan.

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

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

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

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

> FWIW, I disagree:

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

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

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

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

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

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

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

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

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

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

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

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

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

[Eli Zaretskii]

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

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

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

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

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

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

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

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

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

[Juri Linkov]

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

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

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

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

[Basil L. Contovounesios]

Lars Ingebrigtsen <larsi@gnus.org> writes:

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

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

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

Thanks,

-- 
Basil

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

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

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

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

And since you seem to think that

  (interactive "p" foo-mode)

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

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

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

[Lars Ingebrigtsen]

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

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

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

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

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

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

[Basil L. Contovounesios]

Lars Ingebrigtsen <larsi@gnus.org> writes:

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

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

-- 
Basil

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

[Lars Ingebrigtsen]

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

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

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

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

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

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

[Basil L. Contovounesios]

Lars Ingebrigtsen <larsi@gnus.org> writes:

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

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

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

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

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

But that's just me,

-- 
Basil

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

[Stefan Kangas]

Alan Mackenzie <acm@muc.de> writes:

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

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

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

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

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

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

Smarter M-x that filters on major-mode

[Boruch Baum]

> Matt Armstrong <matt@rfc20.org> writes:
>
>> What if instead help showed all the interactive commands provided by
>> the mode? What if M-x were smarter about highlighting mode specific
>> commands?

I remember a version of this discussion a few months ago, which led me
to write and publish what you may be looking for[1]. It defaults to
collecting all commands for the current major mode, but is designed to
handle other customized scenarios, too.

[1] https://github.com/Boruch-Baum/emacs-key-assist

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

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

[Stefan Monnier]

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

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

    (interactive "p" foo-mode)

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

    (interactive)

and the remaining 3% can use the more verbose:

    (declare (completion t))
    (interactive)

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


        Stefan

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

[Lars Ingebrigtsen]

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

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

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

I think

(interactive "p" foo-mode)

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

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

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

[Lars Ingebrigtsen]

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

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

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

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

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

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

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

[Eric S Fraga]

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

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

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

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

[Alan Mackenzie]

Hello, Stefan.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Sean Whitton]

Hello,

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

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

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

-- 
Sean Whitton

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

[Stefan Kangas]

Hi Alan,

Alan Mackenzie <acm@muc.de> writes:

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

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

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

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

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

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

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