njr 3.0

Tonight I’ve been tackling the conflict between discontiguous selection in Tiger’s Cocoa text system and ICeCoffEE. I initially thought it would be a primarily technical problem to fix, but it turns out to be much more interesting.

For those of you who haven’t discovered it, discontiguous selection can be pretty useful. If you’re using Tiger, feel free to follow along, but if you’ve got ICeCoffEE installed, temporarily uncheck “⌘-click to open URLs and email addresses” in ICeCoffEE settings, under the Modules tab of the Application Enhancer System Preferences pane.

If you’re not using Tiger, open Nisus Writer Express or grab a demo of 2.1.3. Nisus has implemented discontiguous selection in its word processors for quite a while. (I seem to remember Microsoft Word 2004 does it, too, but I don’t have a copy to check.)

Open TextEdit (or Nisus Writer Express). Type a few words of nonsense, say “foo bar baz”. When you double-click “foo”, it selects the word, so you should see “foo bar baz” (in your preferred highlight color :). Now, hold down the Command (⌘) key, and double-click on “baz”. The selection should now be “foo bar baz”.

Nisus Writer Express (NWX) and Cocoa’s behaviors differ somewhat. Discontiguous selection in NWX is additive, whereas in Cocoa, it inverts. If you Command-double-click on “foo” again, NWX will leave “foo bar baz” selected, while TextEdit will show “foo bar baz”. I much prefer Cocoa’s selection inversion, as it allows you to undo one of a series of selection components without having to start over, and matches the established behavior of the Command modifier in lists.

So what does this all have to do with ICeCoffEE? With the introduction of discontiguous selections and their use of the Command key in text views, there is now a difference between a Command-click and a regular click, and a Command-drag and a regular drag within text, where before there was none.

With ICeCoffEE 1.4.1 enabled, the first click you make with the Command key held down tries to open a URL surrounding the place you clicked. What can I do to make ICeCoffEE work yet preserve the ability to select discontiguous regions? Let’s ignore the possibility that I could change ICeCoffEE’s invocation mechanism fundamentally—say, by adding Control to all the modifier combinations.

The easy case, where it’s obvious what to do—but ICeCoffEE 1.4.1 doesn’t—is when you drag the mouse with the Command key held down. Dragging means moving the mouse substantially, which I define as 4 pixels horizontally or vertically. Whether this drag serves to extend the selection or initiate a drag and drop operation is immaterial; ICeCoffEE should stay out of the way regardless.

If you’ve already got a discontiguous selection (or any selection at all), ICeCoffEE could also do nothing, allowing you to Command-double-click to your heart’s content. There are at least two problems with that, though:

1. In a future version of ICeCoffEE, I plan to add support for opening a URL consisting of the selected text, if you Command-click somewhere within it. Currently, if you try that, ICeCoffEE does its usual thing of creating a selection starting where you clicked, and ignores the current selection. To change this behavior, then change back later, would be confusing.
2. If the selected text is not visible, or the user just doesn’t notice, Command-clicking will cause nothing to apparently happen. I can see the bug reports now.

There’s even a case in which there is no selection and a Command-click should not trigger ICeCoffEE. When some users, such as my mother, use the Command key to perform discontiguous selection in lists, or select multiple icons with the Shift key in the Finder, they hold down the modifier key before selecting the first item or range. There is no difference between a modified and unmodified selection at that point, but with ICeCoffEE implementing the above behavior, the wrong thing would happen in the user’s eyes.

Another possibility: Always trigger on a Command-click which is not followed by a second click, incorporating a delay similar to the Finder’s file renaming delay. Try it: double-click on an icon’s name in the Finder. Did you click fast enough to open it, or did the name select itself for renaming? Conversely, try clicking once on the name, and note the time it takes for the rename field to appear. Would you mind that delay in ICeCoffEE for URL launching?

Or… can you think of a better way to distinguish between discontiguous selections and ICeCoffEE invocations?

The alpha version of ICeCoffEE I’ll release tomorrow employs a very simple test: if there’s any text selected, the Command-click is processed as a URL launch; if there isn’t, it gets passed through, and used for selection. This is not a good solution, as discussed above, but it’s working for now.

Assuming your eyes haven’t glazed over yet, your thoughts are appreciated.

11:37 PM | PyCS