[ilyagr]

Fascinating idea!

To summarize for those who know [Kakoune](https://github.com/mawww/kakoune) or [Helix](https://github.com/helix-editor/helix), the idea is that every command has the form ["selection mode" -> "movement" -> "action"](https://ki-editor.github.io/ki-editor/comparisons/modal-edit...) instead of Kakoune's movement->action.

So, instead of having separate commands for "next character", "next word", "next structural element", there is one command for "next" (as well as [a few additional motions](https://ki-editor.github.io/ki-editor/normal-mode/core-movem...)). Every command starts with a ["selection mode"](https://ki-editor.github.io/ki-editor/normal-mode/selection-...) like "column", "line", or "structural element".

It's hard to know without some practice and experience how much I'd enjoy it, but it is a good idea, and perhaps it'd be easier for a newcomer to learn than Kakoune/Helix.

[boomskats]

Is this significantly better than the typical `nvim-treesitter-textobjects`[0] / `nvim-various-textobjs`[1] workflow?

[0]: https://github.com/nvim-treesitter/nvim-treesitter-textobjec... [0]: https://github.com/chrisgrieser/nvim-various-textobjs

[hou32hou]

I think it's significantly better, because you don't need to know the specific type of node you want to select.

In Ki, you only need to use `s` for any syntax node, while in nvim-treesitter-textobject, you need to use `vaf` for functions, `vac` for classes, and so on. Additionally, this also depends on how well the Tree-sitter queries are written, or if they're written at all.

[hou32hou]

To be frank it takes time to get used to, especially if you are already a Vim amateur.

However, once you get the hang of it you will find that most common operations can be achieved within 3 keypresses.

For example, to delete the current line, press `e` (Line selection mode) and then `d` (Delete).

To delete the current word, press `w` (Word selection mode) and then `d`.

To insert new text at the end of the current line, press `e`, then `a` (enter insert mode at the end of the selection).

To insert new text at the beginning of the current line, press `e`, then `i` (enter insert mode at the beginning of selection).

To go to the first line, press `e`, then `,` (Move to the first selection).

To go to the last line, press `e`, then `.` (Move to the last selection).

There are too many of such examples that I cannot fit in one comment, but I think you get the idea. It's all about creative combinations between selection modes and movements.

[samatman]

In Vim:

- dd

- diw

- A

- I

- 1G

- G

Code golfing, I count 12 keystrokes in your example, and 10 in stock Vim.

This is the problem which kak/helix/Ki have with drawing in experienced Vim users: a language is a language, once you know it, you know it, and switching is mostly a drag. It does seem like the "it's better to do it this way" pitch works well enough for those who haven't used a modal editor and are curious.

I disagree with the premise (from the Fine Article) that vi/vim is in some way less coherent as a language. Languages don't really do 'coherent', they do 'expressive'. To get expressive, you need some complexity, and all you can do is hide it in different places.

The argument for Vim's coherence can be found here: https://stackoverflow.com/questions/1218390/what-is-your-mos...

The basic premise of Kakoune, which Ki seems to share, is that it's more natural to move first and then command. That's not how my brain works: I know what I want to do immediately, and it takes more time to express the region I want to do it to (simple things like a line or lines are instant, but would be either way). If I found the opposite more natural, I would use `v` more heavily than I do, and then I might wish to switch. The variety of human minds and personalities virtually guarantees that different people will find one or the other to be more natural.

That all said, I think structural editing is a fine thing, and encourage any and all experiments in modal editing: vim is just a language, not a law of nature, and totalizing attitudes towards language smack of cultural imperialism. Perhaps Vim is stuck in a local optimum, although I don't happen to think so.

So, personally, I might try a structural editor which speaks fluent Vim, but won't otherwise. It's like Dvorak: I see the point in the abstract, but I type around 100WPM without any RSI, I know that switching will make me slower, potentially for a long time, and I'm pessimistic that the final state would be faster: the world record holders use QWERTY.

So I'll just limp along with treesitter objects extensions and hope for the best.

[ilyagr]

I ended up switching to Kakoune and Dance mainly for the multiple cursor support. I treat it like `sed`, but interactive. It feels miles ahead of other editors I know, with the exception of Helix, Vis, and maybe Ki (haven't played with it enough to tell).

> The basic premise of Kakoune, which Ki seems to share, is that it's more natural to move first and then command. That's not how my brain works:

I also didn't find this as a huge benefit, though some people do. That's why I'm sorry Vis (link in another comment of mine) is not more popular; I could far more easily recommend it to other people if it was as polished as Kakoune and maybe had a VS Code plugin.

---------

Now, for some things I don't fully agree with.

> I disagree with the premise (from the Fine Article) that vi/vim is in some way less coherent as a language. Languages don't really do 'coherent', they do 'expressive'.

I think Vim is definitely less coherent. The first example that comes to mind: it's easy to get to the first line with `:1<enter>` or `gg`, while getting to the last line is `G` for some reason (Update: TIL that `:$<enter>` also works, which makes a little more sense. But `:|<enter>` does not take you to the first line). Getting to the first column is `|` I think? I can never remember it, fortunately `<Home>` works.

Now, where I do agree is that, IMO, it's an open question whether making a modal editor's language more coherent than Vim's would make it more expressive or easier to learn. Vim's language is pretty good. My personal feeling is that Kakoune maybe gets close to Vim's bar, and maybe even exceeds it, but not by enough to make it a fundamentally better language (except for its multiple selection support, where it is fundamentally better).

My hope is that Ki might be better, or that its ideas might lead to a better language. I am not certain this is the case, but it should make the situation I described two paragraphs ago better, at least.

> Code golfing, I count 12 keystrokes in your example, and 10 in stock Vim.

To me, the number of actual keystrokes matters less than how much space they take up in my mind and how easy they are to think of (or, better, perform reflexively). If I typed faster than I thought (e.g. if I was transcribing a voice recording or translating), I might feel differently.

[tomtheelder]

Honestly I used to feel this way, but ended up using Helix for a few months mostly as an experiment. Now the selection-action version feels just as natural as action-selection used to. I’m sure I could flip it back if I wanted to.

I’m pretty sure it’s not a natural wiring of your brain, but rather long ingrained familiarity.

That said, incredibly marginal value to switching so I wouldn’t bother.

[actionfromafar]

Bookmarking

[kragen]

what's the keystroke sequence to move forward five words, one word at a time (so you don't have to count them first)? in vim it's wwwww, and in emacs it's alt-f f f f f

the asciinema demos are super cool! btw asciinema has an option to record input keystrokes as well as screen output, but i don't know if there's a way to display them in the standard js web player for it

[wffurr]

I tried but couldn't figure it out from the docs. It's unclear if the selection mode is sticky or is required before each command. e.g. wl would be "next word". I don't know if the command is "wl wl wl wl wl" or "wl l l l l" or if there's a "repeat movement" command.

Update: I installed it and the selection mode is sticky. The command is "wl l l l l"

[kragen]

so sometimes it's just l l l l l, but other times that does a different movement, depending on what mode you're in? how many different things can l l l l l do? are there situations where two of them look the same so you might continue to believe you are in a different mode than you are?

this kind of thing might be a good ux tradeoff but I think you'd have to validate it empirically to see how much the extra cognitive load slows user task completion

[wffurr]

Yes, but there’s a visual indicator what the selection mode is, which helped in my brief experimentation.

[hou32hou]

Selection modes are sticky, so it would be “w l l l l l”

[mroche]

> in vim it's wwwww

You may also want to try out <num><action> methods while in normal mode.

    # Move forward 5 words
    5w

    # Move 20 lines up
    20k

The latter paired with relative line numbering can be really handy.

[kragen]

yeah, that's why i said 'so i don't have to count them first' (the reason i have a computer is so it can count things for me) and used words rather than lines. i agree that relative line numbering is a big plus here

[cassepipe]

I am a vim user and I wonder what is the use of going five words forward when you can just search for the beginning of the word you want to go to and press enter (even works across lines).

After using vim for a while now I do most of my navigation and editing by searching/replacing

[kragen]

yes, usually it's better to do a search in both vim and emacs, unless you're recording a keyboard macro or using multiple cursors. commonly in the macro or multicursor case, the search string would be different on every line you're trying to make the edit on

[cocok]

I wouldn't say either is better "usually", it really depends on the situation.

If the next five words begin with the same prefix (happens to me), searching will be wasteful. Just spamming "w" is easier.

But when there's something really distinctive (often, punctuation) near the position I'm aiming for, I'll definitely use search.

That's one of the reasons I prefer BRE over ERE/PCRE when editing text interactively - I can search for punctuation in code without having to backslash-escape it.

[kragen]

you have some good points

'bre vs. ere' is terminology i wasn't familiar with, though i've often tripped over the differences: https://www.gnu.org/software/sed/manual/html_node/BRE-vs-ERE...

iirc mit teco used control characters for its regexp metacharacters to diminish this particular problem

[Chris2048]

From a theory/implementation point of view, maybe this is relevant: https://groups.csail.mit.edu/graphics/lapis/doc/papers.html