From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Matt Armstrong Newsgroups: gmane.emacs.devel Subject: Re: Current mode command discovery Date: Wed, 17 Feb 2021 10:21:23 -0800 Message-ID: References: <87eehfnd83.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2962"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Lars Ingebrigtsen , =?utf-8?Q?=C3=93scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Feb 17 19:22:49 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 1lCRTN-0000ei-6i for ged-emacs-devel@m.gmane-mx.org; Wed, 17 Feb 2021 19:22:49 +0100 Original-Received: from localhost ([::1]:41508 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lCRTM-0004vT-9J for ged-emacs-devel@m.gmane-mx.org; Wed, 17 Feb 2021 13:22:48 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60490) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lCRSD-00045j-J4 for emacs-devel@gnu.org; Wed, 17 Feb 2021 13:21:37 -0500 Original-Received: from relay1-d.mail.gandi.net ([217.70.183.193]:31991) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lCRS8-0006C8-GI for emacs-devel@gnu.org; Wed, 17 Feb 2021 13:21:37 -0500 X-Originating-IP: 24.113.169.116 Original-Received: from matts-mbp-2016.lan (24-113-169-116.wavecable.com [24.113.169.116]) (Authenticated sender: matt@rfc20.org) by relay1-d.mail.gandi.net (Postfix) with ESMTPSA id D14F0240002; Wed, 17 Feb 2021 18:21:27 +0000 (UTC) In-Reply-To: <87eehfnd83.fsf@gnus.org> Received-SPF: pass client-ip=217.70.183.193; envelope-from=matt@rfc20.org; helo=relay1-d.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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:265036 Archived-At: To your original queston of "should we build a command like this?" I suspect it just needs to be prototyped to see how it feels. I have many times totally failed to appreciate how useful a thing could be *before* I tried it out. I know that, personally, I have't felt I wanted such a thing so far. Command name prefixes in M-x do a pretty good job (for me). Lars Ingebrigtsen writes: [...] > Hm... there's two obvious sources if information about what commands > "belong" to a mode: There's the key bindings, and then there's the new > mode tagging. We could perhaps use both in this new command? I.e., if > somebody has gone to the trouble to add a command to the keymap of the > mode, then it's probably pretty useful for that mode? A third possible signal is the command name prefix. A fourth signal could be a new 'all mode annotation that means "generally useful" regardless of mode. I say "signal" because I'm not sure what you're imagining: a exploration/discoverability tool or a menu of stuff absolutely known to work here commands. [...] > So: Tagging by mode conveys more information to the system than just > having predicates, and we can use that. This also means that > > (declare (modes ...)) > > should be implemented differently than it is today (which is just > slapping a predicate onto the symbol-plist). Declarative programming for the win. Could the (declare (modes ...)) and the new (interactive ... modes) be unified? I understand that they do different things today, but they're both called "modes" and the difference is pretty subtle. If they stay separate, perhaps rename to (declare (completion-modes ...))?