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

Previous Next

Full log

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

From: Yuan Fu <casouri <at> gmail.com>
To: João Távora <joaotavora <at> gmail.com>
Cc: 68246 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 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: Sat, 13 Jan 2024 20:00:13 -0800

> On Jan 13, 2024, at 7:10 PM, João Távora <joaotavora <at> gmail.com> wrote:
> 
> 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'.

I agree. “Not confusing” is very valuable for Emacs, or any system.

> So it might not break, and even have some reasonalby solid theoretical
> backend beautifully enshrined in documentation.  But is it the right
> thing?  I think not.  Unless I'm mistaken it's already proven to be
> confusing even to two seasoned Emacs hackers in this thread (and I'm not
> including myself).
> 
> And it doesn't do much for two main problems that were presented at the
> base: Eglot and Yasnippet.  I.e. Eglot still inescapably needs to report
> the language to the server and Yasnippet would be better and much
> simpler if it could organize snippets by languages instead of major
> modes.
> 
> 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 :-) ).

Yeah, I made a mistake there, as Stefan corrected. Still, the other part of the argument holds: creating a base mode needs cooperation from every involved major modes’ authors. We can’t unilaterally create base modes and make third-party major modes to base on it. I’m not saying it wouldn’t work, it would, but we can’t apply it everywhere.

> 
> 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.
> 
> Nevertheless, I suspect that you want a solution to some real problem
> happening today Can you say in your own words what that problem is?  As
> I explained, I don't have a good idea of the cases besides Eglot,
> Yasnippet and possibly/likely Lsp-mode.

I think I want the same thing as you do: right now many packages have a central database that maps major mode to some mode-specific configuration. IIUC, for Eglot, that’s the server’s arguments; for Yasnippet, that’s the snippets. I can think of other examples like hs-special-modes-alist in hideshow.el. I’m sure there are countless third-party packages that uses a central database rather than a buffer-local variable for their mode-based configuration.

For those databases, I want lang-ts-mode to use the same configuration for lang-mode.

More importantly, I hope the countless databases in all these third-party packages to continue to work. Adding language tags for major modes is nice and all, but a) third-party packages has to change their database to make use of it, and b) third-party major modes need to add language tags. 

That’s why I like major mode names a bit better. Both major mode names and language tags are leaky abstraction to some degree, so might as well use the one that already exists.

> [*]: It's possible though.  One way would be for a user to have added
> entries to 'eglot-server-programs' for non-TS 'foo-mode' specifically
> with 'add-to-list', a very common practice.  Her later 'foo-ts-mode'
> entries would be shadowed.  Unlikely, perhaps?  But what about variables
> set in '.dir-locals.el' for 'foo-mode' and 'foo-ts-mode'?  Suprising
> "magic" aside, it seems these settings will be merged (right?) in
> 'foo-ts-mode' buffers.  But does this make sense every time?  Even in
> our own dir-locals.el there are some settings for 'c-mode' (unrelated to
> cc-mode.el) that are not in the 'c-ts-mode' section, but after Stefan's
> patch it will be as if they were.  I think it's unavoidable we'll catch
> some users off-guard and break things.

Right… Sometimes we want lang-mode and lang-ts-mode to share some config, and sometimes we don’t. I don’t have good ideas right now :-)

Yuan

Previous Next

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