Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Eli Zaretskii]

> Date: Thu, 18 Feb 2021 19:57:59 +0000
> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > 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_.