"Neil Hodgson" <[EMAIL PROTECTED]> wrote:
>
> [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.
Scratch that then.
> > 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.
The more I think about it, the less I like compile time options.
> > 3) [add a new 'long' API]
> >
> > 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.
Hrm. Good point. I guess the thing to do would be to have...
SCI_LONGSETSTYLINGEX
Which takes an array of ints (regardless of the number of bytes of
styling information per character), which are masked as necessary when
written to the underlying styling portion of the cell buffer.
> > 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.
Zero bytes as an option sounds reasonable, and easily supported.
> > 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.
I'll check out sinkworld shortly, but I'm not that terribly concerned
about having to subclass for the styling buffers. Or if you didn't mind
(I would understand if you would), there's always the void* for pointing
to varying internal types.
As an additional feature proposal (obviously if it is going to go in,
I'll be implementing the above proposal, as well as what follows...)
In this rewriting, I was going to ask you if you would consider
a patch that changed the underlying structure of data representation.
Say, for example, that instead of arrays of characters, with a
linebuffer that is really just an array of positions, there were to
exist blocks of characters. Say 4k of data each block, each of which
include some number of full lines (a function of the lengths of lines)
(with pointers). Each one of these blocks would link to adjacent blocks
as a doubly linked list (for quick and easy scrolling over time, fast
sequential access, etc.), as well as a tree hierarchy laid over the top
of it for log-time access to arbitrary blocks/lines. Internally, each
node in this tree could hold certain information about the range of
blocks that descend from it:
number of lines
number of 'virtual' lines (when wrapping is enabled)
maximum length of these lines
number of characters
...
Because the API to the CellBuffer is opaque with regards to its internal
implementation, no external tools should be aware of the change, other
than a slight increase in sequential access and modification time for
smaller documents, but a small to large reduction in access/modification
time for non-sequential access for larger documents.
- Josiah
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
