plugins/vim-colemak: init

[kalbasit]

Integrate the vim-colemak plugin.

[GaetanLepage]

What is the difference with https://github.com/linduxed/colemak.nvim ?
If both are doing the same, maybe we should choose which one to add (and have it named plugins.colemak).

[kalbasit]

@GaetanLepage I have not used that plugin. This plugin (mine) is forked from this one with the motion (hjkl on qwerty) moved to neio the keys on the home row for the right hand on the colemak keyboard layout. I submitted a PR years ago but it was never merged.

I have not evaluated the colemak.nvim but I took a quick look at it, and from the README:

unei (ijkl on QWERTY) replaces hjkl

Makes it immediately a no-go for me as it moves the home-row motion into a reverse T style arrow key movement (the u is above e, n to the left of e and i to the right) and that's moving away too far from how Vim typically works with the flat-style motion.

I also do not see it packaged in nixpkgs.

I don't have strong opinions on the name (colemak vs vim-colemak).

[MattSturgeon]

This plugin (mine) is forked from this one with the hjkl motions moved to neio the keys on the home row [...]

I have not evaluated colemak.nvim but I took a quick look at it, and from the README:

unei (ijkl on QWERTY) replaces hjkl

Makes it immediately a no-go for me as it moves the home-row motion into a reverse T style arrow key movement [...]

I also do not see it packaged in nixpkgs.

So to summarise, we have three plugins with the same goal (making vim more colemak friendly) but different strategies. Of those, this is the only one packaged in nixpkgs?

I can see a case for simplicity; naming the plugin simply "colemak"... But it also seems conceivable that (down the line) some users may wish to package and use the other competing plugins instead. On that basis, I think the current "vim-colemak" name is the best choice.

---

As an aside; neio are all fairly fundamental actions in vim, many with a mnemonic relation to what they do; n next, e end of word, i insert, o open new line.

Therefore, even as a colemak user myself, I've avoided these kinda rebindings. I've also held back to maintain consistency with other programs that have vi-style keybindings, e.g. pagers like less that are often used by things like git.

I'm curious how you find this affects your other keybinds?

[MattSturgeon]

No issues from me 👍

[kalbasit]

@MattSturgeon Thanks for your review and approval.

As an aside; neio are all fairly fundamental actions in vim, many with a mnemonic relation to what they do; n next, e end of word, i insert, o open new line.

Therefore, even as a colemak user myself, I've avoided these kinda rebindings. I've also held back to maintain consistency with other programs that have vi-style keybindings, e.g. pagers like less that are often used by things like git.

I'm curious how you find this affects your other keybinds?

It hasn't been easy, but doable. Most programs allows some level of custom keybing, including less using the less-known lesskey program that can adjust its keybinding; See this module I created for it: https://github.com/SoxinOS/soxin/blob/main/modules/programs/less/default.nix

The vim-colemak moves things around to allow me to use neio for motion, and I do the same for all other applications I use. This also forces me to change some settings for (n)vim plugins in order to change their default keybinding, for instance NeoTree, (or multicursors that I'm trying to integrate currently); I'm consolidating my work on the plugins here.

[GaetanLepage]

Ok, this was indeed the motivation behind my question: If we could want at some point to have several of those plugins in nixvim, it is better to anticipate and have it named vim-colemak.

[MattSturgeon]

@mergify queue

[mergify]

queue

✅ The pull request has been merged automatically

Details

The pull request has been merged automatically at a81a03a

[mergify]

This pull request, with head sha a81a03a3f5dcdcdee5cbe831a9f2e81895e92875, has been successfully merged with fast-forward by Mergify.

This pull request will be automatically closed by GitHub.

As soon as GitHub detects that the sha a81a03a3f5dcdcdee5cbe831a9f2e81895e92875 is part of the main branch, it will mark this pull request as merged.

It is possible for this pull request to remain open if this detection does not happen, this usually happens when a force-push is done on this branch colemak, this means GitHub will fail to detect the merge.