[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [FR-devel] RE: bRuby? (Yet another Ruby parser)
From: |
Rich Kilmer |
Subject: |
RE: [FR-devel] RE: bRuby? (Yet another Ruby parser) |
Date: |
Thu, 7 Nov 2002 23:10:52 -0500 |
> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden On Behalf Of Hal E. Fulton
> Sent: Thursday, November 07, 2002 9:13 PM
> To: address@hidden
> Subject: Re: [FR-devel] RE: bRuby? (Yet another Ruby parser)
> <SNIP>
>
> Since the editor will make heavy use of the parser
> I think the parser should expose state as much as
> appropriate (for this kind of specialized app, not
> for the typical app perhaps).
>
> What I mean is, suppose we have this code fragment:
>
> def alpha(...)
> ...
> end
>
> def beta(...)
> ...
> end
>
> def gamma(...)
> ...
> end
>
> And suppose we are editing the beta method. It would
> be nice if the editor somehow knew to keep checkpoints
> of some kind, so that re-parsing during editing need
> only happen with a certain syntactic region.
>
> Might also provide a way for the editor to tell the
> parser which parts of the text are "dirty" and need
> to be re-parsed.
>
> Obviously we want to 1) parse on the fly and 2) avoid
> a manual triggering such as we have now and 3) avoid
> reparsing from the ground up every time.
>
Just a point of note. The Ripper parser takes .05 seconds to parse a 2k
line file. That's darned fast. Not that I want it parsing continually,
but maybe on carriage return and/or moving off a modified line with the
arrow keys.
Optimizations would be nice, but only if necessary.
-rich