emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [External] : Re: command mode-specificity [was: scratch/command 064f


From: Alan Mackenzie
Subject: Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]
Date: Thu, 18 Feb 2021 19:57:59 +0000

Hello, Eli.

On Thu, Feb 18, 2021 at 21:42:57 +0200, Eli Zaretskii wrote:
> > Date: Thu, 18 Feb 2021 17:35:44 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: emacs-devel@gnu.org

> > > It would be nice to update the info at runtime, but IMO it is beyond
> > > what is reasonable to ask.

> > 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.

> > > In the future the system can be expanded so a mode can declare that it
> > > uses specific commands (or all of them) from some other mode, but that
> > > is not required now for the filtering to be effective.

> > No, not from some other mode.  We're talking about commands shared by a
> > set of modes known only at runtime.  If the list of modes cannot be
> > updated at runtime, this is a deficiency in the design.

> 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?

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]