Robert Roessler: > 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.
OK. > > 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? :) Lazy and Eval don't seem very descriptive to me: eval is what you call when you want to run some text as a script in languages like Python or JavaScript. > 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. > 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? The converse is a modification that only affects one line. This is special cased so holding down the backspace key is not too slow. If a modification only inserts or deletes from one line and doesn't cause a flow on of restyling to further lines or a change in wrapping then only that line needs to be redrawn. If a line deletion or insertion is performed then all lines from there to the end of the window need to be redrawn. > 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"? Unless you can see a problem I doubt whether this is worth chasing. > 2) try to "accumulate" a [char] range to invalidate - but this looks > [too] hard to compute and update. :( This is an area that would need thorough thinking about before implementation. > An updated lazy.zip is on my site - with just the "restored" > SC_LASTSTEPINUNDOREDO behavior. I am seeing the same files as before although that could be caching somewhere. Neil _______________________________________________ Scintilla-interest mailing list [email protected] http://mailman.lyra.org/mailman/listinfo/scintilla-interest
