Ticket #64 (closed defect: fixed)

Opened 10 years ago

Last modified 8 years ago

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

comment:1 Changed 10 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 9 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 9 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 9 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 8 years ago by rme

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

comment:6 Changed 8 years ago by rme

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