> No, you are right. It isn't shown in red, even if it is a unknown symbol.
>
> I'll have a look.

Oh, that is bad.
The check for existing Symbols always succeeds, because
Parsing an expression with RBParser creates RBMethod- and RBMessageNodes
And they use always #asSymbol for its selectors.

Argh this is a pity because this is a really useful

That means, as soon as we parse an expression, we add all new Symbols.

And as the parser is now used for syntax highlighting as well, this means
new symbols will be added on compiling new methods and expressions
or just highlighting them. That's bad.

Yes I was discussing with students that used Pharo 40 during a lecture and they loved it.

anyone an idea?

I'm trying to think.
Looks like it would be good to be able to make a distinction between symbols and selectors (selectors installed
in method dictionaries)

Stef ��

��
>> 2016-01-15 13:10 GMT+01:00 stepharo <stepharo@free.fr>:
>>>
>>> Hi
>>>
>>> In the past in Pharo when a message was not matching an existing selector the selector was turned into red
>>
>>
>> I think this only happened for names not known as a symbol, regardless whether this symbol exists as a message selector or just a symbol.
>>
>> If no symbol table includes the symbol yzw
>>
>> Color yzw
>>
>> will show yzw red,
>>
>> Color yello
>> will print yello in italic
>> Color yellow
>> will print yellow normal
>> Color jaune
>> will print jaune red, as long it is not in a SymbolTable.
>>
>> ��
>>>
>>> So we could see immediately that you typed an error.
>>>
>>> Right now, the behavior only exists for Class
>>> so
>>>
>>> �� Po is italiczec
>>> �� Pox is red
>>>
>>> I played with the blueStyleTable but I cannot get it working on selector.
>>> Does anybody know?
>>>
>>> Such kind of glitch is slowing me when shooting new pharo videos.
>>>
>>> Stef
>>>
>>>
>>
>