Opened 14 years ago

Closed 12 years ago

Last modified 11 years ago

#150 closed defect (fixed)

confused by close paren at end of file

Reported by: gz Owned by: gb
Priority: major Milestone: Cocoa IDE v1
Component: IDE Version:
Keywords: funded Cc:


Reported by Ron Garret in openmcl-devel:

Double-clicking on a close-paren doesn't do the right thing when the close paren is the last character in the file.

Change History (6)

comment:1 Changed 14 years ago by gb

  • Status changed from new to assigned

The confusion may be Cocoa's, on both Tiger and Leopard.

If you double-click at the end of the buffer, #/selectionRangeForProposedRange:granularity: is called with a proposed range whose offset is 1- the length of the buffer (rather than = the length of the buffer.) We don't see any close paren there (or see the wrong one) and fail accordingly.

I'm not sure if anything that we do affects this; we might want to do this differently (e.g., by handling double-clicks ourselves and not overriding #/selectionRangeForProposedRange:granularity:)

comment:2 Changed 13 years ago by gb

This should be fixed in the trunk in r11619, at least under Leopard. The problem there had to do with the granularity argument, not with the range; should check to see if that's true on Tiger, too.

comment:3 Changed 13 years ago by jaj

  • Keywords funded added
  • Milestone set to Cocoa IDE v1

This bug still exists in r11688. Leaving it major since a funder requested it.

comment:4 Changed 12 years ago by gb

I think that I have a fix for this. The text system seems to change the selection when a double-click occurs when the selection is 0-length and at the end of the buffer; it calls #/setSelectedRange:affinity:stillSelecting: to a range that surrounds the last character and with the stillSelecting arg true. Our implementation of that method doesn't change the Hemlock point or mark when that (stillSelecting) arg is true.

The #/mouseDown: method then calls #/selectionRangeForProposedRange:granularity: with the propose range at the beginning of the modified selection (e.g. preceding the last character in the buffer, rather than following it.) There's no way that I know of to distinguish between this situation and actually having double-clicked before the last character, based on the parameters that #/selectionRangeForProposedRange:granularity: receives.

The difference is that the first click of the double-click sequence will have called #/setSelectedRange:affinity:stillSelecting: with stillSelecting false, so the Hemlock point will be set properly. A double-click at the end of the buffer will select the last character (but do so in a way that causes us to not change the Hemlock point); a double-click within the buffer won't change the selection; in both cases, the Hemlock point's position reflects the insertion point location when the double-click began.

Since (AFAIK) #/selectionRangeForProposedRange:granularity: is only called in response to mouse events - and since double-click at the end of a buffer changes the textstorage's selection without changing the Hemlock point/mark - it seems that we can handle both the "double-click at end of buffer" and "double-click before last char in buffer" cases by ignoring the location of the proposed range and using the location of the Hemlock point instead if the current event is a double-click. (Those two locations will - I think - be identical except in the "double-click at end of buffer" case.

comment:5 Changed 12 years ago by gb

  • Resolution set to fixed
  • Status changed from assigned to closed

The fix that I thought I had a few months ago was checked into the trunk in r11967.

comment:6 Changed 11 years ago by rme

(In [13439]) Fix for double-clicking paren at end of buffer, from Ron Garret. see ticket:150.

Note: See TracTickets for help on using tickets.