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

Previous Next

Package: emacs;

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


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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 68246 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, casouri <at> gmail.com,
 João Távora <joaotavora <at> gmail.com>
Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes
Date: Thu, 11 Jan 2024 05:41:49 +0200
On 10/01/2024 18:11, Stefan Monnier wrote:
>> That's very nice and concise, but it still leaves the issue of users being
>> able to use a common hook for a family of major modes (for the same
>> language).  So I guess some inheritance-based solution is needed?
> We have `define-derived-mode` for that.
> And even those major modes which don't want to inherit via
> `define-derived-mode` can `run-mode-hooks` any additional hook they like.

Hmm, I guess I figured that having a common hook is the more pressing 
issue, since the users would want to try the different available modes, 
and they don't always know where to put their settings - on 
js-mode-hook, or js-ts-mode-hook, or that there is the base mode that 
can be used (which is the case not for every ts mode).

Whereas the packages that use derived-mode-p are most likely less 
numerous than our total set of users who employ customizations in hooks, 
and thus can more easily bear the inconvenience of having to mention 
both js-ts-mode and js-mode, for example.

> Doing it when a mode is defined is easy and "safe".

Indeed, 'run-mode-hooks' is a workable approach, but if we decided on a 
common hook name to use (e.g. if it used the format like 
xyz-language-mode-hook) that might relieve the situation somewhat.

> Changing it after the fact risks introducing breakage (just like my
> `derived-mode-add-parents` does) where the code run via the hook depends
> on specific details of the original mode which aren't available in the
> "pseudo-derived" mode.

Sure. A new hook shouldn't have such a problem, though.

> For this reason my patch only proposes the use of
> `derived-mode-add-parents` since that's the part where a clear need has
> been found.

That makes sense.




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.