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

[Yuan Fu <casouri@gmail.com>]

> On Jan 20, 2024, at 2:16 AM, João Távora <joaotavora@gmail.com> wrote:
> 
> On Sat, Jan 20, 2024, 07:04 Eli Zaretskii <eliz@gnu.org> wrote:
> 
>>> After it lands, derived-mode-p will cease to mean "A derived
>>> from B via defined-derived-mode, so you can trust hook for B
>>> runs in hook for A and a lot of other things".  It will mean
>>> something else.
>> 
>> Indeed, and it was not meant to mean what you suggest it should mean.
> 
> Then pray tell.  What will it mean exactly?  This patch has no doc
> yet (last I saw).
> 
>>> * if it lands, we should document very well what that new meaning
>>>  of "<lang>-mode" is.  Also make some "provided-mode-walk-parents"
>>>  so that at least problem 2 can be solved, by string-matching
>>>  the symbol name of what will now be an even more enshrined
>>>  convention.  As to problem 3,   maybe, it can be written off to
>>>  "major-mode-remap-alist" (which I doubt will ever see much
>>>  adoption)
>> 
>> Feel free to suggest improvements and clarifications to the
>> documentation in these matters.
> 
> I don't understand the vision behind this patch.  It has do doc
> yet.  Despite your attempts to wrap this up and shut me up
> I'm trying to at least converse with the author to expound it.
> Often it's when trying to explain something in plain English
> that to see how suitable it is.
> 
>>> * if it doesn't land, we should look at some solution that solves
>>>  1 2 and 3 cleanly.   I think Dmitry's patch is a decent start.
>> 
>> Since it will land, there's no need yet to look for alternatives.
> 
> If you've already decided that, just install it and save
> us all some time.
> 
>> We will consider alternatives or other ways to fix this when
>> we have data
> 
> I've given you data: at least Eglot and markdown mode have brittle
> hacks this patch does nothing for.  You have chosen to ignore it.
> Also I've explained how potentially dangerous this patch is to
> Eglot customizations.
> 
>> We already use base modes where it makes sense.  It sounds like your
>> opinion is that we should use it much more radically, with which I
>> disagree and will object to introduction of base modes that server no
>> useful purpose by themselves.
> 
> So solving the common language-detection problem, deduplicating
> hooks and dir-locals is not serving a purpose "by oneself"?
> Indeed you make up an undefined high bar of "by oneselfness"
> you get to choose what clears it and doesn't.  But it doesn't
> make your argument an argument.


[I’ve been loosely following the thread so this might have been brought up and I missed it]

IIUC Stefan’s patch is trying to use xxx-mode to represent “mode for xxx in general”, sort of like the keys in major-mode-remap-alist. And IIUC Joao and Dmitry are not very comfortable with it because (mode-A R mode-B) where R is derived-mode-p implicitly means mode-B runs mode-A’s hooks and major mode body, and this patch would break that, which would bring a lot of confusion.

Instead of using xxx-mode, can we set common-xxx-mode to the parent of both xxx-mode and xxx-ts-mode? Or maybe abtract-xxx-mode, or just xxx, the name doesn’t matter. The point is this is just a symbol and doesn’t have hooks and other implicit things a major mode have. It’s still a bit confusing, but it should be less confusing. We can also add a variable common-mode-list or abstract-mode-list so these symbols don’t seem to come out of nowhere.

Yuan