> On 08 Sep 2015, at 15:53, Eliot Miranda <[email protected]> wrote:
>
> Hi Marcus,
>
> On Tue, Sep 8, 2015 at 6:28 AM, Marcus Denker <[email protected]
> <mailto:[email protected]>> wrote:
>
>> On 08 Sep 2015, at 15:19, Eliot Miranda <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>
>>
>> On Tue, Sep 8, 2015 at 5:13 AM, Marcus Denker <[email protected]
>> <mailto:[email protected]>> wrote:
>> Yes, we do name analysis on the AST before coloring it…
>>
>> Even worse than the transcript output are
>>
>> -> it adds everything into Undeclared
>> -> Playground colors variables wrong that the playground knows as the name
>> analysis does
>> not setup the requestorscope correctly.
>>
>> I will add issue tracker entries…
>>
>> Alternatively one could simply use Shout, a specialized parser for syntax
>> highlighting that is simple, efficient, mature and customizable.
>>
>
> The idea was to reduce the amount of Parsers (and models of methods) in the
> system…
>
> I understand that. But parsing for code generation is very different from
> the quick and simple parsing for syntax highlighting that Shout provides, and
> if one ends up complicating the former to make it encompass the latter then
> maybe that's not such a good idea. I'd rather have a number of smaller
> simpler parsers than one great big complex difficult to understand and full
> of special cases parser (think... Morphic). Just a thought.
Yes… but the Shout parser is actually not that simple.
SHParserST80 package linesOfCode “2581”
And if you then see how much work the completion system has to do to get
structural information out of the token stream it that is already in a normal
AST by default…
Until now the only real change to the RB Parser is the feature to generate an
error node for syntactically wrong input.
(#parseFaultyExpression/#parseFaultyMethod).
Everything else was ok as is. The AST is unchanged (and we therefore use the
same AST for the RB Engine, the Compiler and the syntax highlighter).
Marcus
