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: Ordering of command completions Date: Sun, 07 Dec 2014 19:33:25 +0100 Message-ID: <87zjaztimi.fsf@wanadoo.es> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1417977243 22114 80.91.229.3 (7 Dec 2014 18:34:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 7 Dec 2014 18:34:03 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 07 19:33:56 2014 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 1Xxgea-0007P3-88 for ged-emacs-devel@m.gmane.org; Sun, 07 Dec 2014 19:33:56 +0100 Original-Received: from localhost ([::1]:58850 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxgeZ-0004EV-OH for ged-emacs-devel@m.gmane.org; Sun, 07 Dec 2014 13:33:55 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41500) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxgeP-0004E8-Lj for emacs-devel@gnu.org; Sun, 07 Dec 2014 13:33:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XxgeI-0002v2-NO for emacs-devel@gnu.org; Sun, 07 Dec 2014 13:33:45 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:57177) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxgeI-0002ue-GS for emacs-devel@gnu.org; Sun, 07 Dec 2014 13:33:38 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XxgeH-0007Fe-1e for emacs-devel@gnu.org; Sun, 07 Dec 2014 19:33:37 +0100 Original-Received: from 129.red-88-10-128.dynamicip.rima-tde.net ([88.10.128.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 07 Dec 2014 19:33:37 +0100 Original-Received: from ofv by 129.red-88-10-128.dynamicip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 07 Dec 2014 19:33:37 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 55 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 129.red-88-10-128.dynamicip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:dXOSMC6QZN6Xgs9Y+Ky1URtSDTo= 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:179291 Archived-At: Lars Magne Ingebrigtsen writes: > We discussed the opposite problem a while ago -- excluding commands that > only make sense in a specific mode from turning up when doing command > completion. For instance, if you're in the *scratch* buffer, you never > want the `message-send-and-exit' command. > > During the last discussion, we touched on introducing a new form that > would explicitly say what mode a commands belongs to. (Some commands > are applicable generally; most are related to a specific mode.) So > something like > > (defun message-send-and-exit () > "Doc string." > (command message-mode "P") > ...) > > where `command' is just like `interactive', only that it takes a mode > name (or a list of mode names) that says "where it belongs". That's ok, but it is also very handy to have a global statement saying "all the definitions on this file are bound to `message-mode' unless the contrary is explicitly stated." Consider Gnus, for instance. It has lots of stuff that only makes sense within a Gnus buffer, but it has just a few "entry points" that are intended to be used from any context. Having file-level statements would save a lot of work. The schema should work for all definitions that target the user, not just interactive defuns. defcustoms, for instance. Hence, I'm not sure that the `declare' approach mentioned on other message is appropriate. A cookie-based approach seems more effective. The cookie affects the definitions that follow it until a new cookie is found. > The main problem with that approach is that it wouldn't really work for > out-of-tree packages, since introducing something like that requires > Emacs Lisp engine level changes, I think. This is a lesser problem, because the vast majority of noise on M-x comes from packages distributed with Emacs. > But if we had this mechanism, then `M-x m' would only complete to > things that are potentially useful in the current buffer (or globally), > which would be very nice. Yes, and with the right completing engine M-x comes to be much more effective on terms of efficiency and discoverability. BTW, I still volunteer to do the foot job (annotating the files and/or definitions) if a more knowledgeable hacker implements the feature. [snip]