[Top][All Lists]

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

Re: PL support (was: Drop the Copyright Assignment requirement for Emacs

From: Daniel Colascione
Subject: Re: PL support (was: Drop the Copyright Assignment requirement for Emacs)
Date: Sat, 09 May 2020 09:17:38 -0700
User-agent: AquaMail/1.24.0-1585 (build: 102400006)

On May 9, 2020 9:02:43 AM Eli Zaretskii <address@hidden> wrote:

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.

They do have this problem, and they usually address it with hand written fix-up and glue code. (See the IntelliJ family.) I really want modes (and multi-modes) driven entirely by declarative (and customizable!) grammars --- with everything else figured out automatically. Maybe this goal isn't practical and we should start with the parser combinator C acceleration.

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.


reply via email to

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