From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Current mode command discovery Date: Tue, 16 Feb 2021 21:50:41 +0200 Message-ID: <834kib94ha.fsf@gnu.org> References: <87v9aubm96.fsf@gnus.org> <83a6s6bkrg.fsf@gnu.org> <87mtw6bkjo.fsf@gnus.org> <838s7qbjn2.fsf@gnu.org> <87eehi820x.fsf@gnus.org> <83v9at9xel.fsf@gnu.org> <87wnv8xlqa.fsf@gnus.org> <838s7o9g90.fsf@gnu.org> <87im6revhq.fsf@tcd.ie> <83im6r98qd.fsf@gnu.org> <87k0r7uade.fsf@gnus.org> <83eehf978r.fsf@gnu.org> <87ft1vu9hd.fsf@gnus.org> <838s7n95pf.fsf@gnu.org> <8735xvu7sx.fsf@gnus.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28480"; mail-complaints-to="usenet@ciao.gmane.io" Cc: contovob@tcd.ie, emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Feb 16 20:51:42 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lC6Np-0007Hr-TX for ged-emacs-devel@m.gmane-mx.org; Tue, 16 Feb 2021 20:51:41 +0100 Original-Received: from localhost ([::1]:38326 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lC6No-0003dG-Ub for ged-emacs-devel@m.gmane-mx.org; Tue, 16 Feb 2021 14:51:40 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56628) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lC6Mn-0002hP-5x for emacs-devel@gnu.org; Tue, 16 Feb 2021 14:50:37 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:59556) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lC6Mm-0001OJ-Hx; Tue, 16 Feb 2021 14:50:36 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2704 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lC6Mj-0004bA-U4; Tue, 16 Feb 2021 14:50:34 -0500 In-Reply-To: <8735xvu7sx.fsf@gnus.org> (message from Lars Ingebrigtsen on Tue, 16 Feb 2021 20:33:18 +0100) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:264928 Archived-At: > From: Lars Ingebrigtsen > Cc: contovob@tcd.ie, emacs-devel@gnu.org > Date: Tue, 16 Feb 2021 20:33:18 +0100 > > Eli Zaretskii 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.