emacs-devel
[Top][All Lists]
Advanced

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

Re: A possible way for CC Mode to resolve its sluggishness


From: Stephen Leake
Subject: Re: A possible way for CC Mode to resolve its sluggishness
Date: Sun, 28 Apr 2019 09:32:25 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (windows-nt)

Alan Mackenzie <address@hidden> writes:

>> Maybe if we want to speed things up, we should consider a new parsing
>> engine (instead of parse-partial-sexp and syntax-tables) based maybe on
>> a DFA for the tokenizer and GLR parser on top.  That might arguably be
>> more generally useful and easier to use (in the sense that one can more
>> or less follow the language spec when implementing the major mode).
>
> That would be a lot of design and a lot of work, and sounds like
> something from the distant rather than medium future.  

ada-mode uses just that approach; the WisiToken parser generator reads a
bison-like description of the grammar, and generates a lexer and
error-correcting parser. Those run in an Emacs background process,
which also runs other code to process the AST and produce font and
indent info, which is sent back to Emacs.

It works very well for Ada code, and I've got a very preliminary version
working with Java. See http://www.nongnu.org/ada-mode/ for the latest
release.

C++ is definitely more of a challenge; you need to run the preprocessor,
at least. In another post Oscar says you would need a full C++
front-end; I can believe that. Still, the approach is similar; run the
C++ front-end (maybe the clang one?) in a background process, together
with code that computes the info needed by Emacs.

One possible problem is that the parser needs to handle huge syntax
errors; it will be called to compute indent when the user has entered a
partial statement and hit return. I don't know how good clang is with
error correction; I spent a lot of time making the WisiToken parser
handle such errors well.

> The indentation and font-lock routines would have to be rewritten
> for each mode using it.

Yes; I had to translate the elisp into Ada. Currently, I'm maintaining
both (to support people who don't want to or can't compile the
background process code), but at some point I'll probably drop the
elisp.


It is a huge redesign and implementation effort. I started this for Ada
in 2013 when it became clear that the earlier ad-hoc approach could not
handle Ada 95 and 2012 syntax, and it took several years (with several
detours along the way; Java will take much less time). I'm almost at the
point where I can delete the old ad-hoc ada-mode code from Emacs core.

-- 
-- Stephe



reply via email to

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