Opened 13 years ago

Closed 12 years ago

#64 closed defect (fixed)

blinking parens are too slow to start blinking

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


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 (6)

comment:1 Changed 13 years ago 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.)

comment:2 Changed 13 years ago 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.

comment:3 Changed 13 years ago 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.

comment:4 Changed 13 years ago 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.)

comment:5 Changed 12 years ago by rme

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

comment:6 Changed 12 years ago by rme

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.