From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Leaving out non-applicable commands on Mx Date: Fri, 8 Jan 2016 19:08:59 -0800 (PST) Message-ID: <4002fc97-5629-4367-8b8f-48b659fefdce@default> References: <87mvszdp6b.fsf@gnus.org> <8737u9kv6f.fsf@russet.org.uk> <87fuy7hdc6.fsf_-_@wanadoo.es> <87bn8vh8q4.fsf@wanadoo.es> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1452308969 17305 80.91.229.3 (9 Jan 2016 03:09:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 Jan 2016 03:09:29 +0000 (UTC) To: =?utf-8?B?w5NzY2FyIEZ1ZW50ZXM=?= , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 09 04:09:17 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aHjty-0003Ad-0P for ged-emacs-devel@m.gmane.org; Sat, 09 Jan 2016 04:09:14 +0100 Original-Received: from localhost ([::1]:38786 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHjtx-0001t4-5P for ged-emacs-devel@m.gmane.org; Fri, 08 Jan 2016 22:09:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53405) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHjts-0001sq-6D for emacs-devel@gnu.org; Fri, 08 Jan 2016 22:09:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aHjtn-00055S-6l for emacs-devel@gnu.org; Fri, 08 Jan 2016 22:09:08 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:37163) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHjtm-00055K-Vc for emacs-devel@gnu.org; Fri, 08 Jan 2016 22:09:03 -0500 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u0939009006475 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 9 Jan 2016 03:09:01 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u09390Wa026473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 9 Jan 2016 03:09:00 GMT Original-Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u09390MQ021512; Sat, 9 Jan 2016 03:09:00 GMT In-Reply-To: <87bn8vh8q4.fsf@wanadoo.es> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: userv0022.oracle.com [156.151.31.74] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:197869 Archived-At: > On the M-x prompt, the set of candidates is restricted to those that > make sense given the current context. Not if a user invokes `M-x' to see which commands are currently available in general, i.e., as a kind of interactive `apropos'. (Especially if s?he can hit a key to get help about the command.) Especially if you have an "advanced completion system" that lets you (a) match command names more flexibly and (b) narrow the matches using a succession of patterns. > Leaving out functions that are > specific to modes not enabled is a start. And that's also a feature of some "advanced completion systems". But it should not (except by user option) be the default behavior. The default behavior should be all candidates matching the input patterns and the completion predicate - no other "helpful" filtering unless requested by the user. The command calling `completing-read' or `read-file-name' (or whatever) should get first shot at specifying the filtering. And it does that, as usual, with a predicate. > So if you are editing a C file and press `M-x g' almost > all gnus* functions shall not be considered as > candidates for completion. Yes they should, by default - unless a user has configured a different behavior. Emacs is smartest when it doesn't try to outsmart the user; when it helps the user be smart instead of trying to second-guess her. It's about what the user wants, not what an Emacs developer thinks is clever or is what the user must want. But hey, I sympathize wrt the many matches of something like `gnus'. I filter those out by matching & tossing them - unless I really want to see them for some reason. Let the specific _command_, first, and the _user_ who invokes it, second, filter out stuff that is not appropriate. Please don't decide ahead of time (unless it's through a specific command) what is appropriate and what is not. > This is important with advanced completion systems. See above about "advanced completion systems". > An example: while working on a org-mode file, if I wish > to execute org-clock-report I can use its binding: > "C-c C-x C-r". With ido+flx, I can do "M-x ocr ENTER" > which, IMO, is superior on each and every aspect. And? Are you now suggesting that users and libraries should not bind keys because you are convinced that your "advanced completion system" is "superior on each and every aspect"? I hope not. > The M-x interface can be an improvement over both keybindings and the > menu on terms of usability, given the correct methods, but having > thousands of irrelevant candidates every time you invoke M-x is an > inconvenience for that goal, not to say plain dumb. Thousands of candidates might be just what a user wants. But more importantly is to let the _user_ choose which 100 or which 10 of the thousands s?he really wants to interact with. Please don't presume to guess, in some general way, how a user might want to filter candidates. Specific commands already can, and do, make such judgments (e.g. only symbols bound to commands are candidates for `M-x). Leave it up to the command (and to the user who chooses to use that command) to make such a preliminary judgment. And more importantly, leave it up to the user to decide how to subsequently filter the preliminary candidates. What Emacs could do to help is to: 1. Provide powerful and flexible ways to match, and to combine multiple match patterns. 2. Provide command-specific keys to use during completion, to let the user filter in ways that are helpful in the context of that command. As one example (and I'm sure there are plenty of others), Icicles lets you narrow using any number of patterns, each of which can be a regexp or a fuzzy-match of various kinds. You can exclude matches as well as including them. And for buffer-name candidates, for example, you can use keys to keep or remove the names of buffers in a derived mode or a given mode or that are already displayed or not. (You can even provide a filtering predicate interactively, on the fly, to narrow candidates any fancy way you like.) What Icicles offers is not the only way to help users filter. The point is to try to do that, not try to guess, in some general way, what kind of filtering is good for them for all commands. The way to do what you suggest wrt commands that make sense for a given mode ("leaving out functions that are specific to modes not enabled is a start") is to let the user hit a key to do this, i.e., to ask for it on demand, not to impose it on everyone and everywhere by default.