Neil Hodgson wrote:
Robert Roessler:
I have finished a version of Editor::NotifyModified Undo/Redo "optimizations"... it would be good if you could check it over WRT "safety"/"correctness" assumptions.
Containers will no longer see SC_LASTSTEPINUNDOREDO on single step undo so won't know to update UI.
Cool, I can restore the previous behavior on this - note that the doc *does* say "This is the final step in an Undo or Redo that has several sections" for this flag... looking at SciTE (e.g.), the "old" behavior is definitely needed. So, the doc should be changed - I can take care of that if you like.
The names NotLazyEval and MustEvalForUndoRedo are too generic. Maybe something like CanDeferToLastStep and IsLastStep?
Also fine names - but note that the new handling of the "before" insert/delete cases (which it appears you will accept) takes this out of being strictly an Undo/Redo thing... which is why I *tried* to make them more generic but still capture the ["lazy"] essence. Should I keep trying with generic but not too generic names? :)
One of the "optimizations" my be controversial (i.e., wrong), but I am suppressing visual updates on the "before" insert/delete cases, since the "real" inserts/deletes will be seen *very* shortly. Is this reasonable?
I expect so.
Good.
OTOH, some of this happens "for free" in the Windows graphics code - I would imagine that GTK/GDK tries to do the same, but I do not know this to be the case.
Yes, GTK merges redraws into a redraw region although like Windows it doesn't promise much about this process so could decide that merging two rectangles produces their bounding box or the whole window.
Yes, we can only *hope* that this reduces the cost of all the full Redraws. :)
I am not sure precisely what you mean with the "flag indicating if any of this batch has had lines added or deleted could be used for two of the checks" - but if it means less screen updating, I am ready! :)
The modification performs a full window redraw for every undo even if only a single character is added or deleted.
Speaking of full Redraws, you are absolutely correct... but note that the *intention* is to only do this on the last step of a MULTI-STEP sequence - to make it still work this way after restoring the previous behavior for SC_LASTSTEPINUNDOREDO, I just need to add the SC_MULTISTEPUNDOREDO constraint back in - I had it in until I realized that the "new" SC_LASTSTEPINUNDOREDO made it unnecessary. :)
Now, about the full Redraw on a multi-step sequence - how bad do we (you) feel about this? Clearly if the sequence is "long enough", we are still way ahead - but how long is that?
If you decide that this is too simplistic, there a few obvious [to me - hopefully you have some better ones] approaches:
0) you mention tracking things at the level of lines added or deleted - what is the converse? Character ranges? And what would be different about their handling?
1) since we know how long the sequence length when we start, the SC_MULTISTEPUNDOREDO flag *could* only be switched on for sequences of some decided length. Interestingly, I just instrumented this and notice that in "real-life" SciTE usage, I get a lot of 2-step Undo/Redo cases. Either a skewed sample or an artifact of Scintilla's "auto-batching"?
2) try to "accumulate" a [char] range to invalidate - but this looks [too] hard to compute and update. :(
BTW, thanks for taking the time to look this over. :)
An updated lazy.zip is on my site - with just the "restored" SC_LASTSTEPINUNDOREDO behavior.
Robert Roessler [EMAIL PROTECTED] http://www.rftp.com _______________________________________________ Scintilla-interest mailing list [email protected] http://mailman.lyra.org/mailman/listinfo/scintilla-interest
