From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Leaving out non-applicable commands on Mx Date: Fri, 08 Jan 2016 23:14:14 -0500 Message-ID: References: <87mvszdp6b.fsf@gnus.org> <8737u9kv6f.fsf@russet.org.uk> <87fuy7hdc6.fsf_-_@wanadoo.es> <87bn8vh8q4.fsf@wanadoo.es> <877fjjh51p.fsf@wanadoo.es> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1452312889 7982 80.91.229.3 (9 Jan 2016 04:14:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 Jan 2016 04:14: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 05:14:39 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 1aHkvG-00067v-KM for ged-emacs-devel@m.gmane.org; Sat, 09 Jan 2016 05:14:38 +0100 Original-Received: from localhost ([::1]:38926 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHkvF-00046J-9J for ged-emacs-devel@m.gmane.org; Fri, 08 Jan 2016 23:14:37 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33230) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHkvC-00046B-2g for emacs-devel@gnu.org; Fri, 08 Jan 2016 23:14:34 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aHkv8-0001Hq-Rt for emacs-devel@gnu.org; Fri, 08 Jan 2016 23:14:33 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:49193) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHkv8-0001HP-L4 for emacs-devel@gnu.org; Fri, 08 Jan 2016 23:14:30 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aHkv2-0005xG-NW for emacs-devel@gnu.org; Sat, 09 Jan 2016 05:14:24 +0100 Original-Received: from 184-175-3-20.dsl.teksavvy.com ([184.175.3.20]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Jan 2016 05:14:24 +0100 Original-Received: from monnier by 184-175-3-20.dsl.teksavvy.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Jan 2016 05:14:24 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 39 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 184-175-3-20.dsl.teksavvy.com User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:T7JzJDThpkZyRWDU7mk/y1lN88k= 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:197882 Archived-At: > 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 This is the crucial part, indeed. > Maintaining all this information on an external resource is > unmanageable, it simply wont work. It's better if it's managed directly in the packages's sources, indeed, but it will still work if the info is only available for some packages, and for many packages, this info could be managed externally with fairly little harm. So while I agree that the right way to do it is "in core", I think it'd still be useful if packaged as a GNU ELPA package (or a bundled package but fully self-contained). Also, the new package could provide some function/macro which core packages may use conditionally. E.g. Gnus could "declare its mode-specific commands" using this new macro/function (if/when defined), so that it provides support for the "filtering-m-x" package. > So yes, the Elisp source files need to be annotated (that's the work > I'm volunteering for). An important part of this work is on the design of the "annotation system" so that it's lightweight. E.g. ideally, this same annotation system should be able to wrap the corresponding commands so that they signal an error if you happen to trigger them in the wrong mode (currently many commands do such a check by hand, so the annotation system could *replace* this manual test). Being "able to" doesn't mean that it should necessarily do so, just that the design would probably be better if it took into account such related-but-slightly-different use-cases. Stefan