* Smarter M-x that filters on major-mode
@ 2021-02-14 23:54 Boruch Baum
0 siblings, 0 replies; 85+ messages in thread
From: Boruch Baum @ 2021-02-14 23:54 UTC (permalink / raw)
To: Emacs-Devel List
> 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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Experimentally unbind M-o on the trunk
@ 2021-02-09 12:30 Gregory Heytings
2021-02-10 8:44 ` Alfred M. Szmidt
0 siblings, 1 reply; 85+ messages in thread
From: Gregory Heytings @ 2021-02-09 12:30 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: emacs-devel
>
> That is, I propose that we remove the `M-o' binding on the trunk for one
> month, and see how many (if any) complaints we get.
>
Perhaps replacing its binding with a message "The M-o key has been
experimentally unbound, please M-x report-emacs-bug if you need it" would
be even better?
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Experimentally unbind M-o on the trunk 2021-02-09 12:30 Experimentally unbind M-o on the trunk Gregory Heytings @ 2021-02-10 8:44 ` Alfred M. Szmidt 2021-02-10 14:54 ` Jean Louis 0 siblings, 1 reply; 85+ messages in thread From: Alfred M. Szmidt @ 2021-02-10 8:44 UTC (permalink / raw) To: Gregory Heytings; +Cc: larsi, emacs-devel If M-o is to become unbound, how does one center a line or a paragraph? Those are on M-o M-s and M-o M-S respectively. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Experimentally unbind M-o on the trunk 2021-02-10 8:44 ` Alfred M. Szmidt @ 2021-02-10 14:54 ` Jean Louis 2021-02-10 15:12 ` Alfred M. Szmidt 0 siblings, 1 reply; 85+ messages in thread From: Jean Louis @ 2021-02-10 14:54 UTC (permalink / raw) To: Alfred M. Szmidt; +Cc: Gregory Heytings, larsi, emacs-devel * Alfred M. Szmidt <ams@gnu.org> [2021-02-10 11:45]: > If M-o is to become unbound, how does one center a line or a > paragraph? Those are on M-o M-s and M-o M-S respectively. We have M-o as prefix and M-l to downcase the word. Maybe M-l could be made as a new prefix and then: M-l M-s could center the line M-l l could downcase the word then there is plethora of other options for M-l as prefix. Jean ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Experimentally unbind M-o on the trunk 2021-02-10 14:54 ` Jean Louis @ 2021-02-10 15:12 ` Alfred M. Szmidt 2021-02-10 15:45 ` Eli Zaretskii 0 siblings, 1 reply; 85+ messages in thread From: Alfred M. Szmidt @ 2021-02-10 15:12 UTC (permalink / raw) To: Jean Louis; +Cc: gregory, larsi, emacs-devel Sorry, I atleast have a hard time taking these suggestion to remap long standing keybindings randomly seriously, likewise suggestions that users should just resort to M-x or binding them themselves. Might as well unbind all they keys and have a wizard query the user the first time they start Emacs about what each interactive function should be bound too. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Experimentally unbind M-o on the trunk 2021-02-10 15:12 ` Alfred M. Szmidt @ 2021-02-10 15:45 ` Eli Zaretskii 2021-02-10 19:10 ` Matt Armstrong 0 siblings, 1 reply; 85+ messages in thread From: Eli Zaretskii @ 2021-02-10 15:45 UTC (permalink / raw) To: Alfred M. Szmidt; +Cc: gregory, larsi, bugs, emacs-devel > From: "Alfred M. Szmidt" <ams@gnu.org> > Date: Wed, 10 Feb 2021 10:12:20 -0500 > Cc: gregory@heytings.org, larsi@gnus.org, emacs-devel@gnu.org > > Sorry, I atleast have a hard time taking these suggestion to remap > long standing keybindings randomly seriously, likewise suggestions > that users should just resort to M-x or binding them themselves. Can you explain why you are so worried about Emacs changing the default key bindings? Given that it takes one line in your .emacs to restore any binding you care for, why argue so much about the defaults? This question also goes to everyone else in this long dispute who wants their precious key bindings preserved: why is such a long discussion needed when it is so easy to restore, in your init file, a binding you want preserved? ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Experimentally unbind M-o on the trunk 2021-02-10 15:45 ` Eli Zaretskii @ 2021-02-10 19:10 ` Matt Armstrong 2021-02-10 19:16 ` Lars Ingebrigtsen 0 siblings, 1 reply; 85+ messages in thread From: Matt Armstrong @ 2021-02-10 19:10 UTC (permalink / raw) To: Eli Zaretskii; +Cc: larsi, Alfred M. Szmidt, gregory, bugs, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: "Alfred M. Szmidt" <ams@gnu.org> >> Date: Wed, 10 Feb 2021 10:12:20 -0500 >> Cc: gregory@heytings.org, larsi@gnus.org, emacs-devel@gnu.org >> >> Sorry, I atleast have a hard time taking these suggestion to remap >> long standing keybindings randomly seriously, likewise suggestions >> that users should just resort to M-x or binding them themselves. > > Can you explain why you are so worried about Emacs changing the > default key bindings? Given that it takes one line in your .emacs to > restore any binding you care for, why argue so much about the > defaults? > > This question also goes to everyone else in this long dispute who > wants their precious key bindings preserved: why is such a long > discussion needed when it is so easy to restore, in your init file, a > binding you want preserved? I'd even take it up another level. Why are we satisfied with Emacs' current approach to exposing command based functionality to users? What we've got with Emacs today is a key binding resource exhaustion problem. But is moving bindings around the only way to address the problem? What if having a key binding was just one possible way to make a command easy and convenient to find and invoke. What if there were other equally good ways, and we all thought it would be strange to bind a precious key to a command if it were rarely used in practice? Case in point: if a command isn't bound to a key it doesn't show up in help, so there is this pressure to bind everything that could possibly be useful to some person some day to some key. What if instead help showed all the interactive commands provided by the mode? What if M-x were smarter about highlighting mode specific commands? Perhaps exploring these kinds of ideas would be useful. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Experimentally unbind M-o on the trunk 2021-02-10 19:10 ` Matt Armstrong @ 2021-02-10 19:16 ` Lars Ingebrigtsen 2021-02-11 2:50 ` Smarter M-x that filters on major-mode Stefan Kangas 0 siblings, 1 reply; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-10 19:16 UTC (permalink / raw) To: Matt Armstrong Cc: Eli Zaretskii, gregory, Alfred M. Szmidt, bugs, emacs-devel Matt Armstrong <matt@rfc20.org> writes: > What if instead help showed all the interactive commands provided by > the mode? What if M-x were smarter about highlighting mode specific > commands? It's been discussed before -- somebody just has to implement one of the various possibilities here. The problem is that commands are only tied very loosely to modes: (defun foo-thing () (interactive) ...) will make `M-x fTAB' show `foo-thing' even if it's useless outside of all other modes than `foo-mode'. Conversely, `C-h m' in `foo-mode' won't, as you mention, list `foo-thing' unless there's a binding for it. My suggestion is to introduce a new form: (defun foo-thing () (command foo-mode) ...) This would be just like `interactive', but will do the right thing in `M-x fTAB' and `C-h m' in modes derived from `foo-mode'. (It could also be a list of mode, of course, but that'd be more rare, is my guess.) A (declare (mode foo-mode)) form would also work, but it's a bit more verbose and noisy. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 85+ messages in thread
* Smarter M-x that filters on major-mode 2021-02-10 19:16 ` Lars Ingebrigtsen @ 2021-02-11 2:50 ` Stefan Kangas 2021-02-11 3:44 ` Stefan Monnier ` (3 more replies) 0 siblings, 4 replies; 85+ messages in thread From: Stefan Kangas @ 2021-02-11 2:50 UTC (permalink / raw) To: Lars Ingebrigtsen, Matt Armstrong Cc: Eli Zaretskii, emacs-devel, gregory, bugs, Alfred M. Szmidt 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. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-11 2:50 ` Smarter M-x that filters on major-mode Stefan Kangas @ 2021-02-11 3:44 ` Stefan Monnier 2021-02-11 5:02 ` Yuan Fu 2021-02-11 8:58 ` Lars Ingebrigtsen 2021-02-11 8:40 ` tomas ` (2 subsequent siblings) 3 siblings, 2 replies; 85+ messages in thread From: Stefan Monnier @ 2021-02-11 3:44 UTC (permalink / raw) To: Stefan Kangas Cc: bugs, Alfred M. Szmidt, emacs-devel, gregory, Matt Armstrong, Lars Ingebrigtsen, Eli Zaretskii > 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-11 3:44 ` Stefan Monnier @ 2021-02-11 5:02 ` Yuan Fu 2021-02-11 8:58 ` Lars Ingebrigtsen 1 sibling, 0 replies; 85+ messages in thread From: Yuan Fu @ 2021-02-11 5:02 UTC (permalink / raw) To: Stefan Monnier Cc: Jean Louis, Stefan Kangas, gregory, emacs-devel, Alfred M. Szmidt, Matt Armstrong, Lars Ingebrigtsen, Eli Zaretskii > 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-11 3:44 ` Stefan Monnier 2021-02-11 5:02 ` Yuan Fu @ 2021-02-11 8:58 ` Lars Ingebrigtsen 2021-02-11 11:00 ` Lars Ingebrigtsen 2021-02-11 14:38 ` Stefan Monnier 1 sibling, 2 replies; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-11 8:58 UTC (permalink / raw) To: Stefan Monnier Cc: bugs, Stefan Kangas, Alfred M. Szmidt, emacs-devel, gregory, Matt Armstrong, Eli Zaretskii 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-11 8:58 ` Lars Ingebrigtsen @ 2021-02-11 11:00 ` Lars Ingebrigtsen 2021-02-11 13:46 ` Lars Ingebrigtsen 2021-02-11 14:16 ` Eli Zaretskii 2021-02-11 14:38 ` Stefan Monnier 1 sibling, 2 replies; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-11 11:00 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-11 11:00 ` Lars Ingebrigtsen @ 2021-02-11 13:46 ` Lars Ingebrigtsen 2021-02-11 14:16 ` Eli Zaretskii 1 sibling, 0 replies; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-11 13:46 UTC (permalink / raw) To: Stefan Monnier; +Cc: Andrea Corallo, emacs-devel 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-11 11:00 ` Lars Ingebrigtsen 2021-02-11 13:46 ` Lars Ingebrigtsen @ 2021-02-11 14:16 ` Eli Zaretskii 2021-02-11 15:04 ` Lars Ingebrigtsen 1 sibling, 1 reply; 85+ messages in thread From: Eli Zaretskii @ 2021-02-11 14:16 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: monnier, emacs-devel > 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? ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-11 14:16 ` Eli Zaretskii @ 2021-02-11 15:04 ` Lars Ingebrigtsen 2021-02-11 16:05 ` Stefan Monnier 0 siblings, 1 reply; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-11 15:04 UTC (permalink / raw) To: Eli Zaretskii; +Cc: monnier, emacs-devel 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-11 15:04 ` Lars Ingebrigtsen @ 2021-02-11 16:05 ` Stefan Monnier 2021-02-11 16:13 ` Lars Ingebrigtsen 0 siblings, 1 reply; 85+ messages in thread From: Stefan Monnier @ 2021-02-11 16:05 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Eli Zaretskii, emacs-devel > 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-11 16:05 ` Stefan Monnier @ 2021-02-11 16:13 ` Lars Ingebrigtsen 2021-02-11 16:14 ` Lars Ingebrigtsen 2021-02-11 19:09 ` Óscar Fuentes 0 siblings, 2 replies; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-11 16:13 UTC (permalink / raw) To: Stefan Monnier; +Cc: Eli Zaretskii, emacs-devel 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-11 16:13 ` Lars Ingebrigtsen @ 2021-02-11 16:14 ` Lars Ingebrigtsen 2021-02-11 19:09 ` Óscar Fuentes 1 sibling, 0 replies; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-11 16:14 UTC (permalink / raw) To: Stefan Monnier; +Cc: Eli Zaretskii, emacs-devel 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-11 16:13 ` Lars Ingebrigtsen 2021-02-11 16:14 ` Lars Ingebrigtsen @ 2021-02-11 19:09 ` Óscar Fuentes 2021-02-11 19:52 ` Lars Ingebrigtsen 1 sibling, 1 reply; 85+ messages in thread From: Óscar Fuentes @ 2021-02-11 19:09 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-11 19:09 ` Óscar Fuentes @ 2021-02-11 19:52 ` Lars Ingebrigtsen 2021-02-11 20:39 ` Óscar Fuentes 0 siblings, 1 reply; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-11 19:52 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Ó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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-11 19:52 ` Lars Ingebrigtsen @ 2021-02-11 20:39 ` Óscar Fuentes 2021-02-11 21:08 ` Lars Ingebrigtsen 0 siblings, 1 reply; 85+ messages in thread From: Óscar Fuentes @ 2021-02-11 20:39 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-11 20:39 ` Óscar Fuentes @ 2021-02-11 21:08 ` Lars Ingebrigtsen 2021-02-11 22:22 ` Jose A. Ortega Ruiz 0 siblings, 1 reply; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-11 21:08 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Ó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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-11 21:08 ` Lars Ingebrigtsen @ 2021-02-11 22:22 ` Jose A. Ortega Ruiz 2021-02-12 9:32 ` Lars Ingebrigtsen 0 siblings, 1 reply; 85+ messages in thread From: Jose A. Ortega Ruiz @ 2021-02-11 22:22 UTC (permalink / raw) To: emacs-devel 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 -*- ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-11 22:22 ` Jose A. Ortega Ruiz @ 2021-02-12 9:32 ` Lars Ingebrigtsen 2021-02-12 16:18 ` jao 0 siblings, 1 reply; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-12 9:32 UTC (permalink / raw) To: Jose A. Ortega Ruiz; +Cc: emacs-devel "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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-12 9:32 ` Lars Ingebrigtsen @ 2021-02-12 16:18 ` jao 2021-02-12 17:05 ` Stefan Kangas ` (2 more replies) 0 siblings, 3 replies; 85+ messages in thread From: jao @ 2021-02-12 16:18 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-12 16:18 ` jao @ 2021-02-12 17:05 ` Stefan Kangas 2021-02-12 17:58 ` jao 2021-02-12 17:36 ` Stefan Monnier 2021-02-13 11:22 ` Lars Ingebrigtsen 2 siblings, 1 reply; 85+ messages in thread From: Stefan Kangas @ 2021-02-12 17:05 UTC (permalink / raw) To: jao, Lars Ingebrigtsen; +Cc: emacs-devel 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". ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-12 17:05 ` Stefan Kangas @ 2021-02-12 17:58 ` jao 0 siblings, 0 replies; 85+ messages in thread From: jao @ 2021-02-12 17:58 UTC (permalink / raw) To: Stefan Kangas; +Cc: Lars Ingebrigtsen, emacs-devel 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 :) ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-12 16:18 ` jao 2021-02-12 17:05 ` Stefan Kangas @ 2021-02-12 17:36 ` Stefan Monnier 2021-02-12 17:57 ` jao ` (2 more replies) 2021-02-13 11:22 ` Lars Ingebrigtsen 2 siblings, 3 replies; 85+ messages in thread From: Stefan Monnier @ 2021-02-12 17:36 UTC (permalink / raw) To: jao; +Cc: Lars Ingebrigtsen, emacs-devel 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. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-12 17:36 ` Stefan Monnier @ 2021-02-12 17:57 ` jao 2021-02-12 18:12 ` Dmitry Gutov 2021-02-13 11:28 ` Lars Ingebrigtsen 2 siblings, 0 replies; 85+ messages in thread From: jao @ 2021-02-12 17:57 UTC (permalink / raw) To: Stefan Monnier; +Cc: Lars Ingebrigtsen, emacs-devel 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. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-12 17:36 ` Stefan Monnier 2021-02-12 17:57 ` jao @ 2021-02-12 18:12 ` Dmitry Gutov 2021-02-12 18:16 ` Stefan Monnier 2021-02-13 11:28 ` Lars Ingebrigtsen 2 siblings, 1 reply; 85+ messages in thread From: Dmitry Gutov @ 2021-02-12 18:12 UTC (permalink / raw) To: Stefan Monnier, jao; +Cc: Lars Ingebrigtsen, emacs-devel 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. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-12 18:12 ` Dmitry Gutov @ 2021-02-12 18:16 ` Stefan Monnier 2021-02-12 23:58 ` Óscar Fuentes 0 siblings, 1 reply; 85+ messages in thread From: Stefan Monnier @ 2021-02-12 18:16 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Lars Ingebrigtsen, jao, emacs-devel >> 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-12 18:16 ` Stefan Monnier @ 2021-02-12 23:58 ` Óscar Fuentes 2021-02-13 11:33 ` Lars Ingebrigtsen 0 siblings, 1 reply; 85+ messages in thread From: Óscar Fuentes @ 2021-02-12 23:58 UTC (permalink / raw) To: emacs-devel 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... ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-12 23:58 ` Óscar Fuentes @ 2021-02-13 11:33 ` Lars Ingebrigtsen 0 siblings, 0 replies; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-13 11:33 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Ó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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-12 17:36 ` Stefan Monnier 2021-02-12 17:57 ` jao 2021-02-12 18:12 ` Dmitry Gutov @ 2021-02-13 11:28 ` Lars Ingebrigtsen 2021-02-13 11:30 ` Lars Ingebrigtsen 2021-02-14 2:40 ` [External] : " Drew Adams 2 siblings, 2 replies; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-13 11:28 UTC (permalink / raw) To: Stefan Monnier; +Cc: jao, emacs-devel 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-13 11:28 ` Lars Ingebrigtsen @ 2021-02-13 11:30 ` Lars Ingebrigtsen 2021-02-14 2:40 ` [External] : " Drew Adams 1 sibling, 0 replies; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-13 11:30 UTC (permalink / raw) To: Stefan Monnier; +Cc: jao, emacs-devel 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* RE: [External] : Re: Smarter M-x that filters on major-mode 2021-02-13 11:28 ` Lars Ingebrigtsen 2021-02-13 11:30 ` Lars Ingebrigtsen @ 2021-02-14 2:40 ` Drew Adams 2021-02-14 13:30 ` Lars Ingebrigtsen 1 sibling, 1 reply; 85+ messages in thread From: Drew Adams @ 2021-02-14 2:40 UTC (permalink / raw) To: Lars Ingebrigtsen, Stefan Monnier; +Cc: jao, emacs-devel@gnu.org > > There seems to be an assumption here that the defining info > > to hiding a command (or not) is the current major mode. > > > > While it's an important case, I think it'd be a mistake to design > > a feature that can only use such tests. There are many other useful > > conditions that one might like to test, such as the activation of the > > region, the existence of some other buffer, etc... My thoughts too. > Commands bound to modes cover 97% of the cases, > my stats dept. informs me, Really? Could you please post what's behind those stats? And maybe say just what you mean by "commands bound to modes". Do you mean commands whose only reasonable use is only within a given mode? How did you measure this? ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-14 2:40 ` [External] : " Drew Adams @ 2021-02-14 13:30 ` Lars Ingebrigtsen 2021-02-14 14:20 ` Basil L. Contovounesios 2021-02-14 15:20 ` Lars Ingebrigtsen 0 siblings, 2 replies; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-14 13:30 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-14 13:30 ` Lars Ingebrigtsen @ 2021-02-14 14:20 ` Basil L. Contovounesios 2021-02-14 14:23 ` Lars Ingebrigtsen 2021-02-14 15:20 ` Lars Ingebrigtsen 1 sibling, 1 reply; 85+ messages in thread From: Basil L. Contovounesios @ 2021-02-14 14:20 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-14 14:20 ` Basil L. Contovounesios @ 2021-02-14 14:23 ` Lars Ingebrigtsen 2021-02-14 14:32 ` Basil L. Contovounesios ` (4 more replies) 0 siblings, 5 replies; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-14 14:23 UTC (permalink / raw) To: Basil L. Contovounesios; +Cc: emacs-devel "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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-14 14:23 ` Lars Ingebrigtsen @ 2021-02-14 14:32 ` Basil L. Contovounesios 2021-02-14 14:45 ` Lars Ingebrigtsen 2021-02-14 15:00 ` Dmitry Gutov ` (3 subsequent siblings) 4 siblings, 1 reply; 85+ messages in thread From: Basil L. Contovounesios @ 2021-02-14 14:32 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-14 14:32 ` Basil L. Contovounesios @ 2021-02-14 14:45 ` Lars Ingebrigtsen 2021-02-15 18:16 ` Sean Whitton 0 siblings, 1 reply; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-14 14:45 UTC (permalink / raw) To: Basil L. Contovounesios; +Cc: emacs-devel "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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-14 14:45 ` Lars Ingebrigtsen @ 2021-02-15 18:16 ` Sean Whitton 0 siblings, 0 replies; 85+ messages in thread From: Sean Whitton @ 2021-02-15 18:16 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-14 14:23 ` Lars Ingebrigtsen 2021-02-14 14:32 ` Basil L. Contovounesios @ 2021-02-14 15:00 ` Dmitry Gutov 2021-02-14 15:03 ` Alan Mackenzie ` (2 subsequent siblings) 4 siblings, 0 replies; 85+ messages in thread From: Dmitry Gutov @ 2021-02-14 15:00 UTC (permalink / raw) To: Lars Ingebrigtsen, Basil L. Contovounesios; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-14 14:23 ` Lars Ingebrigtsen 2021-02-14 14:32 ` Basil L. Contovounesios 2021-02-14 15:00 ` Dmitry Gutov @ 2021-02-14 15:03 ` Alan Mackenzie 2021-02-14 16:11 ` Stefan Kangas ` (2 more replies) 2021-02-14 17:43 ` Juri Linkov 2021-02-15 2:49 ` Stefan Monnier 4 siblings, 3 replies; 85+ messages in thread From: Alan Mackenzie @ 2021-02-14 15:03 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Basil L. Contovounesios, emacs-devel 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). ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-14 15:03 ` Alan Mackenzie @ 2021-02-14 16:11 ` Stefan Kangas 2021-02-14 16:49 ` Alan Mackenzie 2021-02-14 16:57 ` Eli Zaretskii 2021-02-14 16:15 ` Óscar Fuentes 2021-02-14 16:55 ` Eli Zaretskii 2 siblings, 2 replies; 85+ messages in thread From: Stefan Kangas @ 2021-02-14 16:11 UTC (permalink / raw) To: Alan Mackenzie, Lars Ingebrigtsen; +Cc: Basil L. Contovounesios, emacs-devel 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. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-14 16:11 ` Stefan Kangas @ 2021-02-14 16:49 ` Alan Mackenzie 2021-02-14 23:33 ` Stefan Kangas 2021-02-14 16:57 ` Eli Zaretskii 1 sibling, 1 reply; 85+ messages in thread From: Alan Mackenzie @ 2021-02-14 16:49 UTC (permalink / raw) To: Stefan Kangas; +Cc: Basil L. Contovounesios, Lars Ingebrigtsen, emacs-devel 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). ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-14 16:49 ` Alan Mackenzie @ 2021-02-14 23:33 ` Stefan Kangas 2021-02-15 15:15 ` Alan Mackenzie 0 siblings, 1 reply; 85+ messages in thread From: Stefan Kangas @ 2021-02-14 23:33 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Basil L. Contovounesios, Lars Ingebrigtsen, emacs-devel 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. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-14 23:33 ` Stefan Kangas @ 2021-02-15 15:15 ` Alan Mackenzie 2021-02-16 17:07 ` Stefan Kangas 0 siblings, 1 reply; 85+ messages in thread From: Alan Mackenzie @ 2021-02-15 15:15 UTC (permalink / raw) To: Stefan Kangas; +Cc: Basil L. Contovounesios, Lars Ingebrigtsen, emacs-devel 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). ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-15 15:15 ` Alan Mackenzie @ 2021-02-16 17:07 ` Stefan Kangas 0 siblings, 0 replies; 85+ messages in thread From: Stefan Kangas @ 2021-02-16 17:07 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Basil L. Contovounesios, Lars Ingebrigtsen, emacs-devel 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. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-14 16:11 ` Stefan Kangas 2021-02-14 16:49 ` Alan Mackenzie @ 2021-02-14 16:57 ` Eli Zaretskii 2021-02-14 17:10 ` Lars Ingebrigtsen 1 sibling, 1 reply; 85+ messages in thread From: Eli Zaretskii @ 2021-02-14 16:57 UTC (permalink / raw) To: Stefan Kangas; +Cc: contovob, acm, larsi, emacs-devel > 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. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-14 16:57 ` Eli Zaretskii @ 2021-02-14 17:10 ` Lars Ingebrigtsen 2021-02-14 17:59 ` Basil L. Contovounesios 0 siblings, 1 reply; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-14 17:10 UTC (permalink / raw) To: Eli Zaretskii; +Cc: contovob, acm, Stefan Kangas, emacs-devel 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-14 17:10 ` Lars Ingebrigtsen @ 2021-02-14 17:59 ` Basil L. Contovounesios 2021-02-14 18:02 ` Lars Ingebrigtsen 0 siblings, 1 reply; 85+ messages in thread From: Basil L. Contovounesios @ 2021-02-14 17:59 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: acm, Eli Zaretskii, Stefan Kangas, emacs-devel 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-14 17:59 ` Basil L. Contovounesios @ 2021-02-14 18:02 ` Lars Ingebrigtsen 2021-02-14 18:44 ` Basil L. Contovounesios 0 siblings, 1 reply; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-14 18:02 UTC (permalink / raw) To: Basil L. Contovounesios; +Cc: acm, Eli Zaretskii, Stefan Kangas, emacs-devel "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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-14 18:02 ` Lars Ingebrigtsen @ 2021-02-14 18:44 ` Basil L. Contovounesios 2021-02-14 18:53 ` Lars Ingebrigtsen 0 siblings, 1 reply; 85+ messages in thread From: Basil L. Contovounesios @ 2021-02-14 18:44 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: acm, Eli Zaretskii, Stefan Kangas, emacs-devel 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-14 18:44 ` Basil L. Contovounesios @ 2021-02-14 18:53 ` Lars Ingebrigtsen 2021-02-14 19:01 ` Basil L. Contovounesios 0 siblings, 1 reply; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-14 18:53 UTC (permalink / raw) To: Basil L. Contovounesios; +Cc: acm, Eli Zaretskii, Stefan Kangas, emacs-devel "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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-14 18:53 ` Lars Ingebrigtsen @ 2021-02-14 19:01 ` Basil L. Contovounesios 2021-02-15 2:59 ` Lars Ingebrigtsen 0 siblings, 1 reply; 85+ messages in thread From: Basil L. Contovounesios @ 2021-02-14 19:01 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: acm, Eli Zaretskii, Stefan Kangas, emacs-devel 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-14 19:01 ` Basil L. Contovounesios @ 2021-02-15 2:59 ` Lars Ingebrigtsen 2021-02-15 12:34 ` Eric S Fraga 0 siblings, 1 reply; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-15 2:59 UTC (permalink / raw) To: Basil L. Contovounesios; +Cc: acm, Eli Zaretskii, Stefan Kangas, emacs-devel "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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-15 2:59 ` Lars Ingebrigtsen @ 2021-02-15 12:34 ` Eric S Fraga 0 siblings, 0 replies; 85+ messages in thread From: Eric S Fraga @ 2021-02-15 12:34 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-14 15:03 ` Alan Mackenzie 2021-02-14 16:11 ` Stefan Kangas @ 2021-02-14 16:15 ` Óscar Fuentes 2021-02-14 16:55 ` Eli Zaretskii 2 siblings, 0 replies; 85+ messages in thread From: Óscar Fuentes @ 2021-02-14 16:15 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-14 15:03 ` Alan Mackenzie 2021-02-14 16:11 ` Stefan Kangas 2021-02-14 16:15 ` Óscar Fuentes @ 2021-02-14 16:55 ` Eli Zaretskii 2 siblings, 0 replies; 85+ messages in thread From: Eli Zaretskii @ 2021-02-14 16:55 UTC (permalink / raw) To: Alan Mackenzie; +Cc: contovob, larsi, emacs-devel > 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? ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-14 14:23 ` Lars Ingebrigtsen ` (2 preceding siblings ...) 2021-02-14 15:03 ` Alan Mackenzie @ 2021-02-14 17:43 ` Juri Linkov 2021-02-14 18:00 ` Lars Ingebrigtsen 2021-02-15 2:49 ` Stefan Monnier 4 siblings, 1 reply; 85+ messages in thread From: Juri Linkov @ 2021-02-14 17:43 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Basil L. Contovounesios, emacs-devel >> 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)) ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-14 17:43 ` Juri Linkov @ 2021-02-14 18:00 ` Lars Ingebrigtsen 0 siblings, 0 replies; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-14 18:00 UTC (permalink / raw) To: Juri Linkov; +Cc: Basil L. Contovounesios, emacs-devel 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-14 14:23 ` Lars Ingebrigtsen ` (3 preceding siblings ...) 2021-02-14 17:43 ` Juri Linkov @ 2021-02-15 2:49 ` Stefan Monnier 2021-02-15 3:09 ` Lars Ingebrigtsen 4 siblings, 1 reply; 85+ messages in thread From: Stefan Monnier @ 2021-02-15 2:49 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Basil L. Contovounesios, emacs-devel > 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-15 2:49 ` Stefan Monnier @ 2021-02-15 3:09 ` Lars Ingebrigtsen 0 siblings, 0 replies; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-15 3:09 UTC (permalink / raw) To: Stefan Monnier; +Cc: Basil L. Contovounesios, emacs-devel 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-14 13:30 ` Lars Ingebrigtsen 2021-02-14 14:20 ` Basil L. Contovounesios @ 2021-02-14 15:20 ` Lars Ingebrigtsen 1 sibling, 0 replies; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-14 15:20 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-12 16:18 ` jao 2021-02-12 17:05 ` Stefan Kangas 2021-02-12 17:36 ` Stefan Monnier @ 2021-02-13 11:22 ` Lars Ingebrigtsen 2 siblings, 0 replies; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-13 11:22 UTC (permalink / raw) To: jao; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-11 8:58 ` Lars Ingebrigtsen 2021-02-11 11:00 ` Lars Ingebrigtsen @ 2021-02-11 14:38 ` Stefan Monnier 2021-02-11 15:29 ` Lars Ingebrigtsen ` (3 more replies) 1 sibling, 4 replies; 85+ messages in thread From: Stefan Monnier @ 2021-02-11 14:38 UTC (permalink / raw) To: Lars Ingebrigtsen Cc: bugs, Stefan Kangas, Alfred M. Szmidt, emacs-devel, gregory, Matt Armstrong, Eli Zaretskii > 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-11 14:38 ` Stefan Monnier @ 2021-02-11 15:29 ` Lars Ingebrigtsen 2021-02-11 17:29 ` Lars Ingebrigtsen ` (2 subsequent siblings) 3 siblings, 0 replies; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-11 15:29 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-11 14:38 ` Stefan Monnier 2021-02-11 15:29 ` Lars Ingebrigtsen @ 2021-02-11 17:29 ` Lars Ingebrigtsen 2021-02-11 17:43 ` Lars Ingebrigtsen 2021-02-11 18:57 ` Lars Ingebrigtsen 2021-02-12 9:59 ` Lars Ingebrigtsen 3 siblings, 1 reply; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-11 17:29 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-11 17:29 ` Lars Ingebrigtsen @ 2021-02-11 17:43 ` Lars Ingebrigtsen 0 siblings, 0 replies; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-11 17:43 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-11 14:38 ` Stefan Monnier 2021-02-11 15:29 ` Lars Ingebrigtsen 2021-02-11 17:29 ` Lars Ingebrigtsen @ 2021-02-11 18:57 ` Lars Ingebrigtsen 2021-02-11 21:12 ` Lars Ingebrigtsen 2021-02-12 9:59 ` Lars Ingebrigtsen 3 siblings, 1 reply; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-11 18:57 UTC (permalink / raw) To: Stefan Monnier Cc: bugs, Stefan Kangas, gregory, emacs-devel, Alfred M. Szmidt, Matt Armstrong, Eli Zaretskii 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-11 18:57 ` Lars Ingebrigtsen @ 2021-02-11 21:12 ` Lars Ingebrigtsen 2021-02-11 23:21 ` Stefan Monnier 0 siblings, 1 reply; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-11 21:12 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-11 21:12 ` Lars Ingebrigtsen @ 2021-02-11 23:21 ` Stefan Monnier 2021-02-12 8:59 ` Lars Ingebrigtsen 0 siblings, 1 reply; 85+ messages in thread From: Stefan Monnier @ 2021-02-11 23:21 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-11 23:21 ` Stefan Monnier @ 2021-02-12 8:59 ` Lars Ingebrigtsen 2021-02-12 13:39 ` Stefan Monnier 0 siblings, 1 reply; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-12 8:59 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-12 8:59 ` Lars Ingebrigtsen @ 2021-02-12 13:39 ` Stefan Monnier 2021-02-13 11:43 ` Lars Ingebrigtsen 0 siblings, 1 reply; 85+ messages in thread From: Stefan Monnier @ 2021-02-12 13:39 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: emacs-devel >>> 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-12 13:39 ` Stefan Monnier @ 2021-02-13 11:43 ` Lars Ingebrigtsen 0 siblings, 0 replies; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-13 11:43 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-11 14:38 ` Stefan Monnier ` (2 preceding siblings ...) 2021-02-11 18:57 ` Lars Ingebrigtsen @ 2021-02-12 9:59 ` Lars Ingebrigtsen 2021-02-12 10:29 ` Lars Ingebrigtsen 3 siblings, 1 reply; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-12 9:59 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-12 9:59 ` Lars Ingebrigtsen @ 2021-02-12 10:29 ` Lars Ingebrigtsen 2021-02-12 10:47 ` Robert Pluim 0 siblings, 1 reply; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-12 10:29 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-12 10:29 ` Lars Ingebrigtsen @ 2021-02-12 10:47 ` Robert Pluim 2021-02-12 11:19 ` Lars Ingebrigtsen 0 siblings, 1 reply; 85+ messages in thread From: Robert Pluim @ 2021-02-12 10:47 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Stefan Monnier, emacs-devel >>>>> 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-12 10:47 ` Robert Pluim @ 2021-02-12 11:19 ` Lars Ingebrigtsen 2021-02-12 13:40 ` Robert Pluim 0 siblings, 1 reply; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-12 11:19 UTC (permalink / raw) To: Robert Pluim; +Cc: Stefan Monnier, emacs-devel 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-12 11:19 ` Lars Ingebrigtsen @ 2021-02-12 13:40 ` Robert Pluim 2021-02-13 11:44 ` Lars Ingebrigtsen 0 siblings, 1 reply; 85+ messages in thread From: Robert Pluim @ 2021-02-12 13:40 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Stefan Monnier, emacs-devel >>>>> 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-12 13:40 ` Robert Pluim @ 2021-02-13 11:44 ` Lars Ingebrigtsen 0 siblings, 0 replies; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-13 11:44 UTC (permalink / raw) To: Robert Pluim; +Cc: Stefan Monnier, emacs-devel 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-11 2:50 ` Smarter M-x that filters on major-mode Stefan Kangas 2021-02-11 3:44 ` Stefan Monnier @ 2021-02-11 8:40 ` tomas 2021-02-11 19:03 ` Óscar Fuentes 2021-02-12 7:06 ` Jean Louis 2021-02-11 8:53 ` Lars Ingebrigtsen 2021-02-12 16:39 ` Basil L. Contovounesios 3 siblings, 2 replies; 85+ messages in thread From: tomas @ 2021-02-11 8:40 UTC (permalink / raw) To: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-11 8:40 ` tomas @ 2021-02-11 19:03 ` Óscar Fuentes 2021-02-11 20:05 ` Eli Zaretskii 2021-02-12 7:06 ` Jean Louis 1 sibling, 1 reply; 85+ messages in thread From: Óscar Fuentes @ 2021-02-11 19:03 UTC (permalink / raw) To: emacs-devel <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. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-11 19:03 ` Óscar Fuentes @ 2021-02-11 20:05 ` Eli Zaretskii 2021-02-11 20:11 ` tomas 2021-02-11 20:12 ` Lars Ingebrigtsen 0 siblings, 2 replies; 85+ messages in thread From: Eli Zaretskii @ 2021-02-11 20:05 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-11 20:05 ` Eli Zaretskii @ 2021-02-11 20:11 ` tomas 2021-02-11 20:12 ` Lars Ingebrigtsen 1 sibling, 0 replies; 85+ messages in thread From: tomas @ 2021-02-11 20:11 UTC (permalink / raw) To: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-11 20:05 ` Eli Zaretskii 2021-02-11 20:11 ` tomas @ 2021-02-11 20:12 ` Lars Ingebrigtsen 1 sibling, 0 replies; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-11 20:12 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Óscar Fuentes, emacs-devel 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-11 8:40 ` tomas 2021-02-11 19:03 ` Óscar Fuentes @ 2021-02-12 7:06 ` Jean Louis 1 sibling, 0 replies; 85+ messages in thread From: Jean Louis @ 2021-02-12 7:06 UTC (permalink / raw) To: tomas; +Cc: emacs-devel * 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-11 2:50 ` Smarter M-x that filters on major-mode Stefan Kangas 2021-02-11 3:44 ` Stefan Monnier 2021-02-11 8:40 ` tomas @ 2021-02-11 8:53 ` Lars Ingebrigtsen 2021-02-12 16:39 ` Basil L. Contovounesios 3 siblings, 0 replies; 85+ messages in thread From: Lars Ingebrigtsen @ 2021-02-11 8:53 UTC (permalink / raw) To: Stefan Kangas Cc: bugs, Alfred M. Szmidt, emacs-devel, gregory, Matt Armstrong, Eli Zaretskii 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-11 2:50 ` Smarter M-x that filters on major-mode Stefan Kangas ` (2 preceding siblings ...) 2021-02-11 8:53 ` Lars Ingebrigtsen @ 2021-02-12 16:39 ` Basil L. Contovounesios 2021-02-12 17:20 ` Stefan Kangas 3 siblings, 1 reply; 85+ messages in thread From: Basil L. Contovounesios @ 2021-02-12 16:39 UTC (permalink / raw) To: Stefan Kangas Cc: bugs, Alfred M. Szmidt, emacs-devel, gregory, Matt Armstrong, Lars Ingebrigtsen, Eli Zaretskii 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-12 16:39 ` Basil L. Contovounesios @ 2021-02-12 17:20 ` Stefan Kangas 2021-02-12 17:56 ` Basil L. Contovounesios 0 siblings, 1 reply; 85+ messages in thread From: Stefan Kangas @ 2021-02-12 17:20 UTC (permalink / raw) To: Basil L. Contovounesios Cc: bugs, Alfred M. Szmidt, emacs-devel, gregory, Matt Armstrong, Lars Ingebrigtsen, Eli Zaretskii "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. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Smarter M-x that filters on major-mode 2021-02-12 17:20 ` Stefan Kangas @ 2021-02-12 17:56 ` Basil L. Contovounesios 0 siblings, 0 replies; 85+ messages in thread From: Basil L. Contovounesios @ 2021-02-12 17:56 UTC (permalink / raw) To: Stefan Kangas Cc: bugs, Alfred M. Szmidt, emacs-devel, gregory, Matt Armstrong, Lars Ingebrigtsen, Eli Zaretskii 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
end of thread, other threads:[~2021-02-16 17:07 UTC | newest] Thread overview: 85+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2021-02-14 23:54 Smarter M-x that filters on major-mode Boruch Baum -- strict thread matches above, loose matches on Subject: below -- 2021-02-09 12:30 Experimentally unbind M-o on the trunk Gregory Heytings 2021-02-10 8:44 ` Alfred M. Szmidt 2021-02-10 14:54 ` Jean Louis 2021-02-10 15:12 ` Alfred M. Szmidt 2021-02-10 15:45 ` Eli Zaretskii 2021-02-10 19:10 ` Matt Armstrong 2021-02-10 19:16 ` Lars Ingebrigtsen 2021-02-11 2:50 ` Smarter M-x that filters on major-mode Stefan Kangas 2021-02-11 3:44 ` Stefan Monnier 2021-02-11 5:02 ` Yuan Fu 2021-02-11 8:58 ` Lars Ingebrigtsen 2021-02-11 11:00 ` Lars Ingebrigtsen 2021-02-11 13:46 ` Lars Ingebrigtsen 2021-02-11 14:16 ` Eli Zaretskii 2021-02-11 15:04 ` Lars Ingebrigtsen 2021-02-11 16:05 ` Stefan Monnier 2021-02-11 16:13 ` Lars Ingebrigtsen 2021-02-11 16:14 ` Lars Ingebrigtsen 2021-02-11 19:09 ` Óscar Fuentes 2021-02-11 19:52 ` Lars Ingebrigtsen 2021-02-11 20:39 ` Óscar Fuentes 2021-02-11 21:08 ` Lars Ingebrigtsen 2021-02-11 22:22 ` Jose A. Ortega Ruiz 2021-02-12 9:32 ` Lars Ingebrigtsen 2021-02-12 16:18 ` jao 2021-02-12 17:05 ` Stefan Kangas 2021-02-12 17:58 ` jao 2021-02-12 17:36 ` Stefan Monnier 2021-02-12 17:57 ` jao 2021-02-12 18:12 ` Dmitry Gutov 2021-02-12 18:16 ` Stefan Monnier 2021-02-12 23:58 ` Óscar Fuentes 2021-02-13 11:33 ` Lars Ingebrigtsen 2021-02-13 11:28 ` Lars Ingebrigtsen 2021-02-13 11:30 ` Lars Ingebrigtsen 2021-02-14 2:40 ` [External] : " Drew Adams 2021-02-14 13:30 ` Lars Ingebrigtsen 2021-02-14 14:20 ` Basil L. Contovounesios 2021-02-14 14:23 ` Lars Ingebrigtsen 2021-02-14 14:32 ` Basil L. Contovounesios 2021-02-14 14:45 ` Lars Ingebrigtsen 2021-02-15 18:16 ` Sean Whitton 2021-02-14 15:00 ` Dmitry Gutov 2021-02-14 15:03 ` Alan Mackenzie 2021-02-14 16:11 ` Stefan Kangas 2021-02-14 16:49 ` Alan Mackenzie 2021-02-14 23:33 ` Stefan Kangas 2021-02-15 15:15 ` Alan Mackenzie 2021-02-16 17:07 ` Stefan Kangas 2021-02-14 16:57 ` Eli Zaretskii 2021-02-14 17:10 ` Lars Ingebrigtsen 2021-02-14 17:59 ` Basil L. Contovounesios 2021-02-14 18:02 ` Lars Ingebrigtsen 2021-02-14 18:44 ` Basil L. Contovounesios 2021-02-14 18:53 ` Lars Ingebrigtsen 2021-02-14 19:01 ` Basil L. Contovounesios 2021-02-15 2:59 ` Lars Ingebrigtsen 2021-02-15 12:34 ` Eric S Fraga 2021-02-14 16:15 ` Óscar Fuentes 2021-02-14 16:55 ` Eli Zaretskii 2021-02-14 17:43 ` Juri Linkov 2021-02-14 18:00 ` Lars Ingebrigtsen 2021-02-15 2:49 ` Stefan Monnier 2021-02-15 3:09 ` Lars Ingebrigtsen 2021-02-14 15:20 ` Lars Ingebrigtsen 2021-02-13 11:22 ` Lars Ingebrigtsen 2021-02-11 14:38 ` Stefan Monnier 2021-02-11 15:29 ` Lars Ingebrigtsen 2021-02-11 17:29 ` Lars Ingebrigtsen 2021-02-11 17:43 ` Lars Ingebrigtsen 2021-02-11 18:57 ` Lars Ingebrigtsen 2021-02-11 21:12 ` Lars Ingebrigtsen 2021-02-11 23:21 ` Stefan Monnier 2021-02-12 8:59 ` Lars Ingebrigtsen 2021-02-12 13:39 ` Stefan Monnier 2021-02-13 11:43 ` Lars Ingebrigtsen 2021-02-12 9:59 ` Lars Ingebrigtsen 2021-02-12 10:29 ` Lars Ingebrigtsen 2021-02-12 10:47 ` Robert Pluim 2021-02-12 11:19 ` Lars Ingebrigtsen 2021-02-12 13:40 ` Robert Pluim 2021-02-13 11:44 ` Lars Ingebrigtsen 2021-02-11 8:40 ` tomas 2021-02-11 19:03 ` Óscar Fuentes 2021-02-11 20:05 ` Eli Zaretskii 2021-02-11 20:11 ` tomas 2021-02-11 20:12 ` Lars Ingebrigtsen 2021-02-12 7:06 ` Jean Louis 2021-02-11 8:53 ` Lars Ingebrigtsen 2021-02-12 16:39 ` Basil L. Contovounesios 2021-02-12 17:20 ` Stefan Kangas 2021-02-12 17:56 ` Basil L. Contovounesios
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.