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!
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:pharo-dev-bounces@lists.pharo.org] On Behalf Of Nicolai Hess Sent: Tuesday, February 23, 2016 2:41 PM To: Pharo Development List <pharo-dev@lists.pharo.org> 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!
On 23 Feb 2016, at 14:41, Nicolai Hess <nicolaihess@gmail.com> 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-sho... (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
2016-02-23 14:48 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:
On 23 Feb 2016, at 14:41, Nicolai Hess <nicolaihess@gmail.com> 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-sho...
(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
I addd this as an issue: https://pharo.fogbugz.com/f/cases/17684/highlighting-broken-in-message-list-...
On 23 Feb 2016, at 15:15, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-02-23 14:48 GMT+01:00 Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>>:
On 23 Feb 2016, at 14:41, Nicolai Hess <nicolaihess@gmail.com <mailto:nicolaihess@gmail.com>> 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-sho... <https://pharo.fogbugz.com/f/cases/16020/Syntax-Highlighting-Rubric-First-sho...>
(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
participants (3)
-
Henrik Nergaard -
Marcus Denker -
Nicolai Hess