The current externally visible SCI_CANUNDO / SCI_CANREDO state should be preserved so that container behaviour does not change because of this modification.
You got it.
Since there are now 4 sites with the if (cb.IsReadOnly() .. NotifyModifyAttempt(); block, the common code should be moved into NotifyModifyAttempt with a name change, possibly to CheckReadOnly.
You got it.
WRT the modification checking patch, I couldn't see a reason for allocating SC_MULTILINEUNDOREDO at 0x10000 rather than the next available bit 0x1000. SC_MODEVENTMASKALL could also have the bit added in although it is unlikely a client would be interested in selectively seeing multi-line undo/redo operations.
You got it (well, in Scintilla.h, anyway). I had just raised the possibility of defining internal (not user-visible) "MOD" flags for purposes of discussion.
The key is having the ability to get a notification about changing the
doc AND be able to change STYLE information while processing it -
which is beyond what the the [much more detailed] SCN_MODIFIED supports...
I am not opposed to allowing style modification during content change notifications. The current lock covers both because it was simpler. However, changing this shouldn't lead to allowing content changes during content or styling notifications or reentrant styling modifications. Any such change should have clear semantics including a reasonable model for what the endStyled position does.
I am not looking for more changes in this area - I already have what I want with the "broadened" behavior for SCN_MODIFYATTEMPTRO... I was just reminding anyone who might need it *why* this particular patch is a "Good Thing(tm)". :)
Changes (WITH Undo/Redo "lazy" processing patch) in
http://www.rftp.com/lazyro.zip
Robert Roessler [EMAIL PROTECTED] http://www.rftp.com _______________________________________________ Scintilla-interest mailing list [email protected] http://mailman.lyra.org/mailman/listinfo/scintilla-interest
