Numeric window selection

[freqmod]

These patches makes it possible to move focus to a window by pressing c+w and then a number like you do with ctrl+ in sublime text, vscode etc. This is particularly useful if you have a wide/tall monitor and thus using the arrow keys would make you have to repeat the command to get to the desired window.

Currently the numbering is based on the window vector list, which may not match the physical layout on the screen. However the displayed id and the window jumped to does match.

This is mostly a starting point for discussion. Especially the size of the window menu may be a bit verbose with this change.

I did look for an integration test, but i could not find any tests for other window commands to be inspired by and this is quite straightforward to i skipped it, at least for now until I know that the current implementation approach is desirable.

[the-mikedavis]

Instead of separate commands for each index, this should be a command that takes the next character as input to determine which index to use. Examples: mi, ma, f and t.

[sudormrfbin]

I think taking the count before would be better suited here, similar to goto line number <n>gg.

[archseer]

I think taking the count before would be better suited here, similar to goto line number <n>gg.

My first thought was using the count too, but there's no way to visualize the split numbers first.

I'd drop all these bindings and instead use cx.on_next_key callback to read the next keypress and convert it to a number. Similar to how r works for example.

[archseer]

Also for the number overlay, here's an idea from tmux: https://asciinema.org/a/KZAbKGDHxitvEmv0TJ90xD5Pm

[freqmod]

I will look into how on_next_key works. Not sure about how to render number superimposed over the windows though (as the tmux image macro), i guess that may be a next step afterwords.

[freqmod]

I rebased the PR on master, and added a commit for taking the index for the window as a parameter (now 1 indexed).

I am not sure what is the best approach to fix the clippy lints complaining about too many parameters to functions in editor.rs. Should i make a struct for passing View, the view index and if indices are visible as one struct, or is it better to just disable the lint cause for those function parameters? I guess if we take in the whole editor as a parameter (as i see it is done in master now) we could at least skip the view and use the index to retrieve it. That will reduce the number of parameters slightly, but not enough as far as i can see.

[archseer]

You can just tag that function with #[allow(clippy::too_many_parameters)] or whatever the lint name is.

[freqmod]

#[allow(clippy::too_many_parameters)

I guess, thanks for the pointer... I was mostly wondering what the policy of this project is, i.e. how many hoops to jump around to avoid too many arguments in the first place.

[freqmod]

Thanks for the comments, and the hints on where to look for refactoring. I added my own conversion functions, to support 1-9 a-z for more views. I put them in helix/helix-view/src/lib.rs but i feel they are probably a bit out of place there too.

[freqmod]

I see lint is failing. I will try fixing that tomorrow. If anyone wants to merge before that just run cargo fmt first.

[freqmod]

I will be abandoning this PR.

The current window numbering scheme is a bit lacking when moving windows around anyhow. I may be trying to get similar functionality working in helicone at some point in the future. Currently i am keeping this patch rebased in https://github.com/freqmod/helix (qol_improvements branch) as long as i am using the helix editor