Eak - Kakoune with an easier keymap

[ftonneau]

At long last, I have published the plugin on which I have been working since I started using Kakoune, and without which I would be unable to use Kakoune.

Here is the opening blurb:

Eak/EAK is a set of key assignments for the Kakoune editor that makes it (a lot) easier on your fingers and even (a bit) easier on your brain. In Eak:

• there are no double modifiers (you never need to press Alt-Shift-...)
• selections are extended without holding Shift
• more common operations involve fewer modifiers (e.g., you repeat object selection with o instead of Alt-.)
• actions on selections involve easy mnemonics: F to fuse selections, D to discard selections, I to copy indent, etc.

Other features include improved navigation by words and subwords, improved support for paragraphs and sentences, automatic selection flipping in the direction of extension, and easy access to advanced grouping/marking operations.

All of this is accomplished without encroaching on the user’s custom mappings and without adding any visual/extension mode.

Link:

GitHub - ftonneau/eak: Kakoune with an easier keymap

Edit: replaced “chords” by “modifiers”

[hpf]

I just happened to come across this in an old reddit thread yesterday! And immediately looked it up on github, since you said there that it was not yet published. Hadn’t even noticed that the repo was brand new

This is extremely interesting to me. I’m still working on the ‘native’ keymap – hoping to make the transition this Christmas holiday – and, as you recommend, will do that first. But I think I will definitely come back to Eak.

[ftonneau]

I guess that many Kakoune users (those with a special programmer’s keyboard?) have no problem with Alt+Shift chords. Other users do find Alt+Shift hard to deal with, however, to the extent of desisting from Kakoune. For example, the issue is explicitly mentioned by (Emacs) Meow’s author (and Helix’s too).

Out of curiosity, are you coming from another modal editor (say, vim/neovim or helix)?

[hpf]

Yes, the chording is more of a mind-bend than the order of operations. Coming from Vim, I really need to get used to doing multiple chords in a row. They take up multiple bytes each in my mental ram, so to speak, so then I need to hit swap - i.e. look them up in docs.

For example, u/U makes perfect sense for undo/redo. <c-r> to redo always tripped me up in the beginning with Vim. In other words, modifier keys always felt out of place to me in the beginning in Vim’s modal language, and it took a while to make their use automatic in the few instances they are needed. In Kakoune, modifiers are much more common, but are used for different meanings on different keys, which makes them unpredictable at first. For example, what Alt does in <a-j>, <a-|>, and <a-!> has nothing to do with each other, and for me at least, that makes it very hard to remember what Alt does in any of those situations.

In fact, U is a ‘chord’, since it involves the Shift key. But in Vim’s documentation, a point is made of always writing the uppercase character, and somehow for me that maps to a single finger operation, whereas when I see or something, it feels heavier.

I haven’t been able to go fast enough yet for the physical aspect which you mention to bother me.

I have two weeks with no pressing work to do in a text editor, so I hope to finally get through the barrier. I’ve been trying to start using Kakoune for the last half year, but its always been a bit too much at once.

(EDIT: my key combos looked too much like html tags and were disappearing: added escapes, e.g. on <c-r> ‘redo in Vim’)

[hpf]

@hpf

what Alt does in <a-j>, <a-|>, and <a-!> has nothing to do with each other…

This is why Eak makes so much sense to me, at least on initial perusal of the README. For example, Step 1, relating moving and extending to each other through context and/or an initial ‘mode’ toggle, the hyphen, means that this whole domain is not spuriously related to other domains through the presence of Alt or Shift.

In fact, the use of a prefix modifier rather than a simultaneous modifier feels more Vim-like. And in my experience so far, that is a huge advantage of Vim’s language for building a mental model. The often-mentioned verb order distinction is one important one, and Kakoune’s choice may be superior, but another linguistic metaphor is agglutinative versus fusional syntactics. Perhaps for text editing, the agglutinative model is more suited? Though I guess all emacs users would disagree …

[7v0lk0v]

this is really really awesome! can’t wait to try it.

but my immediate thought is… how can I merge this with geospatial mapping (thanks for linking to it btw, I’ve come across the concept in other editors but didn’t realise someone’s already done it for kak).

[ftonneau]

In my confused mind, “chord” and “modifier” were roughly synonyms, but I have just discovered that they are not – so I have changed Eak’s README page accordingly. Eak means fewer modifiers, not fewer chords ;~)

[ftonneau]

I do not think you could combine eak.kak and geospatial.kak – at least, not easily. Eak is organized around alphabetical mnemonics, geospatial around spatial relations. Because the design space is tight (there are only so few keys for so many commands/functions in a editor as powerful as Kakoune), any decision about a few keys ripples down to all of the other keys. Differences in basic design entail differences (almost) everywhere, so eak and geospatial tend to be incompatible.

It may still be possible to assemble parts of eak and parts of geospatial into a new monster :-), but again, not easily. Also, if you look at the plugin script, you’ll see that eak is around 800 LOC because it calls many commands behind the scenes: commands that check the state of the current selection, commands that flip the selection, commands that update what the repeat-last-selection key (o in Eak) should do (this may involve selection flipping), etc.

If, like me, you can’t stand Alt+Shift, my recommendation for now would be try both eak and geospatial (there is also a God-mode plugin, btw: link at the end of my GitHub Eak page) and see what works best for you.

[ftonneau]

Interesting! About systematicity vs. mnemonics: Kakoune’s defaut keymap is, in fact, highly systematic: in vanilla Kakoune, “Alt” doesn’t do one single, separable, thing, but means “alternative course of action” (by contrast, “Shift” often means, “extend” instead of “move”). There is real beauty in there, but of course the beauty will be lost on anyone who can’t stand Alt+Shift.

Also, however important, when dealing with an editor (as opposed to an axiomatic system) I think the only value of systematicity is in making learning keys easier (once learned, muscle memory takes over :-). And on this score, mnemonics do just as well (provided mnemonics can be found and that there are not too many of them).

This is why Eak replaces Alt-K (etc.) operations with single, easy modifiers: fuse with F, merge with M, copy indent with I, trim partial lines with T, etc.

Sure, we lose some systematicity (but I have just argued it doesn’t matter as long as we have good mnemonics as replacement – and Eak does have good mnemonics), but we improve vastly on ergonomics (no more Alt+Shift).

Aside from this, and as you note, Eak improves systematicity with its -, z, x, e keys/menus, which group related actions with a prefix. I have tried hard to achieve groups that make sense, as opposed to mixed bags of only loosely related mappings.

[hpf]

@ftonneau

Kakoune’s defaut keymap is, in fact, highly systematic: in vanilla Kakoune, “Alt” doesn’t do one single, separable, thing, but means “alternative course of action”

Yeah, I definitely agree there’s systematicity here: interesting how for me, this results in confusion. At least, I think this is the cause. I guess ‘alternative course of action’ is a bit too abstract of a grouping to tie to one key?

That’s why groupings like you’ve done in Eak seem more like the right ‘unit’. Or, alternatively, the Geospatial approach. Either way, as you say, the end goal is muscle memory.

@ftonneau

(by contrast, “Shift” often means, “extend” instead of “move”)

Which is not followed by e.g. u/U, undo/redo, interestingly. There it’s more like ‘reversal’.

Conclusion: keyboard layout design could be a field of research in itself!

[ftonneau]

True, the meaning of Shift is not universally consistent in vanilla Kakoune: U vs u, also A vs a, I vs i. More reason to not make a fetish of this sort of consistency. Btw, fully agree with your conclusion on layout design

[7v0lk0v]

yea I fully expect it to end up as a monster - but hopefully one easy to love

of course I’m starting with zero familiarity with either plugin but seems to me that a lot of your functionality could be reused by merely changing what keys they’re bound to ie. replacing any less powerful ones in geospatial plugin.

I’ll either start with geo then try plucking things into it from eak, or start with eak then try moving things around - this might be the easier route as I’m already heavily invested into (burdened by) mnemonics (so eak is less to learn/more predictable), and I really like that eak achieves a lot with just a few keys (geo seems more spread out).

[ftonneau]

I have lost any objectivity I might have had with respect to Eak, but I do think it feels quite close to default Kakoune in terms of actual functioning. Just get used to Steps 1 and 2 (about - and movement/extension), then use z, x, e instead of Alt-a/i etc. and you have a lot covered. The easy mnemonics for selection actions (keep with K, discard with D, join with J, etc.) do (most of) the rest.

[gregk]

Very interesting! Thanks for publishing.

To try it out, I have downloaded eak.kak to my home directory which is NOT on the kak plugins path. :source eak.kak to activate it in a test instance of kak. This appears to work fine without changing my “production” kak instances. So far haven’t found any conflicts with my existing kakrc or .kak scripts. I don’t think eak conflicts, but am still testing and trying to understand if it will interact with my own .kak scripts. Would appreciate a little more documentation on the interaction with user .kak scripts and other plugins if any.

Also have a quibble with the 17 steps in the docs. steps implies a progression. It seems to me it’s all 17 at once or none (short of editing the source of eak.kak). I think the numbers are just for reference which is fine. I would omit the word steps (if I’m understanding correctly)

I definitely had to refer to the readme while trying it out. I looked for :doc but didn’t find any. It would be nice to have a :doc eak for those times when I’m using kak disconnected from the internet.

Thanks again. I find kakoune’s flexibility mind bending. And this is an outstanding demonstration of that flexibility!

[ftonneau]

Thanks for the comments, a few replies in turn:

Eak is merely a key remapping and should not conflict with anything, unless, of course, some of your config/plugins call execute-key with the -with-maps switch turned on – a bad idea, I believe, precisely because it puts your plugins at the mercy of a keymap change. I will speak a bit of this issue in the README.

The 17 steps in the README are conceptual steps. In actual use, Eak is all-or-none. I organized the README as a series of “steps” because there is a reason to step ordering. With the exception of Steps 9 and 10 (which could be moved to a later position), all of the steps from 1 to 12 free keys that are repurposed later, up to (and including) Step 13. For example, Step 12 (on pasting) leaves P free for increasing selection width (“plus”) at Step 13. Steps 14 to 17 could appear in any order.

All in all, I think the ordering helps readers understand the “evolutionary logic” from plain Kakoune to Eak. But perhaps I could do some rewording.

I do think that a shorter prospective summary would be helpful, and yes, I should also include a slightly more compact version of the 17 steps as plain text file and/or a PDF for downloading.

Let me think

[ftonneau]

I have rewritten and reorganized Eak’s GitHub readme.

I have added a short note on compatibility with other plugins. More important, the “steps” have been replaced by descriptive titles more in touch with what users will look after. Some of the steps have been condensed/joined, so the whole thing looks simpler.

I have streamlined all details that deserved it, but I have added a short table with the selection operations whose Kakoune shortcut remains valid in Eak.

Last bust not least, the whole explanation is available for download as a plain text file, USAGE.txt, so that you can open it in Kakoune and play with it

Thanks again for your comments, they have been very helpful.

[hpf]

Last week I did a few sessions practising vanilla Kakoune keybindings, and had come to the conclusion before Christmas that I would install Eak long before I became ‘fully fluent’ in vanilla Kak movements. Perhaps this is premature, but I feel like I’ve got the main keys down and have visited and understood most of documentation on a basic level.

The combinations of Shift+Alt are indeed uncomfortable and slow, both physically and mentally, as you pointed out. But the main pain point for me was that I felt like I was spending half my time getting out of multi-selections. It’s really fast and powerful to select a lot of things ,but extracting yourself from them is tedious. For example, turning the selection direction around, figuring out which selection was the primary one, and where my cursor would end up when I escaped.

No doubt this will become easier over time as I became more familiar. However, many features in Eak make this much easier. For example:

Importantly, typing - before w or b (or, for that matter, h, j, k, or
l) automatically flips the selection in the required direction.

This is so helpful and is, I think, the more obvious use case for editing prose.
I will remain aware of the need to really understand how Kakoune’s multi-selection model works, but it was slowing me down so much I couldn’t resist using Eak.

[ftonneau]

Glad to see that things work out smoothly :-).

However, I am not sure I understand your issue with respect to “getting out of multi-selections.” In vanilla Kakoune as in Eak, a single key (, in vanilla Kakoune, q in Eak) keeps the main selection in place, clearing all of the others. What remains when you leave the multiple-selection “mode,” then, is just your main selection (which retains its place and orientation, which any good colorscheme should make obvious).

Now, if you are referring to leaving the multiple-selection “mode” at a specific place/selection, say the Nth selection from the top one, you can prefix , (in vanilla Kakoune) or q (in Eak) with N as a count. However, in this use case I personally find it easier to rotate the main selection manually to the place of interest with ( or ), and leave multiple selections from there.

This being said, Eak does add shortcuts to Kakoune’s goto mode that allow you to leave multiple selections faster:

gk       Move the cursor to the line above the first selection
gj       Move the cursor to the line below the last selection
g[       Move the cursor to the paragraph above the first selection
g]       Move the cursor to the paragraph below the last selection

[ftonneau]

@hpf

Perhaps this is premature, but I feel like I’ve got the main keys down and have visited and understood most of documentation on a basic level.

This should be enough to keep you going with Eak :-). My README is perhaps more emphatic than it should about learning vanilla Kakoune, but I prefer to err on the side of caution.

Also, switching to Eak may allow you to catch up more easily with whatever multiple-selection facilities the Alt+Shift barrier prevented you from learning. In my case, working in vanilla Kakoune, it took me months before eventually understanding how powerful multiple selections are. With Eak (and thus, with the Alt-Shift barrier removed), I am now happy to use multiple selections every day.

In this thread:

https://www.reddit.com/r/kakoune/comments/1o4baiz/prose_vi_bindings_vs_kakoune_philosophy/

I proposed this challenge:

Assume the following table:

| Color1 | (156,52,31) |

| Color2 | (0,76,115) |

| Color3 | (128,86,25) |

| Color4 | (34,51,85) |

where the 2nd field specifies a color in the (r,g,b) format with r, g, b <= 255.

On each line, I need to add the 2nd field converted to (r,g,b) with r,g,b <= 65535:

| Color1 | (156,52,31) | (40092,13364,7967) |

| Color2 | (0,76,115) | (0,19532,29555) |

| Color3 | (128,86,25) | (32896,22102,6425) |

| Color4 | (34,51,85) | (8738,13107,21845) |

How do you do it in Vim?

Here is the answer I gave in Kakoune:

In my use case (real-life example), I first selected the 4-line block, then split it by lines, then selected the final parenthesis blocks, copied them and pasted them at the end of each line.

Then the computation part: Kakoune allows you to pipe each of your multiple selections to any Unix tool that accepts standard input, and Kakoune will replace each of the selections by the standard output of your chosen tool.

In my use case, I selected the inside of each of the newly added parenthesis blocks, then split the inside by commas, and piped the results to an awk one-liner I typed at Kakoune’s command prompt:

awk ‘{ print($1 * 257) }’

Done.

And all of this – available out of the box, no plugin needed – with visual feedback at every step (so you don’t edit anything in the dark :-).

EDIT: Just to be clear, everything (including yanking and pasting) is done with multiple selections.

EDIT 2: simplified awk’s expression along the lines of @gregk’s comment

[gregk]

[quote=“ftonneau, post:19, topic:2793”]
Happy New Year! I will get to your revised docs… Glad to find another awk enthusiast.
Here’s a one liner to do it all in gawk
gawk ‘{split($4,arr,“[(,)]”);print $0" (" arr[2]*257 “,” arr[3]*257 “,” arr[4]*257 “) |”}’`
awk is perfectly content to handle one or multiple lines so you don’t have to split the selection into lines…