50603 highlighting broken

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

50603 highlighting broken

Nicolai Hess-3-2
in pharo 50603, if you open a sendersOf MessageBrowser, the first selected
methods code is not or wrongly highlightey (all red).
You have to change the selected item to get the right result!
Reply | Threaded
Open this post in threaded view
|

Re: 50603 highlighting broken

Henrik Nergaard

Caused by:

Build 50601

16020 Syntax Highlighting Rubric: First shows non-highlighted text, then color. Looks slow

               https://pharo.fogbugz.com/f/cases/16020

 

 

From: Pharo-dev [mailto:[hidden email]] On Behalf Of Nicolai Hess
Sent: Tuesday, February 23, 2016 2:41 PM
To: Pharo Development List <[hidden email]>
Subject: [Pharo-dev] 50603 highlighting broken

 

in pharo 50603, if you open a sendersOf MessageBrowser, the first selected

methods code is not or wrongly highlightey (all red).

You have to change the selected item to get the right result!

Reply | Threaded
Open this post in threaded view
|

Re: 50603 highlighting broken

Marcus Denker-4
In reply to this post by Nicolai Hess-3-2

> On 23 Feb 2016, at 14:41, Nicolai Hess <[hidden email]> wrote:
>
> in pharo 50603, if you open a sendersOf MessageBrowser, the first selected
> methods code is not or wrongly highlightey (all red).
> You have to change the selected item to get the right result!

Yes, this is a side effect of not deferring syntax highlighting for small methods:

        https://pharo.fogbugz.com/f/cases/16020/Syntax-Highlighting-Rubric-First-shows-non-highlighted-text-then-color-Looks-slow

(which
        a) makes looking at code feel much faster (no double rendering)
        b) works around a race condition for rendering in the background that made all CI jobs fails 8 times our of 10)
)

I think this just makes a bug visible that was hidden by the double  rendering… we should find how to fix it.

        Marcus
Reply | Threaded
Open this post in threaded view
|

Re: 50603 highlighting broken

Nicolai Hess-3-2


2016-02-23 14:48 GMT+01:00 Marcus Denker <[hidden email]>:

> On 23 Feb 2016, at 14:41, Nicolai Hess <[hidden email]> wrote:
>
> in pharo 50603, if you open a sendersOf MessageBrowser, the first selected
> methods code is not or wrongly highlightey (all red).
> You have to change the selected item to get the right result!

Yes, this is a side effect of not deferring syntax highlighting for small methods:

        https://pharo.fogbugz.com/f/cases/16020/Syntax-Highlighting-Rubric-First-shows-non-highlighted-text-then-color-Looks-slow

(which
        a) makes looking at code feel much faster (no double rendering)
        b) works around a race condition for rendering in the background that made all CI jobs fails 8 times our of 10)
)

I think this just makes a bug visible that was hidden by the double  rendering… we should find how to fix it.

Oh yes thats bad :-(

setEditingModeFor: textArea withBehavior: behavior
    behavior
        ifNil:
            [
            self isForSmalltalkCode
                ifTrue: [ textArea beForSmalltalkScripting ]
                ifFalse: [ textArea beForPlainText ] ]
        ifNotNil: [ :class |
            self haltOnce.
            textArea
                classOrMetaClass: class;
                beForSmalltalkCode
                 ]

here we set the classOrMetaClass attribute of the styler, but at this point it is not
configured for styling and the classOrMetaClass setting is ignored.
After that we set the styler #beForSmalltalkCode, but now, styleing does not know about the classOrMetaClass.
If we exchange the calls:

            textArea
                beForSmalltalkCode;
                classOrMetaClass: class

it wouldn't work either, because now the styler is called without the classOrMetaClass is set.
And if we set the classOrMetaClass, the styling does not change because the code did not change :-(


 

        Marcus

Reply | Threaded
Open this post in threaded view
|

Re: 50603 highlighting broken

Marcus Denker-4
I addd this as an issue:


On 23 Feb 2016, at 15:15, Nicolai Hess <[hidden email]> wrote:



2016-02-23 14:48 GMT+01:00 Marcus Denker <[hidden email]>:

> On 23 Feb 2016, at 14:41, Nicolai Hess <[hidden email]> wrote:
>
> in pharo 50603, if you open a sendersOf MessageBrowser, the first selected
> methods code is not or wrongly highlightey (all red).
> You have to change the selected item to get the right result!

Yes, this is a side effect of not deferring syntax highlighting for small methods:

        https://pharo.fogbugz.com/f/cases/16020/Syntax-Highlighting-Rubric-First-shows-non-highlighted-text-then-color-Looks-slow

(which
        a) makes looking at code feel much faster (no double rendering)
        b) works around a race condition for rendering in the background that made all CI jobs fails 8 times our of 10)
)

I think this just makes a bug visible that was hidden by the double  rendering… we should find how to fix it.

Oh yes thats bad :-(

setEditingModeFor: textArea withBehavior: behavior
    behavior
        ifNil:
            [
            self isForSmalltalkCode
                ifTrue: [ textArea beForSmalltalkScripting ]
                ifFalse: [ textArea beForPlainText ] ]
        ifNotNil: [ :class |
            self haltOnce.
            textArea
                classOrMetaClass: class;
                beForSmalltalkCode
                 ]

here we set the classOrMetaClass attribute of the styler, but at this point it is not
configured for styling and the classOrMetaClass setting is ignored.
After that we set the styler #beForSmalltalkCode, but now, styleing does not know about the classOrMetaClass.
If we exchange the calls:

            textArea
                beForSmalltalkCode;
                classOrMetaClass: class

it wouldn't work either, because now the styler is called without the classOrMetaClass is set.
And if we set the classOrMetaClass, the styling does not change because the code did not change :-(


 

        Marcus