From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: Leaving out non-applicable commands on Mx Date: Sat, 09 Jan 2016 03:15:14 +0100 Message-ID: <877fjjh51p.fsf@wanadoo.es> 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: 8bit X-Trace: ger.gmane.org 1452305749 7682 80.91.229.3 (9 Jan 2016 02:15:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 Jan 2016 02:15:49 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 09 03:15:43 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 1aHj49-0001iv-2c for ged-emacs-devel@m.gmane.org; Sat, 09 Jan 2016 03:15:41 +0100 Original-Received: from localhost ([::1]:38715 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHj48-0003ef-2j for ged-emacs-devel@m.gmane.org; Fri, 08 Jan 2016 21:15:40 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53255) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHj3v-0003eK-Jt for emacs-devel@gnu.org; Fri, 08 Jan 2016 21:15:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aHj3r-0007OQ-JC for emacs-devel@gnu.org; Fri, 08 Jan 2016 21:15:27 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:45000) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHj3r-0007OJ-C3 for emacs-devel@gnu.org; Fri, 08 Jan 2016 21:15:23 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aHj3p-0001Qi-Ii for emacs-devel@gnu.org; Sat, 09 Jan 2016 03:15:21 +0100 Original-Received: from 126.red-88-21-15.staticip.rima-tde.net ([88.21.15.126]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Jan 2016 03:15:21 +0100 Original-Received: from ofv by 126.red-88-21-15.staticip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Jan 2016 03:15:21 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 51 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 126.red-88-21-15.staticip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:LhZcHFM8CtrNyzWBdbgP0hdNbLg= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:197865 Archived-At: John Wiegley writes: >>>>>> Óscar Fuentes writes: > >> On the M-x prompt, the set of candidates is restricted to those that make >> sense given the current context. Leaving out functions that are specific to >> modes not enabled is a start. 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. > > This sounds like a feature that should evolve first as a separate package in > ELPA, and after proving itself, be considered for core. But I sense ways in > which this could go wrong: expecting to find a command, failing for some > undiscovered reason X, and then the user believing no such command exists. This could ony happen if there is a mistake on how that command is declared. A bug like any other. >> 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. > > Core Emacs behavior doesn't need to change to demonstrate this feature, does > it? Write a new execute-extended-command and see if it works as well as you > hope. It is necessary to annotate the functions with the context they are suppossed to work on. Something like (defun foo-something () "docstring" (interactive) (declare this-applies-to-foo-mode) ...) Doing that for every function is unnecessary work, so a method for saying "all the functions defined on this .el file apply to foo-mode, except foo-bar and foo-zoo" is a sensible enhancement. (We also could exploit the fact that we know wich functions are autoladed. Most autoloaded functions are context-free, while the non-autoloaded functions on the same file are context-specific). Maintaining all this information on an external resource is unmanageable, it simply wont work. So yes, the Elisp source files need to be annotated (that's the work I'm volunteering for). For reading the annotations (and, possibly, for performance reasons, applying the filter) modifications are required on some Emacs infrastructure. From past discussion it seems that those modifications are expected to be small, though.