From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Current mode command discovery Date: Sat, 20 Feb 2021 09:36:43 -0500 Message-ID: References: <87v9aubm96.fsf@gnus.org> <83v9at9xel.fsf@gnu.org> <87wnv8xlqa.fsf@gnus.org> <838s7o9g90.fsf@gnu.org> <87im6revhq.fsf@tcd.ie> <83im6r98qd.fsf@gnu.org> <87k0r7uade.fsf@gnus.org> <83eehf978r.fsf@gnu.org> <87ft1vu9hd.fsf@gnus.org> <838s7n95pf.fsf@gnu.org> <8735xvu7sx.fsf@gnus.org> <834kib94ha.fsf@gnu.org> <874kibh9mu.fsf@telefonica.net> <83o8gi7lh2.fsf@gnu.org> <871rdebmmh.fsf@telefonica.net> <831rdc4epn.fsf@gnu.org> <87o8ggte2j.fsf@gnus.org> <875z2mq3s4.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="14702"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: ofv@wanadoo.es, chad , EMACS development team , Eli Zaretskii , Richard Stallman To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Feb 20 15:38:04 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 1lDTOV-0003gg-CJ for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Feb 2021 15:38:03 +0100 Original-Received: from localhost ([::1]:33216 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lDTOU-0001Se-EN for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Feb 2021 09:38:02 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55304) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lDTNP-0000wA-D0 for emacs-devel@gnu.org; Sat, 20 Feb 2021 09:36:55 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:40275) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lDTNM-0006lr-Mo; Sat, 20 Feb 2021 09:36:54 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 858B48078F; Sat, 20 Feb 2021 09:36:50 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id C22C3807E9; Sat, 20 Feb 2021 09:36:44 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1613831804; bh=xe+F91FsreMu4JAiCidJI2TwHymybKFjDBah6mrqUiY=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=WEzX0siBul98RC27jHTjwrUOqsN/Ayt6a2tKHs1knl4g5f2VPc4fvrKD3ntHmnsnm MpZY2nghZeeSeeI5NDctroPrsSCv7WH276s+5lMl/1CoM68tf1p+8imoMV4Yb+uihZ EsZBW4sheZQTq+tcPaInC1JhqqtGZwRsnHjZ4hQl8LT92KNdqnyPd++A/CnmefgtCG qOhVS9oHL6qJQ10VTmy6oN7lv3jTrfDdweew0z7ndofqRNQ+n20t4ctthAVl7kL3Zg XubJsQDAByjLyhFpjX0gsl3uovxL3xAt3G3YL3k2RfV6EsHqNIxc/B5uinH61NgUpd ju+1ZivRwL9+w== Original-Received: from alfajor (unknown [216.154.41.47]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 75D48120147; Sat, 20 Feb 2021 09:36:44 -0500 (EST) In-Reply-To: <875z2mq3s4.fsf@gnus.org> (Lars Ingebrigtsen's message of "Sat, 20 Feb 2021 14:15:07 +0100") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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:265314 Archived-At: >>> It reminds me of the disabled-command-function machinery, or at least the >>> concept. Maybe there's a decent way to leverage the two concepts into a >>> similar UI pattern? > > Yes, that makes sense. If we do add a "Really execute this command from > this other mode?" thing, then being able to permanently disable the > warning, like with disabled commands, would be nice. > >> Talking about integration with other pre-existing functionality: how >> 'bout merging the new command enable functionality with the >> `menu-enable` symbol property? > > That does seem natural, doesn't it? > > However, I'm not quite sure about the proposed usages for using > completion-predicate for commands that are currently not usable. In > menus, the commands are still there -- they're just greyed out, so you > can tell that if you just do something (mysterious), then they'll be > enabled. > > In `M-x' completion, that's not really a natural... thing? (Unless > using a display method that displays all completions, no matter what the > predicate, but sort/display/colour them differently, as Eli suggested.) I think that goes back to my point about defining what the "completion-predicate" means. I don't think it should mean "don't list me in M-x" but something more like "doesn't make sense to use now in this way". Then the UI is free to decide to still show it but greyed out, or to not show it at all, or to show it but "further down" or something, and different UIs can make different choices. [ BTW, maybe the predicate should take an extra arg indicating telling whether we want to know if the command would be meaningful when run from `M-x` or when run from a menu or when run from a key (in case we want to "grey out" bindings in things like ` C-h`). ] It makes sense for M-x to "not list it at all" yet for the menu bar to still show it (as greyed out) because the circumstances are different (the fact that the entry is present in the menu is proof that the command is sometimes relevant, just not currently). Stefan