From: Daniel Colascione <address@hidden>
CC: <address@hidden>, <address@hidden>, <address@hidden>
Date: Sat, 09 May 2020 08:50:45 -0700
Please someone start working on this ASAP. We sorely need that, just
look at the recent discussions on Reddit that underline these
deficiencies in Emacs.
It's a hard problem. A mode based on a real parser must be fast,
incremental, and robust against transient errors that arise in the normal
course of editing.
I agree. But other IDE's have the same problem, don't they? And
AFAIU incremental parsers such as tree-sitter are explicitly targeting
such use patterns, and their documentation says they are tolerant to
temporarily incorrect source.
We'd also want the ability to parse complex languages
(far beyond LALR) and incorporate out-of-band information in order to
resolve semantic ambiguities --- e.g. the C++ template problem. On top of
all that, the parser would need to be highly malleable to make it easy to
adjust to slight differences in dialect as well as deal with multiple
languages in a buffer.
AFAICT, tree-sitter supports many languages already. I know less
about LSP, but I'm guessing they are not very far of that, either.
A much simpler approach I've also had in mind is providing a C-assisted
incremental parser combinators facility to Lisp --- something like the
venerable pyparsing. Parser combinators make it pretty easy to incorporate
error recovery rules, and the C code can use approaches like current
syntax-ppss to keep the parse up to date and maintain, cheaply, an AST.
I'm sure more than one alternative exist, and maybe we should support
more than one.
Thanks.