Robert Roessler:
The names NotLazyEval and MustEvalForUndoRedo are too generic. Maybe something like CanDeferToLastStep and IsLastStep?
You got 'em. :)
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 it only occurs in multi-step undo then it won't be a problem for most users but the motivating issue for this thread was your problem with a situation that I hadn't foreseen.
Here is my latest take on this -
I took out some of the "defer" tests, after looking at which MOD codes can actually appear when.
I allow changes WITHIN a line to be displayed right away.
In the Undo/Redo code in Document, I track whether a given Undo/Redo sequence has ANY multi-line changes... then a new flag SC_MULTILINEUNDOREDO (which is defined currently as 0x10000 to be well above the user-visible ones) is conditionally set along with SC_LASTSTEPINUNDOREDO. This new flag feeds into the decision to do a Redraw in Editor::NotifyModified, so that "simple" Undo/Redo ops will not do a Redraw. :)
Other than where you want to assign the new ["internal use"] flag, my only real question concerns the evil "wrap" mode... actually, I think it may take care of itself. Since I do not interfere with the wrap logic, then I should be able to see the single/multi line Redraw logic (which comes after any wrap-induced repaints) as being independent.
BTW, I may change Editor::CheckModificationForWrap to return a value indicating that it has done a Redraw - that way I could suppress the following [possibly] "deferred" Redraw, right?
This plus my "Undo/Redo can cause SCN_MODIFYATTEMPTRO" changes are in
http://www.rftp.com/lazyplus.zip
Robert Roessler [EMAIL PROTECTED] http://www.rftp.com _______________________________________________ Scintilla-interest mailing list [email protected] http://mailman.lyra.org/mailman/listinfo/scintilla-interest
