[antlr-interest] Serious doubts on usage of incremental parsing inides

[Prashant Deva]

Scott,
  You got me completly wrong. I am not talking about incremental
compilation, but incremental parsing in the editor which happens while
you are typing.

>Editor parsing only affects the file you're editing, not the
>potentially impacted code outside that file. It usually triggers this
>when the user pauses.

Thats cause if you give a time interval in which you wanna run ur
parser, say 500 ms, eclipse will collect all the consecutive additions
or removals and pass them as one block. It will be triggered at the
interval regardless of whether the user has paused or not.
Also note that additions and removals are collected separately.

Torkild,

>I'm currently implementing incremental parsing for my "Visual
>DataFlex plugin" for Eclipse. Since the grammar is fairly large and
>not very fast I see no other option because:
>
>* The outline view should be accurate.
>* The "highlight range indicator" should be accurate.
>* Automatic indentation should be accurate.
>* Content assist should be accurate.
>* Templates should be accurate.
>* Specialized search should be accurate.
>* etc. etc.

Thats what i wanna say. How are u gonna make all this stuff dead
accurate. See if you update all these components after say every 500
ms , then after every few keystrokes the user is gonna encounter a
short pause while all this stuff is updated, which will completly
screw the editing experience.

>Well it depends I guess. But in my experience the delta is not very large,
>a few lines of code at the most

Thats where you guys are not getting me. Its NOT the size of the delta
that worries me. Its the amount of components which will be updating
themselves using that delta. If i have 10 components that wil redraw
themselves, then there WILL be a pause in typing no matter how small
the delta is.
And you can't tell these components to update themselves in the
background, you HAVE to pause the editor, cause if u don't pause then
the editor and everything else is out of sync.

PRASHANT 


On 4/25/05, shmuel siegel <antlr at shmuelhome.mine.nu> wrote:
> Ingo Maier wrote:
> > Isn't Prashant talking about incremental parsing (as opposed to
> > incremental compilation)? I guess incremental parsing with all related
> > semantic checking and stuff is way more complex than eclipse/jdt is
> > doing incremental compilation. It has no "delta" ASTs/nodes but whole
> > delta compilation units as far as I know. When a compilation unit has
> > changed, it parses it from beginning to end and builds a whole new AST,
> > (not just the lines that changed modifying single nodes). The
> > synchronization happens on a level above Prashant's talking and should
> > be much simpler to manage. Please correct me if I am wrong.
> Word processors have dealt with this problem for years. They "must"
> layout the visible page at typing speed. The general way to do this is
> to break up the document into smaller objects; determine the first
> object that could have changed; do a foreground layout for anything that
> can change on the screen and a background layout for the rest. As an
> optimization, the layout can terminate anytime an object that is still
> valid has not been affected by the current change (for instance if a
> modified paragraph doesn't change its number of lines, further layout is
> unnecessary).
> Parsing code is very similar. It can't do the foreground/background
> split but the other optimizations are very appropriate.
> 
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.10.2 - Release Date: 4/21/2005
> 
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.10.2 - Release Date: 4/21/2005
> 
>