[Openmcl-devel] Aha!

[Gary Byers]

On Sun, 27 Jan 2008, Ron Garret wrote:

> I think I've had a breakthrough!  It turns out that if you use my red-
> green cursor blink hack and move the cursor around with the mouse or
> the arrow keys then it DOES leave red and green squares behind.  It is
> only when you actually type a close-paren that they get reset to
> white, and then only in the same line as the cursor is currently on.
>
> So I suspect that Hemlock is repainting the entire current line every
> time you type a close-paren and hence undermining the matching-paren
> highlighting.
>
> Anyone know offhand where the code that does that repainting might be?

I think that it's the drawRect: method for NSTextView (e.g., part of
Cocoa.)

It's sometimes interesting (if a little unsettling) to see what gets
redrawn (in CCL and in other OSX applications); one way of seeing this
is to use the Quartz Debug (in Leopard with XCode installed, it's in 
/Developer/Applications/Performance Tools/ with a link to it from
/Developer/Applications/Graphics Tools/ ; I seem to remember that it
was traditionally in Graphics Tools but may just not have noticed
the link.)

If you run it (wherever it is) and click the "Flash Screen Updates"
checkbox), then all drawing in all applications will be highlighted.
If you type text into an IDE window with updates highlighted, you'll
see that some editing changes cause minimal updates and others may redraw 
the containing line (or possibly more.)  What gets redrawn is basically
the "rect" argument to drawRect:, and I suspect that you're right that
the delay in blinking a matching paren is caused by some combination
of the matching paren's glyph rectangle being outside the clip rect
(or being inside it but not being invalidated properly.)

We don't actually want to change the text (e.g., don't want to 
erase the matching paren by storing a #\space in the buffer) and
what we're trying to do doesn't always interact well with the
textview's redisplay code.  What we sort of want to do is make
transient changes in the text attributes of the matching paren
(specifically, we want to change its foreground color to be
the same as its background color and revert that change) in
a way that will interact properly with the redisplay code.
NSLayoutManager has methods to add/remove "temporary attributes"
from a given character range, and I assume/hope that changes in
the temporary attributes of the matching paren would be reflected
in the next redisplay.

(If we were to give up on the idea of paren-highlighting by
blinking and highlighted by changing foreground/background color
instead, then I think that NSLayoutManager's temporary attributes
would probably be the right tool for the job.)