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: Wed, 17 Feb 2021 17:38:49 +0200 Message-ID: <83o8gi7lh2.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> <834kib94ha.fsf@gnu.org> <874kibh9mu.fsf@telefonica.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4569"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: =?iso-8859-1?Q?=D3scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Feb 17 16:39:27 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 1lCOvG-00012x-P4 for ged-emacs-devel@m.gmane-mx.org; Wed, 17 Feb 2021 16:39:26 +0100 Original-Received: from localhost ([::1]:57688 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lCOvF-0005Zr-Rv for ged-emacs-devel@m.gmane-mx.org; Wed, 17 Feb 2021 10:39:25 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46450) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lCOuW-00057K-RL for emacs-devel@gnu.org; Wed, 17 Feb 2021 10:38:40 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:48723) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lCOuW-0007UT-Dc; Wed, 17 Feb 2021 10:38:40 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3911 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lCOuV-0006bY-8h; Wed, 17 Feb 2021 10:38:40 -0500 In-Reply-To: <874kibh9mu.fsf@telefonica.net> (message from =?iso-8859-1?Q?=D3scar?= Fuentes on Wed, 17 Feb 2021 00:32:09 +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:265007 Archived-At: > From: Óscar Fuentes > Date: Wed, 17 Feb 2021 00:32:09 +0100 > > Eli Zaretskii writes: > > > Imagine user confusion and frustration when a command that is known to > > Help cannot be invoked! > > Why would the user wish to invoke a command that makes no sense on the > context he is working on? Because whoever marked it "nonsensical" made a mistake? Or because time passed, things have changed, and what made no sense back then may make sense now, and Emacs maintainers missed that or couldn't keep up? IOW, let's not assume that the marking is perfect. It's done by us, and we can make mistakes. > > My suggestion to change the sorting order instead of actually > > filtering out candidates would at least avoid that danger. > > The danger you are talking about is saving the user from having to > search among thousands of irrelevant commands and/or firing himself on > the foot. If you are talking about display of completion candidates, we could make display of those "irrelevant" command optional, with some suitable gesture (like another TAB, perhaps?). But please don't forget that completion is also invoked when you type RET to exit the minibuffer and run the command, and it's at that point that hard removal of some commands could be harmful. > After all, we also hide the menus of modes when they are not active > on the current buffer. Menus only show a small fraction of the commands. More importantly, a command that doesn't appear in the menus still can be invoked, so the user does have a "fire escape" in that case.