From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.devel Subject: Re: master 927b885 1/3: Disable filtering of commands in M-x completion Date: Wed, 17 Feb 2021 11:27:11 -0800 Message-ID: References: <20210217165944.26910.26583@vcs0.savannah.gnu.org> <20210217165946.030D420DFC@vcs0.savannah.gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22807"; mail-complaints-to="usenet@ciao.gmane.io" To: Eli Zaretskii , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Feb 17 20:28:50 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 1lCSVG-0005pC-4R for ged-emacs-devel@m.gmane-mx.org; Wed, 17 Feb 2021 20:28:50 +0100 Original-Received: from localhost ([::1]:52992 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lCSVF-0004NK-3j for ged-emacs-devel@m.gmane-mx.org; Wed, 17 Feb 2021 14:28:49 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47526) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lCSTp-0002zQ-CL for emacs-devel@gnu.org; Wed, 17 Feb 2021 14:27:21 -0500 Original-Received: from mail-pj1-x102d.google.com ([2607:f8b0:4864:20::102d]:38762) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lCSTj-0008TD-Ld; Wed, 17 Feb 2021 14:27:19 -0500 Original-Received: by mail-pj1-x102d.google.com with SMTP id l18so2293527pji.3; Wed, 17 Feb 2021 11:27:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=IFb9HoV8uLB/VQ+TXVrQqHaWZ4BjZgDm1Et41PNPYGE=; b=WI76XnHglgsI1WYrO/DJLOSb8jBWab9dFrIO0kjxr4yKDRkJ5I8gIKX8qBiCLxwiYA rrjPu7Cgm+VGOJ7E/QSNuYWVfynjT5UPrk+E2KoEkilm75t8kmlk9gj6L1J9RLPupPig WPiHoAhQqwwxDPa5FVeGUPfmytxVvbokHID9mz+hq/CyMth8YqSuiziba7v7xh3HL69p gCNEDeLSIQIIZYjx/kzIbPLl6JbXsDxzosZ5GB5S+r2hRoyMdBAvkljlpqtYnbEiJyRE 4SPnWPsGBtKqs5YKlrd4ZNI5eSlnj6WqfsFRHvDPaG+FqAumS4FaLx07TLsece5dIuU7 0n+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=IFb9HoV8uLB/VQ+TXVrQqHaWZ4BjZgDm1Et41PNPYGE=; b=BVEos/gtTpc2DMpBfGJj+UmqGxMrb24kl6WlWnD7YT17linSV2WzvJ0+zj7YEO+zMx n/7LxPeYZABLBhA1Wrd4a6tu6ZUxgBDs8UXBPCEnvb0ra/gBfot6mhyBkQEOLq29Hv7U 8jfBhQqMHXBxWdAXlJQZowUotWLXcj0LoY6SIHkkT4mhdvJcXjFHdXwZNjNhmqjojp6p PLQWKzQ0sEfz3OyLHe+mWGP+AbKW8k+xY5dLSuRywlgzsGOXBy0K2cMAj/OPnV8nvJQP 6COhpezFGTlIxSuZEYBn17ZwNVMxQnqOZWyxr6pl55YczIzAJlAZ9cr5m064TKcbEQnj OuXg== X-Gm-Message-State: AOAM530fojsuaKNtugA6Q/jpEZ2P4l2n4HbV88xOAiWnrsIlzJJnwyZ9 XHYmNCgxMMMXVCZGunaq7VKmFjGFz/WpbAAh7JXCZUpd X-Google-Smtp-Source: ABdhPJz8jnyZvjYzZlyy6SXxICCuGpW8JpF461AVYchgp0cgyya3qkefVIhgnUDYNhrvZpxci3x58/iOGr8zY0uYhnw= X-Received: by 2002:a17:902:ea8a:b029:e2:1526:91ef with SMTP id x10-20020a170902ea8ab02900e2152691efmr451301plb.41.1613590032216; Wed, 17 Feb 2021 11:27:12 -0800 (PST) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Wed, 17 Feb 2021 11:27:11 -0800 In-Reply-To: <20210217165946.030D420DFC@vcs0.savannah.gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::102d; envelope-from=stefankangas@gmail.com; helo=mail-pj1-x102d.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:265056 Archived-At: eliz@gnu.org (Eli Zaretskii) writes: > branch: master > commit 927b88571cebb4f64aca360fbfa5d15a1f922ad6 > Author: Eli Zaretskii > Commit: Eli Zaretskii > > 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'. I can understand this decision for Emacs 28, but hope that we can consider enabling it by default in Emacs 29. (I would have preferred it as the default in Emacs 28, but I can see the benefit in having a period to let the feature stabilize and mature a bit first.) I understand that sometimes a package developer will get filtering wrong (i.e. a bug), and that at other times the user will know best if a command is relevant or not. I would expect this to overwhelmingly not be the most common case. But even if I am right about that, it is still important that we get this situation right. I think we should take one of the below actions: a) Add a key to show the unfiltered list of matches in `M-x'. (We could use any key, but how about just using `M-x M-x' to show the unfiltered list? It would affect recursive minibuffers, but we could just require a third `M-x' for that.) b) Add a new command, e.g. on `C-x x x', that always acts like the old `M-x'. c) Both. And then we should consider making this feature the default, preferably already in Emacs 28 but otherwise in Emacs 29. Here is why: I have never understood why Emacs suggests commands for execution in a context where they will obviously fail. I think this is a glaring deficiency in our default UI -- you are proposed useless commands (that won't work there, will screw up your buffer, etc.). No longer doing that is in my view a big step forward for Emacs usability. Having this feature on provides additional safety that is most sorely needed by "regular" users. It will also make it easier to learn Emacs, as there is less intimidating, often useless cruft to filter through. Finding the correct command, often even a relevant one, was something I personally struggled a lot with when I started out with Emacs. My own conclusion was that `M-x' was often practically useless as a discovery mechanism. This of course largely depends on what you are trying to do, but consider finding a relevant Gnus command using `M-x'... not fun. Finally, I note that Emacs is *not* more powerful because users can say `M-x mwheel-scroll' -- it just has a lower signal to noise ratio.[1] OTOH, it seems to me that the target audience for disabling this feature is (or will be) mostly "hardcore"/"veteran"/"advanced" users who are very used to and like the old behavior. >From the discussions we've had so far, it is my understanding that some like to use it for searching for and discovering commands. That is fine and valid, and reason for having an option to opt-out of this behavior. (I also think we should add a `describe-command' to try to better cover this use-case.) Footnotes: [1] Some modes are prudent in saying: (unless (derived-p 'foo-mode) (user-error "Nope")) I think up until now this has often been the right and safe thing to do, but it has unfortunately been severely underused. Yet it still has the deficiency that the command will show up in 'M-x`, and it provides no fire-escape.