GNU bug report logs - #68246
30.0.50; Add non-TS mode as extra parent of TS modes

Previous Next

Full log

Message #442 received at 68246 <at> debbugs.gnu.org (full text, mbox):

From: Yuan Fu <casouri <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 68246 <at> debbugs.gnu.org, dmitry <at> gutov.dev, stefankangas <at> gmail.com,
 João Távora <joaotavora <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: 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 <at> gnu.org> wrote:
> 
>> From: Yuan Fu <casouri <at> gmail.com>
>> Date: Sat, 20 Jan 2024 16:32:02 -0800
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,
>> Stefan Monnier <monnier <at> iro.umontreal.ca>,
>> Dmitry Gutov <dmitry <at> gutov.dev>,
>> Stefan Kangas <stefankangas <at> gmail.com>,
>> 68246 <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.