[Openmcl-devel] openmcl 1.0 vs. GUI

[alex crain]

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.)
>
> That (fairly simple) change does seem to improve usability quite a
> bit.  To some degree, it's a bandaid on a deeper problem, and I have
> some concerns about whether it'd be simpler and better to run
> editor commands in the event thread.  We've discussed this a little,
> and should probably discuss it more.

I admit that I've been resisting this change and I'm not convinced that
it's necessary. The current GUI does a couple of things to improve  
performance:

1) 1 font per buffer - only color changes allowed, no bolding or  
italics.
2) buffers a always aligned on line boundaries
3) changes are restricted to the current visible area

There is still some horrible code that handles the syntax  
highlighting, but otherwise
it's pretty quick and this makes buffer changes pretty efficient. I'm  
thinking that
the text system should be able to keep up with Hemlock and Hemlock is  
already
pretty smart about buffer updates, since it was designed for slow  
terminals.

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.

:alex