emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [External] : Re: Current mode command discovery


From: Drew Adams
Subject: RE: [External] : Re: Current mode command discovery
Date: Sun, 21 Feb 2021 22:46:07 +0000

> > Have we seen a complete, succinct, description
> > of the two "features" (which both apparently
> > filter)?
> >
> > Could someone please post that description,
> > apart from these long, convoluted threads?
> >
> I believe the NEWS file on the master branch has been kept up-to-date:
> 
> https://urldefense.com/v3/__https://git.savannah.gnu.org/cgit/emacs.git
> /tree/etc/NEWS__;!!GqivPVa7Brio!MbL7drkVlsbDK4CmZc61-V9hngoLnSJgmc-
> UKRC65sOOHceASdzWB6ma_FTFY8ad$

Thanks.

> > ** New command 'execute-extended-command-for-buffer'.
> > This new command, bound to 'M-S-x', works like
> > 'execute-extended-command', but limits the set of commands to the
> > commands that have been determined to be particularly useful with the
> > current mode.

We still have no description (let alone a spec) of
what "particularly useful" for a mode should mean.

It's admitted that this is a judgment call, but no
criteria for judgment have been given, AFAIK, except
for Stefan's NOT-useful-if-always-raises-error.  And
that was said by others not to be a real criterion.

So that new command seems particularly undefined...

However, the particularly useful objections raised
so far have been wrt the implementation: hard-coding
the association of command & mode(s) in source code.

> > ** New user option 'read-extended-command-predicate'.
> > This option controls how 'M-x' performs completion of commands when
> > you type TAB.  By default, any command that matches what you have
> > typed is considered a completion candidate, but you can customize
> > this option to exclude commands that are not applicable to the current
> > buffer's major and minor modes, and respect the command's completion
> > predicate (if any).

I see.  But which way does the predicate go?
Does it filter out or filter in?  I guess that
description doesn't help with that basic question,
and you have to use `C-h v' to find out.

How does this predicate relate to or interact with
the tampering with `interactive' (new, second arg)
in the source code?  Is the predicate an additional
test?  An overriding test?

> > ** New forms to declare how completion should happen has been added.

(Grammar problem in that sentence: plural subject,
singular verb.)

> > '(declare (completion PREDICATE))' can be used as a general predicate
> > to say whether the command should be present when completing with
> > 'M-x TAB'.  '(declare (modes MODE...))' can be used as a short-hand
> > way of saying that the command should be present when completing from
> > buffers in major modes derived from MODE..., or, if it's a minor
> > mode, whether that minor mode is enabled in the current buffer.

So the first one applies only when no input is typed
at the `M-x' prompt - just `TAB'?  No effect otherwise?

Or is that also true of the second one (using `modes')?

How does the `M-x TAB' filtering interact with filtering
by the new option (above)?  (Same question posed above.)

> > ** The 'interactive' syntax has been extended to allow listing
> > applicable modes.
> > Forms like '(interactive "p" dired-mode)' can be used to annotate the
> > commands as being applicable for modes derived from 'dired-mode',
> > or if the mode is a minor mode, that the current buffer has that
> > minor mode activated.  Note that using this form will create byte
> > code that is not compatible with byte code in previous Emacs versions.

This sounds like a repeat of what is said in the previous
entry (except for the last sentence).  Is that right?  If
so, why have both?
___

And again, why go through all that, and make users go
through all of it, instead of just putting a property
on a command symbol to indicate the same thing(s?)?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]