Even more hindsight on Vim, Helix and Kakoune
phaazon.net
phaazon.net
Why Kakoune – The quest for a better code editor (2016) - https://news.ycombinator.com/item?id=36424256 - June 2023 (56 comments)
I checked the source code to figure out what the heck was going on, and I found this: https://github.com/helix-editor/helix/blob/207829eefee51095d...
Pretty often, my projects have weirdly specific needs like this. I think (Neo)Vim's greatest strength is that it always absolutely has some way of covering a weirdly specific need, whether a one-off command or a project configuration. But that seems to be against Helix's philosophy.
If Helix can't be the editor, then I can't justify taking the time to learn it. It makes me sad, though, because I really like what it's going for.
As long as nothing is depending on 'static lifetime further down the line. (EDIT: ignore and see below)
> (or at least increase the upper limit to 16)
That should be doable for sure. Even something like (I'm not a rust developer, just have a passing familiarity, so my syntax may be off):
IndentStyle::Spaces(n) if 0 < n && n <= 16 => &" "[0..n as usize],
EDIT: after toying around in the rust playground, I think the following will support any indent level (within the bounds of the u8 type).
At the top level:
static INDENTS: [u8: 256] = [' '; 256];
IndentStyle::Spaces(n) => std::str::from_utf8(&INDENTS[0..n as usize]).unwrap() const INDENTS: [u8; 256] = [b' '; 256];
// ...
IndentStyle::Spaces(n) => unsafe { std::str::from_utf8_unchecked(&INDENTS[0..n as usize]) },
const INDENTS: &str = str_repeat!(" ", 256);I get it, don't run a project if you see some bad code and question the quality of the project. Quality that very well could, and likely will, impact you. From bugs to performance. Don't run it, of course. But to attack it, seemingly with such personal zeal.. can people not improve?
I dunno, i guess i just don't feel the software we write on average is actually good. We make compromises and mistakes constantly. Our house is the purist of glass and many of us are just chucking stones like there's no tomorrow.
Lets take a step back. Breathe. Point out flaws by all means, but maybe reduce the often apparent revelry in someone else's mistake.
... sorry for the high horse rant. I'm nursing coffee and i've just seen it a lot with Lemmy/Kbin recently. Also this isn't pointed at anyone here directly.. just a pattern i feel i frequently see.
If this was a carefully observed decision, one that is prone to looking odd, it deserves an explanation for future selves to not chase the rabbit of understanding.
what's the (Neo)Vim way of covering the need for elastic tabstops, multicursor editing, differentiating left vs right modifiers and tap vs hold regular keys?
I respect those features, and I respect Helix as a great forward-thinking editor. I will just have to revisit it in the future once it's more configurable.
That said, I had an editing paradigm too opinionated even for Helix, so I mangled my Helix config into what I thought at the time was my dream editor.
Over time, though, I started to "see the light" of Vim's ways. I'd run into this or that use-case, realize that I had mapped the key for it to something that fit my custom paradigm ideas, and one by one, switched back to the defaults. Eventually, my Helix config became more Vim-y. So I switched to Neovim and didn't look back.
I got really into the plugins and customization, and while yes, I still do have a good bit of plugins and a somewhat large config, it's become more and more stock with time.
It took me a long time to get it, but the Vim model really is truly brilliant. I still appreciate Helix (and by extension, Kakoune), and I'm happy I went through the weird twisty road that I did, but ultimately I found that the ways in which those two differ from Vim were indicative of me "clinging" to old editing habits from more "standard" editors. It took truly diving in and accepting that maybe, just maybe, I didn't have better ideas than a 50-year old editor that's stood the test of time, to see it.
I think Helix made a good choice by building in LSP support and other things that would otherwise require extensions, and by having a "you don't really need it" policy for things like panes, which you can just do with tmux. And I think Neovim made a good choice by exporting a configuration/extension API in a very standard, commonplace extension language like Lua. I disagree that Neovim's Lua API is really a different language. It's just an API; Kakoune has one too, albeit of a more esoteric sort.
Incidentally, I started using Helix a month or two ago and I've been liking it a lot. Having the language server stuff already integrated is a fantastic convenience. I could probably switch to using hx exclusively if I really wanted, even with no extension system whatsoever. The only thing I want that they haven't implemented yet is easymotion jumps, and there's an MR for that already [0].
Wow, https://github.com/helix-editor/helix/issues/405, indeed no side-by-side diffing and the approach being suggested would be hopelessly crippled for even two-way diff (let alone three- or four-way diff, which are probably just total non-starters), since it would only support editing one of the documents!
Seriously, my mind is boggling at considering a “you don’t really need it” policy for at least splits. I really do need it: even on my base task load, tmux would be inadequate in painful ways multiple times per month; and I regularly (sometimes daily for weeks, though other times not for months on end) do things for which it would be completely debilitating so that I couldn’t possibly use Helix and would have to go back to Vim.
They do panes, they don't have tabs. Although it looks like github user nrabulinski created a PoC[0]. Not having tabs is what made helix unusable for me, it just messes with my workflow too much.
And you are wrong about using tmux for this. It does not work with helix because it doesn't follow a client-server model, two instances do not share information between each other (someone please correct me if I'm wrong)
If you are using kakoune, you can actually use tmux (or any tiling window manager like i3wm) to recreate proper tabs since it does have a client-server model. Multiple kakoune instances can kakoune processes can share information. It's actually the most flexible system for windowing in my opinion. It allows you to do things like |kak|firefox|kak| with both kak instances sharing information.
[0] https://github.com/helix-editor/helix/issues/2295#issuecomme...
Vim is super crusty, Kakoune and helix have better takes on the unix philosophy, integrations. VSCode is easier for absolute beginners to click around in. IntelliJ has better semantic parsing. But none of that matters. None of that holds me back from being successful. I just need an editor I can type code in that I will never have to give up, that will just be there, and I can use at the next job. In fact Vim's quick editing is just a nice to have, it's never been the difference between me killing it and getting killed at work. That's why I'm sticking with Vim.
With good "plugins" or "features" all of these things happen async.
Additionally installing these features on vim is a nightmare for various reasons. It can be done, and I've done it, but the experience is not as good as the more clunkier GUI IDEs. I'm all for a TUI IDE if the experience was as automated or seamless as jetbrains or M$, but such a app doesn't exist yet.
Sometimes, but with single powerful IDE solutions from companies like jetbrains, setting up a "cushy" environment is barely any work.
>Sometimes that means driving somewhere and working through at 9600 baud over an RS-232 cable. Do this a couple times and you'll find that vi is quite usable--you just have to want it to be.
Of course if your network connections completely fail you have to use the serial console to fix it. There's no going around that. But the majority of developers don't even need to do this or don't even know what you're talking about as they only interact with cloud services nowadays.
Additionally a "cushy" environment doesn't preclude you from using serial console or using vim to do edits everywhere. VI in this sense is barely useable, it's basically the baseline necessity. You need it when all else fails. But it's not good to have it as your daily driver.
I promise, installing a Jetbrains product on a traffic controller (which is what I was thinking of re: the field trip) would be a tremendous amount of work.
> The majority of developers don't even need to do this or don't even know what you're talking about as they only interact with cloud services nowadays.
Yes, and they're one geomagnetic storm away from being entirely useless. It might not be for everybody, but there's value in being able to work with a lean toolset.
Jetbrains isn't installed on a traffic controller. It's installed on your local machine. Both VSCode and jetbrains have something called "remote development" which allow you to develop on a remote machine as if it was local. It's similar to ssh and vim.
>Yes, and they're one geomagnetic storm away from being entirely useless. It might not be for everybody, but there's value in being able to work with a lean toolset.
A geomagnetic storm will render everything useless, I don't see how a vim user will be more protected then a vscode user.
Editors are irrelevant to that conversation, but people who are accustomed to relying on stacks with many dependencies will definitely find that they struggle more without the internet than people who keep their dependencies minimal. And it's not a cherry picked example, there are all kinds of cases where minimal dependencies = resilience. It doesn't mean you have to go around using punch cards or something, it's really just the emotional attachment to complex tooling that I'm calling out as a hazard here. You end up cultivating skills that are easily invalidated.
You can remote ssh into the pi with Vscode or a jetbrains IDE with a laptop that likely won't be fried either under your description.
Python can run on the rasperry pi. Even high level interfaces will remain. Additionally GUI support exists on a Pi.
The core functionality being available everywhere means a familiar and efficient, even if not ideal and complete, suite is available everywhere else: servers, other computers, a new system. For transient / temporary use. Like on a business trip, a flight, or the conference.
Just like you wouldn't use a random laptop during a business trip and expect to be efficient, you'd bring your own!
It does sound to me like that is not a consequence of the GUI-ness of VSCode, but just the man-hours that go into making it. In other words, it doesn't sound like that experience can't be replicated in terminal-only editors.
If anyone has experience with remote editing in a terminal editor, but not through an ssh shell (ie, the traditional way), I'm very interested in hearing your experience.
As usual, emacs has a mode for everything:
The mostly-single-threaded nature of Emacs gets in the way sometimes.
Jetbrains suite of IDEs are basically long tails and they have huge utility in many areas that exceed other editors.
LSP and tree-sitter grammars carry so many of the features I had to add to vim and emacs—over years of configuring—that I feel like I’m not missing anything important; despite having an emacs config large enough to justify its own repo outside all my other dotfiles.
My whole helix config is telling helix what theme I want and the path to my nix formatter, and it feels nice.
It's like comparing cars by the color of the trim and air conditioning, instead of… er… their car performance (power, speed, fuel usage, durability).
If you don't care about editing models, and just want to "type code", then Vim is hardly the best choice. Emacs and Intellij are much better than Vim at plugins, and are as available as anything else.
Emacs (1976) predates Notepad (1983).
I do understand what you mean, though. For people using Windows, Emacs needs to be sought out and installed, this effort needs to be justified (assuming one is permitted to install software at all), and hence the requirement for Emacs to "bring something new to the table" over the default option, Notepad, which is just /already there/.
The most basic, implicit, requirement, then, is exactly as GP says: availability. All else follows.
I didn't mean that one is based on the other historically. Notepad was meant as the most minimal example that implements one of the Emacs'es aspects.
The thing I like about emacs is the integration and consistent experience. I can do everything in emacs (and use exwm as my window manager), so I have the same keybindings for everything.
As perhaps an extreme example, imagine having 1. A window manager like i3 2. tmux or screen 3. (n)vim or helix sessions with edited files, possibly inside tmux/screen
Each of these need to be configured separately, and each layer needs different keybindings so that uncaught ones can be forwarded from one layer to the next. Each layer is limited to only the subset of things it manages. E.g., i3 can let you switch between firefox and the terminal running tmux, but not the different sessions tmux manages, or views of any of the files in your nvim session. Etc.
Or I could just use emacs create tiles I can move between, and each of which that is capable of opening any of my x-windows, terminal sessions, or open files. You can even use the same autocomplete in your shell as when editing files.
I don't know of anything that gives the same simple, unified, workflow of EXWM (+ corfu&consult&...). It does have issues and could use a serious modernization -- still single threaded in 2023, with some commands blocking IO??? -- but perhaps it's simply much too ambitious for someone to try and make a competitor. These can have modal editing, tree sitter and lsp integration would be great, etc. The thing I want is the smooth integration of everything I may do on a computer into one interface that emacs, but no other software I'm aware of, offers.
I agree that having different programs on you computer integrated and consistent is a good thing. Sorry for the reference to the old joke, but wouldn't all the things you list look better in a wishlist for an operating system instead of a text editor?
I agree that I'm looking for a tiling window manager. This is what EXWM (the Emacs X Window Manager) is. The problem with things like i3, is that it is not integrated enough with editing and navigation of files.
I wish there was more in this space, as Emacs has some limitations for this purpose (e.g. multithreading), but AFAIK emacs stands alone.
Wow, and here I thought I had seen all derogatives about Emacs ;-) But claiming that it doesn't bring anything new compared to Notepad is really strange.
1. Emacs predates Notepad by one or two decades. 2. Have you actually had a look at what is actually included in Emacs? I am not talking about mail readers and other "apps" inside emacs. I mean just for editing text in a non-mode specific way. Things like rectangular cut and paste, vertically aligning stuff, infinite undo, undo restricted to the selection (region) and many many more stuff. That Notepad doesn't have.
Yes, I've been using it for a few years and made my own plugin with a couple dozen users. Then I discovered Vim overnight and never used Emacs again (literally).
> But claiming that it doesn't bring anything new compared to Notepad is really strange
It does indeed sound strange because you missed the "with respect to editing model" which is crucial for my point. Emacs has nothing in it other than Notepad + a large number of ad-hoc, non-coposable plugins each doing one task.
> Things like rectangular cut and paste, vertically aligning stuff
Ad-hoc things that do only one very specific task each. Incomparable to Kakoune's powerful and composable way of interacting with text.
> infinite undo, undo restricted to the selection (region)
Orthogonal to the editing model. These can be slapped on top of any text editor, be it vim or notepad. Just make a plugin.
However extensibility makes it much easier to move within a tool. The authors sample kakoune config for doing splits is a great example. Since Kak doesn't support splits natively, you have to learn 3 separate tools do the spliting in a WM. In something like Emacs there is only one thing to learn to manage splits on all platforms. And it is using the same extension mechanisms you use for everything else.
I found this the paragraph just before the conclusion to be an interesting demonstration of these trade-offs:
> All of that to say that, the take of Helix is pretty good here, because all of those UNIX problems are not there in that editor: everything runs in the same process, inside the same memory region.
The author spends a lot of time praising composability over extensibility, but then admits that Helix has some real advantages because it is not composed with tree-sitter or lsp, it has those built in. Essentially it was extended with those features, they become part of editor, instead of trying to interact with them in a uniform way.
This reminded me of the xi-retrospective section[1] on modular software. composability works better on the small scale, but struggles when you have many independent things interacting with each other. It is fine for simple things like "using the shell to sort lines" or "bring your own fuzzy finder", but with more complicated integration it starts to falter.
[1]https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.h...
TO that end, Emacs' "everything is open to everything else" works surprisingly well, once you get used to it. Especially so if you go with not introducing new primitives to makes things happen in the process. Even "async" is relatively easy once you get used to the sentinel approach.
Can you imagine a better way? Almost certainly. I have yet to see one survive the test of so many contributors, though.
[1] https://github.com/phaazon
?
But after 20 years of Vim muscle memory, I can't deal with the keybindings. Not that they're inherently worse, just different - I'm perfectly happy with vim motions and relearning to type is pretty low on my list of priorities. Luckily there is a compatibility hack, not perfect but it's close enough: https://github.com/LGUG2Z/helix-vim
- subject-verb isn’t a universal improvement; Vim provides both through visual mode with an extra keypress, kak/helix only make one easy;
- git integration looks sub-par for anyone familiar with magit / fugitive;
- the level of discoverability is at “much worse than Emacs, but proud of the achievement”;
- system integration is on a table stakes level.
The extensibility / composability topic is close to my heart, but the particular take does not sound right.
Emacs, for one, is not extensible like vs code is extensible, it’s runtime modifiable via insane levels of “internal” composability that is not achieved by other tools. It also works well with outside tools. I don't see what prevents the author from running magit separately; you can absolutely eval a magit-status from your command line. You'll lose editor integration, but that seems to be the point of the exercise?
In this particular case, the whole philosophical comparison reads like an excuse for Helix’s limitations.
TOML config would just make me angry on a daily basis.
It’s okay to like simple simple things. Just don’t compare them with Emacs — it's an entirely different kind of thing. Apples, oranges, kitchen sinks.
It's largely focused on programming and won't be as smooth a writing and editing experience in non programming use cases. That seems to be the case for almost every editor I've tried.
After almost 20 years of vim I switched to doom emacs for development. But for sysadmin tasks I still use vim. And sometimes I miss its consistency even for GPLs.
Would be cool, but all it does is move the cursor to the end, anchor remains in the middle of the word (if you start from the middle)
There is an open PR for getting copilot support, though it's currently just a hotfix and likely won't be accepted into core. You can still patch your own version and compile it.
https://github.com/helix-editor/helix/discussions/4037#discu...
And the plugin system is not done/released yet.
> The reason I didn’t stick around Emacs was basically because of its runtime choice, and ultimately, its Lisp ecosystem. The Emacs community is one of the best I have been talking to, and they have really, really talented people working on insanely complex topics, like turning Elisp code into native code (via C), including Emacs itself. But even with all those optimizations, the editor was still feeling too slow, and has a lot of background that you can feel. All the abstraction layers, all the Lisp macros (oh no), etc.
at this point I am so productive in vim/neovim that I more-or-less just glance and pass on announcements of new editors. For me to switch to anything at this point other than neovim would be for it as a project to go away.
At least Vim “mode” seems to be supported everywhere. Surely I get more bang for “time investment” than these others?
Though, IME the cost of learning something like kakoune or helix's motion (having already learned vi) is quite low. -- The value-add of vi's modal editing doesn't go away just because something even nicer comes along; it does mean you get the chance to use something even nicer.
When opening that editor, you should not be greeted with tutorial. It should be simple to do things so that tutorial is not even necessary.
You can say, I want VSCode that runs in terminal, but one that does not hog my cpu/memory. It should feels instant to do anything, without any loading time if possible.
Keyboard shortcuts are essential to increase efficiency and speed. For example, ctrl-c, ctrl-v, ctrl-z, ctrl-s, ctrl-p, ctrl-a etc. People learn these early on if they regularly have to input/edit text to speed up their workflow. Otherwise, they would have to resort to pointing and clicking through menus to accomplish the same thing.
The longer you use an editor, the more of these shortcuts you commit to (muscle) memory, so, even if the commonly used editing operation is easily accessable via the GUI interface, people are going to choose the keyboard shortcut to do the same thing since it's faster.
> When opening that editor, you should not be greeted with tutorial. It should be simple to do things so that tutorial is not even necessary.
You could navigate with the mouse or arrow keys in either vim or emacs. The only thing you would have to learn is how to save the file. You may not even have to learn that because both vim and emacs display a dialog box asking you whether or not you want to save the file if you try to exit the editor without saving first.
Doing things with a mouse is accessible to you because you've already learned how to do it. It's not innately more intuitive or self describing in any way, the learning curve is just behind you.
I used GUI editors for a long time. I'd operate my computer with my right index finger and resisted any attempt to change that interface. I'd learn the usual Ctrl shortcuts and what not, that was about it. One day I finally dove into Helix specifically and not only am I not looking back, I am finding and using software specifically based on whether it uses vim like key interface. If it can't it takes like 50% points off the software, going back to the mouse is just so painful I don't know how I ever tolerated it. I feel like a chicken operating a typewriter.
Nano is considered one of the smallest / simplest editors, and it shows you the keyboard shortcuts on the bottom of the window, is that what you're wanting?
It does sound like it would be a bit slow in operation, though.
There aren't many editors like that around.
Check out micro and mcedit.
Better, "mcedit -b"