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