On Wed, Sep 28, 2005 at 11:19:27AM -0400, Bennett Helm wrote: > On Sep 28, 2005, at 10:25 AM, Jean-Marc Lasgouttes wrote: > > >>>>>>"Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: > >>>>>> > > > >Martin> Slowly grasping it... perhaps you'll like the attached more. > >Martin> Note: no change to lyxfunc. Same functionality (I checked) > > > >This looks much less intrusive indeed. Thanks. > > > >Could people test this? Bennett, Helge, everyone? > > Seems to work well. It fixes the problem I noted before with slow > typing speed within insets -- even with multiple, nested insets. > > A few problems remain: > > 1. Undo oddities: > > (a) Cut ... paste ... undo works well for undoing the paste; however, > undoing again to undo the cut results in the cursor appearing in > front of the text that was restored; it should be after it. > > (b) Typing text and then selecting Undo will undo the typing of only > a single character at a time. (I'm not sure if this is related to > this patch.)
I don't really see how cit could be. > 2. Tables: typing in tables is slow -- seems unaffected by this patch. > > 3. Deleting text still feels ... bumpy. Pressing and holding the > delete key results in somewhat slow (though still usable) deletions, > but the speed varies -- sometimes speeding up and sometimes slowing > down, apparently as the remaining lines in the paragraph need to be > redrawn. CPU usage spikes, as well -- more so than with typing, even > when I type faster than it deletes. Yes, this is right... the speed-up is for typing characters (LFUN_SELFINSERT). As long as you type characters into a paragraph in such a way that the height of the paragraph doesn't change, only _it_ is redrawn; otherwise, the whole screen. I could add the same code also to LFUN_BACKSPACE and LFUN_DELETE. Now, for _every_ character that you delete, the _whole screen_ is re-broken and repainted! No wonder you see spikes. Should I do this still? > Bennett - Martin
pgpl9jsxAfkfO.pgp
Description: PGP signature
