GNU bug report logs -
#52839
29.0.50; The '(declare (modes MODE...))' NEWS entry is confusing
Previous Next
Reported by: Dmitry Gutov <dgutov <at> yandex.ru>
Date: Tue, 28 Dec 2021 01:51:02 UTC
Severity: normal
Found in version 29.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 52839 in the body.
You can then email your comments to 52839 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52839; Package
emacs.
(Tue, 28 Dec 2021 01:51:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Dmitry Gutov <dgutov <at> yandex.ru>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Tue, 28 Dec 2021 01:51:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
It says these syntaxes "declare how completion should happen" or one of
them "can be used as a general predicate to say whether the command
should be present when completing with 'M-x TAB'", but neither have any
effect unless the user customizes read-extended-command-predicate.
The previous entry (the one about (interactive "p" dired-mode)) doesn't
mention the predicate user option either.
Should read-extended-command-predicate be set to
#'command-completion-default-include-p by default? Otherwise the NEWS
entries (at least one of them) should probably mention it.
When reading the manual (subsection "Specifying Modes For Commands"),
I'm feeling a similar problem.
command-completion-default-include-p *is* mentioned, but only somewhere
in the middle. The intro gives the impression that "specifying modes"
will have an effect by default.
The small two paragraphs saying
Specifying modes _may_ affect completion in @kbd{M-x}
...when using the ... predicate ...
look kind of sneaky. Like, we have just described a way to set up a
bunch of meaningful information, and that _may_ affect your Emacs's
behavior if (...). That's weird, but I'm not sure how to resolve that
best. Apart from changing the default value, that is.
Other options may be:
* Change the 'M-x' binding to call execute-extended-command-for-buffer
instead. The behavior of execute-extended-command won't change, but
that probably isn't going to save anybody: the user who set up the
binding to call that command explicitly is probably rare.
* Have the subsection be actually about the command
execute-extended-command-for-buffer. Mention its binding (M-X) and say
that (interactive nil dired-mode) affects its behavior. Then mention
that by customizing read-extended-command-predicate the user can have
'M-x' behaving like that as well. If they like.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52839; Package
emacs.
(Tue, 28 Dec 2021 12:47:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 52839 <at> debbugs.gnu.org (full text, mbox):
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Tue, 28 Dec 2021 03:49:33 +0200
>
> It says these syntaxes "declare how completion should happen" or one of
> them "can be used as a general predicate to say whether the command
> should be present when completing with 'M-x TAB'", but neither have any
> effect unless the user customizes read-extended-command-predicate.
>
> The previous entry (the one about (interactive "p" dired-mode)) doesn't
> mention the predicate user option either.
>
> Should read-extended-command-predicate be set to
> #'command-completion-default-include-p by default? Otherwise the NEWS
> entries (at least one of them) should probably mention it.
>
> When reading the manual (subsection "Specifying Modes For Commands"),
> I'm feeling a similar problem.
> command-completion-default-include-p *is* mentioned, but only somewhere
> in the middle. The intro gives the impression that "specifying modes"
> will have an effect by default.
>
> The small two paragraphs saying
>
> Specifying modes _may_ affect completion in @kbd{M-x}
>
> ...when using the ... predicate ...
>
> look kind of sneaky. Like, we have just described a way to set up a
> bunch of meaningful information, and that _may_ affect your Emacs's
> behavior if (...). That's weird, but I'm not sure how to resolve that
> best. Apart from changing the default value, that is.
>
> Other options may be:
>
> * Change the 'M-x' binding to call execute-extended-command-for-buffer
> instead. The behavior of execute-extended-command won't change, but
> that probably isn't going to save anybody: the user who set up the
> binding to call that command explicitly is probably rare.
>
> * Have the subsection be actually about the command
> execute-extended-command-for-buffer. Mention its binding (M-X) and say
> that (interactive nil dired-mode) affects its behavior. Then mention
> that by customizing read-extended-command-predicate the user can have
> 'M-x' behaving like that as well. If they like.
Stefan, any comments?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52839; Package
emacs.
(Tue, 28 Dec 2021 20:28:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 52839 <at> debbugs.gnu.org (full text, mbox):
> Apart from changing the default value, that is.
That seems to be asking a question: what is the reason for the current
default value. AFAICT this comes from:
commit 927b88571cebb4f64aca360fbfa5d15a1f922ad6
Author: Eli Zaretskii <eliz <at> gnu.org>
Date: Wed Feb 17 18:53:54 2021 +0200
Disable filtering of commands in M-x completion
This makes the default behavior like it was before:
M-x completion doesn't filter out any commands. To
have commands filtered based on their relevance to the
current buffer's modes, customize the option
'read-extended-command-predicate' to call
'command-completion-default-include-p'.
* doc/lispref/commands.texi (Interactive Call):
* doc/emacs/m-x.texi (M-x): Update the description of
'read-extended-command-predicate' and improve wording.
* etc/NEWS: Update the entry about
'read-extended-command-predicate'.
* lisp/simple.el (read-extended-command-predicate): Change default
value to nil. Update doc string. Add :group.
(read-extended-command): Handle nil as meaning to apply
no-filtering.
But the commit doesn't say why this change was made (other than saying
"like it was before"). Was there a specific problem introduced by the
filtering, or was it a change based on a judgment call about what the
default should be to balance the tradeoffs between bringing new
features and surprising the users?
Stefan "who doesn't have an opinion on this one"
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility.
(Wed, 29 Dec 2021 14:46:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Dmitry Gutov <dgutov <at> yandex.ru>:
bug acknowledged by developer.
(Wed, 29 Dec 2021 14:46:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 52839-done <at> debbugs.gnu.org (full text, mbox):
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Tue, 28 Dec 2021 03:49:33 +0200
>
> It says these syntaxes "declare how completion should happen" or one of
> them "can be used as a general predicate to say whether the command
> should be present when completing with 'M-x TAB'", but neither have any
> effect unless the user customizes read-extended-command-predicate.
>
> The previous entry (the one about (interactive "p" dired-mode)) doesn't
> mention the predicate user option either.
>
> Should read-extended-command-predicate be set to
> #'command-completion-default-include-p by default? Otherwise the NEWS
> entries (at least one of them) should probably mention it.
Thanks, I added the caveat to these NEWS entries.
> When reading the manual (subsection "Specifying Modes For Commands"),
> I'm feeling a similar problem.
> command-completion-default-include-p *is* mentioned, but only somewhere
> in the middle.
That's a 75-line node, so "in the middle" is also "close to the
beginning". In fact, it mentions it immediately after explaining the
issue and saying that Emacs has a mechanism for tagging commands as
being specific to modes. I don't see how this could be moved earlier
without severely disrupting the text didactically.
> The intro gives the impression that "specifying modes" will have an
> effect by default.
I don't think so, but I now tried to make it even more evident.
> * Change the 'M-x' binding to call execute-extended-command-for-buffer
> instead. The behavior of execute-extended-command won't change, but
> that probably isn't going to save anybody: the user who set up the
> binding to call that command explicitly is probably rare.
>
> * Have the subsection be actually about the command
> execute-extended-command-for-buffer. Mention its binding (M-X) and say
> that (interactive nil dired-mode) affects its behavior. Then mention
> that by customizing read-extended-command-predicate the user can have
> 'M-x' behaving like that as well. If they like.
I've added the reference to execute-extended-command-for-buffer and
its binding.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52839; Package
emacs.
(Wed, 29 Dec 2021 14:48:01 GMT)
Full text and
rfc822 format available.
Message #19 received at 52839 <at> debbugs.gnu.org (full text, mbox):
> Cc: 52839 <at> debbugs.gnu.org
> Date: Tue, 28 Dec 2021 15:27:38 -0500
> From: Stefan Monnier via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> But the commit doesn't say why this change was made (other than saying
> "like it was before"). Was there a specific problem introduced by the
> filtering, or was it a change based on a judgment call about what the
> default should be to balance the tradeoffs between bringing new
> features and surprising the users?
The latter. We then added the "M-X" binding for the new command that
always omits inapplicable commands from the completion, so now users
can have the cake and eat it, too.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52839; Package
emacs.
(Wed, 29 Dec 2021 14:52:01 GMT)
Full text and
rfc822 format available.
Message #22 received at 52839 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> The latter. We then added the "M-X" binding for the new command that
> always omits inapplicable commands from the completion, so now users
> can have the cake and eat it, too.
That's not what `M-X' does, though -- it filters out commands that
aren't particularly marked for the current mode, but there's always
other commands that will be useful.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52839; Package
emacs.
(Wed, 29 Dec 2021 15:07:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 52839-done <at> debbugs.gnu.org (full text, mbox):
On 29.12.2021 17:45, Eli Zaretskii wrote:
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> Date: Tue, 28 Dec 2021 03:49:33 +0200
>>
>> It says these syntaxes "declare how completion should happen" or one of
>> them "can be used as a general predicate to say whether the command
>> should be present when completing with 'M-x TAB'", but neither have any
>> effect unless the user customizes read-extended-command-predicate.
>>
>> The previous entry (the one about (interactive "p" dired-mode)) doesn't
>> mention the predicate user option either.
>>
>> Should read-extended-command-predicate be set to
>> #'command-completion-default-include-p by default? Otherwise the NEWS
>> entries (at least one of them) should probably mention it.
>
> Thanks, I added the caveat to these NEWS entries.
>
>> When reading the manual (subsection "Specifying Modes For Commands"),
>> I'm feeling a similar problem.
>> command-completion-default-include-p *is* mentioned, but only somewhere
>> in the middle.
>
> That's a 75-line node, so "in the middle" is also "close to the
> beginning". In fact, it mentions it immediately after explaining the
> issue and saying that Emacs has a mechanism for tagging commands as
> being specific to modes. I don't see how this could be moved earlier
> without severely disrupting the text didactically.
>
>> The intro gives the impression that "specifying modes" will have an
>> effect by default.
>
> I don't think so, but I now tried to make it even more evident.
>
>> * Change the 'M-x' binding to call execute-extended-command-for-buffer
>> instead. The behavior of execute-extended-command won't change, but
>> that probably isn't going to save anybody: the user who set up the
>> binding to call that command explicitly is probably rare.
>>
>> * Have the subsection be actually about the command
>> execute-extended-command-for-buffer. Mention its binding (M-X) and say
>> that (interactive nil dired-mode) affects its behavior. Then mention
>> that by customizing read-extended-command-predicate the user can have
>> 'M-x' behaving like that as well. If they like.
>
> I've added the reference to execute-extended-command-for-buffer and
> its binding.
Thank you.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52839; Package
emacs.
(Wed, 29 Dec 2021 16:54:01 GMT)
Full text and
rfc822 format available.
Message #28 received at 52839 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 52839 <at> debbugs.gnu.org,
> dgutov <at> yandex.ru
> Date: Wed, 29 Dec 2021 15:51:00 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > The latter. We then added the "M-X" binding for the new command that
> > always omits inapplicable commands from the completion, so now users
> > can have the cake and eat it, too.
>
> That's not what `M-X' does, though -- it filters out commands that
> aren't particularly marked for the current mode, but there's always
> other commands that will be useful.
How is that different from what I said?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52839; Package
emacs.
(Wed, 29 Dec 2021 16:55:02 GMT)
Full text and
rfc822 format available.
Message #31 received at 52839 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> > The latter. We then added the "M-X" binding for the new command that
>> > always omits inapplicable commands from the completion, so now users
>> > can have the cake and eat it, too.
>>
>> That's not what `M-X' does, though -- it filters out commands that
>> aren't particularly marked for the current mode, but there's always
>> other commands that will be useful.
>
> How is that different from what I said?
There's many commands that are applicable in any given mode that will
not be listed by `M-X'. (I.e., all commands that are generally useful
across modes.)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Thu, 27 Jan 2022 12:24:08 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 87 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.