9

I've selected some text using my keyboard, starting at the bottom line and moving up (the | character indicates the cursor position):

AAA |{BBB CCC

DDD} EEE FFF

create selection


Now, I would like to change the selection so that it starts at the end of the first line, i.e. so that it looks like this:

Expected result:

AAA BBB CCC |{

DDD} EEE FFF


I can reduce the selection word-by-word with :

manipulate selection with option-shift-arrows


But the natural way to do it would be via , to jump directly to the end of the first line. In many decent text editors this works fine (for instance Sublime Text 2). They also keep the | position visible when text is selected btw.

The default behaviour of OSX apps, however, is that they ignore the fact that the cursor is currently at the start of the selection, and moving it to the right should remove the selection there. Instead, always extends the selection from its end until the end of the line, no matter where the cursor currently is:

Actual result:

AAA {BBB CCC

DDD EEE FFF}|

manipulate selection with command-shift-arrows


Is there any way to make also native OSX apps behave the expected way?

I'm on OSX Yosemite 10.10.2 but I think this issue has been there as long as I can remember.

  • I can reproduce this in 10.10.1—maybe it's been fixed in the beta? – 0942v8653 Feb 16 '15 at 2:10
  • 1
    I'm on Yosemite 10.10.2 (also adding it to the question now). But I think this has always been the case. I primarily use code editors with good text editing capabilities, but I'd love to find an OS-level solution to this. – Jakub Feb 16 '15 at 11:26
  • 1
    Please have a look at this Apple Support Document which states that cmd+shift+right arrow will select text between the insertion point and the end of the current line. The only line in your example, where the selection does not already include the end of the line, is the last line. So the expected behaviour in OS X is to extend the selection from there, not to cut it short in the beginning line! I know that some Editors behave differently, but they are doing it wrong not the system! – Asmus Feb 16 '15 at 19:17
  • 1
    @Asmus There is a little asterisk after the description of that (and many other) keyboard shortcut but there's no explanation for it. Any idea what the (*) means? – Jakub Feb 16 '15 at 21:07
  • 1
    No idea what the (*) means, but it's probably left over from previous versions of the documentation. I've updated my answer slightly to include the global keybinding only option I know of, but unfortunately I'm pretty sure there's no way to achieve what you're looking for. Since the behaviour is not built-in, applications would not now how to handle it even if you could trigger it. – Asmus Feb 16 '15 at 21:30
1

Mac doesn't use the cursor position if you have a multiple text selection, it considers the cursor is at 'all selected text'.

You can see this demonstrated if you use Cmd ⌘ Shift ⇧ instead of
Adding to the selection with Shift ⇧ includes the previous selection.

Not a fix, but a workaround might be which would move the cursor to the end of your current selection, simultaneously deselecting it, then Cmd ⌘ Shift ⇧ to select to the beginning of the line.

  • What does this mean? "A multiple text selection". – Nicolas Barbulesco Mar 13 '15 at 11:33
1

So, the way I see it, text navigation on OS X works (and is expected to work) like this:

  1. Navigate per line (or document, i.e. huge chunks of data):

    cmd+arrow keys : moves by lines (left/right for lines, up/down for the whole document). Hold shift to select

  2. Navigate per word (i.e. small chunks of data):

    alt+arrow keys : moves by word (left/right). Hold shift to select.

So to achieve your "expected result" you should press the right arrow first to get it to the end of your current selection and then cmd+shift+ to select the line leading up to it.

When you already have a selection:

  1. using the alt key combo's above will increase/decrease the selection based on direction (always modifying the end-point of your previous selection, presuming that you've missed the end point slightly). Same goes for adding single characters with shift+arrow keys only.
  2. the cmd combo's increase in both directions, presuming you're after selecting big chunks of text anyway.

Update

Long story short: what you want isn't really possible. If you look at the list of available system key bindings by running

plutil -convert xml1 /System/Library/Frameworks/AppKit.framework/Resources/StandardKeyBinding.dict -o -|pl|grep -v noop:|ruby -pe '$_.gsub!(/[^ -~\n]/)' | grep -i selection

You'll see that even though you can bind custom keys to all selection functions ~/Library/KeyBindings/DefaultKeyBinding.dict there is no such function that achieves your requested behaviour (since this behaviour is not built into the system).

  • I think that Apple Up and Apple Down go to the beginning and end of the document, and do not navigate by page. – Nicolas Barbulesco Mar 13 '15 at 11:36
  • 1
    @NicolasBarbulesco you're completely right, I had written "document" just a line before, don't know why I wrote "pages" next. Fixed it now. – Asmus Mar 19 '15 at 19:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .