I gave Helix a shot, and I immediately ran into a wall due to an undocumented limitation where in a language configuration, indentation can only be up to 8 spaces. (I'm working on an Assembly project with an indentation of 12 spaces to make more room for labels.)
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.
That doesn't look hacky, it looks written by someone with 3 months of programming experience. I would personally avoid relying on an editor written by programming newbies.
Its doing that to get a static str (no allocations). I assume it is for performance reasons, but I can’t speak to whether it’s actually a significant impact.
A sane implementation would be for the fallback to construct a string containing the desired number of spaces on the fly and memoize. Unfortunately, this is written in Rust, and the language makes it super awkward to implement caching patterns transparently as they involve passing around references to mutable state.
The great thing about Helix is that it is super easy to build locally. Make changes to the number of spaces allowed and it should work as expected, unless there is another reason they have such a limit.
> always absolutely has some way of covering a weirdly specific need
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?
Multicursor editing, left/right modifiers, and tap/hold keys aren't "needs", they're methods/tools used to accomplish needs. The need is to make a specific edit on a file.
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.
I arrived at modal editors via Helix. I had bounced off (neo)vim multiple times, primarily due to the verb-object editing scheme, and initially found Helix to be a godsend.
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 really don't like Kakoune's model of extensibility. It's one of the reasons I switched back to Vim after using Kakoune as my main editor for several months. The configuration system is esoteric, fiddly, and (as of 4 years ago or so, when I last used it) not thoroughly documented.
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].
Wait, no panes? What about things like diffing two files? There are also plenty of other situations too where I’ve definitely wanted splits in the same client, so I can see multiple files at once but also copy between them (which requires shared registers), write macros that switch between the panes (which… well, I suppose Kakoune’s composability approach might be able to support such a concept, but I get the impression Helix really wouldn’t), &c.
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.
> and by having a "you don't really need it" policy for things like panes, which you can just do with tmux.
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.
All I care about when it comes to editors is availability (on every platform, can be used in a terminal), longevity, and the community for third party plugins. Vim still checks all of those boxes and the only real other contender is still Emacs.
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.
I was drawn to helix specifically because it is excellent without the need for plugins.
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.
Your points concern everything around text editing, but not editing itself. Emacs brings nothing new to the table with respect to editing model, it's essentially notepad (with different interface, plugins, yada yada yada — all the things you mention). Vim has a model with modal editing, much better than Emacs. Kakoune and Helix improve this model even further.
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 brings nothing new to the table with respect to editing model, it's essentially notepad
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.
> Emacs brings nothing new to the table with respect to editing model, it's essentially notepad
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.
Chordal editing isn't as popular as modal editing, but I do like it and think it's something uncommon in other editors, at least to the same extant as emacs.
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.
Why do you care so much about availability of an app that is unusable without a lot of plugins? At which point, you can copy plugin code with the editor app to a place you need it available in
The point of an editor having tons of plugins is captured in one phrase: the long tail [1]. A mature tool with a healthy ecosystem of plugins will have every user installing a unique (or nearly unique) suite of plugins. Attempting to have the base tool itself support all those millions of different use cases and configurations is a lost cause.
I found the discussion on extensibility vs composability to be really fascinating. The author is right that extensibility gives you less freedom between tools. You can't take magit to vim or helix, because it is an Emacs extension. And each tool has it's own way of extending it, which means you need to learn essentially a new API (if not an entire language) to extend a tool.
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.
I found https://yarchive.net/comp/linux/everything_is_file.html a very compelling read today, on similar topics. Specifically, having a base set of abstractions that everything "speaks" is a huge boon that is often hard to articulate. Annoying, as the drawbacks and sheer number of edges is often much more easily described.
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.
The author, Dimitri Sabadie (@phaazon[1]), is a prominent Kakoune contributor[2]. In this article, he offers his thoughts on Helix[3], how it compares and contrasts with Kakoune, and how both Helix and Kakoune improve on the tried-and-true Vi-inspired formula which continues to drive the popularity of keyboard-centric editors like Vim and Neovim.
I really want to like helix. I do like helix. The batteries included ethos is awesome. Multi-select is tantalizingly close to something really interesting. Buts its macro/keybinding vocabulary isn’t quiiiiite there yet. And tbh I’m not sold on multi-selection as the only paradigm.
Readit News
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.
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].
[0]: https://github.com/helix-editor/helix/pull/3791
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.
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.
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.
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.
Deleted Comment
[1] https://en.wikipedia.org/wiki/The_Long_Tail_(book)
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
[2] https://github.com/phaazon/kak-tree-sitter
[3] https://helix-editor.com/
?