> On 05 Feb 2015, at 16:35, Levente Uzonyi <leves at elte.hu> wrote:
> 
> On Thu, 5 Feb 2015, Marcus Denker wrote:
> 
>> 
>>> On 05 Feb 2015, at 10:04, Marcus Denker <marcus.denker at inria.fr> wrote:
>>> 
>>> 
>>>> On 04 Feb 2015, at 22:04, Levente Uzonyi <leves at elte.hu> wrote:
>>>> 
>>>> A single parser is a nice goal, but performance is top priority for Shout, because it should do it's job real-time. When it starts lagging behind, then people just turn it off, because it doesn't help them.
>>>> Can those parsers (SHRBTextStyler and a Smalltalk parser written using PetitParser) parse an average method in less than 20ms on an average machine?
>>> 
>>> I have not yet benchmarked it… PetitParser as it is is too slow, but we will soon have a faster version (factor 10).
>>> 
>>> We should do some benchmarks. For using, it seems ok. With a fast machine + JIT, which does not say much of course.
>>> (there is a setting 'AST based coloring’ in Pharo3 and Pharo4, but it is turned off by default).
>>> 
>>> One thing that is nice with the AST is that it can be used for other things, too. e.g. in Pharo we have a menu that is defined
>>> by the AST nodes and structural navigation in the editor.
>>> 
> 
> Rebuilding the whole AST after every keystroke is possible, but keeping it real-time is a bit challenging.
> 
> I would love to see an editor, which works on the AST directly - aka it maps the source code to AST nodes, and just updates the smallest possible subtree at each keystroke. Implementing such editor has it's challenges ofc, like typing a single character can invalidate the whole code, but the editor should keep the AST somehow in that case too.
> 

Yes! 

	Marcus