GNU bug report logs -
#68246
30.0.50; Add non-TS mode as extra parent of TS modes
Previous Next
Reported by: Stefan Monnier <monnier <at> iro.umontreal.ca>
Date: Thu, 4 Jan 2024 22:12:01 UTC
Severity: wishlist
Found in version 30.0.50
Done: Stefan Monnier <monnier <at> iro.umontreal.ca>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
> On Jan 20, 2024, at 2:16 AM, João Távora <joaotavora <at> gmail.com> wrote:
>
> On Sat, Jan 20, 2024, 07:04 Eli Zaretskii <eliz <at> 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
This bug report was last modified 1 year and 104 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.