- Kakoune
- Helix
- Vis
- Ki
- Ad
- ...
- Kakoune
- Helix
- Vis
- Ki
- Ad
- ...
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.
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...
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.
MS Word and all of Office, and all of its rivals. IE, Edge, Chrome, Firefox, and all other browsers, GUI email clients including on Linux and all the BSDs, etc.
I have written about this, in case you're unfamiliar with CUA:
https://www.theregister.com/2024/01/24/rise_and_fall_of_cua/
I think there are a lot bigger problems to solve in the xNix environment than getting people to stop pressing escape to enter normal mode.
(the argument for Emacs makes less sense since it has customizations available to be as "modern" as you want. You may criticize it's byzantine configuration process, but that's a different topic. It's also funny how Apple, the poster child for elegance in UIs has Emacs keybindings by default everywhere in macOS, even the concepts of "yanking" and "killing". In hindsight though, it makes perfect sense)
I am absolutely not saying that there is any difference in utility whatsoever. I have watched skilled exponents of Vim and Emacs perform wizardry, and I've also seen an adept of Jedit do things with plain English text that I don't know how to do in any editor.
This is absolutely not about utility or capabilities.
It's about UI.
I am aware of efforts to bring a standard modern (as in, 1990s) UI to both editors.
For Emacs there is ErgoEmacs -- https://ergoemacs.github.io/ -- which is amazing and makes it slightly usable even for me, steeped in CUA for over a third of a century.
For Vim I know of Cream -- https://cream.sourceforge.net/ -- but it seems unmaintained for a long time and when I tried it I couldn't get it working.
What I am saying is two other, quite different things:
1. Using the Linux shell is needlessly hard and complicated, because of its adamant refusal to adopt the modernised UIs of other text-mode OSes from 30+ years ago. These could be bringing the shell into harmony with the GUI, making the experience better, and it would be trivially easy to set things up so that experienced users with their own ways of doing things were not inconvenienced at all.
2. As a result of this refusal, or even of this blank ignorance and lack of curiosity in how other OSes and other platforms modernised text-mode apps, the dominant tools in Linux and other FOSS xNixes have no standadisation. Even when there are TUIs driven by ncurses or whatever, they're all different and all inconsistent. There's no need for it. It's wasting everyone's time.
In other words, the tools don't need to be different from one another and they don't need to look and work so differently from in GUI desktops.
Makes no difference. I lived for a decade in Czechia, where they use QWERTZ. CUA works absolutely the same whatever your localisation.
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?
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
I tried "ki vimlike." In retrospect, "ki editor" would have made more sense.
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.
nmap <C-W>+ <C-W>+<SID>ws
nnoremap <script> <SID>ws+ 10<C-W>+<SID>ws
nmap <SID>ws <nop>