bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Yuan Fu
Subject: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes
Date: Tue, 23 Jan 2024 22:20:49 -0800


> On Jan 21, 2024, at 1:54 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Sat, 20 Jan 2024 16:32:02 -0800
>> Cc: Eli Zaretskii <eliz@gnu.org>,
>> Stefan Monnier <monnier@iro.umontreal.ca>,
>> Dmitry Gutov <dmitry@gutov.dev>,
>> Stefan Kangas <stefankangas@gmail.com>,
>> 68246@debbugs.gnu.org
>> 
>> 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.
> 
> There should be no confusion.  derived-mode-add-parents is documented
> regarding the effects and meaning (and if the current documentation is
> not clear enough, we can clarify it further).
> 
> Moreover, I see no reason to assume FOO-mode runs any mode hook except
> FOO-mode-hook.
> 
>> 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.
> 
> I'm firmly against introducing modes that are not real modes.  We do
> use base-modes where it makes sense, but if such a mode makes no
> sense, introducing it as a means to some end is just going to make
> things more confusing.
> 
> Once again: let's have real practical issues on our hands before we
> look for solutions.  Right now, no such issues are known, since the
> changes barely landed on master.  There's no reason for looking for
> hasty solutions for problems we don't have a good handle on.

Ok, I can see that. I don’t have anything else to add.

Yuan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]