[Openmcl-devel] openmcl 1.0 vs. GUI

[Gary Byers]

On Sun, 28 Aug 2005, alex crain wrote:

>
> On Aug 28, 2005, at 8:54 PM, Gary Byers wrote:
>> 
>> One change that I'd made to the bleeding-edge version around the time
>> that you announced your version is to try to defer redisplay until
>> after a simple editing command completes.  (As the code is written,
>> redisplay is attempted after every buffer modification; that's clearly
>> wrong, and the change I introduced at least muffles that so that you
>> don't see a lot of hyterical redisplay when an editing command (like
>> indentation) makes a lot of individual buffer changes.)

> I could always be wrong, of course, but I would hate to introduce
> jumpy text unnecessarily and I'm afraid that your change may have
> unintended side effect on extended commands, like recursive edits or
> incremental searches.

It's necessary to re-enable display in these cases (which I did) and
any similar cases (which I may have missed.)

I think that I'd tried to fix the C-M-Q case in some other way, and
there's currently an unfortunate side-effect which causes the buffer
to be marked as modified even if indentation commands don't do anything.
(At least I -think- that this is what's going on; it's also possible
that the indentation commands are replacing spaces with spaces and
tabs with tabs, and that "counts" as a modification.)

The way that the buffer code was originally written (or at least the
way that it was originaly modified to work with the Cocoa text system)
every buffer-modification primitive (insert-char, replace-char,
insert-string, etc.) is bracketed with beginEditing/endEditing calls.
That ensured that we -did- see the results of those modifications,
but it had the unfortunate effect of causing us ... to see each and
every one of those modifications; this was especially annoying in
the C-M-Q (indent-sexp) case, but was at least mildly annoying in
general.  (Each change to the buffer had to wait for the associated
redisplay to finish; it's hard to make this fast.)

The change that I introduced a month or so ago suppresses this (by
making all modifications occur inside a beginEditing and deferring
endEditing until after the command had finished or a recursive command
was entered.  That seems like a step in the right direction and seems
to improve performance and usability; it could certainly be done
more cleanly than the way that I did it.  (It might be correct to
say that redisplay is allowed any time we need to wait for a keystroke,
for instance.  I'm not sure that that's correct, but something like
that might be.)

>
> :alex