1. 3

    I could recommend utilizing the thumb keys more and offloading work from pinkies. For instance, Shift is a very heavily used modifier and I really like having it on my most accessible thumb key. If you don’t want to lose an existing key, mod/layer taps are a very useful feature (although sometimes you need to tweak it to get it working to your liking). I am comfortably using a 36-key keyboard thanks to these features + combos (aka chording).

    1. 3

      I’m looking at using autoshift to offload most of my shift use. I started with it enabled, but it was really messing me up so I disabled it. I will probably end up using it though.

      I do have a gergoplex kit coming in the mail soon. Once it gets in and I solder on all the switches I will write about it and how I adapted my config to it.

      1. 1

        Autoshift sounds very useful but I admit I haven’t given it a proper shot. When I tried it required me to change my workflow for Vim/Vimium since I tend to hold down keys for scrolling (bad habit).

        Good luck with your Gergoplex, it’s a fun experience optimizing your workflow for 36 keys! Also it is not on QMK master yet, but I have been using this branch successfully.

      2. 1

        Interesting, why that? I have just mapped backspace to my left pinky (Capslock) on an Ergodox and it feels very natural to me.

        1. 2

          Pinky is the weakest finger, so requiring holding it down is less comfortable. You also have to move off the home key positions to reach the outermost column. In contrast, thumbs are pretty strong and you don’t have to contort your hand when holding down a thumb then pressing other alphas.

          There are even layouts which move the most frequent alpha, e.g. E to the thumb: https://precondition.github.io/pressing-e-with-the-thumb

          1. 2

            I do appreciate thumbs keys, previously on an ergodox and now on a Planck. I can’t recommend the SZA ”EZ” products enough.

            That said, the thumb is not really at ease on this keyboard. I find that while it’s strong, the movement required to tap the keys is not the most natural. That being pinching, in an plane orthogonal to the other fingers. As a consequence, I find that turning the keycaps around (with the slope facing the user) helps a bit.

            It’s great at holding modifiers though. My setup is such that each thumb has two tap/hold keys lower(esc), os(space), shift(return) and compose(BS). I often press two modifiers with the same thumb.

            I also kept the lateral and symmetrical control and shift, just for the occasional ZZ, etc.

            The moonlander has a tilted thumb cluster, that should help with that. However those keyboards are so big that holding a key with the thumb makes it problematic to reach the distant keys. In the end, I prefer the Planck/preonic for factor, even with my big hands.

          2. 1

            I feel like this is less keys that are tapped on their own and more an issue for modifier keys; it can cause strain on some people’s hands to reach a far key while the pinky is holding down shift/alt/super/etc.

        1. 1

          The biggest improvement I made in my prompt in years is to only display the hostname when I am SSH’ed. After all I know what machine I am on physically, so it is just extra noise.

          1. 1

            Do you display the username by default?

            1. 1

              I don’t, but I almost never use a different username so YMMV.

          1. 4

            That was an interesting read. The author went deep down the rabbit hole, but took a different approach than most compared to what I have seen in r/ErgoMechKeyboards or various Discord channels. My experience is that people tend to gravitate towards either (a) very customized, keywell keyboards like the Dactyl Manuform (similar to the Kinesis models), or (b) fewer keys so that there is less hand movement, but usually 3 rows and 5 or 6 columns, like the Corne, GergoPlex or Kyria. Not to mention that Ergodox specifically is constrained by some legacy design decisions and is not necessarily very ergonomic, especially for people with normal sized hands.

            It is also worth mentioning that there is a separate trend of going lower profile with Kailh Choc switches so that your wrists are more comfortable and you can perform key combos with multiple keys easier.

            Of course there are many people who work on optimizing their keyboard layout, but people tend to converge to alternatives like Colemak DHm, Workman or RSTHD layouts, rather than coming up with their very customized version.

            1. 2

              Macropads are a good introduction to the deep hole of building your own keyboards, most of which only require basic soldering. For anyone else interested, there are many alternatives through different vendors, with different availability (which is unfortunately usual for this hobby where stock comes and goes, some are only available through group buys etc.):

              These are all programmed with QMK and some even support rotary encoders (knobs that can be used for adjusting volume, scrolling etc.)

              1. 6

                I really like the concept of Kakoune, tried it a couple of times and inverting the movement to action order is a great UX improvement. But unfortunately my muscle memory in vi is keeping me there, the differences is simply slowing me down too much. I would however love to see someone to “steal” Kakoune style editing in a vim extension, visual mode is the closest we have, which I do use quite a bit but it’s not quite the same.

                1. 7

                  I might misunderstand you, but if muscle memory is what’s keeping you in vi, wouldn’t it also keep you from using such an extension?

                  1. 1

                    The upside is that such an extension could be used on an opt in basis, e.g. by toggling it via a :ToggleKak or as an additional mode which can be entered from normal mode. This would allow me to instantly switch back to normal vi-mode thus making me able to get used to it gradually.

                    Additionally I was thinking an extension that keep more original vim movements instead of keeping some and changing others. Word is the same in kak but for instance foregoing g and GG for instance is a massive hassle, I don’t recall on top of my head what more was missing but there was quite a few changes. These changes probably makes sense if you start from a blank slate and thus makes sense for a new editor but as an extension to vi/m I’d rather see adherence to the old learned movement words.

                    Edit: Some things that I notice missing/changed at once when starting kak again and just trying to navigate a little bit in the project I’m working on right now:

                    • Folding, zc/zo
                    • Set line numbers, :set nu
                    • Go to line, :n where n is line number
                    • gcc/cs are popular plugins for comment and change surrounding, these are popular enough to be ported to vi-mode in other editors like vscode.
                    • At this point I’m going back to vi because it’s unfortunately slowing me down to much to get real work done.

                    Now I still love what kak is doing and if I weren’t already a vim user a lot of the things probably make a lot more sense.

                    1. 5

                      I found that the bindings that got changed from Vim was mostly an improvement in consistency, whereas original Vim bindings are constrained by their legacy. For instance in Kakoune shifted version of keys “extend” your current selection rather than move it. Thus, G is just g (which enters “goto” mode that includes g for buffer begin, j for buffer end etc.) that extends the selection rather than moving it, which is why you need to use gj instead of G to go to the buffer end.

                      Other than folding (which is not currently possible) your other missing features are actually available right now, so if you decide to give it a go again here are some pointers:

                      Set line numbers, :set nu

                      This is available as a highlighter, documented in :doc highlighters and the wiki page

                      Go to line, :n where n is line number

                      This is available with <n>g, from :doc keys

                      gcc/cs are popular plugins for comment and change surrounding, these are popular enough to be ported to vi-mode in other editors like vscode.

                      This is built-in with :comment-line and :comment-block commands, but not mapped to a key by default

                      I can’t blame someone much for not being able to discover some features – while in-editor help with the clippy and reference documentation with :doc is pretty great, it doesn’t have a good “user manual” like Vim that the user can discover features through. The wiki also helps but is not very well organized. TRAMPOLINE is a decent vimtutor replacement, but hard to find unless you know it exists.

                      1. 1

                        Thanks, that’s hugely helpful. Will for sure try out trampoline next time I give it a spin, I do love vimtutor.

                  2. 3

                    Similarly for me, kak just simply isn’t available as ubiquitously as vi(m). I fear relearning the muscle memory would be a detriment in the long run as I would still likely need to switch back to vi(m) fairly frequently

                    1. 2

                      What might be left out about how common place vi(m) is the fact that there are vi(m) modes for A LOT of things, I’m talking editors like VSCode, IDE’s like JetBrains suite, Visual Studio, emacs evil, etc. but most importantly all major browsers (vimari/vimium/vimpinator/pentadactly/qtBrowser/w3m/etc), window managers (ultimate macOS for one), tmux, shells, scripting via s(ed), and more. Wherever these will diverge from kakoune there will be friction in daily usage.

                      Again this isn’t criticism to kakoune just a note on how ubiquitously available the vi(m) keybinding set really is.

                      Additionally to that I’ve worked with industrial control systems often being quite literary air gapped (not uncommonly located in rural places without internet connection) running some flavour of BSD/Linux, vi is pretty much always available for some quick adhoc configuration at a customer site, anything else, not so much.

                      1. 2

                        Yeah, this is also a factor for me, though less so as I have never been happy with a vim plugin/emulation layer.

                        1. 3

                          The one in VSCode is surprisingly good if you bind it to a neovim backend. Onivim is also interseting but more expimental.

                          1. 1

                            Have any sources on the neovim backend? I use neovim as my daily editor and was unimpressed by VSCodes vim plugin about ~1 year ago, but using neovim as a backend might address my concerns.

                            I’ve tried OniVim2, as I purchased a license way back when it was fairly cheap. Their current builds seem very promising.

                      2. 2

                        What distro are you using that doesn’t have a Kakoune package available? About a dozen are supported, it’s surprising to hear that the editor isn’t widely available.

                        1. 5

                          What distro are you using that doesn’t have a Kakoune package available?

                          Telecom-deployed clusters of RHEL VM’s.

                          1. 1

                            Can you not use this RHEL package?

                            1. 1

                              First, no el7 build, second, getting it there would be problematic at best (in terms of file copying).

                          2. 2

                            Alpine Linux. I also occasionally deal with embedded ‘distros’ that don’t have a package manager .

                            1. 4

                              I can see a package for Alpine, I’ve installed it myself in Docker containers.

                              In any case, it’s true that muscle memory is a big obstacle when trying to use one or the other. But when you switch over to Kakoune, it’s harder in my experience to go back to Vi bindings (for example when there’s absolutely nothing else installed on a random system).

                              1. 1

                                When I use vim nowadays (and I install kakoune anywhere I need to edit anything), I am staying only with the very limited set of commads.

                                1. 1

                                  The Alpine package is on testing/edge, which isn’t considered stable. I already intentionally stick to stock vi(m) configurations as much as possible to alleviate muscle memory issues, switching seems like a step backwards to me despite the overall UI/UX language being better.