emacs-devel
[Top][All Lists]
Advanced

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

Re[1]: Language environments


From: Eric M. Ludlam
Subject: Re[1]: Language environments
Date: Sun, 18 Nov 2001 09:14:28 -0500

>>> Richard Stallman <address@hidden> seems to think that:
>Should we make a systematic effort to add language environments for
>lots of languages?  Or ask users to start contributing more of them?
  [ ... ]

I think it would be a better use of time to make writing language
environments easier.  Some activities have been made quite easy, like
font lock.  Some actions like beginning/end of defun are either taken
care of, or a challenge write.

For many existing environments, the most commonly expected action,
automatic indentation, is either non-existent, buggy, or really
complicated.

When I took over maintenance of matlab.el, I found that the shared
syntax of the ' character between strings and comments, and the fact
that MATLAB doesn't use a parenthetical form caused the bulk of the
lisp file to consist of re-implementations of such simple things as
font lock string/comment support, beginning/end of sexp, and a really
massive indentation engine.

Some of this would have been made easier by making core services of
navigating syntactic expressions, defuns, parsing strings, and such
replaceable on a per-mode basis so that when one core item needs
replacing (like parsing across strings & comments), the whole harness
of dependent functionality (font-lock, sexp navigation, etc) doesn't
need to be replaced.

I think most of my problem with matlab.el was derived from the fact
that syntax tables are trying to hybridize lexical information with
syntactic information.  For a large batch of languages this is a boon,
simplifying many things.  For the some, however, it obsoletes a large
chunk of functionality.

Anyway, I'm interested in making a flex & bison like interface for
Emacs which could solve some of these problems.  The current version
of my tool is an LL parser which uses syntax tables for lexical
analysis.  It is optimized at the moment for creating accurate tag
information.

Fortunately, there is already a port of Bison to Emacs Lisp in the
harness I wrote for the next release.  My hypothesis is that state
from the LALR parser could be used to provide super accurate
indentation information, and could drool sexp state into the buffer.

A side effect of this type of usage is that someone who knows a
language could express that language in a bison-like format, and hard
stuff like indentation engines and syntactic blocks would be handled
magically instead of through complex Emacs Lisp indentation engines
or incidental parenthetic expressions in a subset of languages.

Anyway, I want to build this harness over the course of the next year.
If it proves feasible I think it would be useful to port some core
parsing from Emacs Lisp to C in Emacs to speed things up.  Users
already are willing to wait for a parse-step just for tagging
information, so I suspect they wouldn't mind it for other services.
Much of this prototype would be made easier with the options I
mentioned earlier about being able to plug in new functions to
replace core behaviors.

http://cedet.sourceforge.net/semantic.shtml

Eric

-- 
          Eric Ludlam:                 address@hidden, address@hidden
   Home: www.ultranet.com/~zappo            Siege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: www.gnu.org



reply via email to

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