confused by close paren at end of file

[gz]

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.

[gb]

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:)

[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.

[jaj]

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

[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.

[gb]

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

[rme]

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