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: Bob Calco
Subject: RE: [FR-devel] RE: bRuby? (Yet another Ruby parser)
Date: Thu, 7 Nov 2002 22:16:57 -0500

Hal:

%% While we're on the topic: I'm ignorant of parsers
%% (I've written a couple of compilers and such) but
%% I do have an idea to pass along.
%%
%% Take it for what it's worth.
%%
%% 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).

Well the parser's state is one thing; you are talking about the buffer's
state. How to manage the buffer-parser interaction depends on the states of
both. Really something in between the buffer being edited and the raw parser
needs to be developed to manage this.

%%
%% 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.

Reparsing isn't the problem, it's managing event triggers that cause the
parser to parse many more times than is humanly useful that is the problem.

I shall consider it, probably after I get the basic functionality working.
:)

%%
%% 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.
%%
%% I've no idea how to accomplish this, but it would be
%% nice. :)

I think really the "intellisense" functionality you describe is something
that would be built on top of the parser; the parser itself needs to be as
simple as possible to remain flexible. that is to say, you are talking about
something else that would use the parser, not the parser itself. But the
point is well taken that the parser should be able to do those types of
things that an intellisense engine might need, and those tend to be far more
dynamic than those things needed by a compiler, for instance, which are
fairly static once the compile process is underway.

I will give it thought. Thanks!

- Bob

%%
%% Hal
%%
%%
%%
%% _______________________________________________
%% Freeride-devel mailing list
%% address@hidden
%% http://mail.nongnu.org/mailman/listinfo/freeride-devel
%%






reply via email to

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