freeride-devel
[Top][All Lists]
Advanced

[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






reply via email to

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