Geospatial Keymap

Recipes & Guides
1

A decade of modal editing has brought me to the following approach which groups conceptual editing concepts into distinct geospatial keyboard locations. In short, you learn how to edit by directly learning muscle memory, rather than the additional step of mnemonics.

It drastically simplifies/streamlines the overall interface to modal editing and is extremely comfortable to use; allowing a resting right-hand position wherever.

As this mapping changes the movement keys to the left-hand asdf it might be
hard for experienced kak/vim users to learn it. But as this has resolved shoulder asymmetry for me at the keyboard, I consider it wholely worthwhile .

I feel as though I can no longer improve upon it’s design, so am sharing it here for whomever may find it useful.

4 Likes
2

Hello! As someone who has radically rebound kakoune’s default keybinds, do you have any commentary on the named function debate? Cheers.

3

Hello, before answering that question it should probably be known that I first used vim for about 6 years, then helix for about 4. The reason I chose helix over kakoune at the time was the exact reasoning behind the post you shared, keymap configuration is just a toml file mapped to named operations.

Compared to the countless hours I spent in vim config files, configuring helix genuinely took minutes. In this regard it was nice and is probably the only reason I was able to experiment easily enough to haved developed the layout I have shared.

However, there are other aspects to software than ease of configuration; many of which are far more significant. Software which expresses itself with itself has inherit qualities it would otherwise not possess. Kakoune does this by expressing it’s actions with it’s keystrokes. This has an interesting (and I consider rather significant) effect of encoding it’s history with itself and also provides a natural pathway for exploration/mutation.

vImproved upon vi and kak does the same upon vim. The editing patterns that we utilize are a form of expression arrived at by the experimentation of Bram and the many people hacking away on runs-of-keystrokes which they could immediately share with anyone (even in an IRC message) by simply typing it again.

That level of lossless, direct communication is unheard of in nearly every other aspect of software development. We are all smacking the same input keys, but we do not all speak the same spoken/written language. English being, by far, my least-liked programming language of any.

It is naive to think one can fully understand what a complex concept like “mode based text editor interacted with by 60+ alphanumeric and symbolic inputs” can or should do off the bat. If you try to define it all in words, your gonna miss a lot of what’s possible as you are no longer observing and interacting with the true patterns of your hands/keyboard/screen, you are just swimming in hypotheticals.

Helix has runtime panicked (sometimes just from being open) more than any other piece of software I have utilized. Every versioned update I tried incorporated new runtime panics within the standard editing primitives, while at the same time incorporating features like “git integration”, 10 new themes, and new colorful branding.

I stopped updating and lived with my own fork that would not panic for a long time. In fact I had to, because the owners of the repository started ignoring my PRs for very basic editing primitives not available by keymap after I attempted to explain more clearly a useful editing paradigm a non-english speaker was attempting to communicate to the admin of the helix’s repo on their forums. I wasn’t even recommending they use it in helix, I was just explaining what somebody else said…

Before switching to kakoune recently I attempted to install the stable version of helix from my os’ package manager just to see if it had gotten better. All the functionality rejected in my PRs has since become a part of helix (not through my PRs), and it panicked within 10 minutes of using it.

A lot of software in the wild has very little to do with good design and a whole heck of a lot to do with egos and other personal motives.

Good software/art is something that you don’t know what it is until you find it, if you think you know what you want and try to paint by number to create the image you want, it’s gonna end up real ugly and broken. But if you accept that all you got at the moment is ugly (not-knowing) to work with, you can combine all that gross shit into something absolutely marvelously beautiful which would have not been obtainable through any other method.

As I have grown older, characteristics such as the intent with which people approach the software they create is of significantly greater importance than immedately receiving what I think I want. Because most of the time what I think I want is not at all what I actually need; and the more the tools we use obfuscate us from the medium we are using, the more we will become unable to even see what’s possible.

This mapping took me a few days to put together, I enjoyed every second of it.

2 Likes
4

I think I understand what you’re saying. It seems like Kakoune being configured in the same way that it’s used makes communication between users and from the user to the software more direct then if it was configured via named functions. You also seem to be saying that this directness avoids a prescriptivist approach in program design. I’m not really sure what that has to do with the differences from Helix that you point out (enhanced stability, not using toml as a config language), though.

5

Precisely.

Instability of software (any system) can come about as a result of trying to force the features you want, rather than finding/understanding the way that those features naturally express themselves and work together within the confines of the system you are working in (binary computation).

Just by reading kakoune’s documentation I can understand what scripting tools are provided, and why they are provided (because they are crucial to the operation of how kakoune operates). If I am capable of understanding (albiet abstractly) what ‘registers’ are and how they are operate, I can do a lot of things. I am learning how to fish.

To approach it from the inverse perspective, is to make ‘registers’ a piece of code to be written like any other function, completely divorced from the big picture of what the software is doing as a whole. This also creates a brick-wall-of-divorcement from the actual computation occuring and our capability to understand the systems we are working within; probably one of the most important aspects to software design that a lot of people don’t seem to consider or care about.

However, a reductive (“prescriptivist”?) approach can be useful for a small cli tool to automate a bunch of disparate unix admin shell commands. In this scenario I need to standardize a bunch of complex interfaces I cannot readily change into something sensible and predictable to get the result I want. A reductive approach achieves these goals.

When I am unsure what I really wanna do, then the other end of this spectrum becomes far more useful as it is inheritly malleable and expansive by definition. I think really good software balances dualities like these harmoniously based on the problems attempting to be solved.

Kakoune does this well, so well in fact, that does not this repository make the entire argument moot? terids/kak-keyoptions: The default Kakoune keybinds as options - Codeberg.org

1 Like