Robert Roessler:
> This seems like a good place to bring up a problem I see with what I
> (and Armel?) want to do - if there are, say, two "protected" regions
> in your buffer and the user deletes all of the text between them, what
> happens next? With Scintilla's current implementation of protected
> text, it is not possible to move the cursor "into" the now-joined
> range... is Undo your only friend at this point?
If your app want to maintain the separation, it could add a space
whenever the regions join.
It would be better to allow positions within a read-only zone where
the caret could go but I can't see an easy implementation of that.
> Speaking of changes, here is something which I believe was brought up
> semi-recently: some way of providing feedback from, e.g., an
> SC_MOD_BEFOREDELETE notification returning "NO - do not permit this!"
> - this approach obviously only works if the notifications are always
> synchronous.
I think this would increase uncertainty over too much code and it
is unlikely I'll want to cope with all the confusing fault reports
that will be caused.
> OK - this is the sort of real-world feedback I was looking for. BUT,
> what I have in mind is not quite as naive as that... just something to
> handle [maybe] "small" requests from a char array always allocated in
> a stack frame (triggered by some macro like USE_LOCAL_ALLOC), with the
> definition of "small" coming from a compile-time def. The POSIX
> interface for PCRE uses something like this.
There is a ByteBuffer class in SinkWorld that looks something like
SW_PUBLIC class ByteBuffer {
int size;
SW_BYTE *s;
enum { SmallSize = 32 };
unsigned char smallS[SmallSize];
I don't really like to put these sorts of thing in without clear
evidence they are needed as they add complexity and make code less
obvious than a simple char *. I think I added ByteBuffer after a
profiler made it look like a win but the profiler was showing
measurement bias due to greater instrumentation cost in user code than
in system code.
Neil
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
