6 ms·

Fascinating idea! To summarize for those who know [Kakoune](https://github.com/mawww/kakoune https://github.com/mawww/kakoune) or [Helix](https://github.com/he

by ilyagr 2y ago

Fascinating idea! To summarize for those who know [Kakoune](https://github.com/mawww/kakoune https://github.com/mawww/kakoune) or [Helix](https://github.com/helix-editor/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-editors.html 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-movements.html 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-modes/index.html 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.

hou32hou 2y ago
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.
- kragen 2y ago
  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
  - cassepipe 2y ago
    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 2y ago
      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 2y ago
        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 2y ago
        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.html 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
- samatman 2y ago
  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-most-productive-shortcut-with-vim/1220118#1220118 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.
  - actionfromafar 2y ago
    Bookmarking
  - ilyagr 2y ago
    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.
Chris2048 2y ago
From a theory/implementation point of view, maybe this is relevant: https://groups.csail.mit.edu/graphics/lapis/doc/papers.html https://groups.csail.mit.edu/graphics/lapis/doc/papers.html
boomskats 2y ago
Is this significantly better than the typical `nvim-treesitter-textobjects`[0] / `nvim-various-textobjs`[1] workflow? [0]: https://github.com/nvim-treesitter/nvim-treesitter-textobjects https://github.com/nvim-treesitter/nvim-treesitter-textobjec... [0]: https://github.com/chrisgrieser/nvim-various-textobjs https://github.com/chrisgrieser/nvim-various-textobjs
- hou32hou 2y ago
  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.

by ilyagr 2y ago

hou32hou 2y ago

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.

kragen 2y ago
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
- cassepipe 2y ago
  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 2y ago
    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 2y ago
      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 2y ago
        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.html 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
samatman 2y ago
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-most-productive-shortcut-with-vim/1220118#1220118 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.
- actionfromafar 2y ago
  Bookmarking
- ilyagr 2y ago
  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.

Chris2048 2y ago

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

boomskats 2y ago

Is this significantly better than the typical `nvim-treesitter-textobjects`[0] / `nvim-various-textobjs`[1] workflow? [0]: https://github.com/nvim-treesitter/nvim-treesitter-textobjects https://github.com/nvim-treesitter/nvim-treesitter-textobjec... [0]: https://github.com/chrisgrieser/nvim-various-textobjs https://github.com/chrisgrieser/nvim-various-textobjs

hou32hou 2y ago
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.