Re: State-machine based syntax highlighting

["Robert Thorpe" <rthorpe@realworldtech.com>]

Tim X wrote:
> "spamfilteraccount@gmail.com" <spamfilteraccount@gmail.com> writes:
> > Robert Thorpe wrote:
> >>
> >> If parsing were to be used to support syntax highlighting then maybe
> >> some work would have to be done to avoid having to use Elisp.  But I'm
> >> not sure since it would still require loads of regexps and they would
> >> probably still eat up a lot of the runtime.
> >>
> >
> > That may be true, but the advantage is that parsing actually
> > understands code, not just matches it with some regexps, so it could be
> > used for much more than syntax highlighting (some kind of error
> > checking, code completion, etc.).
> >
> > I think if there are already parsers written in elisp they should be
> > intergrated into the official emacs distribution (e.g. in directory
> > lisp/parsers), so that packages can use them to understand the code
> > better.
> >
>
> Have a look at
>
> http://cedet.sourceforge.net/
>
> The combination of semantic and cedet is, amongst other things, aimed
> at providing parse based functionality for emacs. some of this is (I
> think) going to be bundled in with emacs 22. The idea is to provide a
> more powerful devleopment environment that can do things like code
> completion based on more than just abbrevs and dynamic completion
> based on recently used keywords and regexp.
>
> The problem with parse based analysis is that you need an in-built
> parser for all the languages that the editor is used to develop in and
> this is not a trivial task. I suspect some sort of plugin architecture
> that is able to use stand-alone parses for some language of interest
> would probably be the way to go as it is unlikely even a small subset
> of the languages devleoped within an emacs environment can have a
> parser developed in elisp which is readily maintained.

I think that would be a very difficult approach.  If Emacs wants to
keep it's portability then interfacing it with other programs is
difficult.  It's not as though the language parsers in compilers etc
could be reused anyway, they are inappropriate.

As far as I can see implementing a data-driven GLR parser into Emacs is
the way to go.  That way the parser could interface directly with the
buffer.