[Moved this back on list as others will have opinions and I didn't mean to reply directly to you]
Josiah Carlson:
1) Make the change, let compiler warnings and release notes tell everyone that the API has changed.
There are no headers for many users, just the version of Scintilla.iface translated into their language, possibly by hand.
2) Make the expanded functionality a compile-time option, disabled by default. If people want the new functionality, they will change their code and recompile the library (or use a pre-compiled version that fits what they want).
This is reasonably simple although it'll also need some way to ensure you don't get the wrong version when someone sticks the 4 byte wide version in the path before your expected version.
bool SetStyleWidth(int width) int LongStyleAt(int position) bool LongSetStyleAt(int position, int style, int mask='\377'); bool LongSetStyleFor(int position, int length, int style, int mask);
The important API is SCI_SETSTYLINGEX which is the main way external lexers write styles as it works on large blocks so avoids a large number of calls which for some clients use SendMessage so go through the OS.
SetStyleWidth() would take the number of bytes to use for styling information, returning true if the conversion went successfully. The only acceptable width values are 1, 2, 4 . Switching from a 4 to a 2 or 1, or 2 to a 1 only masks the values, so any 'higher order' styling information is lost.
Changing the depth can zero the buffer. Styling is supposed to be regenerateable and changing the depth is a major and unusual operation. There's also the 0 case that some people like for logs and the popular near-infinite length XML.
Generally speaking, it would require separating character data from styling data, which may have a cache penalty. This separation would require changing Basic[Insert|Delete]Chars] to split characters and styling information, as well as most of the internals of the other CellBuffer methods. It would also require the changing of the drawing code (more potential styles and indicators).
It may also require extra tests or inheriance or similar which can be avoided with the recompile aproach. You could look at SinkWorld's code for this which also allows run-length encoded styling buffers and stacked styling buffers. Neil _______________________________________________ Scintilla-interest mailing list [email protected] http://mailman.lyra.org/mailman/listinfo/scintilla-interest
