bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes

[João Távora]

Eli Zaretskii <eliz@gnu.org> writes:

>> However it is not easy to quantify confused users looking to understand
>> the new meaning of things in dir-locals.el.  Or users wondering why they
>> need to set Eglot variables in both 'c++-mode-hook' and
>> 'c++-ts-mode-hook' when all they see is 'c++-mode' in
>> 'eglot-server-programs'.
>
> Those users will hopefully submit bug reports or otherwise complain on
> the Emacs mailing lists, and then we will know.

You also know this doesn't always happen.  A confused user has a certain
probability of using those channels, and that is most definitely not
100%.  But I will make sure to send any Eglot confusion this way yes.

>> There are better alternatives to this patch:
>> 
>> 1. The base modes, which are substantially _already_ in place.  They
>>    follow the naming convention <lang>-base-mode.  After giving more
>>    thought to your earlier objection about derived modes overriding
>>    variables, it doesn't make sense (I can elaborate if you want :-) ).
>
> The recommendation is to use base modes where it makes sense, and the
> installed changes around derived-mode-add-parents don't in any way
> preclude having a base mode and don't make it harder.  But I don't
> think we should force everyone in this situation to invent a base mode
> as the sole means for solving this.

We can invent for them.  There's very little to invent.  Earlier you
seemed to view a base mode as a receptacle for common code.  It _can_ be
that (and _should_ where applicable).  But it doesn't _have_ to be.  An
empty base mode is useful just for its hook and its behaviour in
dir-locals, for example.

So, find two modes for the same language foo, make an empty
foo-base-mode:

   (define-derived-mode foo-base-mode prog-mode "Base mode for Foo")

Then ask the authors of 'foo-mode', 'foo-ts-mode', 'foo-nongnu-mode',
etc to put foo-base-mode in their mode definitions.  If they refuse or
are unresponsive, consider insinuating 'foo-base-mode' in them (after
asking why, of course).  If this insinuation is acceptable for complex
"extra parents", why shouldn't it be acceptable for normal parents?

This is not technically hard to do, a simple add-function works (and
it's also self-documenting).

>> 2. Explicitly associating some major modes with languages or file types.
>>    This doesn't seem hard and other further uses like suggesting modes
>>    or packages to a new user based on languages have been proposed.
>
> This is IMO a heavier and more thorough change, especially since Emacs
> doesn't have the notion of "language".  This discussion shows that its
> advantages are not evident, and moreover we don't even have a clear
> shared view what will that entail.

It's not an extremely heavy change, at least not when compared to extra
parents at least.  But yes, we should be careful how to implement it.

The advantages are evident though.  Eglot and Yasnippet would be much
simpler to configure.  Even simpler with a language-specific hook.

But "base mode" approach, which has a significant deployment already, is
basically the "languages approach" in slightly more verbose naming.

> So I think Yuan is right: let's see what happens with what we have on
> master, and take it from there.

OK, experimenting in master is what master is good for, after all.
Could be effective (even too much, as the recent register imbroglio
clearly showed).  But I think the practical subtleties (like dir-locals
merging, potential Eglot fallout) need to be highlighted somewhere or at
least announced in emacs-devel.

Also I for one would like to understand the how consistently these
extra-parents are going to be used in the future: the symbol named
'foo-mode' is about to be promoted to something above just _a_
major-mode for Foo, and I'd like to see that cleanly described
somewhere.

João