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: Eli Zaretskii
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@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Stefan Monnier
>  <monnier@iro.umontreal.ca>,  68246@debbugs.gnu.org
> Date: Sun, 14 Jan 2024 03:10:02 +0000
> 
> Yuan Fu <casouri@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.





reply via email to

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