[antlr-interest] Serious doubts on usage of incremental parsinginides

Prashant Deva prashant.deva at gmail.com
Tue Apr 26 10:22:05 PDT 2005


part 3..

Jean,
> 3) On thread B (syntax coloring), I have the following problem: I need
> to lock the editor while the colorization is being made because
> otherwise the user can insert/delete a character and the color will not
> be applied at the right place. I currently cache the previous tokens
> list so when the new tokens list is available, I only colorize the
> modified tokens (using a fast diff comparaison). This is fast enough so
> the user doesn't notice anything. But this is maybe not the best
> solution - any idea ?
> 

As there is an interval between the time u do the parsing and the
coloring, what if the text has  been changed by the user in that
interval?

PRASHANT


On 4/26/05, Prashant Deva <prashant.deva at gmail.com> wrote:
> part 2 of my reply....
> 
> Jean,
>   What is the config of the comps you ran ur antlrWorks under till now?
> 
> PRASHANT
> 
> On 4/26/05, Prashant Deva <prashant.deva at gmail.com> wrote:
> > john,
> >
> > > Depends on how tightly you need/want to constrain the synchronization of
> > > the various views.
> > >
> > exactly, so if u have to update everything else so late only, then why
> > run an incremental parser. why not run a batch parser?
> >
> >
> > > For some situations, people do really want the system to be extremely
> > > strict.  Though, in most of those cases that come immediately to mind,
> > > the interface is relatively simple.
> > >
> > > Of course, in those really strict cases, I don't know that I'd call them
> > > incremental parsers as much as I'd call them extremely constrained
> > > editors.
> > >
> >
> > You dont seem to get the meaning of an 'incremental parser'. an
> > incremental parser is one which will produce exactly the same output
> > as that of a batch parser but it parses just the modifications and
> > leaves the rest of the stuff as is.
> > Thus a good incremental parser (like mine ;) ) should allow an
> > unrestricted editing model and should recover from errors eaxctly as a
> > batch parser would.
> >
> > Jean,
> >
> > >Back to our discussion, have you any clue how IDE are handling >the
> > >drawing of UI element without "blocking" the user on the >event-thread ?
> >
> > No idea. I am still looking at the source of eclipse. They have got a
> > custom implementation of almost every SWT widget, which is super
> > complex!
> >
> > PRASHANT
> >
> > On 4/26/05, John D. Mitchell <johnm-antlr at non.net> wrote:
> > > >>>>> "Prashant" == Prashant Deva <prashant.deva at gmail.com> writes:
> > > [...]
> > >
> > > > So here is my problem stated once again - You can't run an incremental
> > > > parser on every keystroke cause no matter how fast the parser is, the
> > > > amount of 'other' stuff to update will slow the editor.
> > >
> > > Depends on how tightly you need/want to constrain the synchronization of
> > > the various views.
> > >
> > > [...]
> > > > So what's the use of an incremental parser.
> > >
> > > For some situations, people do really want the system to be extremely
> > > strict.  Though, in most of those cases that come immediately to mind,
> > > the interface is relatively simple.
> > >
> > > Of course, in those really strict cases, I don't know that I'd call them
> > > incremental parsers as much as I'd call them extremely constrained
> > > editors.
> > >
> > > Take care,
> > >         John
> > >
> >
>


More information about the antlr-interest mailing list