Ticket #64 (new defect)

Opened 1 year ago

Last modified 2 months ago

blinking parens are too slow to start blinking

Reported by: jaj Assigned to: gb
Priority: major Milestone:
Component: IDE Version:
Keywords: Cc:

Description

This is a minor annoyance, but I find myself impatiently waiting for blinking parens to start blinking after typing or moving the cursor. Blinking should begin immediately for the UI to feel responsive.

Change History

08/22/07 19:57:27 changed by gb

It starts blinking as soon as the insertion point starts blinking.

In the method #/drawInsertionPointInRect:color:turnedOn: (in ccl:cocoa-ide;cocoa-editor.lisp), the glyph rectangle is always erased and then the glyph for the matching paren is drawn if the insertion point is off "(unless flag ...", near the bottom of the method.

Does it feel more responsive if the blinking happens in the other phase (if the "unless" is changed to "when" ?)

I think that it's done the way that it's done to ensure that the glyph is drawn when a window is deactivated, so changing the "unless" to a "when" may reintroduce display artifacts (which can probably be dealt with in other ways.)

11/01/07 08:37:05 changed by gz

  • priority changed from minor to major.

This was also reported by Ron Garret in openmcl-devel:

1. When typing a sexpr, matching-paren highlighting does not happen as you type. Instead, the matching paren only starts to flash a second or two after I stop typing. This really slows me down.

12/08/07 19:51:57 changed by rongarret

Does it feel more responsive if the blinking happens in the other phase (if the "unless" is changed to "when" ?)

That does help, but IMO that's not the RIght Answer. The phase is correct as it currently stands (i.e. with "unless" instead of "when"). The problem is that the highlight doesn't occur until after the cursor has gone through a complete blink cycle. I think the problem may be that this is not the right method, that the highlighting needs to be moved (or added) to the key-event-handler method.

12/08/07 20:04:45 changed by gb

I think that what may be happening is that when #/drawInsertionPointInRect: .. is called, drawing in the view is restricted/clipped to the insertion point rectangle; if we invalidate a glyph rectangle, that only affects the next display cycle.

If that's true, then we may want to invalidate the glyph rectangle as soon as we determine that there's a matching paren, so the redisplay that draws the insertion point also draws the glyph (or an empty rect) for the paren.

(We've also discussed the idea of using other types of matching-paren highlighting, like changing the background color or foreground color of both parens.)

11/10/08 14:05:22 changed by rme

Instead of blinking, we're now (as of r11293) highlighting the matching parens.