all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: "Óscar Fuentes" <ofv@wanadoo.es>, emacs-devel@gnu.org
Subject: RE: Ordering of command completions
Date: Sun, 7 Dec 2014 12:42:42 -0800 (PST)	[thread overview]
Message-ID: <99caf488-cdcb-4897-9a94-393bcbf36326@default> (raw)
In-Reply-To: <87mw6ztdhc.fsf@wanadoo.es>

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



  reply	other threads:[~2014-12-07 20:42 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-07 16:14 Ordering of command completions Tom
2014-12-07 16:28 ` Lars Magne Ingebrigtsen
2014-12-07 17:36   ` Andreas Schwab
2014-12-07 17:42     ` Lars Magne Ingebrigtsen
2014-12-07 21:20       ` Lars Magne Ingebrigtsen
2014-12-07 21:33         ` Lars Magne Ingebrigtsen
2014-12-07 21:47           ` Lars Magne Ingebrigtsen
2014-12-07 22:00             ` Autoload cookies (was: Ordering of command completions) Lars Magne Ingebrigtsen
2014-12-07 22:03               ` Autoload cookies Daniel Colascione
2014-12-07 22:08                 ` Lars Magne Ingebrigtsen
2014-12-07 22:06               ` Andreas Schwab
2014-12-08  0:14               ` Autoload cookies (was: Ordering of command completions) Artur Malabarba
2014-12-07 22:05             ` Ordering of command completions Óscar Fuentes
2014-12-07 22:13               ` Lars Magne Ingebrigtsen
2014-12-08  0:53                 ` Artur Malabarba
2014-12-08  0:56                   ` Artur Malabarba
2014-12-07 18:33   ` Óscar Fuentes
2014-12-07 18:42     ` Drew Adams
2014-12-07 19:37       ` Óscar Fuentes
2014-12-07 20:10         ` Drew Adams
2014-12-07 20:24           ` Óscar Fuentes
2014-12-07 20:42             ` Drew Adams [this message]
2014-12-07 21:06               ` Óscar Fuentes
2014-12-07 21:26                 ` Drew Adams
2014-12-07 18:45     ` Lars Magne Ingebrigtsen
2014-12-07 18:59       ` Óscar Fuentes
2014-12-07 20:34         ` Lars Magne Ingebrigtsen
2014-12-07 20:47           ` Drew Adams
2014-12-07 21:20   ` Stefan Monnier
2014-12-07 21:25     ` Lars Magne Ingebrigtsen
2014-12-08  9:51   ` define "out-of-tree"? Stephen Leake
2014-12-08 18:04     ` Lars Magne Ingebrigtsen
2014-12-09 11:00       ` Richard Stallman
2014-12-09 20:00     ` Karl Fogel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=99caf488-cdcb-4897-9a94-393bcbf36326@default \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=ofv@wanadoo.es \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.