if I click on the line number for a line it selects that line but it does not select the selected line number but the line number of the following line.
Select line not working right
deathaxe
#2
As the whole line including newline is selected, the caret is placed on the next line - right after the end of a line.
Gutter always highlights lines a caret is located in. It is unrelated with selections.
0 Likes
mark4
#3
if a line is selected the cursor should be put on THAT line not the foillowing line.
0 Likes
deathaxe
#4
That’s a question of taste and use case. Ctrl+shift+L does the same and often it is handy to have a selection including trailing newline to add it in between other content. As a result, caret is located at the next line.
0 Likes
mark4
#5
Well, while this is not a deal breaker for me it is a deal breaker for someone I recommended the editor to who is actively seeking a replacement for an editor he has used for years which is now bit rotting.
I still recommend it even for him but this behavior is counter to his preferences and I agree with him, the behavior is coimpkletely and utterly WRONG. But …
So is the HORRENDOUS auto double indent inside a switch statement then auto UNDENTING when I start typing a case which drives me ABSOLUTELY batsh*t crazy to the point where the behavior destracts me so much i lose my train of though while typing almost every time.
Yet… I wont be abandoning ST any time soon : ) and will always recommend it…
0 Likes
bschaaf
#6
The caret going to the next line is standard behavior in every text editing field I’ve ever seen. Firefox, Chrome, Atom, VSCode, Notepad, Notepad++, WordPad all behave the same way ST does because it’s standard behavior.
You can control smart indentation using the "smart_indent" setting.
0 Likes
kapitanluffy
#7
I guess that would be a nice setting for preference? or maybe if we can listen to the clicks on the gutter, we can override it?
@mark4 if your colleague is okay with keyboard shortcuts, ask him to put this
{
"keys": [ "ctrl+alt+l" ],
"command": "chain",
"args": {
"commands": [
{ "command": "move_to", "args": { "to": "hardbol", "extend": false } },
{ "command": "move_to", "args": { "to": "eol", "extend": true } }
]
}
}
This should allow him to select the line with the caret at EOL w/o the newline
0 Likes
elmoonlite
#8
To be honest, it does look a bit weird.
You select a line, and 100% of the selection is in the line above the highlighted gutter line number.
I can see how that can be very confusing for a (new) user.
I think most of the confusion can be caused by the fact that highlighted selected text and highlighted line/gutter are colored the same, but they represent different things. If the color of the selected text is clearly a different color than the line highlight with the caret in it, then everything makes a lot more sense intuitively. It could be this depends on your selected theme.
e.g. Mine does show them in the same color. From my Mariana.sublime-color-scheme (dark theme),
"line_highlight": "var(blue2)",
"selection": "var(blue2)",
If I change this to:
"line_highlight": "var(grey)",
"selection": "var(blue2)",
now I can clearly see the difference between selection and line highlight, and it makes more sense.
I do think that when a text editor has a select line feature then usually it does include the newline in the selection.
However, not all text editors display this the same.
Some editors light up behind all the characters on the selected line and nothing else.
Some editors light up behind all the characters on the selected line, and the final newline as an extra selected whitespace character.
Some editors light up behind the entire line, including everything to the right of the last character, beyond end of line.
Some editors do not have a gutter so there is no gutter to highlight on the next line.
Some editors do have a gutter, but they do not light up on the next line.
Some editors show no caret when something is selected.
Some editors show the caret at the beginning of the selection instead of at the end.
When there is a gutter with line numbers, clicking it has different meaning in different editors. Some do nothing, some select the line, some editors place a breakpoint, some do something else.
Some editors do not even have a select line option.
All this is to say, not all editors are the same, or have the same features. So it is to be expected behavior is different from what one can expect.
Another interesting thing is what happens with a selection and then using arrow keys. Most editors seem to do it like this: the first left click puts the caret at the beginning of the selection and unselects all, or the first right click puts the caret at the end of the selection and unselects.
An option could be to reverse the selection; the start of the selection after the newline, and the end of the selection at the beginning of the line (e.g. click “end” key, then “right”, then “shift+up”), now the caret is on the same line as the selection, and the gutter lights up at the selected line. However, that does mean that when you alter the selection (shift+click, or shift+arrowkeys), it changes from another point. So probably not a solution for everyone.
Another option might be to change the behavior when clicking the gutter.
Right now it toggles between selecting the entire line (including newline, caret on begin of next line), and selecting the entire file (not sure why, does not seem very useful).
Maybe toggle between selecting the line including or excluding the newline.
Or reverse the selection, from after the newline to begin of line, so the caret is on the same line.
Another way of selecting a line is triple clicking.
Right now the first click changes caret position, 2nd click selects word, 3rd click selects line, and then cycle back to 2nd, alternate between 2nd and 3rd.
We could optionally introduce a 4th state: 1: move caret, 2: select word, 3: select line without newline, 4: select line with newline, then cycle back to 2.
To be honest, I’m fine with the current behavior because I’m used to it, but I can see how things can be confusing for others.
I think it is mostly a display issue, which can be fixed with clearly different colors for selection and line highlight, and leave the rest of the behavior as is.
0 Likes