emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Why tree-sitter instead of Semantic? (was Re: CC Mode with font-lock-max


From: Lynn Winebarger
Subject: Why tree-sitter instead of Semantic? (was Re: CC Mode with font-lock-maximum-decoration 2)
Date: Tue, 9 Aug 2022 20:22:00 -0400

On Tue, Aug 9, 2022, 1:58 PM Eli Zaretskii <eliz@gnu.org> wrote:
> Date: Tue, 9 Aug 2022 17:43:31 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
>
> But I don't like your proposed solution, which you've mentioned several
> times, namely to make level 3 more like level 2.  I.e., to deliberately
> reduce its accuracy in the name of speed.

Then I guess CC Mode will remain slow, until maybe tree-sitter
integration will fix it.  Sadly.

I have a related question.  I have this programming mode derived from CC mode.  The formal syntax is on the one hand much simpler than anything like C++, but I find trying to capture the constructs by the regular _expression_ rules employed by font lock very difficult to get right.
I have a re-entrant LALR grammar for this language that I intend to use with Semantic to get proper handling of all constructs.  That's one of the main reasons I wanted to be sure to get as efficient a baseline system as possible (and can now proceed with).

I'm curious, though, as to why Semantic/CEDET seems to have been superceded by external solutions like tree-sitter or LSP-based (non-emacs) servers.  One of the draws of Emacs for me is the "batteries included" nature of it having Emacs Lisp built in.  Is there a downside to using Semantic as the basis for improving my derived mode that's non-obvious?  Would producing a threaded code parser instead of a straight table driven parser be a better approach with the native compilation option now available?

I also use this mode to fontify a REPL session for this language, which has pretty awful performance when producing tracing output that hits 1-5 hundred K lines in a buffer, which is why this narrowing discussion interests me, even though the buffers in question don't have particularly long lines.  It just chews up memory if I try to jump from the end of the buffer to the beginning. Or at least it did in v24.3.

Thanks,
Lynn






reply via email to

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