From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...] Date: Thu, 18 Feb 2021 22:04:56 +0200 Message-ID: <83o8gh3zx3.fsf@gnu.org> References: <83h7ma7k5y.fsf@gnu.org> <87tuqa1ogn.fsf@gnus.org> <83tuqa5ug7.fsf@gnu.org> <87eehdy5ie.fsf@gnus.org> <87tuq98gdl.fsf@telefonica.net> <87pn0x8f8l.fsf@telefonica.net> <83wnv540xq.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30825"; mail-complaints-to="usenet@ciao.gmane.io" Cc: ofv@wanadoo.es, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Feb 18 21:07:31 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 1lCpaF-0007uq-A4 for ged-emacs-devel@m.gmane-mx.org; Thu, 18 Feb 2021 21:07:31 +0100 Original-Received: from localhost ([::1]:51582 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lCpaE-00057n-7v for ged-emacs-devel@m.gmane-mx.org; Thu, 18 Feb 2021 15:07:30 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43284) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lCpXb-0003UZ-5I for emacs-devel@gnu.org; Thu, 18 Feb 2021 15:04:47 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:49340) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lCpXZ-0003Ln-Kf; Thu, 18 Feb 2021 15:04:45 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1361 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lCpXY-0002wG-U8; Thu, 18 Feb 2021 15:04:45 -0500 In-Reply-To: (message from Alan Mackenzie on Thu, 18 Feb 2021 19:57:59 +0000) 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:265187 Archived-At: > Date: Thu, 18 Feb 2021 19:57:59 +0000 > Cc: ofv@wanadoo.es, emacs-devel@gnu.org > From: Alan Mackenzie > > > > In other words, this is a flaw in the idea of abusing the interactive > > > spec for miscellaneous information. > > > No, this issue is common to _any_ implementation of tagging commands > > with relevant mode, not just the implementation via the interactive > > spec. > > If the tagging information were on, say, a symbol property, there would > be no great problem in updating it at run time. The main problem that bothered me in this sub-thread was not the update itself, it's the need to be aware that an update is needed. There's no way to automate that decision, so we cannot program the build process to warn about possibly changed relevance criteria. It will have to be a human decision, and those are easily forgotten. > > I don't think this problem is real, because the idea is that commands > > which are relevant only to a _single_ mode will be tagged by that > > mode. Commands which are useful in several modes will remain > > untagged. > > So CC Mode, and in particular, third party modes derived from it, will > remain outside the scope of this feature? That surely cannot be the > intention? No, CC mode and its descendants are one mode for the purpose of this discussion, because the filtering checks whether the current major mode is the one recorded in the tag _or_its_descendants_.