You might want to look at the Eclipse text API for clues how to
integrate a parser into an editor, in particular the idea of damaged
regions and repair. This was designed for text highlighting using
scanners that partition the text into regions, each identified with a
kind. The kind is then used to direct highlighting, which can be
context-sensitive within a single partition.
When the user changes text, the entire region of text changed is
damaged. The scanners back up to the last partition before the damaged
region and proceed forward until a newly added partition exactly matches
a previously existing partition of the same kind and span. This
completes the repair.
If you think of the output of a PEG parse as a parse tree each node of
which has attributes for the start and end position in the text, then it
is clear that any node that spans a damaged region will need to be
repaired by some amount of reparsing.
There are two issues: In the Eclipse scheme, repair can be stopped
whenever a new partition exactly matches a previously existing partition
of the same kind and span. But PEG-derived parse trees will add (at
least) the notion of depth, as a parse tree is not a flat partition.
Also, the repair must begin in the context of some ancestor node, and it
is not clear which ancestor.
I'd guess this is roughly a master's thesis problem.
Bob
Derek Peschel wrote:
> On Mon, Feb 05, 2007 at 06:44:10PM -0500, Robert Grimm wrote:
>
>>Rats! does support incremental parsing, in the sense that it does not
>>require the entire input to be available at parsing time. I.e., you
>>can parse some production, process the result, and then parse the
>>next production. Whether that helps in implementing text editors, I'm
>>not sure. It does help with reducing the resource requirements for
>>very large inputs and with processing interactive input one
>>expression at a time.
>
>
> Does Rats! tell the caller that the parse is incomplete? Can the caller
> undo all or part of a parse in progress? That would allow an interactive
> program to read multiline expressions and allow already-read lines to be
> cancelled... not a true text editor but still a useful feature.
>
> On true text editors: as much as I've thought this out (which isn't a
lot),
> I'm looking for a way to relate the text buffer to the parser tree
and back,
> and a way for the parser to adapt to random changes in the text.
>
> The first item means that the text should be "enriched" with pointers
into
> the parse tree, perhaps one pointer per line instead of one per
character.
> And the parse tree should store information about the beginning and
ending
> text positions for each node. With both of those data structures, it
should
> be possible to do the kinds of movement and editing commands I'm looking
> for. I wouldn't expect the standard Rats! code to have data
structures like
> that, but if there's a way to add them as some kind of action code, that
> would probably be fine.
>
> The second item means that if the user changes the text, the parser
updates
> the parts of the parse tree that need updating and then generates new
> attributes for the text. Does Rats! keep the parser state in a form that
> can be saved (so the text can be "enriched" with that also)? Can you
pass
> the new state and new text back to the parser?
>
> I'll probably have to deal with erroneous text. I suspect that's a
matter
> for the grammar writer, but I could be wrong.
>
> -- Derek
>
> _______________________________________________
> PEG mailing list
> PEG@lists.csail.mit.edu
> https://lists.csail.mit.edu/mailman/listinfo/peg
>
>
_______________________________________________
PEG mailing list
PEG@lists.csail.mit.edu
https://lists.csail.mit.edu/mailman/listinfo/peg
