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

Previous Next

Full log

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

From: João Távora <joaotavora <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 68246 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes
Date: Fri, 5 Jan 2024 15:16:30 +0000

On Fri, Jan 5, 2024 at 1:26 PM Eli Zaretskii <eliz <at> gnu.org> wrote:

> That's right -- but it's justified.  The commonality is usually either
> very thin or almost non-existent.  If you think about it, you will
> understand: where the traditional modes use regexps and syntax-ppss,
> the TS modes use parser-related primitives.

I _have_ thought about it.  And I started from evidence that
not everything a major mode dedicated to a language supplies
is directly related to the parser implementation. Many things
are, but not all.  So reimplementing a full major mode just
for changing the praser backend might not make sense.

> How can you find common
> grounds between these so different bases for implementation?

Very easily, I think.  Stefan's patch is one such example.
What it is fixing?  Tools that want this common ground and haven't
found it, of course!

But there's also my own hookage that I had to move from c++-mode
to c++-ts-mode.  Stefan's patch doesn't fix that.

Take inserting comments via comment-dwim.  Or invoking LSP in
any mode for another example.  Or consulting documentation.  Or
anything we've built (including muscle memory) that lives on
top of syntactic abstractions like forward-sexp.  Basically any
preference that the major-mode expresses regarding an orthogonal
facility (minor mode or not) should, in principle, be shared.

At the very least, it seems a common hook would be useful, and that's
what an empty foo-base-mode() would give.  It _also_ gives you the
possibility to fix this more elegantly (well, at the expense of
yet another naming convention).

> > > It should modify our .dir-locals.el and Eglot's database to
> > > remove special entries for TS modes
> >
> > As Dmitry mentioned: if that is done just like that it will
> > break Eglot's support of ts modes in any Emacs which doesn't
> > have Stefan's patch.
>
> Then Eglot (or maybe compat.el) will have to provide compatibility
> shims.

Yes, if any wants to update Eglot to use compat.el, I think
it would be useful in this and more situations.

João

Previous Next

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