Ordering of command completions

Ordering of command completions

[Tom]

Just a quick thought: various modes have lots of keybindings and
often I use M-x to invoke commands of unfamiliar or rarely used
modes, because I don't always know the relevant keybindings. Of
course, I can use the prefix of the mode when completing, but I
may not know it and it may not be obvious depending on the
mode. It occured to me that M-x, when showing completions, could
list command matches from the current major mode first, then from
the minor modes and then the rest of the commands.

It could improve M-x usability and help with the discoverability
of commands in the active modes, because commands relevant to the
current context would be listed first, instead of everything in a
huge alphabetical list.

Re: Ordering of command completions

[Lars Magne Ingebrigtsen]

Tom <adatgyujto@gmail.com> writes:

> Just a quick thought: various modes have lots of keybindings and
> often I use M-x to invoke commands of unfamiliar or rarely used
> modes, because I don't always know the relevant keybindings. Of
> course, I can use the prefix of the mode when completing, but I
> may not know it and it may not be obvious depending on the
> mode. It occured to me that M-x, when showing completions, could
> list command matches from the current major mode first, then from
> the minor modes and then the rest of the commands.

By looking at the commands bound in the active keymaps?  Yes, that would
help.

We discussed the opposite problem a while ago -- excluding commands that
only make sense in a specific mode from turning up when doing command
completion.  For instance, if you're in the *scratch* buffer, you never
want the `message-send-and-exit' command.

During the last discussion, we touched on introducing a new form that
would explicitly say what mode a commands belongs to.  (Some commands
are applicable generally; most are related to a specific mode.)  So
something like

(defun message-send-and-exit ()
  "Doc string."
  (command message-mode "P")
  ...)

where `command' is just like `interactive', only that it takes a mode
name (or a list of mode names) that says "where it belongs".

The main problem with that approach is that it wouldn't really work for
out-of-tree packages, since introducing something like that requires
Emacs Lisp engine level changes, I think.

But if we had this mechanism, then `M-x m<TAB>' would only complete to
things that are potentially useful in the current buffer (or globally),
which would be very nice.

Other, less intrusive approaches (that is, that could be used out of
tree by including legacy macros) would be

(defcommand message-send-and-exit ()
  "Doc string."
  (command message-mode "P")
  ...)

where out-of-tree `defcommand' would be a macro that just transforms
`command' into `interactive'.

Or even more ugly, but even less intrusive for out-of-tree use, by using
a special comment cookie that would just the appropriate modes:

;;;##!message-mode
(defun message-send-and-exit ()
  "Doc string."
  (interactive "P")
  ...)

And probably other approaches...

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

Re: Ordering of command completions

[Andreas Schwab]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> (defun message-send-and-exit ()
>   "Doc string."
>   (command message-mode "P")
>   ...)
>
> where `command' is just like `interactive', only that it takes a mode
> name (or a list of mode names) that says "where it belongs".
>
> The main problem with that approach is that it wouldn't really work for
> out-of-tree packages, since introducing something like that requires
> Emacs Lisp engine level changes, I think.

Why do you need to replace interactive?  There is already a fitting
place: declare.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Ordering of command completions

[Lars Magne Ingebrigtsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Why do you need to replace interactive?  There is already a fitting
> place: declare.

That's a good idea.

(defun message-send-and-exit ()
  "Doc string."
  (declare (mode message-mode))
  (interactive "P")
  ...)

I assume Emacs ignore `declare' statements it doesn't know about?

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

Re: Ordering of command completions

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I assume Emacs ignore `declare' statements it doesn't know about?

The `declare' itself is harmless, but it would result in these being
spewed by virtually all interactive commands in out-of-tree builds:

Compiling net/eww.el
Warning: Unknown defun property `mode' in eww-copy-page-url
Wrote /home/larsi/src/emacs/trunk/lisp/net/eww.elc

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

Re: Ordering of command completions

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> I assume Emacs ignore `declare' statements it doesn't know about?
>
> The `declare' itself is harmless, but it would result in these being
> spewed by virtually all interactive commands in out-of-tree builds:
>
> Compiling net/eww.el
> Warning: Unknown defun property `mode' in eww-copy-page-url
> Wrote /home/larsi/src/emacs/trunk/lisp/net/eww.elc

This turns out not to be a problem.

Out of tree packages that has this markup can just add it to
`defun-declarations-alist' in a compat function, I think.

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

Re: Ordering of command completions

[Lars Magne Ingebrigtsen]

I've done ten minutes of exploratory hacking to see whether it would be
a lot of work to get this to work.  The `declare' solution turns out to
be rather trivial, apparently.

The patch below is all that's needed to add a new `declare' form.  And
then, after marking some stuff up, we just have to make the `M-x'
completion function examine the `mode' `function-get' value, and compare
it to the current modes in effect.

So if we decide to do something like this, getting the framework in
place is very little work.  Annotating all of Emacs is a bit larger
(ahem), but it can be done gradually, and `M-x TAB' would work a bit
better each week...

diff --git a/lisp/emacs-lisp/byte-run.el b/lisp/emacs-lisp/byte-run.el
index 8bf63ea..098f1c4 100644
--- a/lisp/emacs-lisp/byte-run.el
+++ b/lisp/emacs-lisp/byte-run.el
@@ -105,6 +105,11 @@ The return value of this function is not used."
                    ''pure (list 'quote val)))
          "If non-nil, the compiler can replace calls with their return value.
 This may shift errors from run-time to compile-time.")
+   (list 'mode
+         #'(lambda (f _args val)
+             (list 'function-put (list 'quote f)
+                   ''mode (list 'quote val)))
+         "If non-nil, this command belongs in a specific mode, or a list of modes.")
    (list 'side-effect-free
          #'(lambda (f _args val)
              (list 'function-put (list 'quote f)

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

Autoload cookies (was: Ordering of command completions)

[Lars Magne Ingebrigtsen]

Speaking of `declare', I've always found the autoload cookie thing a bit
odd.  Putting functionality into comments is kinda hacky.

What about a new (declare (autoload t)) defun form or something?

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

Re: Autoload cookies

[Daniel Colascione]

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

On 12/07/2014 02:00 PM, Lars Magne Ingebrigtsen wrote:
> Speaking of `declare', I've always found the autoload cookie thing a bit
> odd.  Putting functionality into comments is kinda hacky.
> 
> What about a new (declare (autoload t)) defun form or something?

But you can autoload things that aren't function definitions, like
keybindings or auto-mode-alist modifications. I think the current scheme
is fine, but if we had to use something more lispy, I'd opt for a
top-level with-autoload macro. (Or would that be
emacs-core-eval-with-autoload?)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Autoload cookies

[Lars Magne Ingebrigtsen]

Daniel Colascione <dancol@dancol.org> writes:

> On 12/07/2014 02:00 PM, Lars Magne Ingebrigtsen wrote:
>> Speaking of `declare', I've always found the autoload cookie thing a bit
>> odd.  Putting functionality into comments is kinda hacky.
>> 
>> What about a new (declare (autoload t)) defun form or something?
>
> But you can autoload things that aren't function definitions, like
> keybindings or auto-mode-alist modifications.

Ah, that's true.  I had forgotten...

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

Re: Autoload cookies

[Andreas Schwab]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> What about a new (declare (autoload t)) defun form or something?

autoload isn't only about functions, you can put arbitrary sexps into
autoloads.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Autoload cookies (was: Ordering of command completions)

[Artur Malabarba]

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

On 7 Dec 2014 20:00, "Lars Magne Ingebrigtsen" <larsi@gnus.org> wrote:
>
> Speaking of `declare', I've always found the autoload cookie thing a bit
> odd.  Putting functionality into comments is kinda hacky.
>
> What about a new (declare (autoload t)) defun form or something?

I'd love that (it would have made Names.el a lot easier), but the declare
form is only for defun and defmacro, while the autoload cookies go on
anything.

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

Re: Ordering of command completions

[Óscar Fuentes]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I've done ten minutes of exploratory hacking to see whether it would be
> a lot of work to get this to work.  The `declare' solution turns out to
> be rather trivial, apparently.

Good.

> The patch below is all that's needed to add a new `declare' form.  And
> then, after marking some stuff up, we just have to make the `M-x'
> completion function examine the `mode' `function-get' value, and compare
> it to the current modes in effect.

A sorted array of pairs of symbols, perhaps? (<fn, mode>, or the
reverse, <mode, fn>, with `mode' being `nil' when the function is not
restricted.)

> So if we decide to do something like this, getting the framework in
> place is very little work.  Annotating all of Emacs is a bit larger
> (ahem), but it can be done gradually, and `M-x TAB' would work a bit
> better each week...

Annotating the functions is no small task, indeed. There are quite a few
traps. However, my experience with ido+flx convinced me about the
potential value of an effective M-x which, for commands that you use a
few times a day at most, requires far less cognitive load than using its
keybindings (when they have one) or M-x with the default completion
system.

[snip]

Re: Ordering of command completions

[Lars Magne Ingebrigtsen]

And this wouldn't necessarily be just about `M-x'.  Once in a while a
user executes a command that's meant for a totally different mode, and
then all the text disappears from the buffer and the user is sad.  If
the user manages to type `M-x message-send-and-exit' without TAB
completion, Emacs could then say "This command is for message-mode, and
this is a text-mode buffer.  Really execute?" or something.

I remember some bug reports along those lines over the years...

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

Re: Ordering of command completions

[Artur Malabarba]

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

> And this wouldn't necessarily be just about `M-x'.  Once in a while a
> user executes a command that's meant for a totally different mode, and
> then all the text disappears from the buffer and the user is sad.  If
> the user manages to type `M-x message-send-and-exit' without TAB
> completion, Emacs could then say "This command is for message-mode, and
> this is a text-mode buffer.  Really execute?" or something.
>

I was thinking along the same lines. package.el, for instance, is full of
commands which throw errors if not in package-mode. It would be useful if
this could be built-in by declaring the mode.

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

Re: Ordering of command completions

[Artur Malabarba]

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

> It would be useful if this could be built-in by declaring the mode.

Here I meant some sort of sanity check, like suggested by Lars. Not
necessarily an immediate error.

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

Re: Ordering of command completions

[Óscar Fuentes]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> We discussed the opposite problem a while ago -- excluding commands that
> only make sense in a specific mode from turning up when doing command
> completion.  For instance, if you're in the *scratch* buffer, you never
> want the `message-send-and-exit' command.
>
> During the last discussion, we touched on introducing a new form that
> would explicitly say what mode a commands belongs to.  (Some commands
> are applicable generally; most are related to a specific mode.)  So
> something like
>
> (defun message-send-and-exit ()
>   "Doc string."
>   (command message-mode "P")
>   ...)
>
> where `command' is just like `interactive', only that it takes a mode
> name (or a list of mode names) that says "where it belongs".

That's ok, but it is also very handy to have a global statement saying
"all the definitions on this file are bound to `message-mode' unless
the contrary is explicitly stated."

Consider Gnus, for instance. It has lots of stuff that only makes sense
within a Gnus buffer, but it has just a few "entry points" that are
intended to be used from any context. Having file-level statements would
save a lot of work.

The schema should work for all definitions that target the user, not
just interactive defuns. defcustoms, for instance. Hence, I'm not sure
that the `declare' approach mentioned on other message is appropriate.

A cookie-based approach seems more effective. The cookie affects the
definitions that follow it until a new cookie is found.

> The main problem with that approach is that it wouldn't really work for
> out-of-tree packages, since introducing something like that requires
> Emacs Lisp engine level changes, I think.

This is a lesser problem, because the vast majority of noise on M-x
comes from packages distributed with Emacs.

> But if we had this mechanism, then `M-x m<TAB>' would only complete to
> things that are potentially useful in the current buffer (or globally),
> which would be very nice.

Yes, and with the right completing engine M-x comes to be much more
effective on terms of efficiency and discoverability.

BTW, I still volunteer to do the foot job (annotating the files and/or
definitions) if a more knowledgeable hacker implements the feature.
<wink>

[snip]

RE: Ordering of command completions

[Drew Adams]

> the vast majority of noise on M-x comes from packages
> distributed with Emacs.

Just what noise are we talking about?

Are you referring to the fact that there can be many commands
that match your minibuffer input?  If so, then the answer
(IMHO) is better completion behavior.  Packages such as
Icicles and Helm let you narrow things down quickly.

> > But if we had this mechanism, then `M-x m<TAB>' would only
> > complete to things that are potentially useful in the current
> > buffer (or globally), which would be very nice.

OK, but it might be better to put that the other way around.
Emacs should exclude only candidates that it is *sure* are
not appropriate in the current context (which might involve
more than which buffer is current).

Certainly any command that is bound to a key sequence that
is available in the current context should be a candidate.
(That's a minimum.)
 
> Yes, and with the right completing engine M-x comes to be
> much more effective on terms of efficiency and discoverability.

Yes.

Re: Ordering of command completions

[Óscar Fuentes]

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

>> the vast majority of noise on M-x comes from packages
>> distributed with Emacs.
>
> Just what noise are we talking about?
>
> Are you referring to the fact that there can be many commands
> that match your minibuffer input?  If so, then the answer
> (IMHO) is better completion behavior.  Packages such as
> Icicles and Helm let you narrow things down quickly.

I use Ido+flx. Yes, as you type the number of candidates quickly
decrease from thousands to dozens, but my experience is that the
vast majority of candidates are not applicable on the current context
and they force you to type quite a bit more.

Then we have non-predictability. You enable a mode through an autoloaded
function and suddenly, for the rest of the Emacs session, `M-x foo' no
longer resolves to the same list of candidates where it used to.

[snip]

> Certainly any command that is bound to a key sequence that
> is available in the current context should be a candidate.
> (That's a minimum.)

IMHO introducing ad-hoc heuristics for *discarding* candidates is very
risky. OTOH, if it is a matter of sorting the candidates, which is what
the OP suggested, it is fine. However, certain completion systems (such
as Ido+flx) wouldn't benefit from that sorting, in the general case.

[snip]

RE: Ordering of command completions

[Drew Adams]

> I use Ido+flx. Yes, as you type the number of candidates quickly
> decrease from thousands to dozens, but my experience is that the
> vast majority of candidates are not applicable on the current
> context and they force you to type quite a bit more.

I don't disagree wrt "applicable on the current context", but
I'm wary as to what someone might think that should mean.

I don't think Emacs should be overly ambitious here in excluding
commands.  It should instead exclude only commands that it is
absolutely sure no user would be able to use in the current
context.  What "context" means here is probably the real question.

> Then we have non-predictability. You enable a mode through an
> autoloaded function and suddenly, for the rest of the Emacs
> session, `M-x foo' no longer resolves to the same list of
> candidates where it used to.

You see?  Now that's an example of what I meant by the meaning
of "context" being important.

To me, if you have loaded a library that defines commands that
you can invoke currently (which, a priori is the case for most
commands), then I *want* `M-x' to include those commands when
my input matches their names.

If I load a library (or it is autoloaded) then I expect to be
able to invoke its commands using `M-x'.  I certainly hope
that feature is not removed in favor of some "predictability".

I am becoming more wary of the proposed change...

> > Certainly any command that is bound to a key sequence that
> > is available in the current context should be a candidate.
> > (That's a minimum.)
> 
> IMHO introducing ad-hoc heuristics for *discarding* candidates
> is very risky.

That was my point.  Emacs needs to be very sure that it makes
no sense for a given command to be invoked currently using
`M-x', before it thinks about excluding that command.

A priori, there are very few commands that can reasonably
be excluded, with that in mind.  And in that case, little
is gained, in terms of reducing the supposed "noise".

And something is lost: the user does not see those commands.
S?he may well become confused, and think that this or that
command has not been defined or is no longer supported or...

> OTOH, if it is a matter of sorting the candidates, which is
> what the OP suggested, it is fine.

I see.  I misunderstood.  I asked whether by "noise" what
was meant was a large number of candidates.  I guess the
answer is no.  It is apparently the position of inappropriate
candidates high in the sort order that constitutes "noise",
and not their mere presence.

In that case I have a different objection.  The sorting
being used should be *very clear to users*.  And in
general it should not combine very different criteria,
such as (1) appropriateness (one form of which is what
this proposed feature is about, I guess) and, say,
(2) how recently candidates were used (or some other
sorting criterion, such as alphabetic comparison).

If sorting combines such different criteria then it can
be confusing to users.  This is all the more nefarious if
a measure of "inappropriateness" is applied unbeknownst
to the user.

Picking the right candidates to sort lower according to
the context can be tricky, and once they are sent to the
end of the list a user might well wonder what's going on.

I come back, I think, to what I said in the beginning:
"the answer (IMHO) is better completion behavior."

Re: Ordering of command completions

[Óscar Fuentes]

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

>> I use Ido+flx. Yes, as you type the number of candidates quickly
>> decrease from thousands to dozens, but my experience is that the
>> vast majority of candidates are not applicable on the current
>> context and they force you to type quite a bit more.
>
> I don't disagree wrt "applicable on the current context", but
> I'm wary as to what someone might think that should mean.
>
> I don't think Emacs should be overly ambitious here in excluding
> commands.  It should instead exclude only commands that it is
> absolutely sure no user would be able to use in the current
> context.  What "context" means here is probably the real question.

Well, if the command definition comes with an attached statement about
its applicable context ("when such mode is enabled") Emacs has a
definitive method for the decision.

>> Then we have non-predictability. You enable a mode through an
>> autoloaded function and suddenly, for the rest of the Emacs
>> session, `M-x foo' no longer resolves to the same list of
>> candidates where it used to.
>
> You see?  Now that's an example of what I meant by the meaning
> of "context" being important.
>
> To me, if you have loaded a library that defines commands that
> you can invoke currently (which, a priori is the case for most
> commands), then I *want* `M-x' to include those commands when
> my input matches their names.

I was thinking about this scenario: the user is happily hacking on C
code, then he starts Gnus, reads for a while, quits the Gnus session and
comes back to his C hacking. Now M-x lists hundreds of gnus-* functions
such as gnus-summary-expire-articles-now, which only applies to a Gnus
Summary buffer. This is a net negative contribution to the usability of
M-x.

[snip]

>> OTOH, if it is a matter of sorting the candidates, which is
>> what the OP suggested, it is fine.
>
> I see.  I misunderstood.  I asked whether by "noise" what
> was meant was a large number of candidates.

Yes, it was. The OP asked about the ordering of candidates. Then Lars
mentioned the old discussion about discarding the non-applicable ones,
those that I call "noise".

[snip]

RE: Ordering of command completions

[Drew Adams]

> > I don't think Emacs should be overly ambitious here in excluding
> > commands.  It should instead exclude only commands that it is
> > absolutely sure no user would be able to use in the current
> > context.  What "context" means here is probably the real question.
> 
> Well, if the command definition comes with an attached statement
> about its applicable context ("when such mode is enabled") Emacs
> has a definitive method for the decision.

OK, yes.

It's not always good for the code of a command (which I guess is
where this declaration resides) to preclude where it might be
invoked.  But I guess this is no different in that regard than
the command raising an error if not in the desired mode.  So I
don't have a problem with this way of making it known to `M-x'
that a command is "inappropriate".

In that case, why only move it to the end of the sort order,
instead of completely excluding it as a candidate?  Presence
as a candidate affects completion (e.g. whether there is a match).

> > To me, if you have loaded a library that defines commands that
> > you can invoke currently (which, a priori is the case for most
> > commands), then I *want* `M-x' to include those commands when
> > my input matches their names.
> 
> I was thinking about this scenario: the user is happily hacking on C
> code, then he starts Gnus, reads for a while, quits the Gnus session
> and comes back to his C hacking. Now M-x lists hundreds of gnus-*
> functions such as gnus-summary-expire-articles-now, which only
> applies to a Gnus Summary buffer. This is a net negative contribution
> to the usability of M-x.

Yes, but whose fault is that? ;-)

Just kidding.  If Gnus declares its stuff invocable by `M-x'
only when in some Gnus mode, I agree that that is an improvement.

But in that case, it should not just be about sort order.  The
noise should be removed altogether, if it is truly inappropriate
outside of some context.

Sounds good to me, I guess.  Is there a way for a user to advise
such a command to change or remove the declaration?  Is `declare'
amenable to advising?

Re: Ordering of command completions

[Óscar Fuentes]

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

[snip]

> Just kidding.  If Gnus declares its stuff invocable by `M-x'
> only when in some Gnus mode, I agree that that is an improvement.
>
> But in that case, it should not just be about sort order.  The
> noise should be removed altogether, if it is truly inappropriate
> outside of some context.

The idea discussed on this sub-thread (sorry, OP) is about not listing
those candidates on M-x.

> Sounds good to me, I guess.  Is there a way for a user to advise
> such a command to change or remove the declaration?  Is `declare'
> amenable to advising?

Dunno. What scenario do you have on mind?

As a last resort, the user could define a new interactive function,
without associated restrictions, that simply calls the "hidden" one.

Besides, the filtering would be optional, of course.

RE: Ordering of command completions

[Drew Adams]

> > Sounds good to me, I guess.  Is there a way for a user to advise
> > such a command to change or remove the declaration?  Is `declare'
> > amenable to advising?
> 
> Dunno. What scenario do you have on mind?

A user ... not wanting a particular command to be excluded ...
for whatever usery reason.  How to override the exclusion?

> As a last resort, the user could define a new interactive function,
> without associated restrictions, that simply calls the "hidden" one.

Sure, people can always rewrite the code we provide.  That's not
what is generally meant by user control over commands, in Emacs.

> Besides, the filtering would be optional, of course.

Optionally completely on or completely off is not what I'm
getting at, either.

We are talking about providing declarations at the individual
command level (and possibly at the file/package/mode level).

Users should be able to change that behavior for an individual
command, just as you can declare it for an individual command.
That's what advice is for: tweaking an individual function.
Users should not need to redefine commands, if we can give them
a better way.

Re: Ordering of command completions

[Lars Magne Ingebrigtsen]

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

> That's ok, but it is also very handy to have a global statement saying
> "all the definitions on this file are bound to `message-mode' unless
> the contrary is explicitly stated."

So we'd have a new top-level declaration

(declare (commands message-mode))

and then we'd have an override in the commands that are global?

(defun message-mail ()
  (declare (command global))
  ...)

That would be a lot less annotating, but it seems a bit kludgy...

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

Re: Ordering of command completions

[Óscar Fuentes]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

[snip]

> That would be a lot less annotating, but it seems a bit kludgy...

It seems a bit kludgy, but would be a lot less annotating...

Óscar, the annotator.

Re: Ordering of command completions

[Lars Magne Ingebrigtsen]

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

>> That would be a lot less annotating, but it seems a bit kludgy...
>
> It seems a bit kludgy, but would be a lot less annotating...

:-)

Adding `(declare (mode foo-mode))' to interactive functions can almost
be done automatically to most files.  You basically search for
"(interactive", go to the previous line, and insert
"(declare (mode foo-mode))".  Except for the ones that are global, which
would (mostly) just be the ones that already have autoload cookies
associated with them.

So annotating should be as easy in any case -- you just have to write
the declare-inserting-function.

But having such a form in every command would be more clutter when
reading the code, and when writing new commands.  So I'm sympathetic to
your file-wide cookie, too.

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

RE: Ordering of command completions

[Drew Adams]

> But having such a form in every command would be more clutter when
> reading the code, and when writing new commands.  So I'm sympathetic
> to your file-wide cookie, too.

A file-wide declaration is good too.  But again, how can a user
override this?  S?he can advise a command (dunno about a declaration
part - see previous question).  How to override the file-wide setting?

Re: Ordering of command completions

[Stefan Monnier]

> We discussed the opposite problem a while ago -- excluding commands that
> only make sense in a specific mode from turning up when doing command
> completion.

I think excluding those that don't make sense will take too much work to
work well.


        Stefan

Re: Ordering of command completions

[Lars Magne Ingebrigtsen]

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

>> We discussed the opposite problem a while ago -- excluding commands that
>> only make sense in a specific mode from turning up when doing command
>> completion.
>
> I think excluding those that don't make sense will take too much work to
> work well.

We already have a volunteer to do the markup if we decide how these
should be marked up.  :-)

And it's something that would grow progressively better as more stuff is
marked up.  For instance, `M-x gTAB' now shows (and I've quickly
estimated here) 2.42E45 commands.  If gnus*.el was marked up,
`M-x gTAB' would then show (another quick estimate) 4 commands.

And marking up Gnus would take ten minutes at most.

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

Re: define "out-of-tree"?

[Stephen Leake]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> The main problem with that approach is that it wouldn't really work for
> out-of-tree packages, since introducing something like that requires
> Emacs Lisp engine level changes, I think.

I've never seen the term "out-of-tree" used this way before; I have seen
it when talking about compiling outside the source tree.

In most of this discussion, it seems to mean "with older versions of
Emacs", but sometimes it seems to mean something else. Hmm, perhaps
"with other than current Gnu Emacs implementations of lisp" (ie,
XEmacs)?

In either case, the phrase "out-of-tree" seems an odd term for that
meaning.

Could you define it for me, please?

A complete etymology would be nice, too :).

-- 
-- Stephe

Re: define "out-of-tree"?

[Lars Magne Ingebrigtsen]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> In either case, the phrase "out-of-tree" seems an odd term for that
> meaning.
>
> Could you define it for me, please?

Emacs has a lot of packages that are mainly developed in their own
source code repos and are later integrated into the Emacs tree.  org,
cc-mode, Gnus, etc.

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

Re: define "out-of-tree"?

[Richard Stallman]

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

I thought it was short for "you're out of your tree".
;-)

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: define "out-of-tree"?

[Karl Fogel]

Stephen Leake <stephen_leake@stephe-leake.org> writes:
>In either case, the phrase "out-of-tree" seems an odd term for that
>meaning.
>
>Could you define it for me, please?

I think it just means "is not included in what you get when you check
out the Emacs source tree" -- is not included in the tree cloned with
'git clone USERNAME@git.sv.gnu.org:/srv/git/emacs.git'.

Best,
-Karl