Helix 23.03
helix-editor.com
helix-editor.com
If Helix were completely different in this regard, like Emacs is, I could handle--and I know because I use both vim and Emacs regularly pretty fluently. But Helix is way too close to the vim keybindings to discern it from a memory muscle perspective. I use vim keybindings everywhere else (zsh, all readline-based apps via a setting in ~/.inputrc, VSCode), so getting used to slight differences in just one editor is extremely hard because I can't just drop all other apps.
I recently tried this: https://github.com/LGUG2Z/helix-vim which attempts to provide vim mappings to Helix. It's funny how the description in the page describes my progression almost 100%. And while it makes things slightly better, it's still not accurate enough to make this a non-issue.
(To the extent that it matters, I also mostly use the Dvorak keyboard layout if I can, but can still use QWERTY).
The helix keymap overall seems very well thought out. The built-in multicursor functionality also seems very expressive/powerful.
I will sometimes think I'm driving helix when in emacs (or vice versa), but overall don't see that as a major issue.
It did take a bit of time to learn how to do some things in Helix which I'm otherwise comfortable doing with vim motions.
> If Helix were completely different in this regard, like Emacs is, I could handle--and I know because I use both vim and Emacs regularly pretty fluently. But Helix is way too close to the vim keybindings to discern it from a memory muscle perspective.
You might want to reconsider trying a bit to see if you think it's worth it. I ended up learning vim deeply, emacs deeply, and meow (most similar to Helix being almost somewhat vim-like but different) somewhat deeply. I thought before each one that I couln't possibly learn the other, especially the similar one.
BTW: nearly 500 stars for this simple config, that should send a clear message to Helix devs.
I suspect the helix devs knew what they were doing when they deviated from the vim gospel.
One does not convert the users of vim; text editors are like science — it advances one death at a time.
I also went through the :tutor several times. Unfortunately, it doesn't cover typical coding activities, but it does a good job at explaining the editing model.
The features of Helix are also a lot more discoverable than in Vim, because you get these nice menus when you press one of <space> g m v
The one thing I really appreciate about Helix is that all of the features I want are already built in - I don't have to install any plugins nor configure anything. The fact that Helix feels much more responsive than Neovim is just a bonus. Here's my complete ~/.config/helix/config.toml:
theme = "nightfox"
[editor]
true-color = true
auto-save = true
line-number = "relative"
[keys.insert]
"C-backspace" = ["normal_mode", ":w"]
[keys.normal]
"C-j" = ["goto_next_paragraph"]
"C-k" = ["goto_prev_paragraph"]
"C-backspace" = ":w"
"C-h" = "jump_view_left"
"C-l" = "jump_view_right"
[keys.normal.space]
"space" = "goto_last_accessed_file"
"H" = ":toggle lsp.display-inlay-hints"
[keys.select]
"C-j" = ["goto_next_paragraph"]
"C-k" = ["goto_prev_paragraph"]
I've been using Helix 22.12 release for a few months, it's been really stable. The previous release had some stability issues (crashes due to panic, no data loss experienced) but I've had none of that for the past three-four months.
I have written about 15 kLOC of Rust code using Helix. LSP and tree-sitter are really nice built-in features. I've also occasionally used it to browse C and C++ codebases, features like go-to-definition work quite well without even building the source (which you need for compile-commands.json to get CFLAGS etc working).
Looking forward to trying out the new release.
Right now there is now way to do that, because there is no consensus on how the state should be stored. That's a worse developer experience, compared with vim for instance.
Another story is that some people pointed out a missing feature - moving lines or blocks of text up and down, as more advanced IDEs do. I volunteered to implement this feature, however I'm getting impression that the community is a bit puristic when it comes to features like that, based on feedback I get.
One argument is that this feature will make the code too complex to maintain (write your own bindings if you want that). Another that have been brought up is that acting on selected lines, instead of characters violates the rule act-by-selection (that is, modify only selected characters in the buffer, similarly how visual mode in vim works).
I acknowledge these arguments, yet I got a feeling that the community is a bit too perfectionist.
Wait, what does this add? I feel like in Helix I would just select a bunch of lines (say, via treesitter or the x command), and then I'd delete them, and paste them somewhere else. Could you elaborate what the difference is between this and 'moving lines or blocks of text up and down'?
All the major IDEs like sublime/jetbrains/vscode have both of these functionalities.
Either way, love Helix. It's now my quick editor of choice; I really like the Kakoune-style motions.
[keys.normal.space]
"H" = ":toggle lsp.display-inlay-hints"Kakoune has often seemed like a platonic ideal to me. Of course, my mind doesn't agree so much about the visual by default stuff much of the time. Maybe I didn't use Kakoune long enough.
I gave it a try for a while, but had to go back to emacs ecosystem.
This led me to inevitably tryout https://github.com/meow-edit/meow which I think is the best combination of fast, stable, well-integrated, similar to the kakoune model.
1) I am used to Vim motions and Helix was just slightly different which was confusing.
2) No plugins. I have my Nvim heavily customized with many plugins and would not want to miss their functionality. This cannot all be provided by the core editor so I guess it won't be an option for me as long as they don't support user plugins.
> If Neovim is the modern Vim, then Helix is post-modern.
/s
There will very likely be a time when Plugins are supported, but this time is not now. I like the approach to make first class integrated functionality rather than the mess we currently have in vim. Helix aims to have an out of the box experience that would take you hours or even days if you are fresh to vim. If you need functionality on top of it, plugins will come into play. There is a reason why astrovim, spacevim etc. are popular, people don't want to spend to much time configuring the most basics that everyone is expecting today.
So if Helix does most of the things you need today i would encourage you to try it out and if it does not have a feature that you really need, plugins wouldn't help much either because somebody needs to write it in the first place and by the current userbase its very unlikely. It seems that most of the people are just gathering around the main project and make PR's directly which somewhat guarantees a certain amount of quality.
Of course the plugins need to be written but my point is that they cannot be written at the time.
I understand and support the idea of Helix to be useful out of the box for many use cases. However for me the editor in its current form is not sufficient. As I already stated I use many (wonderful) plugins in Neovim. I could not justify going away from the status quo because it is pretty good. I have my setup configured so the ease to jump into is not really a valid argument for me and I suspect for many more Vim users.
Plugin systems are not easy and they have a clear vision of how this should NOT end up working. In their current state putting in work into a Plugin-System does not make much sense (limited developer time that is better spend elsewhere) regarding their project goal.
As i said you can argue that the project is in its infancy and does not work for you because of that. But the main reason is not the support or lack of plugins. As i said, even if there was a plugin system you could argue that there are no plugins available for the things you want – ending up at exactly the same point you're today. Having a Plugin-System does not magically makes hundred of useful plugins appear out of nowhere.
As long as there is no way to extend the editor for me or for anyone else (aside from contributing to core), I am not interested in adopting it when I have another option that already does all of these things I want.
So yes you need plugins but for that you first need a plugin system. If that takes a while I am totally fine with it. I am all for good software. But why should I currently choose it over nvim?
Theoretically no, practically, it is since someone is indeed more likely to extend the functionality via a plugin since the barrier is lower vs. adding the same thing to the core Also, for some things that someone could also be you
> Helix aims to have an out of the box experience that would take you hours or even days if you are fresh to vim.
Or you'd just copy the plugins/configs of someone who spend those days already, just like in those astro-space-packages you mentioned
- tpope/vim-fugitive
- samoshkin/vim-mergetool
- folke/zen-mode.nvim
- kevinhwang91/rnvimr
- nvim-telescope/telescope.nvim
There might be more I am forgetting.. and maybe something like telescope is already part of Helix. I will check Helix again in a year ;)
I want multiple lsp for html files with tailwindcss its more a thing because im still learning/memorizing tailwind stuff.
Or, rather, what's the difference betweeen "helix but with vim motions" and a bundled vim distribution?
I see Helix as a polished-out-of-the-box editor with kakoune-style motion, LSP, and tree-sitter (which supports enhanced motion). -- I think each of these things is a nice improvement over what came before; even if vim motions have long staying power.
Vim/Neovim distribution as polished as Helix OOTB does not exist :D
I still appreciate the effort, looking forward to more modal editors that are better suited to modern programming specific editing capabilities that are easy to learn and apply!
Why wouldn't you be able to do that with a CLI editor?
So helix is not for me. My ideal editor would be a modern re-implementation of the Vim way of doing things, probably using different keys, probably thought-out more, probably more light-weight. But for some reason no editor wants to go there. They either break from Vim's model (kakoune, helix) or follow Vim along with all it's flaws (Neovim, Vis).
[1]: https://github.com/noctuid/dotfiles/blob/master/emacs/editin...
I am sincerely curious of what flaws from Vim has Vis inherited, in your opinion.
I have the impression that the design idea of Vis is taking only the modal design of Vi (not Vim), plus the structural regular expressions of Sam, then make it as clean as possible with programmability via Lua plugins.
In fact, the state non-goals [1] seems to clearly distant itself from Vim.
Neovim, though, if it wanted to distinguish itself to novices, should integrate which-key.nvim as well as the behavior in the annotation plugins you listed in the article to make things more obvious.
Vim's big fail is discoverability, not the editing model. You can run through past (Neo)vim threads on HN and consistently find 10+ year vets discovering some new behavior from the TFA of the thread. Perhaps some sort of predictive ChatGPT-based solution would expedite that effort since Vim has a lot of behavior to surface from its manuals. There's :helpgrep yes, but a novice still needs to know what to do ask.
This is why I'm a big fan of efforts like Fish, cause it does a great job surfacing CLI tooling behavior OOB just by pressing tab and navigating for what you want, with descriptions, in place
So far for me the story has been: see or read something cool on Helix, try it for 20min and attempt to do my actual work for the day on it, then get frustrated and feel slowed down, switch back to my neovim to get stuff done and forget about Helix until the next release hype.
My only problem is personal productivity speed. My whole setup and automation workflow is built around nitpicked or hand-built tools, I'm not Primeagen fast but nearly there. With a full time job, side project/startup I'm really passionate about and family/kids, every seconds matters.
Oh wow... I thought I abandoned new editor attempts quickly when I spent less than a week through the frustration phase.
I switched from PyCharm and Sublime Text, although I admit I still use them from time to time when trying to grasp an entire codebase. Helix is my primary editor now and I wish I had the helix navigation and editing everywhere now lol.
Can somebody share his/her experience?
They’ll get there eventually.
- Can't make the the editor's theme automatically switch at runtime when I change the system to dark/light mode. In neovim this is done by hooking Signal and VimResume. - Can't dynamically configure auto-formatters for python projects on the basis of the presence and contents of a file located at the root* - Can't turn off the completely unusual feature of having the tabstop position change (for the actual tab character) depending on the language, or to set a default. Also, why on earth is the bash (or shell) tabstop set to 2 characters? - Can't only show trailing whitespace. - Editor doesn't warn you when you open a file twice (only once you actually edit it). In neovim I have this set up with a custom bit of code to find out which window the neovim instance is in and focus that window instead. An incredibly neat feature you can't seem to implement in hx either.
At this point I can't spend much more time with this, but may later.
The main issue I have with helix (and had with kakoune when I tried it) is just the vast number of slight issues. I don't really care that the motions are different (I agree that the vim motions are inconsistent and would be happy to ditch them for something more consistent) but there's just too many little things for me to feel happy with the end result.
*I have worked around this in hx temporarily using a bash script which works in the formatter key in a [[language]] block for python:
#!/usr/bin/env bash
bail() { exec cat; }
declare -A rootfile=([python]=pyproject.toml)
declare -A format_cmd=([isort]="isort -" [black]="black -q -")
while [[ ! -e "${rootfile[$1]}" && ! .. -ef . ]]; do cd .. || bail; done
[[ -e "${rootfile[$1]}" ]] || bail
pipeline=()
{ exec 3< .autoformat; } 2>/dev/null || bail
while read -r; do
pipeline+=("${format_cmd[$REPLY]}")
done <&3
recpipe() {
if (( $# > 1 )); then
$1 | recpipe "${@:2}"
else
$1
fi
}
recpipe "${pipeline[@]}"
But you can also do it in the INS mode but sandwitching the commands in mode shifts, for example, these should work in the INS mode part of your config
[keys.insert]
'C-j' = ['normal_mode','copy_selection_on_next_line','insert_mode'] # Copy selection onto the next line (add cursor ↓)
'C-k' = ['normal_mode','copy_selection_on_prev_line','insert_mode'] # Copy selection onto the previous line (add cursor ↑)Meanwhile you could use something like this (if you already have the word selected as you might likely have since Helix selects by default, then delete the first two command that expand your selection to a word like in Sublime)
'*' = ['select_mode' #
, 'move_prev_word_start' #
, 'move_next_word_end' #
, 'search_selection' #
, 'extend_search_next' #
, 'exit_select_mode' #
] # = find_under_expand '*' = ['select_mode' # = find_under_expand
, 'move_next_word_end' # 1st since word_start command might select previous word
, 'move_prev_word_start' #
, 'search_selection' #
, 'make_search_word_bounded' #
, 'extend_search_next' #
, 'insert_mode' #
] #