Neil Hodgson wrote:
Robert Roessler:
Right, but recall that *my* sample case with alleged bad display
generation is with the HTML lexer (CSS file) inside of STRINGs and
COMMENTs... where the style isn't necessarily bold at all. ;)
Yes, so the HTML properties turn bold off:
# Matched Operators
style.hypertext.34=fore:#0000FF,notbold,$(font.text)
style.hypertext.35=fore:#FF0000,notbold,$(font.text)
This does, however, lead to problems with braces in styles like
embedded scripts.
Why doesn't Scintilla force only colour changes for brace
highlighting? Its because people wanted to be able to switch other
attributes for brace highlights. SciTE could make up for this by copying
the original style of the brace to style 34/35 and then just modifying
the colours but then there'd probably be people that want to fully
specify this in SciTE too.
Hey, I'm not really complaining about this anyway. ;)
If the caret is improperly displayed in the bizarre case of brace
matching within strings or comments in the HTML lexer, "big deal" if
this is the price to pay for full control over the appearance of the
brace hilite effects... although it does still seem like the caret
positioning is being computed too early, and something like this shows
that by violating an "invariant" assumption.
Hmmm... I think I see what you may be trying to say - that the brace
matching "effects" are sort of brute-forced on top of a buffer without
invoking the layout engine again, and this wouldn't normally show
because *usually* we are showing a bold char at the same spot where we
are already showing that same char bolded? Twisted.
Robert Roessler
[EMAIL PROTECTED]
http://www.rftp.com
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
