Simon Steele:
As far as storage, I can't see a view with >32 indicators as anything other than disastrous from a usability point of view so surely a 32-bit field would be adequate?
I was thinking that it could be allocated for different purposes since you don't want to have a conflict between lexers and containers. The first 8 bits could be for lexers. This includes the existing 3 bits currently available to lexers. For a transition period, indicators 0, 1, and 2 are still stored in the style bytes. but will be treated as equivalent by the new API. Lexers are then updated to use bits 3 to 7 and after the transition, bits 0,1,and 2 use RunStyles. If anyone is using indicators for dense styles that are not suitable for RunStyles (such as marking the start of every lexeme) then they should comment. The order of drawing may be important for some decorations - such as highlighting the spelling mistake under the cursor while retaining the original mistake decorations. There is also the possibility of a multi-valued decoration: maybe you have 5 levels of issue severity. While this can be represented as 5 separate decorations, it may be better to treat it as a simple decoration with 6 values (including 0 as none).
I'm presuming lexers will be able to set decorations as well as making them available via an API. In this case would it not be better to store the state with the document, I don't think we currently lex multiple times for multiple views?
Yes, lexing is handled by the document. Looks like decorations have to be stored in the document. Neil _______________________________________________ Scintilla-interest mailing list [email protected] http://mailman.lyra.org/mailman/listinfo/scintilla-interest
