Re: Current mode command discovery

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: contovob@tcd.ie,  emacs-devel@gnu.org
> Date: Tue, 16 Feb 2021 20:33:18 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> No, in "Editing Changes in Emacs 28.1"...  But that section is perhaps a
> >> better one?  Feel free to move it (and expand upon it) if you wish.
> >
> > I'd prefer to make the feature opt-in, see my other message.  Then
> > NEWS entry won't need to be moved.
> 
> What the default completion predicate should be is totally up for
> discussion, and we could take a poll.  (Cries of horror ensue.)

The current master already makes the behavior incompatible, so I'm not
sure I understand how would you like to have a discussion about
something that is already a "fait accompli".

Moreover, I thought I _was_ discussing how to make this filtering less
radical and dangerous, but all I got in response was "don't worry, we
are talking about this theoretical non-existing command, not about
changing how M-x behaves".  And now it turns out it _was_ about M-x
after all.

> But I'd prefer to have the new predicate as the default in the
> development version for the time being, to see if that'll spur people
> into doing mode tagging.

My problem is not with the lack of tagging, my problem is that there's
no "fire escape" when a command I want to invoke was filtered out by
this new feature: M-x says "[No match]" and that's it, although the
command does exists and "C-h f" will happily tell me about it.
Imagine user confusion and frustration when a command that is known to
Help cannot be invoked!  My suggestion to change the sorting order
instead of actually filtering out candidates would at least avoid that
danger.