On Aug 26, 2023, at 1:59 PM, Eshel Yaron <me@eshelyaron.com> wrote:

I think the last sentence is a slight over simplification: even before
`foo-ts-mode`s, Emacs didn't have a clean abstraction for a (programming
language) AFAICT, only major modes. And "competing" major modes for the
same language are not a new problem. So these "consumer modes" would
have to be more clever and, hopefully, already have the right methods in
place to deal with the existence of multiple major modes per language.
(Admittedly, `foo-ts-mode`s make this challenge much more pronounced.)

Looking at the specific examples you mentioned: Org mode handles this
well with `org-src-lang-modes`, which is quite more sophisticated than
just reaching out for `LANG-mode`. (BTW in `sweeprolog.el` there's a
similar mechanism for highlighting quasi-

Thanks for these thoughts. I did and do acknowledge multiple prevailing modes for some languages, but IME that has been the exception and now is effectively the rule! The hope is to come up with useful defaults that don’t need tweaking for most users. Your example of `org-src-lang-modes` actually provides a very good illustration of this issue:

org-src-lang-modes ¶

If an Emacs major-mode named <LANG>-mode exists, where <LANG> is the language identifier from code block’s header line, then the edit buffer uses that major mode.

That default may surprise users who have carefully set things up for, say, python-ts-mode in their .py file buffers (python-ts not being a language).