emacs-devel
[Top][All Lists]
Advanced

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

Re: progmodes/project.el and search paths


From: Eric Ludlam
Subject: Re: progmodes/project.el and search paths
Date: Fri, 14 Aug 2015 07:52:15 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0

On 08/13/2015 08:05 AM, Dmitry Gutov wrote:
On 08/13/2015 02:53 PM, Nix wrote:

(This is a fairly
strong argument *against* relying on the compiler, in fact -- we'll
always want something like Semantic, because we can tell it to be less
pedantic in its parsing, recover as much as possible from every parse
error, and so on.)

Can we?

I'm guessing Semantic has at most one level of being "less pedantic",
and implementing several of them, as well as support for those in
grammars, wouldn't be trivial.

While Semantic does have an implementation of Bison as it's core for some languages, it is quite unlike most compilers. You can think of it has having 4 ways of handling errors the grammar author doesn't have to put effort into:

1) Lexical 'block' symbols

The lexer can identify blocks, which would normally be handled by the parser. This is because Emacs has built in block matching that is quite good. This lets the parser completely ignore anything in { code } blocks or ( paramater lists ) unless it is important. As long as your block indicators match up, it doesn't matter how crappy your code is.

2) Parsers don't check types, etc as they go, and are flexible about the symbols they accept.

This means you can get irrational tags. This is for a combination of handling incomplete code, speed (less to do) and because most folks just go an run their compiler at some point anyway.

3) Iterative parsing, so each invocation of the parser only executes across a single tag.

This means that if parsing fails, we just move forward one lexical token and try again. This lets the parser just wash over anything it doesn't get.

4) Incremental parser

Emacs watches you edit, tracks your changes, and matches it up against previously parsed tags. If things are 'broken' in the code you edit, but you didn't touch the boundaries of the other nearby tags, it lets it be until next time. This means all the previously captured data is available for use, including the active broken tag you might be editing.


It also has the typical bison error handling, but that tends not to be necessary.

In summary; Semantic can extract useful data out of pretty badly trashed code, and track your changes while you edit in a robust way.

Eric





reply via email to

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