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

[Alan Mackenzie]

Hello, Óscar.

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

> > Hello, Robert.

> > On Thu, Feb 18, 2021 at 18:55:59 +0100, Robert Pluim wrote:
> >> >>>>> On Thu, 18 Feb 2021 17:35:44 +0000, Alan Mackenzie <acm@muc.de> said:

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

> >> Iʼm having a hard time thinking of an example, eg you might not know
> >> which of the modes provided by the cc-mode package the user actually
> >> uses, but adding all of them to the relevant commands can be done
> >> beforehand. Can you expand?

> > No, it can't be done.  There is no list of "all" CC Mode packages.
> > They're largely created and distributed by third parties, i.e.
> > they're outside the orbit of Emacs development.  There is no complete
> > list of them.

> AFAIR those modes derive from c-mode, right? It that is so, the
> commands are automatically applicable to them.

Not in the sense of define-derived-mode, no.  csharp Mode isn't a "sort
of Java Mode", so it wouldn't make sense to use define-derived-mode here.
So the commands aren't automatically applicable to these modes.

> > For this facility to be general, the list of modes MUST be changeable at
> > runtime.

> Why at runtime? (apart that compile-time and run-time is a somewhat
> diffuse distinction for Elisp) Can't the mode have declarations like
> thos I mentioned?

At runtime, meaning at the time when the user builds or loads csharp
Mode.  This is not the build time of Emacs as a whole.

I'm not sure which declarations you mean, but it isn't reasonable to
expect third party maintainers to change their source code for this.

> But apart from that, I see no big problem about changing the list of
> modes at runtime, although I don't know the current implementation, so
> I hope someone else can clarify this.

The current implementation is that the lists of modes has been
shoe-horned onto the `interactive' form.  This may be a candidate for
going into read-only memory, I don't know.

-- 
Alan Mackenzie (Nuremberg, Germany).