5 ms·

Is it just me, or in the latest few (10?) years there have surged more vi-like alternatives like never before? - Kakoune - Helix - Vis - Ki - Ad - ...

JadeNB 2y ago
I'd never heard of Ki, and it's hard to google. Do you have a reference?
- yjftsjthsd-h 2y ago
  Sounds like a Google problem; https://duckduckgo.com/?t=ffab&q=ki+text+editor&ia=web https://duckduckgo.com/?t=ffab&q=ki+text+editor&ia=web gives https://ki-editor.github.io/ki-editor/ https://ki-editor.github.io/ki-editor/ in the first screen.
  - dcre 2y ago
    It’s the first result for “ki editor” on Google as well. I suspect they just typed in “ki”.
    - JadeNB 2y ago
      > It’s the first result for “ki editor” on Google as well. I suspect they just typed in “ki”. I tried "ki vimlike." In retrospect, "ki editor" would have made more sense.
- barnabee 2y ago
  https://ki-editor.github.io/ki-editor/ https://ki-editor.github.io/ki-editor/ It’s quite a young editor but is conceptually pretty neat! It works on syntax trees as defined by tree sitter, and the tutorial on their site shows off how powerful that is pretty nicely. I also like how it gets by with pretty much just buffers and readline for everything. I’m a bit more wary of all config happening by changing code and recompiling, though. Definitely one I’m watching, though it’s far from being able to tempt me away from Helix at this stage.
  - porridgeraisin 2y ago
    This is nice. I like this editor, will try it out. The beginnings of a "mode" exist in vim, with plugins like tinykeymap that let you get into "tab manipulation mode" or "window manipulation mode", you can really do that with anything though, but maybe not as extensively as in Ki. It's quite a neat trick, example that lets you c-w +++++ instead of c-w + c-w +: nmap <C-W>+ <C-W>+<SID>ws nnoremap <script> <SID>ws+ 10<C-W>+<SID>ws nmap <SID>ws <nop>
  - lern_too_spel 2y ago
    A lot of these new editors do things that Emacs does quite easily while losing all of Emacs's other advantages. https://www.masteringemacs.org/article/combobulate-structured-movement-editing-treesitter https://www.masteringemacs.org/article/combobulate-structure...
    - barnabee 2y ago
      Honestly I think being narrower in scope and less (or at least more simply) programmable/configurable than emacs is a pro not a con 95% of the time.
      - lern_too_spel 2y ago
        Nothing is more simply programmable than Emacs. You can reprogram it while it is running.
- nine_k 2y ago
  If "ki editor" is hard to google, I suppose "ad editor" must be basically impossible to google. A clever way to keep the project low-profile before it's ready for world domination :)
AdieuToLogic 2y ago
There is a reason why interactive command shells such as bash, korn, and zsh only support two editing modes; emacs and vi. Emacs reifies its LISP underpinnings by modelling edit commands as an AST[0]. "Top down" as it were. This optimizes for command categorization. Vi/vim/derivatives model editing by "flattening" the editing command tree such that the vast majority are no more than two or three keystrokes (excluding repeat count prefixes). This optimizes for uniform command distribution. Both eschew requiring a mouse and/or a GUI, which vastly increase their applicability. As to which is superior, that is the subject of thousands of "editor wars" threads in one form or another. My stance is to pick whichever best suits how you like to think when solving problems. 0 - https://en.wikipedia.org/wiki/Abstract_syntax_tree https://en.wikipedia.org/wiki/Abstract_syntax_tree
- lproven 2y ago
  > Both eschew requiring a mouse and/or a GUI, which vastly increase their applicability. This is a prime example of what is, it seems to me, one of the absolutely core misunderstandings of the wider Unix world. GUI does not mean, imply, or require a mouse. The original Mac and Lisa were mouse-centric, yes, but folks, that was 40 years ago now and the world has moved on. You can use a modern Mac entirely without a pointing device, via Voiceover, which is built in to all Macs, iPhones, iPads, etc. Windows has been amenable to being 100% keyboard driven since Windows 1.0 in 1985 and I have been using Windows primarily by keyboard controls since 1988. This is the standard method of computer interaction for millions of blind computer users around the world since the 1980s. What's more, the Windows keyboard UI strongly influenced IBM CUA, which in turn was informed by the mid-1980s Apple Human Interface Guidelines, and that influenced OS/2, DOS from 1990 or so onwards (so MS/PC DOS 4 and later), and that influenced Xfce, KDE, GNOME 1/2, and most other xNix GUIs. It is only the shell oriented xNix world that has refused to adapt. Console-mode shell-only Linux text editors such as eFTE, SETedit, and Tilde all have the third-of-a-century-old standard UI and can be used 100% with the keyboard but also have menus and dialog boxes. The standard design of basically all 21st century GUIs (except for the handful that are intentionally different – GNOME, Pantheon, Unity) does not need graphics. It does not need a mouse. It can be, and still today is, sometimes implemented entirely in text mode, it works on dumb text terminals, and it was universal in 1990s DOS, OS/2 and other native x86 OSes. The result of the refusal of the xNix world to even notice this is happening has absolutely crippled the field of editor design on xNix. In all other fields of software, text editors moved on from the awful and terribly dated design of Vi and Emacs by the late 1970s. See this interview with Larry Tesler, who invented cut/copy/paste as a computer UI. https://worrydream.com/refs/Tesler_2012_-_A_Personal_History_of_Modeless_Text_Editing_and_Cut-Copy-Paste.pdf https://worrydream.com/refs/Tesler_2012_-_A_Personal_History... This means that there are something like a million times more users out there happily editing text every day with editors with better UI than the absolute top-rated shell editors on any xNix.
deleted 2y ago
[deleted]
TeMPOraL 2y ago
It's not just me. There's also some Zigs or Zags or something; pretty sure your list is missing several entries. My pet theory, we can thank LSP for that, as it removed the major hurdle for any new editor project: the complexity of supporting modern programming languages and practices. Being able to offload most of that complexity to a language server (and most of the rest to tree-sitter) just about makes a new editor a viable side project. As for motivation... I wonder how many of the new editors are a "let's rewrite it in Rust" thing?
- aja12 2y ago
  > As for motivation... I wonder how many of the new editors are a "let's rewrite it in Rust" thing? None? I mean, Helix and Kakoune are written in Rust, but they are not rewrites, they have very different goals than e.g. neovim. They explore different concepts, workflows and ideas, and the choice of Rust as a language merely stems from the authors finding Rust to be a pleasant and appropriate language to explore their ideas

JadeNB 2y ago

I'd never heard of Ki, and it's hard to google. Do you have a reference?

yjftsjthsd-h 2y ago
Sounds like a Google problem; https://duckduckgo.com/?t=ffab&q=ki+text+editor&ia=web https://duckduckgo.com/?t=ffab&q=ki+text+editor&ia=web gives https://ki-editor.github.io/ki-editor/ https://ki-editor.github.io/ki-editor/ in the first screen.
- dcre 2y ago
  It’s the first result for “ki editor” on Google as well. I suspect they just typed in “ki”.
  - JadeNB 2y ago
    > It’s the first result for “ki editor” on Google as well. I suspect they just typed in “ki”. I tried "ki vimlike." In retrospect, "ki editor" would have made more sense.
barnabee 2y ago
https://ki-editor.github.io/ki-editor/ https://ki-editor.github.io/ki-editor/ It’s quite a young editor but is conceptually pretty neat! It works on syntax trees as defined by tree sitter, and the tutorial on their site shows off how powerful that is pretty nicely. I also like how it gets by with pretty much just buffers and readline for everything. I’m a bit more wary of all config happening by changing code and recompiling, though. Definitely one I’m watching, though it’s far from being able to tempt me away from Helix at this stage.
- porridgeraisin 2y ago
  This is nice. I like this editor, will try it out. The beginnings of a "mode" exist in vim, with plugins like tinykeymap that let you get into "tab manipulation mode" or "window manipulation mode", you can really do that with anything though, but maybe not as extensively as in Ki. It's quite a neat trick, example that lets you c-w +++++ instead of c-w + c-w +: nmap <C-W>+ <C-W>+<SID>ws nnoremap <script> <SID>ws+ 10<C-W>+<SID>ws nmap <SID>ws <nop>
- lern_too_spel 2y ago
  A lot of these new editors do things that Emacs does quite easily while losing all of Emacs's other advantages. https://www.masteringemacs.org/article/combobulate-structured-movement-editing-treesitter https://www.masteringemacs.org/article/combobulate-structure...
  - barnabee 2y ago
    Honestly I think being narrower in scope and less (or at least more simply) programmable/configurable than emacs is a pro not a con 95% of the time.
    - lern_too_spel 2y ago
      Nothing is more simply programmable than Emacs. You can reprogram it while it is running.
nine_k 2y ago
If "ki editor" is hard to google, I suppose "ad editor" must be basically impossible to google. A clever way to keep the project low-profile before it's ready for world domination :)

AdieuToLogic 2y ago

There is a reason why interactive command shells such as bash, korn, and zsh only support two editing modes; emacs and vi. Emacs reifies its LISP underpinnings by modelling edit commands as an AST[0]. "Top down" as it were. This optimizes for command categorization. Vi/vim/derivatives model editing by "flattening" the editing command tree such that the vast majority are no more than two or three keystrokes (excluding repeat count prefixes). This optimizes for uniform command distribution. Both eschew requiring a mouse and/or a GUI, which vastly increase their applicability. As to which is superior, that is the subject of thousands of "editor wars" threads in one form or another. My stance is to pick whichever best suits how you like to think when solving problems. 0 - https://en.wikipedia.org/wiki/Abstract_syntax_tree https://en.wikipedia.org/wiki/Abstract_syntax_tree

lproven 2y ago
> Both eschew requiring a mouse and/or a GUI, which vastly increase their applicability. This is a prime example of what is, it seems to me, one of the absolutely core misunderstandings of the wider Unix world. GUI does not mean, imply, or require a mouse. The original Mac and Lisa were mouse-centric, yes, but folks, that was 40 years ago now and the world has moved on. You can use a modern Mac entirely without a pointing device, via Voiceover, which is built in to all Macs, iPhones, iPads, etc. Windows has been amenable to being 100% keyboard driven since Windows 1.0 in 1985 and I have been using Windows primarily by keyboard controls since 1988. This is the standard method of computer interaction for millions of blind computer users around the world since the 1980s. What's more, the Windows keyboard UI strongly influenced IBM CUA, which in turn was informed by the mid-1980s Apple Human Interface Guidelines, and that influenced OS/2, DOS from 1990 or so onwards (so MS/PC DOS 4 and later), and that influenced Xfce, KDE, GNOME 1/2, and most other xNix GUIs. It is only the shell oriented xNix world that has refused to adapt. Console-mode shell-only Linux text editors such as eFTE, SETedit, and Tilde all have the third-of-a-century-old standard UI and can be used 100% with the keyboard but also have menus and dialog boxes. The standard design of basically all 21st century GUIs (except for the handful that are intentionally different – GNOME, Pantheon, Unity) does not need graphics. It does not need a mouse. It can be, and still today is, sometimes implemented entirely in text mode, it works on dumb text terminals, and it was universal in 1990s DOS, OS/2 and other native x86 OSes. The result of the refusal of the xNix world to even notice this is happening has absolutely crippled the field of editor design on xNix. In all other fields of software, text editors moved on from the awful and terribly dated design of Vi and Emacs by the late 1970s. See this interview with Larry Tesler, who invented cut/copy/paste as a computer UI. https://worrydream.com/refs/Tesler_2012_-_A_Personal_History_of_Modeless_Text_Editing_and_Cut-Copy-Paste.pdf https://worrydream.com/refs/Tesler_2012_-_A_Personal_History... This means that there are something like a million times more users out there happily editing text every day with editors with better UI than the absolute top-rated shell editors on any xNix.

deleted 2y ago

[deleted]

TeMPOraL 2y ago

It's not just me. There's also some Zigs or Zags or something; pretty sure your list is missing several entries. My pet theory, we can thank LSP for that, as it removed the major hurdle for any new editor project: the complexity of supporting modern programming languages and practices. Being able to offload most of that complexity to a language server (and most of the rest to tree-sitter) just about makes a new editor a viable side project. As for motivation... I wonder how many of the new editors are a "let's rewrite it in Rust" thing?

aja12 2y ago
> As for motivation... I wonder how many of the new editors are a "let's rewrite it in Rust" thing? None? I mean, Helix and Kakoune are written in Rust, but they are not rewrites, they have very different goals than e.g. neovim. They explore different concepts, workflows and ideas, and the choice of Rust as a language merely stems from the authors finding Rust to be a pleasant and appropriate language to explore their ideas