Armel Asselin: > I've just got a look to the scintilla code and realized that only a minor > part of Scintilla would have to be updated to get dynamic styling > capabilities (30 or 40 lines of existing code in fact, plus some new APIs), > I mean by 'dynamic' the capability to tell "I require 200 styles and 4 > indicator bits".
This also changes the interface as AddStyledText and GetStyledText expose the storage format. SetStylingEx assumes that there are 8 bits of styling for each character byte and much lexing is performed through this or the equivalent Document::SetStyles. When you start looking at dynamicly sizing styling information, there are quite a few things that help to make the system generic and usable, such as having separate styling cursors for every group of style bits and an API that makes it easy to allocate styling bits in a way that allows style sources to cooperate. This is the sort of thing that SinkWorld does. You don't really want to say "I require 200 styles and 4 indicator bits". Instead you want to say "I am using the HTML lexer, with URL hotspots and a read-only indicator", and each of these style sources knows how many states or bits it needs. You want to be able to use various sources in combination so the system should be able to allocate the bits for you rather than having hard coded masks. > By simply putting in the CellBuffer the number of bytes > that we need per char (i.e. 1+styling bytes), we could replace all the *2 > multiplications by *bytesPerChar. Maybe a bit of DocumentAccessor would need > modifs as well (to cope with dynamic number of style bytes per char). And > Scintilla could go toward 2 or 3 bytes of styling for example releaving > completely the styling problem (at least if we keep current philosophy). The > stuff would remain compatible with current code. We'd need to transform > 'char' in styling API to 'long'. The array of styles would have to be dynamic. There may be overheads to this if the array grows large such as determining a palette when displaying a large style set on an 8-bit display. > I realize that it looks like a major change but maybe not as much as it > seems. SinkWorld is probably intended to solve this kind of problems as well > but I will really need that soon. If it seems of interest I can do it and > put it in common base. Its great to see someone experimenting with this but I think it has limited utility compared with a more complete system like SinkWorld and does not offer enough to offset its costs. Neil _______________________________________________ Scintilla-interest mailing list [email protected] http://mailman.lyra.org/mailman/listinfo/scintilla-interest
