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

[Stefan Monnier]

> That might mean that a content-type corresponds to a number of languages,
> just like a language corresponds to a number (open set) of major modes. But
> I don't see how. Please enlighten.

All three are taxonomies that are related to the content of the buffer.
They are almost identical in general, but differ in details because
taxonomies are not an exact science and those three have each been
defined separately, so the arbitrary decisions that are involved in
making a taxonomy have not been the same.

> The side-effect of this approach is that we basically declare a mode's
> language twice: once in the attribute above, and once in the
> major-mode-remap-alist which is put into autoloads. But it's probably
> minor enough.

Again: not necessarily.  You're making assumptions about what the source
code will look like, but we get to decide what the source code looks
like by defining functions/macros.  Even if the information is stored in
a redundant way, that doesn't mean the surce of that information can't
be the same.

So if/when such a duplication proves to be a problem, I can't see why it
would be difficult to fix it.

>> Cue the patch I submitted when I open this bug report 🙂
>> Now `<LANG>-mode` is again included in `derived-mode-all-parents` for
>> those new modes.
>
> If the language is called <LANG>-lang instead (of without suffix), then the
> major mode could also run the language-specific hook, which in your patch it
> cannot do.

I don't follow: why would the name of the mode (and hence hook) make it
harder/easier/possible to run the hook?

> I think I've included some thoughts on this subject in my previous
> email. They don't seem to be quoted/commented on here.

I didn't have anything to comment on them :-)

>>> The major-mode could be fundamental-mode. If the language were to be
>>> specifiable through settings external to major modes, we could still do
>>> useful things while in fundamental-mode (e.g. do some useful editing with
>>> Eglot, provided it supports indentation and completion), or suggest which
>>> major modes to install from ELPA.
>> I don't see the interest of using specifically `fundamental-mode` for
>> that.  In any case, this seems too hypothetical at this stage to have
>> a good idea of what we'd need in such circumstances.
> The latter feature (suggest which major modes to install) has come up
> recently. It's not that difficult to implement (with a whitelist of
> packages),

I'm with you so far (my `gnu-elpa` package intended to provide
a possible solution for that).

> and fundamental-mode is most likely *the* major mode which would
> be used until the suitable major mode is installed.

Here I don't see it.

>> Anyway, as I mentioned elsewhere, I think this discussion of "languages"
>> is only tangentially related to my proposed patch.  There is some
>> overlap, but they serve different purposes, and they're not
>> mutually exclusive.
> I think the "languages" feature seems to cover the same functionality as
> your patch,

In the longer term, there might be a fair bit of overlap, yes, tho it
all depends on how your proposal works out in the end.
My patch is a short term solution with no new API.


        Stefan