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

[Stefan Kangas]

Dmitry Gutov <dmitry@gutov.dev> writes:

>> The current bug-report*is*  about "finding the language" but the code
>> that needs that info luckily doesn't need "the language" it just needs
>> to know "does the current buffer contain language FOO", which is an
>> easier problem, which I propose to solve with `derived-mode-p`, since
>> that's what we've been using all these years.

I can see the logic in that, however recently the situation has changed
such that many major modes will exist both in standard and treesitter
variants.  If there was ever a good time to take a step back and
consider doing something differently, this would be it, I think.

> TBF, I don't quite like the "subtleness" of this solution. The
> inheritance hierarchy of the modes is an implicit thing, and the fact
> that js-mode-hook would run in js-ts-mode in Emacs 30 but not in Emacs
> 29 would likely trip over a lot of people. Especially those who read
> recipes on the Internet.

I also misunderstood this at first: the major mode hooks would not be
run in Stefan M's proposal.  Perhaps the fact that two of us have had
the same misunderstanding tells us something about the complexity of
that solution.

> Also, "what language is this" does happen to be a meaningful question.
> Eglot's example aside, we can have other tools, databases, etc.

I can't speak for Stefan M but AFAIU he agrees that "which language
corresponds to this mode" is something we want to answer.  He just
proposes using the taxonomy we already have for this, instead of adding
a new one.

I.e. the difference is:

    (derived-mode-p 'foo-mode)   vs    (language-for-mode-p 'foo)
    Monnier                            Távora

Either of those would answer the question "does the current buffer
contain language FOO".  The former reuses the old taxonomy, the right
introduces a new one.

> Finally, if we did have "languages" as an entity, we could have some UI
> for the user to choose the mode for a language - something like Debian's
> 'update-alternatives'. And it would also serve to list the supported
> languages, I guess.

This is a good point.  Also to install extensions for those languages.
Or we could use it to implement the VSCode-like prompt "hey this seems
to be language <foo>, do you want to install support for it?".

At the same time, I don't think anything technically stops us from using
`foo-mode' for this either.  We would just have to be more careful in
how we present it to users, to avoid any confusion.

FWIW, I tend to slightly prefer the solution proposed by João, since it
makes things simpler and less confusing in some ways:

    (derived-mode-p 'foo-mode)

does what you expect, and in every mode where that sexp evaluates to t,
`foo-mode-hook' is also being run.  It also has less potential for
breakage, since only new stuff will use it.

At the same time, I don't want to just discard the argument that simply
sticking with what we have is even simpler.  It obviously is in some
ways.  But I'm not convinced that this level of simplicity doesn't have
a cost that rears its head in the form of complexity elsewhere.

Basically, the biggest weakness of Stefan M's solution is the biggest
strength of João's and vice versa: "backwards-compatibility" (if we can
call it that) vs "clean taxonomy".