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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: João Távora <joaotavora <at> gmail.com>
Cc: 68246 <at> debbugs.gnu.org, casouri <at> gmail.com, monnier <at> iro.umontreal.ca
Subject: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes
Date: Sun, 14 Jan 2024 09:02:25 +0200

> From: João Távora <joaotavora <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  Stefan Monnier
>  <monnier <at> iro.umontreal.ca>,  68246 <at> debbugs.gnu.org
> Date: Sun, 14 Jan 2024 03:10:02 +0000
> 
> Yuan Fu <casouri <at> gmail.com> writes:
> 
> > observe what breaks? Then Joao can either say “I told you” or happily
> > found out that this patch works ok.
> 
> Those are not the only two outcomes.  It might work OK and not break
> anything [*].
> 
> However it is not easy to quantify confused users looking to understand
> the new meaning of things in dir-locals.el.  Or users wondering why they
> need to set Eglot variables in both 'c++-mode-hook' and
> 'c++-ts-mode-hook' when all they see is 'c++-mode' in
> 'eglot-server-programs'.

Those users will hopefully submit bug reports or otherwise complain on
the Emacs mailing lists, and then we will know.

> There are better alternatives to this patch:
> 
> 1. The base modes, which are substantially _already_ in place.  They
>    follow the naming convention <lang>-base-mode.  After giving more
>    thought to your earlier objection about derived modes overriding
>    variables, it doesn't make sense (I can elaborate if you want :-) ).

The recommendation is to use base modes where it makes sense, and the
installed changes around derived-mode-add-parents don't in any way
preclude having a base mode and don't make it harder.  But I don't
think we should force everyone in this situation to invent a base mode
as the sole means for solving this.

> 2. Explicitly associating some major modes with languages or file types.
>    This doesn't seem hard and other further uses like suggesting modes
>    or packages to a new user based on languages have been proposed.

This is IMO a heavier and more thorough change, especially since Emacs
doesn't have the notion of "language".  This discussion shows that its
advantages are not evident, and moreover we don't even have a clear
shared view what will that entail.

So I think Yuan is right: let's see what happens with what we have on
master, and take it from there.

Previous Next

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