
Show HN: Vim-Like Layer for Xorg and Wayland - ceda_ei
https://cedaei.com/posts/vim-like-layer-for-xorg-wayland/
======
renke1
I am also using a custom keyboard layout (basically the movement layer from
the NEO layout + left alt → left ctrl, right alt → left alt, caps lock → esc).
Initially it was implemented as xmodmap, then as xkb layout and finally as C
program using Interception Tools [0]. I had problems with both xmodmap and xkb
where it wouldn't work in certain applications; Interception tools works
everywhere (even in VMs and outside of X/Wayland).

[0]:
[https://gitlab.com/interception/linux/tools/blob/master/READ...](https://gitlab.com/interception/linux/tools/blob/master/README.md)

~~~
fock
Does it need root/sudo? Or only plugdev or some other "sit-in-
front"-privileged group and there you go?

~~~
renke1
I don't think the program itself needs elevated privileges, because it only
reads from stdin and writes to stdout. I am running the interception tools as
systemd service, though. I think the Intercepton Tools themselves need
elevated privileges; I mean, it's kind of key logger if you think about it.

------
dlkmp
I've done a similar thing at the hardware level using a QMK layer. The main
benefit for me is being able to use VIM movement keys in every text input.

As I'm using a dual boot setup, it's also pretty handy to have the mapping
directly embedded in the keyboard firmware.

~~~
Ianvdl
Thanks for mentioning QMK [0], it's not something I've heard of before, and it
seems like a huge step up from standard keyboard firmware. As far as I can
tell only a small number of manufacturers officially support it, but at least
one person seems to have made some progress getting a standard cooler master
keyboard to run it [1].

[0] [https://qmk.fm/](https://qmk.fm/) [1]
[https://github.com/qmk/qmk_firmware/tree/master/keyboards/bp...](https://github.com/qmk/qmk_firmware/tree/master/keyboards/bpiphany/unloved_bastard)

~~~
secure
It’s reasonably simple to port QMK (at least partially) to a new
microcontroller.

I have worked on Teensy 3.6 support for QMK, and plan to work on Teensy 4.x
support as well.

~~~
Ianvdl
Is any special hardware needed, or is it all software work?

~~~
rfoo
It's more like full-hardware-no-software work.

Basically if you want to use this on your "standard" keyboards bought off the
shelf, you have to either:

1\. Open your keyboard, replace the keyboard controller with something that
you can program via soldering etc.

or 2. Pray your keyboard doesn't use a mask ROM to store its firmware, and it
has a powerful enough MCU as keyboard controller, then figure out how to
reflash it and port QMK to it blindly.

------
secure
The NEO keyboard layout ([https://neo-layout.org/](https://neo-layout.org/))
which I’m using for over a decade, has a similar concept of a number of
additional layers.

This is quite handy for having a bunch of special characters for programming
readily available (hover over the layers on [https://neo-
layout.org/](https://neo-layout.org/) to see).

For any other modal use-cases (e.g. resizing windows, changing music volume),
I use i3’s modes:
[https://i3wm.org/docs/userguide.html#binding_modes](https://i3wm.org/docs/userguide.html#binding_modes)

------
jolmg
They're using sway/i3. I don't understand why they're doing it like that when
sway/i3 already has support for modes.

They could have just done something like this in the sway/i3 config:

    
    
      mode "normal" {
        bindsym i mode "default"
    
        bindsym q kill
        bindsym y exec volchange -5
        bindsym u exec volchange +5
        bindsym o exec brightness -200
        bindsym p exec brightness +200
        bindsym w exec mpc prev
        bindsym e exec mpc toggle
        bindsym r exec mpc next
        ...
      }
    
      bindsym $mod+c mode "normal"
    

EDIT: I've realized their method has the benefit of working with other window
managers that don't support modes or on-the-fly reconfiguration.

------
Ianvdl
As someone who uses Vim daily, I quite like this idea. I would customise it to
mimic the original Vim bindings a bit more closely where possible though, to
e.g. keep Ctrl-D as page down.

I'm not sure if this would be possible, but it would be fun to have
customisable per-application bindings (based on the active window, probably)
in addition to the set of global bindings. I can also think of minor cases
where motions would be useful, like 3x alt-tab (i.e. 3gt) to switch to a
specific application.

I wonder at what point the depth of the mode-ness will become too much, if you
were running this, for example, with a vi-mode bash readline.

~~~
ceda_ei
> e.g. keep Ctrl-D as page down.

I tried doing the same using xdotool by binding Ctrl+F<something> to PageDown
but for some reason it didn't work for some reason and I didn't investigate
enough.

~~~
addcninblue
I believe a possible reason is that the OP used xkb, which if I'm not mistaken
is lower level than xdotool (so xdotool would not suffice)

~~~
ceda_ei
I am the OP. What I tried was something along these lines.

e.g. to get w in normal mode to send Ctrl+right, I did the following.

1\. Bind w to F14 in normal mode.

2\. In i3 config, add `bindsym 0xffcb exec xdotool key ctrl+Right`

If I simply ran the command (`xdotool key ctrl+Right`) in normal mode, it
would work but it didn't work via a binding.

This was infact the initial idea behind all this but after quite some testing
xdotool turned out to be unreliable so I repurposed it as a shortcut layer.

------
npmisdown
I'm fan of heavy key mapping customization to boost productivity.

The most productive remapping so far which I made is to globally remap (via
xkb) Left Alt + HJKL to respective arrow keys. Works in all GUI applications
which rely on arrow keys for navigation, plus standard Ctrl + Shift + Left Alt
+ H (Left Arrow) works to select previous word in text fields (e.g. in
browser).

Next one is to remap Left Ctrl to Left Shift and to press it with upper side
of the palm just below pinky (not sure how this part of the hand is called
correctly) instead of utilizing finger for that. Works best on mechanical
keyboards without bevels.

Also I find quite useful to remap keys 5-0 to Right Shift + Q (5), W (6), E
(7), R (8), D (9), F (0). I find these keys are easier to reach and type
without a mistake instead of using standard 5-0 keys which you should stretch
your fingers to type. For example, to type "()" I use Left Ctrl (remapped to
Shift) + Right Shift + D, F which is easier to type without fingers leaving
home row.

~~~
Fnoord
I use Hammerspoon and Karabiner Elements on macOS to rebind keys (including
the examples you gave). There's some examples and repositories available for
these applications.

On Windows, I use AutoHotKey, though mainly for gaming (be aware it can get
you banned on some games though; investigate this beforehand).

On Linux, I have a bit more difficulty with all of this because:

1) There's no standard application or configuration or even desktop. As of now
I mainly use Gnome, but my preference would be to use more lightweight WM/DE
on some of my devices.

2) I sometimes use a Linux desktop in a VM, from macOS.

------
codethief
I've been thinking about doing something like this for quite a while. One
question that's been bothering me is: How will I know what mode I'm in? Can I
somehow change the cursor system-wide? Can I add some sort of notification to
my i3bar?

EDIT: I just noticed that the article mentions this as a "bonus" at the end.
Does this work reliably with i3status-rust? In case of i3bar at least there'd
always be a delay coming from the low refresh rate of (in my case) 5s.

~~~
discreteevent
I wrote a keyboard hook in C for Windows (I was using AHK but it was
unreliable). Initially it was modal but I found over time that I would get
caught out. So now it's not modal. I hold down capslock and then use ijkl to
navigate etc. The only thing left that is modal is spacebar for select/visual
mode but I still a have to hold down capslock for that (e.g. capslock down,
space bar, ijkl to select text, capslock up). Also I was using hjkl but
switched to ijkl to match the arrow keys. I don't use vim enough anymore to
justify hjkl.

Holding down capslock turns out to not be a problem in practice. The main
benefit of vim style navigation for me is not leaving the home row.

~~~
codethief
> Also I was using hjkl but switched to ijkl to match the arrow keys. I don't
> use vim enough anymore to justify hjkl.

Same here. ijkl is so much better!

> So now it's not modal. I hold down capslock and then use ijkl to navigate
> etc.

Hmm… maybe I should try that. Then again, I _am_ afraid of getting the Emacs
pinky all over again…

------
kohlerm
Get a keyboard with layer support,
[https://docs.qmk.fm/](https://docs.qmk.fm/). No need for different modes ...

------
rlkf
I wonder if, instead of having two different layouts and changing between
them, an alternative would be to put all the navigation keys at fifth level
and above, and then hijack the Kanji modifier to switch to them, or maybe
pretend you're a Far East keyboard and use Eisu_toggle.

------
seqizz
Good idea. This could be also useful for assigning custom functionality
instead of vim (e.g. window management).

Also one can switch backlights/keyboard colors depending of the keyboard mode
for visual feedback.

------
sieste
In the fluxbox WM you could achieve something like this using keymodes

[http://fluxbox-wiki.org/Keymodes.html](http://fluxbox-wiki.org/Keymodes.html)

------
geocar
Have you considered just using a (sticky) compose key and setting macros for
some weird characters? That way you wouldn't have to run scripts to change
modes.

------
Timpy
Does this get confusing when you're actually using Vim? Do you ever use
Keyboard Normal Mode when you're in Vim?

~~~
ceda_ei
No, it doesn't. I use keyboard normal mode sometimes for things other than
navigation, like seeking audio, etc

------
fock
sadly wayland means only sway. I've done some remapping as well, but don't
know how to make Gnome in wayland mode (which is nice on a cramped notebook
and someone has to test wayland...) read anything from a user-specified
directory, so I have to edit stuff in /usr every update anew...

------
ggm
Some concrete examples of using it? Did I miss the demo showing some good
exemplary behaviour driven by this?

------
modalkb
I just had a crazy idea based on this- (it's not going to be useful as is,
mostly novel and potentially good)

You know how a desktop screen is fixed width and windows cannot be outside of
the screen (at least in tiling), I want a single workspace for all windows,
where they arrange non-ovrlappingly and screen would just be a view to a fixed
point so I can scroll (quickly using hjkl) in 4 directions to look at other
windows and even maybe select a group of windows and make them my current
view.

Much more dynamic than i3, my current wm.

~~~
vladvasiliu
I've never used AwesomeWM but from a brief reading, maybe it could do part of
what you want: "maybe select a group of windows and make them my current
view".

From what I understand, windows don't belong to a workspace, but a workspace
is a collection of windows having a certain tag. A given window may have
multiple tags, so it can belong to multiple workspaces.

