Version 3202, macos Mojave
Highlight lines with Shift+down - starting at column 1:
The leading character of the following line is included. I have to hit left after highlighting lines to remove it.
This is new behavior from all the previous versions (and all other editors I have used.)
Thanks
I also cannot replicate it on Linux, Windows or MacOS (Mojave 10.14.3); this operation behaves as it always has. The cursor ends up on column 1 of the following line.
Perhaps you have a plugin or package that is misbehaving?
I don’t usually, but if I turn that setting on, Sublime does indeed behave “weirdly”. I think I can reproduce what you’re seeing here (except that backspace doesn’t alter the selection so much as it deletes the selected text; did you mean to say you press left?).
With block_caret set to false, if I put the cursor on Line 1, Column 1 and press Shift+Down, the first line is selected as I would expect it to be. The status line says that three characters are selected (A, 1 and the \n that terminates the line) and also that two lines are selected, which I believe is because the selection spans two lines; the B is not actually selected here though; if I copy and paste, I get the single line that I expect (including that newline at the end).
Pressing Shift+Down a second time results in the second line being selected; now I have three lines and 6 characters because there are two invisible newlines in the selection. This again performs as I would expect; copy and paste gives you the two lines.
The story is a little different when you set block_caret to true and try the same things. With the cursor on Line 1, column 1, a single press of Shit+Down results in this; the status line still says two lines and three characters are selected, but now the caret is at the end of the first line instead of at the start of the second.
If I press Shift+Down one more time, I end up with the two lines and four characters selected. That is, instead of selecting the second line, it has instead selected just the first character of the next line.
If I want to actually select the full second line I need to press Shift+Down one more time, which puts the block caret on the C in the third line (and includes it in the selection), and then press Left once to move back to the end of the previous line.
At some level this behaviour makes sense. When the setting is turned off, the caret is just a thin vertical line, which allows it to be visually positioned to the left of a character without being inclusive of that particular character directly. That allows the newline from the first line to be considered part of the selection and the cursor to appear on the second line without having to include the first character of the next line in the selection.
If the cursor is a block cursor, then you can’t do that without making it appear as if the first character of the second line is also a part of the selection. So I would imagine that it’s intentional that in this case when you select the first line, the caret stays on the end of the first line (and turns into an underscore shape) to let you know; you have selected the newline so the whole of line 1 is selected.
What seems perhaps buggy to some degree is that one might expect that if the whole of the first line is selected, then pressing Shift+Down should select the second line; that is, the caret should jump to the end of line 2 and appear as an underscore in that case.
Instead what it’s doing is extending the selection one character instead. Perhaps internally it thinks that since the caret is at the end of the first line, pressing that key should select the newline, only since the newline is already selected, it’s selecting the first character on the second line instead. Alternatively, since the caret location is logically in a place where it physically cannot be, it may be intentional that it works this way.
This particular selection behaviour is not new. As far back as build 3006 (the oldest build I have available), the same thing happens when you select lines of text while you’re in overtype mode instead of insert mode. In Overtype mode, the caret is an underscore, so as above it can’t show the selection of the first line completely and also have the caret on the second line prior to the first character because the underscore is a full width of a character.
This is the behavior I’m seeing. I edited my first comment as I had stated I used backspace which should have stated “left arrow key”.
@wbond, would you care to comment?
Thanks!
Looks like a bug. I’d file an issue at https://github.com/SublimeTextIssues/Core/issues.