Mouse selection style differs slightly from NSTextView #46
Replies: 7 comments 5 replies
-
|
Thank you for bringing that detail to my attention! That's an interesting detail. You're right that STTextView does not follow the NSTextView selection behavior. There's more to that story. The selection seems to vary between editors.
|
Beta Was this translation helpful? Give feedback.
-
|
While diving deeper into this, I've come to believe that the |
Beta Was this translation helpful? Give feedback.
-
|
I could be wrong on the "bug" aspect. Just for fun I tried some text selection in gnome on Linux and in Windows. The most common selection style appears to be the I still think the |
Beta Was this translation helpful? Give feedback.
-
what do you mean by midpoint here? we may be thinking about different things. for me anchoring in the midpoint does not result in extending either way |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, that wasn't entirely clear - maybe anchor is the wrong term. It's just that the midpoint is used to determine which way to expand/shrink the selection. Click anywhere to the left of the midpoint, the selection will expand/shrink to the new point on the left, depending on whether you click inside or outside the selection. And vice-versa for clicking to the right of the midpoint. |
Beta Was this translation helpful? Give feedback.
-
I agree on that. I'm surprised TextKit doesn't do it automatically for me. Or I'm using it wrong. either way, something to address |
Beta Was this translation helpful? Give feedback.
-
|
Adding TextEdit app to the mix, that is following the NSTextField style Screen.Recording.2024-02-10.at.01.11.58.movThat one makes me confused even more.
TextEdit app uses NSTextView; however, the selection behaves like NSTextField style. TextEdit app also uses NSTextView in TextKit2 mode. I start to think that is the new default and it behave different depends whether NSTextView uses TextKit1 or TextKit2 setup [I didn't test that theory] |
Beta Was this translation helpful? Give feedback.
-
|
TL;DR: While initial click-drag selection should always work around the anchor, even if moving the mouse first to the right and then to the left (while still dragging), additional shift-clicks should probably expand on either side, without clearing previous selection (though it would be nice if that where to be done only with an additional modifier). Compare with cursor-selection. Special case: Starting with word-selection (from double click). Also: Let's consult Inside Macintosh. I like to point out that it's usually important HOW you selected the text initially. If you mouse-click-and-drag, then there's a start point, and the classic (original) rule was that if you extend the selection, you always replace the selection with the points between your original click and the new shift-click. Compare this also to selecting with cursor keys and shift-cursor: Move the cursor to a point in a word, the shift+forward, then shift+backward. You'll see that it keeps anchoring from the point where you started. You'd expect the same behavior from mouse shift-selection. A special case is selecting a word by double clicking. Still, the same behavior should be kept, only that the start point is the entire word, i.e. the word always remains selected entirely, but shift-clicking on either far side would then select anything between the shift-click and the entire word. Still, all this means: Shift-clicking left side, then right side, should never extend the selection on BOTH sides. That's just not conforming with the behavior when selecting with keys, and makes it hard to predict. Of course, sometimes a user WANTS to extend the selection on both ends. For that, another method is needed, though (e.g. by pressing another modifier). OTOH, one could also argue this: Expanding a selection with shift-cursor_keys is behaving the same as click-shift-drag selection: If you click, then drag to the right, it expands only to the right and when you keep dragging, going to the left of the initial click, the selection expands only to the left. Contrary to that, once this drag-selection is finished, another shift-click could then always expand the selection, to either side, without clearing the initial selection. The difference to the initial drag-selection is that you are already finished with that (this doesn't work with keyboard selection though, because you cannot move the cursor to another place without clearing the selection automatically). In fact, that feels more natural to me, indeed. Also consider how you expand selections in a list (TableView): If you select, then shift-click above or below, it also replaces the entire selection with the rows between your initial row and the shift-clicked row. I.e. no expansion. You can only expand by using the cmd modifier (but, at least in Finder, you cannot shift-cmd-drag, but only shift-cmd-click for single row selection expansion). So, the consensus seems to be that: Shift-click always re-selects between the initial point and the shift-click. If you can indeed expand the previous selection, that may be a poor attempt by some programmers to allow multi-expansion without basing that on a common specification on how to do that consistently. I mean: There's nothing about multi-expansion behavior in Inside Mac, IIRC. It's a poor interpretation that's been causing this mess you're pointing out now. If those who started this expansion method had required an additional key, e.g. cmd, to be held alongside, this could have been avoided. Boo to the "smart" devs that did that without consulting the UX team that Steve fired. ;) |
Beta Was this translation helpful? Give feedback.
-
|
You're saying Safari has it wrong? |
Beta Was this translation helpful? Give feedback.
-
|
Well, I think that it's practical to extend the selection with shift-clicks at both ends, but it's not what Raskin worked out originally, I think. There were other rules back then, and ideally the new rules, which are more practical, should be announced in a wider fashion so that everyone adopts them instead of following the original rules (which some still do, and I would as well hadn't I given this some more thought). And the new rule should also applied to list view and grid view selections (in the latter case, Cocoa's |
Beta Was this translation helpful? Give feedback.
-
|
On top of what was said above, I tried the TextKit 1 is the selection extending like @humblehacker reported here Hard to tell whether that is intentional or not, but that at least sort out the mystery for me. Screen.Recording.2024-02-11.at.18.46.48.mov |
Beta Was this translation helpful? Give feedback.
-
|
To summarize my thoughts. I believe the current behavior is correct/expected in the long run. It is a new behavior derived from the TextKit 2, and it spread across the macOS, too. NSTextView, when using TextKit 2 setup, also follows that new way of selection. If anyone wants to provide implementation to support fallback behavior, I'm ok with that. However, I don't plan to invest my time in it in the foreseeable future by myself. |
Beta Was this translation helpful? Give feedback.
-
I've discovered a small difference in the selection styles between
NSTextViewandNSTextField. Specifically, when Shift-clicking before some already selected text,NSTextViewwill extend the selection, whileNSTextFieldwill replace the selection.To illustrate:
brackets
[and]mark the selection, while|marks the shift-click point.12|345[678]9NSTextView12[345678]9NSTextField12[345]6789As it turn out,
STTextViewfollows theNSTextFieldbehavior of replacing the selection rather than theNSTextViewbehavior of extending the selection. So perhaps ifSTTextViewis meant as a replacement forNSTextViewits selection style should match? Or maybe made configurable?Beta Was this translation helpful? Give feedback.
All reactions