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