有关NSTextView的“智能”剪切/复制/粘贴的更多信息

所以随着智能剪切/复制/粘贴的东西yesterday, I definitely did not mean to imply that I thought the general concept of “smart” C/C/P was new在脚注中,我写道:

I’ve only noticed this “smart” C/C/P behavior recently, but for all I know, it’s been around for years, maybe even dating back to NextStepIf it has been around for a while, I suspect the reason I didn’t notice it until now is that I do most of my text editing in BBEdit and Mailsmith, which aren’t based on NSTextView, and even when I am using NSTextView-based text editing apps, ones like Xcode and SubEthaEdit抑制此功能

What I meant here is that I wasn’t sure whether NSTextView had been doing this dating back to NextStep, not that I wasn’t sure whether NextStep originated the idea of trying to do something clever with word-bordering spaces when you C/C/P.

A bunch of Mac apps have offered similar functionality over the years,1and the HIG has contained a“智能复制和粘贴”部分dating back at least to 1992The behavior prescribed by the HIG is sensible enough, and for prose editing probably does do what the user wants almost every time:

If your application supports intelligent cut and paste, follow these guidelines:

  • If the user selects a word or a range of words, the selection itself is highlighted, but spaces adjacent to the selection are not highlighted.

  • When the user chooses Cut, if the character preceding the selection is a space, cut that space along with the selection. If the character preceding the selection is not a space, but the character following the selection is a space, cut that space along with the selection.

  • When the user chooses Paste, if the character to the left or right of the current selection is part of a word (but not inside a word), insert a space before pasting.

Note, though, that the NSTextView implementation clearly contradicts these guidelinesHIG中没有任何内容怎么样you make your selection — a selected word is a selected word, no matter whether you selected it by double-clicking or by clicking and dragging.

And as noted yesterday, my primary complaint isn’t with “smart” C/C/P in general, but rather with NSTextView’s “sometimes you get it, sometimes you don’t, depending on how you made your selection” rules which govern when the feature kicks in.

这样想吧如果在编辑文本时你看到这个:

TextEdit文档中单个选定单词的屏幕截图。

You ought to be able to know exactly what’s going to happen if you hit ⌘X, but in Cocoa apps that use NSTextView’s smart C/C/P, you can’t, because you have to know how the word “uncomfortable” was selected而不是“你是什么看到is what you get”, it’s “what you没有is what you get”, and the whole point of a GUI is about what you see.

The point of “smart” C/C/P is, ostensibly, to free you from thinking about word-bordering spaces before and after C/C/PWith old-fashioned “non-smart” C/C/P, sure, you have to deal with word-bordering spaces manually, but I think in practice, you get used to doing so without even thinking about it, because you know you have to do it every timeCut a word, delete the extra space; paste a word, hit the space bar.

With NSTextView’s implementation, however, you do have to think about it — or at least most users do — because sometimes you get the “smart” behavior, and other times you don’t.


  1. 包括BBEdit,它提供了多年的偏好几个版本之前,它被托付给了历史的垃圾箱。↩︎