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 17:35:44 +0000

Hello, Óscar.

On Thu, Feb 18, 2021 at 18:20:26 +0100, Óscar Fuentes wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > On Thu, Feb 18, 2021 at 17:55:50 +0100, Óscar Fuentes wrote:
> >> Alan Mackenzie <acm@muc.de> writes:

> >> > What about commands used by a small number of modes, but that set of
> >> > modes is only known at runtime?

> >> > Are we supposed to amend a command's interactive spec at runtime?

> >> No.

> > What, then?  Do you have a positive suggestion?

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

> This feature works on the pretense that if a command has a real
> potential for being used outside of its mode, it shall not be annotated
> as mode-specific. The scenario you described indicates that the
> application realm of the command is open-ended.

Not particularly.  I was thinking of commands such as
c-toggle-comment-style, whose realm is strictly constrained.

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

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

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