[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: |
João Távora |
Subject: |
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@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
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes, (continued)
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes, Eli Zaretskii, 2024/01/05
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes, João Távora, 2024/01/05
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes, Eli Zaretskii, 2024/01/05
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes,
João Távora <=
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes, Eli Zaretskii, 2024/01/05
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes, João Távora, 2024/01/05
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes, Eli Zaretskii, 2024/01/05
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes, João Távora, 2024/01/05
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes, Stefan Monnier, 2024/01/05
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes, João Távora, 2024/01/05
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes, Stefan Monnier, 2024/01/05
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes, João Távora, 2024/01/06
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes, Stefan Monnier, 2024/01/06
- bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes, João Távora, 2024/01/06