CODEWITHSUNDEEP
sublimetext3
Santhosh
Santhosh

Reputation: 11788

Sublime text: Home key not moving to the beginning of line

I do the following in sublime text:

Ctrl + A (select all)
Ctrl + Shift + L (into column selection)
Home

i want all the cursors to go to the starting of each line. But in some lines the cursor not going to the beginning of the line

The below is how home key is defined in the Default

{ "keys": ["home"], "command": "move_to", "args": {"to": "bol", "extend": false} },

Upvotes: 0

Views: 620

Answers (1)

OdatNurd
OdatNurd

Reputation: 22791

All of the key bindings that use the Home key to jump the cursor to the start of the line use the move_to command to move the cursor position and specify in the to argument the value of "bol". This includes not just the "bare" key, but also the shifted version that extends the selection, and so on.

The "bol" value of to tells move_to to move the cursor to the beginning of the line, but it toggles between two different beginning of line "states":

  1. The location where the line text starts (for indented lines), which is the "soft" beginning of the line.
  2. Column 1, which is the "hard" beginning of the line

Depending on where the cursor currently sits, you get one or the other, but pressing the key a second time flips the position to the other state.

For example, given a Python example like the following, where | is where a cursor is sitting:

def somefunc():|
    print("Hello")|

The first time you press Home, the cursor will jump to the p in print, because that's the "soft" beginning of the line. While the cursor is there, if you press Home again the cursor will jump to the "hard" beginning of the line. Pressing Home again will put the cursor back on the p. For the def line, the cursor will jump to the first column when you press the key and stay there, because it's not indented at all.

The general idea is that in most cases when you want to jump to the start of the line, it's because you want to make edits to the text that starts there without taking the indent into account (in the above example, say you wanted to swap print for log, it's handier if when you press Home you don't have to arrow right a bunch to get back to the function).

In your particular case you can see this happening when you press the key; the lines containing just indent white space jump to the start, as do the lines that physically start in column 1. All of the other lines jump to the soft bol instead.

If you work in files or content where blank lines don't have any trailing white space and are truly "blank", then you could do what you want to do by pressing Home a second time. In that case all of the lines currently sitting at the soft bol would jump to the hard bol, and any lines already at the hard bol will stay there (because the line is empty).

In your case that won't work because all of the blank lines contain spaces, so pressing the key will swap those lines to the soft bol while the other ones go to the hard bol instead, and you end up with a weird flip-flip that never gets you where you want to be.

One way to fix this would be to use the trim_trailing_white_space command to remove all trailing white space from lines first, in which case you could press Home twice.

This command is the one that gets executed when you save a file and have trim_trailing_white_space_on_save turned on in your preferences, but it's not bound to any keys or menu items by default. So to do that you would first have to bind it to a key, add it to the command palette, turn on the setting and save the content first, etc.

Alternatively you can bind an alternate key (or re-bind the Home key) in your user bindings to specify a to of hardbol instead, which will make that key always jump to column 1 no matter what:

{ 
    "keys": ["home"], 
    "command": "move_to", 
    "args": {"to": "hardbol", "extend": false},
}

Upvotes: 1

Related Questions