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

["João Távora" <joaotavora@gmail.com>]

On Mon, Jan 15, 2024 at 8:51 PM Dmitry Gutov <dmitry@gutov.dev> wrote:

> > I don't think there's anything magical about a base mode.  But I like your
> > solution too.
>
> As "magical", I meant the original patch for this report. I wouldn't
> mind the "base mode" approach, but I guess its still suffers from not
> being suitable for using with earlier Emacs versions.
>
> And every programming mode will have to come with -base-mode defined,

We could define them all in batch in a macro, that's not too bad.  And
then let the existing fleshed out ones overwrite those definitions by
making sure to load them later.

The main advantages of the foo-base-mode approach is that:

* it is easily grokkable by everybody, as it is very simply based on
  simple inheritance, which everybody knows already.

* there's already a fair number of such modes in the tree.

But I do like your patch better, it seems pretty useful to introduce the
language concept, as it solves this and more problems more cleanly.  So
let's see where that goes.

> This choice is coupled with the corresponding logic in 'buffer-language'
> (whether to keep the replace-regexp-in-string branch).

Yes.  I think we should err on the side on convenience.  What exactly are
the defects can we get?  I can't see anything else but the tuareg-mode, and we
can plug that on our side.  Maybe you can see more.

> Are there specific uses for get-mode-for-language when there is no
> existing buffer?

Yes, I'd say this markdown-mode use is exactly that.  Markdown inserts
some text into a buffer and all it knows is the language it's supposed
to fontify it with.  The major mode has that logic, so it must invoke
the correct (and preferred) major-mode function.

Another use is allowing the user to choose major modes for languages,
say from a tutorial or wizard or at Emacs startup.  Say, I prefer
ruby-ts-mode for Ruby, but c++-mode for C++.  It'd be helpful to summarize
those preferences.

> We could have both functions: buffer-language and get-language-for-mode
> ('get-mode-language'?). Or define one initially and add the other as needed.

Yes.  buffer-language isn't bad, it's a useful helper.  But buffer-language
should be just

   (with-current-buffer buffer (get-language-for-mode major-mode))

Right?  Modulo some caching if it turns out to be very inneficient
(which I really doubt)

João