"Better" Home/End/PageUp/PageDown

[patrick-kidger]

I'm new to Helix and really enjoying it.

In both Vim and Helix, I find myself using Home/End/PageUp/PageDown very frequently -- for example, End to get out of some autocreated close-brackets and close-quotes, and PageUp/PageDown to quickly scroll through a file and refresh my thoughts.

I'm thinking that their implementation in Helix can be improved a bit. I've had a look through the issues and not seen this topic already discussed. Hopefully the following aren't a classic case of a poorly-thought-out suggestion from a new user.

I write "better" in quotes because I recognise that some of these might be subjective.

1. "Better" defaults.

I ended up adding the following to my config.toml almost immediately after getting started with Helix:

[keys.normal]
H = "goto_line_start"
L = "goto_line_end"
J = "page_down"
K = "page_up"
"S-left" = "goto_line_start"
"S-right" = "goto_line_end"
"S-down" = "page_down"
"S-up" = "page_up"
g = {e = ["goto_last_line", "goto_line_end"]}

# Copied out appropriately to the other modes like keys.insert etc.

Obviously I can just keep using this file, but I thought I'd suggest these as perhaps a reasonable modification to the current default keybindings.

So far I'm loving using these: I find it much (much) quicker to quickly scroll through a file than having to shift my finger positions to C-f and C-b. Doubly so when avoiding moving my whole hand to Home and End. I think this is also much more consistent with the current Helix keybindings than C-f and friends. (I'm contemplating also rebinding A-l to w, etc., although I've not played around with that as much.)

These proposed defaults do override the existing behaviour for J, K and ge, but I feel like J and K are niche enough that they can probably be found a home elsewhere. And realistically I never use ge except in the context of gegl.

2. PageUp and PageDown do nothing on short files; more generally speaking they don't move the cursor if it would go beyond the start or end of a file.

Once again this feels inconsistent. PageUp and PageDown currently do two separate (in principle unrelated) things: (1) they move the view window. (2) they move the cursor. As a result of (2) I find myself using them as a handy way to move the cursor over large regions, which is a use-case that stops working at the start or end of a file. So I would advocate that in this case the cursor is "clipped" to to land on either the start/end of the whole file, or the start of the first/last line of the whole file.

---

If there's interest, and I can be pointed at where to start, I'd be happy to try making a PR for these. I'm guessing 1. can be accomplished just through changing a default config file somewhere. I'm very new to Rust but would guess at 2. being a good first project.

[the-mikedavis]

There has been some discussion on this especially with Home and End in #1511

These all seem like personal preference to me and I'd prefer to not have them in the default keymap. IMO there's nothing uncomfortable about the goto menu: I prefer gh and gl to H and L - if you count Shift as its own keystroke, it's the same number of keystrokes except that with H and L you need to press the keys simultaneously. In particular that seems uncomfortable on a regular keyboard with the arrow-keys bindings.

C-f and C-b are carried over from vim as far as I know and there might be some room for improvement there at the cost of muscle memory for vim converts. They're not the only ways of shifting the view though: I often use the z menu's commands like gczt to focus the view to the top of the old view-point's center.

PageUp and PageDown do nothing on short files ... this feels inconsistent

inconsistent with respect to what else? These commands only move the view and the cursor only follows the view because it's not allowed to leave. I think the commands would be doing too much if they also moved the cursor.

[patrick-kidger]

Yeah, I realised some of this might be personal preference.

However, I have also just clocked that insert mode has a whole different set of keybindings for moving around, that I think are entirely inconsistent wrt the normal mode keybindings. e.g. C-f is page-up in normal mode but forward-one-character in insert mode. w is forward one word in normal mode, but delete the last word in insert mode? etc. etc.

PageUp and PageDown do nothing on short files ... this feels inconsistent

inconsistent with respect to what else?

Wrt themselves. They always move the viewport. Sometimes the move the cursor. It'd be nicer to have commands that operate without edge-case "sometimes".

---

FWIW, I came to Helix out of a dislike of the hodge-podge of inconsistency in Vim. One of the main attractions for Helix was reading that it had consistent defaults that worked out-of-the-box. I know many folks love customising their Vim/etc. setups, but personally I'd rather use something simple+consistent+opinionated from someone who has already thought this through (rather than making thinking-this-through another item on the neverending to-do list of my own). Anyway, that doesn't seem to be the case.

That's no bash at you or the other contributors to Helix! Perhaps this simply isn't the product for me. Thank you anyway, and I'll keep looking around at some of the other alternatives.

[pickfire]

These proposed defaults do override the existing behaviour for J, K and ge, but I feel like J and K are niche enough that they can probably be found a home elsewhere. And realistically I never use ge except in the context of gegl.

pageup and pagedown is a disastrous key such that the column will be moved which is probably why the reason it is not done as J like you said or in g and it is done in C-f.

C-f is page-up in normal mode but forward-one-character in insert mode.

Oh, I just realized that, but I think that is due to consistency with GNU readline, it's useful I think.

Closing the issue as the proposed keys seemed far too weird, J, K, if we take those two

• means leaving the rest of the shift keys inconsistent (N, P, O), but J I think it's just that due to vim
• opens up the argument that J and K should move half page down or up (some people may use half of full page up down), or even by sentence or paragraph
• disastrous movement key such that JK might not move back to the same position

But yeah, what you showed for S-left to go to leftmost is still okay I think but not really that useful given that home and end can do the same thing, but C-left (currently we have A-left) looks like reasonable to be able to move a word left or right (like in most GUI editors) and we current don't have that.

Thanks for discussing about this. But if you do have better suggestions on why we still do need it feel free to reopen the issue.

[adrian5]

Like @patrick-kidger, I find myself scrolling quite often. In neovim I use C-j and C-k for that, which is still unmapped in helix, no? I always found the mod_key + <action> approach very intuitive in applications. You replicate behavior of a similar nature in a slightly different direction/context.

Modo (3D application) used to do this to great effect, and imo much better than any competing product.