16 ms·

Helix 23.03

228 points by emerongi 4y ago

koalalorenzo 4y ago
I fell in love with Helix a few months ago and every single release is improving so much. I stopped using Microsoft visual studio code and vim, and I am not missing them at all.
- ctenb 4y ago
  What language are you programming in?
  - Casperin 4y ago
    Not GP, but same story for me (except it's been more than a year now for me). I'm coding 90% in Rust. The remaining 10% is a good mix of OCaml, TS, Python, Shell. It doesn't really matter what I touch. Helix is my editor :)
p2hari 4y ago
Love the editor for making some quick fixes or checking the repo/files. But not using it as a full time driver. This release has support for snippets but at this day and age, I would have thought we would get our long time request fixed. https://github.com/helix-editor/helix/issues/1927 https://github.com/helix-editor/helix/issues/1927
- shzhdbi09gv8ioi 4y ago
  If you read the issue you link to, you would know that the request itself is not the issue, but the lack of a plugin system is.
deleted 4y ago
[deleted]
dragonelite 4y ago
Ooh man had hoped multiple lsp servers in one file would have made it into this release. Ooh well its not such a biggy but i would have made my transition to hx from vs code more doable. I want multiple lsp for html files with tailwindcss its more a thing because im still learning/memorizing tailwind stuff.
fogzen 4y ago
Soft-wrap! I love Helix Editor (it’s my daily driver), and soft-wrap was the last feature I was waiting for. Thanks to all the people who contributed to this release.
- friend_and_foe 4y ago
  Same here. I don't usually like soft wrap when writing code, but I really need it when reading documentation. I saw this and am about to update in a minute.
ngrilly 4y ago
The rate of progress is impressive.
catfishx 4y ago
I'm very excited about LSP snippet support, I will finally be able to use stuff like emmet on my svelte/html projects.
strus 4y ago
I wish Helix has vim-motions as an option. I don't want to break my muscle memory and le-learn everything just to use it in one editor (I use vim motions everywhere I can via plugins).
- rgoulter 4y ago
  I think that helix doesn't have vim motions is a core part of its identity. 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.
  - strus 4y ago
    > Or, rather, what's the difference betweeen "helix but with vim motions" and a bundled vim distribution? Vim/Neovim distribution as polished as Helix OOTB does not exist :D
- bioemerl 4y ago
  Up further, I wish things like vim were abstracted out so that they were hiding in the operating system level instead of on the application level. That way you could have vim emotions everywhere.
  - softjobs 4y ago
    Something close to that is available for macOS. https://vim.tonisives.com/ https://vim.tonisives.com/
paulsmal 4y ago
Good editor. Unfortunately no copilot so I'll keep using NeoVim.
- armchairhacker 4y ago
  Devs could use the unofficial plugin for Emacs (https://github.com/zerolfx/copilot.el https://github.com/zerolfx/copilot.el) as a guideline to add support
fileeditview 4y ago
When I tried Helix I was impressed by what I saw but had two problems with it: 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.
- xvilka 4y ago
  Yes, just rewriting NeoVim in Rust would be a perfect solution.
  - lordnaikon 4y ago
    Helix does not want to limit itself by what NeoVim is: > If Neovim is the modern Vim, then Helix is post-modern. /s
  - efficax 4y ago
    why would you want to go and do a silly thing like that. what’s the benefit
    - jeremyjh 4y ago
      Making the front page of HN.
- lordnaikon 4y ago
  The ability to use plugins is no quality in itself. Even if Helix would support plugins tomorrow, it would not magically mean you could use the same (or equal) plugins from your vim experience – someone needs to write them. You can argue that the Helix Project is in its early stages but many of the features you get by crafting your vim config are running out of the box in Helix now. 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.
ciuncan 4y ago
These are all great features, really. Everything I ask from a modern editor with language server support is just there. I also love modal text editors and use vi daily, EVERYWHERE (e.g. `set -o vi` on shell). But not on terminal GUI to write code, unless I am live debugging some shell script or python code on a server. I install vi extensions/plugins on all my editors. Using vscode over a terminal application has a lot advantages mostly due to being a very flexible graphical editor. You can move windows around, put them side by side, have fancy themes/colors/fonts. You can both use the keyboard AND the mouse when it is more convenient. 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!
- 2pEXgD0fZ5cF 4y ago
  > You can move windows around, put them side by side Why wouldn't you be able to do that with a CLI editor?
  - ciuncan 4y ago
    You can, but I'm not convinced that is as efficient. As someone who uses keyboard a lot, even for window management, I still reach for mouse whenever it is convenient. That's just one example. When you think about all the little information around (like in the status bar below), all the GUI elements like buttons. Just think about how IDE shows text at different sizes depending on the context, that alone should be a good argument against a CLI editor.
efields 4y ago
For anyone that switched to a CLI editor from GUI, what helped the most with shaking the mouse dependency?
- EligibleDecoy 4y ago
  Patience. It's hard to see the line or word you want to jump to and have to look at your keyboard and be like "what do I do?" For me it was basically tell myself "it's ok to be slow" and I started memorizing the navigation patterns from the top down of the `hx --tutor`. The further down you get on having that tutor file in muscle memory the easier it gets to want to ditch the mouse. 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.
- sibit 4y ago
  Using vim motion extensions for my primary editors (VS Code & Visual Studio) for ~11 months at my day job while using vanilla neovim (no plugins, syntax highlighting, lsp) for the first 6 months on personal projects.
- camel_Snake 4y ago
  Easy-Motion, or whatever the new version of that is.
NeutralForest 4y ago
I tried it and it's great but not being able to use the keybindings I want is a deal breaker. I'm an Emacs user and I won't make the jump to learn another system again.
aseipp 4y ago
Inlay hints look great. Is there a keymap configuration or a motion to toggle them on temporarily and turn off when a key is released? In VSCode you can do this so that holding 'alt+shift' pops up inlays, but releasing that combo makes them go away. Best of both worlds IMO, since type signature inlays often add an unnecessary amount of clutter in some languages. Either way, love Helix. It's now my quick editor of choice; I really like the Kakoune-style motions.
- frankjr 4y ago
  I'm not sure if you can show them only when you're holding a key combination, but you can toggle them. [keys.normal.space] "H" = ":toggle lsp.display-inlay-hints"
  - aseipp 4y ago
    Thanks! This is probably a reasonable substitute; I'm not too sure if "hold to activate/release to deactivate" is something to add to the input model or something the developers are interested in.
- dkarl 4y ago
  I feel the same way. I love the ability to check them when I need them, but 90% of the time, I'd rather they were invisible.
- ParetoOptimal 4y ago
  > I really like the Kakoune-style motions. 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 https://github.com/meow-edit/meow which I think is the best combination of fast, stable, well-integrated, similar to the kakoune model.
exDM69 4y ago
Using Helix has been a really positive experience, thanks to everyone contributing to this release. 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.
jmmv 4y ago
I want to like Helix, I really, really want to. It's lean, fast, polished, purely console based so it fits my workflows perfectly... but the almost-like-vim-but-not-really key bindings are a deal breaker. I just can't make the switch. 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 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.
- jeremyjh 4y ago
  I find this baffling. Who is even going to try a new modal editor if they are not already a vim (bindings) user?
  - moeris 4y ago
    Users of kakoune, like myself. What I don't understand is why this is seem as such a big deal. You spend most of your workday in your editor of choice. It's not that big a deal to spend a day or two getting used to the (IMO better) keybindings. I still up using vim for some things, like vimdiff, and I don't find it difficult to move between the two. Then again, I also use Dvorak, so maybe I'm just used to changing between layouts.
- mi_lk 4y ago
  Same here. Not that having a different editing modal is a bad thing, but vim model is proven so well that I'm not sure why any new editor would choose to die on this hill and not offer vim keybindings for many more audiences.
- rgoulter 4y ago
  I switch between helix and evil bindings on emacs. (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.
sir_eliah 4y ago
I was using Helix for some time, however what stopped me at some point was lack of persistent state in the editor. Helix is a powerful IDE, so you start to use it as an IDE, work on a project and close the editor at some point. How do you get the last opened files when you start the editor again? 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.
- jmmv 4y ago
  Not really what you are asking for, I know, but: run Helix in tmux and leave it running there. Sure, it's not going to survive computer reboots, but your state will survive almost anything else (in particular, closing terminal windows or logging out of a remote server if that's where you are working).
- pikelet 4y ago
  Perhaps you can try Ctrl+z to background the editor, do whatever you need to, and then run 'fg' (foreground I think) to get back into it. It should just stay paused in the background for you.
- TwentyPosts 4y ago
  > 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. 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'?
bamazizi 4y ago
I really want to like Helix, but muscle memory of vim over the past 5-6 years trips me all the time. I frequently have to edit files in remote servers and vi is choice editor mostly by default. 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.
- jzm2k 4y ago
  Maybe you should try committing longer? I had used Vim for nearly 8 years and had learned the crazy tricks you can do with Vim before switching to Kakoune and it took maybe 2 weeks to feel comfortable. I think people may overestimate how long it takes to relearn a style of modal editing which keeps them from committing to Kakoune/Helix which then prevents them from giving Kakoune/Helix a fair chance. After having learned this new style of modal editing, I'm really glad Helix doesn't have Vim style because I feel it be inferior to what Helix has.
  - bamazizi 4y ago
    I agree about committing longer. It took me a long time of switching back n forth with vscode and vim to fully convert over. 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.
- ParetoOptimal 4y ago
  > , try it for 20min and attempt to do my actual work for the day on it, then get frustrated and feel slowed down, Oh wow... I thought I abandoned new editor attempts quickly when I spent less than a week through the frustration phase.
- eviks 4y ago
  By the way, why not start with spending that time changing the keybind to fit your style (someone at the top even mentioned a config with vim bindings already available)? This would at least remove a lot of the frustration and maybe allow you experience the "coolness" longer?
elteto 4y ago
I would really like to try Helix and I'm even willing to learn it's keybindings, but I really need the ability to write plugins. Unfortunately, I work in a very "custom" environment where most modern tools have not made inroads yet. I rely on a couple of VIM plugins that I wrote myself to smooth out the edges and make development a bit nicer.
frankjr 4y ago
I've been using Helix for a few months now and it's fantastic. It was a bit rough at the very beginning because I was a die hard Vim user, but after a few days of struggling and paying close attention to the keys I'm pressing, I slowly adjusted and now I'm pretty comfortable. 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"] If you're just starting out with Helix, go through its tutor `hx --tutor` and if you're wondering why LSP is not working, check out the output of `hx --health` and https://github.com/helix-editor/helix/wiki/How-to-install-the-default-language-servers https://github.com/helix-editor/helix/wiki/How-to-install-th.... Oh and you can search though all available commands with space+?.
hadjian 4y ago
Does debugging work? I think the dap support was experimental. Can somebody share his/her experience?
- hadjian 4y ago
  Ah, the release notes still say: „ and experimental support for Debug Adapter Protocol (DAP).“ They’ll get there eventually.
weakfish 4y ago
Congrats to all the contributors! I wrote a small patch a few months ago and they were incredibly kind and welcoming as a community. Thrilled!
infinitezest 4y ago
Helix is awesome but I'm unlikely to see itch from Neovim. There aren't any killer features that I'm aware of and my Nvim setup is highly customized and works perfectly for my workflows.
kkoncevicius 4y ago
I vastly prefer the Vim way of action+selection to kakoune way of selection+action. Here is a short write-up (not mine) about why kakoune model is not that appealing [1]. 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/editing.org#why-not-kakoune https://github.com/noctuid/dotfiles/blob/master/emacs/editin...
- guiraldelli 4y ago
  > They either break from Vim's model (kakoune, helix) or follow Vim along with all it's flaws (Neovim, Vis). 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. [1]: https://github.com/martanne/vis#non-goals https://github.com/martanne/vis#non-goals
  - kkoncevicius 4y ago
    Vis inherits default keymaps. I prefer the way kakoune tried to clean them up by - for example - putting all the "goto" commands under "g" (where Vim has H, M, L, g;, G, gg, $, 0, ^, etc) and all the "view" commands under "v". Such rearrangements make a lot of sense and to me were more intuitive right away, even after a decade use of Vim. Then there are things like ";" and ",", W, B, E, and gE (where something like w, W, e, E would be a lot more obvious), etc. Vim likely acquired those incrementally and that's why they are all over the place. But if an editor were to start from scratch they could be re-arranged in a more logical order. Yet every vim-inspired editor takes Vim defaults for granted.
- imbnwa 4y ago
  Great write-up. Hate that I gotta press semicolon to drop the preceding selection that's a side-effect of my intent to merely navigate somewhere. 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
Arch-TK 4y ago
This is really cool, but the lack of the ability to have code at runtime to do things dynamically is a massive limitation for me, I think most of my issues could be solved with just the ability to do things at runtime. Here's some things I couldn't get working in helix: - 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[@]}" I encountered what I feel might be a bug during this, if the code formatter exits with a failure, you end losing your code.
klaussilveira 4y ago
The only thing missing from Helix is Sublime-like multiple carets.
- gecko 4y ago
  Can you explain what you mean? Multiple insertion points is kind of The Point Of Helix (and Kakoune, for that matter)
  - klaussilveira 4y ago
    Yes, but only on SEL mode. Not on INS mode. You can't quickly make multiple caret selections and insertions like you can in Sublime.
- eviks 4y ago
  there are plenty of things missing from Helix, but it does support multiple carets via `copy_selection_on_next_line`
  - klaussilveira 4y ago
    Unfortunately, not on INS mode. I can't be editing one line, then quickly create 5 new carets on the lines below, jump to the end of the line and add something, like you can with Sublime.
    - eviks 4y ago
      As an aside, this is a modal editor, so you're supposed to quickly switch modes 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 ↑)
      - 4y ago
scblock 4y ago
Addition of soft wrap is huge. That was the main thing that kept me from sinking more time into this in the past.
deleted 4y ago
[deleted]
_virtu 4y ago
I've finally made the full jump to neovim after using vim bindings in all of my other fully fledged IDES. I've recently been looking at Helix, but the lack of plugin support along with fluid git support is where I'm still stuck. I use lazygit for all of my git operations inside of neovim and it's hard for me to give that up. Anyone have good recommendations for workflows that worked for them regarding these two issues?

228 points by emerongi 4y ago

I fell in love with Helix a few months ago and every single release is improving so much. I stopped using Microsoft visual studio code and vim, and I am not missing them at all.

ctenb 4y ago
What language are you programming in?
- Casperin 4y ago
  Not GP, but same story for me (except it's been more than a year now for me). I'm coding 90% in Rust. The remaining 10% is a good mix of OCaml, TS, Python, Shell. It doesn't really matter what I touch. Helix is my editor :)

p2hari 4y ago

Love the editor for making some quick fixes or checking the repo/files. But not using it as a full time driver. This release has support for snippets but at this day and age, I would have thought we would get our long time request fixed. https://github.com/helix-editor/helix/issues/1927 https://github.com/helix-editor/helix/issues/1927

shzhdbi09gv8ioi 4y ago
If you read the issue you link to, you would know that the request itself is not the issue, but the lack of a plugin system is.

deleted 4y ago

[deleted]

dragonelite 4y ago

Ooh man had hoped multiple lsp servers in one file would have made it into this release. Ooh well its not such a biggy but i would have made my transition to hx from vs code more doable. I want multiple lsp for html files with tailwindcss its more a thing because im still learning/memorizing tailwind stuff.

fogzen 4y ago

Soft-wrap! I love Helix Editor (it’s my daily driver), and soft-wrap was the last feature I was waiting for. Thanks to all the people who contributed to this release.

friend_and_foe 4y ago
Same here. I don't usually like soft wrap when writing code, but I really need it when reading documentation. I saw this and am about to update in a minute.

ngrilly 4y ago

The rate of progress is impressive.

catfishx 4y ago

I'm very excited about LSP snippet support, I will finally be able to use stuff like emmet on my svelte/html projects.

strus 4y ago

I wish Helix has vim-motions as an option. I don't want to break my muscle memory and le-learn everything just to use it in one editor (I use vim motions everywhere I can via plugins).

rgoulter 4y ago
I think that helix doesn't have vim motions is a core part of its identity. 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.
- strus 4y ago
  > Or, rather, what's the difference betweeen "helix but with vim motions" and a bundled vim distribution? Vim/Neovim distribution as polished as Helix OOTB does not exist :D
bioemerl 4y ago
Up further, I wish things like vim were abstracted out so that they were hiding in the operating system level instead of on the application level. That way you could have vim emotions everywhere.
- softjobs 4y ago
  Something close to that is available for macOS. https://vim.tonisives.com/ https://vim.tonisives.com/

paulsmal 4y ago

Good editor. Unfortunately no copilot so I'll keep using NeoVim.

armchairhacker 4y ago
Devs could use the unofficial plugin for Emacs (https://github.com/zerolfx/copilot.el https://github.com/zerolfx/copilot.el) as a guideline to add support

fileeditview 4y ago

When I tried Helix I was impressed by what I saw but had two problems with it: 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.

xvilka 4y ago
Yes, just rewriting NeoVim in Rust would be a perfect solution.
- lordnaikon 4y ago
  Helix does not want to limit itself by what NeoVim is: > If Neovim is the modern Vim, then Helix is post-modern. /s
- efficax 4y ago
  why would you want to go and do a silly thing like that. what’s the benefit
  - jeremyjh 4y ago
    Making the front page of HN.
lordnaikon 4y ago
The ability to use plugins is no quality in itself. Even if Helix would support plugins tomorrow, it would not magically mean you could use the same (or equal) plugins from your vim experience – someone needs to write them. You can argue that the Helix Project is in its early stages but many of the features you get by crafting your vim config are running out of the box in Helix now. 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.

ciuncan 4y ago

These are all great features, really. Everything I ask from a modern editor with language server support is just there. I also love modal text editors and use vi daily, EVERYWHERE (e.g. `set -o vi` on shell). But not on terminal GUI to write code, unless I am live debugging some shell script or python code on a server. I install vi extensions/plugins on all my editors. Using vscode over a terminal application has a lot advantages mostly due to being a very flexible graphical editor. You can move windows around, put them side by side, have fancy themes/colors/fonts. You can both use the keyboard AND the mouse when it is more convenient. 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!

2pEXgD0fZ5cF 4y ago
> You can move windows around, put them side by side Why wouldn't you be able to do that with a CLI editor?
- ciuncan 4y ago
  You can, but I'm not convinced that is as efficient. As someone who uses keyboard a lot, even for window management, I still reach for mouse whenever it is convenient. That's just one example. When you think about all the little information around (like in the status bar below), all the GUI elements like buttons. Just think about how IDE shows text at different sizes depending on the context, that alone should be a good argument against a CLI editor.

efields 4y ago

For anyone that switched to a CLI editor from GUI, what helped the most with shaking the mouse dependency?

EligibleDecoy 4y ago
Patience. It's hard to see the line or word you want to jump to and have to look at your keyboard and be like "what do I do?" For me it was basically tell myself "it's ok to be slow" and I started memorizing the navigation patterns from the top down of the `hx --tutor`. The further down you get on having that tutor file in muscle memory the easier it gets to want to ditch the mouse. 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.
sibit 4y ago
Using vim motion extensions for my primary editors (VS Code & Visual Studio) for ~11 months at my day job while using vanilla neovim (no plugins, syntax highlighting, lsp) for the first 6 months on personal projects.
camel_Snake 4y ago
Easy-Motion, or whatever the new version of that is.

NeutralForest 4y ago

I tried it and it's great but not being able to use the keybindings I want is a deal breaker. I'm an Emacs user and I won't make the jump to learn another system again.

aseipp 4y ago

Inlay hints look great. Is there a keymap configuration or a motion to toggle them on temporarily and turn off when a key is released? In VSCode you can do this so that holding 'alt+shift' pops up inlays, but releasing that combo makes them go away. Best of both worlds IMO, since type signature inlays often add an unnecessary amount of clutter in some languages. Either way, love Helix. It's now my quick editor of choice; I really like the Kakoune-style motions.

frankjr 4y ago
I'm not sure if you can show them only when you're holding a key combination, but you can toggle them. [keys.normal.space] "H" = ":toggle lsp.display-inlay-hints"
- aseipp 4y ago
  Thanks! This is probably a reasonable substitute; I'm not too sure if "hold to activate/release to deactivate" is something to add to the input model or something the developers are interested in.
dkarl 4y ago
I feel the same way. I love the ability to check them when I need them, but 90% of the time, I'd rather they were invisible.
ParetoOptimal 4y ago
> I really like the Kakoune-style motions. 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 https://github.com/meow-edit/meow which I think is the best combination of fast, stable, well-integrated, similar to the kakoune model.

exDM69 4y ago

Using Helix has been a really positive experience, thanks to everyone contributing to this release. 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.

jmmv 4y ago

I want to like Helix, I really, really want to. It's lean, fast, polished, purely console based so it fits my workflows perfectly... but the almost-like-vim-but-not-really key bindings are a deal breaker. I just can't make the switch. 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 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.

jeremyjh 4y ago
I find this baffling. Who is even going to try a new modal editor if they are not already a vim (bindings) user?
- moeris 4y ago
  Users of kakoune, like myself. What I don't understand is why this is seem as such a big deal. You spend most of your workday in your editor of choice. It's not that big a deal to spend a day or two getting used to the (IMO better) keybindings. I still up using vim for some things, like vimdiff, and I don't find it difficult to move between the two. Then again, I also use Dvorak, so maybe I'm just used to changing between layouts.
mi_lk 4y ago
Same here. Not that having a different editing modal is a bad thing, but vim model is proven so well that I'm not sure why any new editor would choose to die on this hill and not offer vim keybindings for many more audiences.
rgoulter 4y ago
I switch between helix and evil bindings on emacs. (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.

sir_eliah 4y ago

I was using Helix for some time, however what stopped me at some point was lack of persistent state in the editor. Helix is a powerful IDE, so you start to use it as an IDE, work on a project and close the editor at some point. How do you get the last opened files when you start the editor again? 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.

jmmv 4y ago
Not really what you are asking for, I know, but: run Helix in tmux and leave it running there. Sure, it's not going to survive computer reboots, but your state will survive almost anything else (in particular, closing terminal windows or logging out of a remote server if that's where you are working).
pikelet 4y ago
Perhaps you can try Ctrl+z to background the editor, do whatever you need to, and then run 'fg' (foreground I think) to get back into it. It should just stay paused in the background for you.
TwentyPosts 4y ago
> 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. 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'?

bamazizi 4y ago

I really want to like Helix, but muscle memory of vim over the past 5-6 years trips me all the time. I frequently have to edit files in remote servers and vi is choice editor mostly by default. 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.

jzm2k 4y ago
Maybe you should try committing longer? I had used Vim for nearly 8 years and had learned the crazy tricks you can do with Vim before switching to Kakoune and it took maybe 2 weeks to feel comfortable. I think people may overestimate how long it takes to relearn a style of modal editing which keeps them from committing to Kakoune/Helix which then prevents them from giving Kakoune/Helix a fair chance. After having learned this new style of modal editing, I'm really glad Helix doesn't have Vim style because I feel it be inferior to what Helix has.
- bamazizi 4y ago
  I agree about committing longer. It took me a long time of switching back n forth with vscode and vim to fully convert over. 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.
ParetoOptimal 4y ago
> , try it for 20min and attempt to do my actual work for the day on it, then get frustrated and feel slowed down, Oh wow... I thought I abandoned new editor attempts quickly when I spent less than a week through the frustration phase.
eviks 4y ago
By the way, why not start with spending that time changing the keybind to fit your style (someone at the top even mentioned a config with vim bindings already available)? This would at least remove a lot of the frustration and maybe allow you experience the "coolness" longer?

elteto 4y ago

I would really like to try Helix and I'm even willing to learn it's keybindings, but I really need the ability to write plugins. Unfortunately, I work in a very "custom" environment where most modern tools have not made inroads yet. I rely on a couple of VIM plugins that I wrote myself to smooth out the edges and make development a bit nicer.

frankjr 4y ago

I've been using Helix for a few months now and it's fantastic. It was a bit rough at the very beginning because I was a die hard Vim user, but after a few days of struggling and paying close attention to the keys I'm pressing, I slowly adjusted and now I'm pretty comfortable. 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"] If you're just starting out with Helix, go through its tutor `hx --tutor` and if you're wondering why LSP is not working, check out the output of `hx --health` and https://github.com/helix-editor/helix/wiki/How-to-install-the-default-language-servers https://github.com/helix-editor/helix/wiki/How-to-install-th.... Oh and you can search though all available commands with space+?.

hadjian 4y ago

Does debugging work? I think the dap support was experimental. Can somebody share his/her experience?

hadjian 4y ago
Ah, the release notes still say: „ and experimental support for Debug Adapter Protocol (DAP).“ They’ll get there eventually.

weakfish 4y ago

Congrats to all the contributors! I wrote a small patch a few months ago and they were incredibly kind and welcoming as a community. Thrilled!

infinitezest 4y ago

Helix is awesome but I'm unlikely to see itch from Neovim. There aren't any killer features that I'm aware of and my Nvim setup is highly customized and works perfectly for my workflows.

kkoncevicius 4y ago

I vastly prefer the Vim way of action+selection to kakoune way of selection+action. Here is a short write-up (not mine) about why kakoune model is not that appealing [1]. 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/editing.org#why-not-kakoune https://github.com/noctuid/dotfiles/blob/master/emacs/editin...

guiraldelli 4y ago
> They either break from Vim's model (kakoune, helix) or follow Vim along with all it's flaws (Neovim, Vis). 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. [1]: https://github.com/martanne/vis#non-goals https://github.com/martanne/vis#non-goals
- kkoncevicius 4y ago
  Vis inherits default keymaps. I prefer the way kakoune tried to clean them up by - for example - putting all the "goto" commands under "g" (where Vim has H, M, L, g;, G, gg, $, 0, ^, etc) and all the "view" commands under "v". Such rearrangements make a lot of sense and to me were more intuitive right away, even after a decade use of Vim. Then there are things like ";" and ",", W, B, E, and gE (where something like w, W, e, E would be a lot more obvious), etc. Vim likely acquired those incrementally and that's why they are all over the place. But if an editor were to start from scratch they could be re-arranged in a more logical order. Yet every vim-inspired editor takes Vim defaults for granted.
imbnwa 4y ago
Great write-up. Hate that I gotta press semicolon to drop the preceding selection that's a side-effect of my intent to merely navigate somewhere. 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

Arch-TK 4y ago

This is really cool, but the lack of the ability to have code at runtime to do things dynamically is a massive limitation for me, I think most of my issues could be solved with just the ability to do things at runtime. Here's some things I couldn't get working in helix: - 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[@]}" I encountered what I feel might be a bug during this, if the code formatter exits with a failure, you end losing your code.

klaussilveira 4y ago

The only thing missing from Helix is Sublime-like multiple carets.

gecko 4y ago
Can you explain what you mean? Multiple insertion points is kind of The Point Of Helix (and Kakoune, for that matter)
- klaussilveira 4y ago
  Yes, but only on SEL mode. Not on INS mode. You can't quickly make multiple caret selections and insertions like you can in Sublime.
eviks 4y ago
there are plenty of things missing from Helix, but it does support multiple carets via `copy_selection_on_next_line`
- klaussilveira 4y ago
  Unfortunately, not on INS mode. I can't be editing one line, then quickly create 5 new carets on the lines below, jump to the end of the line and add something, like you can with Sublime.
  - eviks 4y ago
    As an aside, this is a modal editor, so you're supposed to quickly switch modes 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 ↑)
    - 4y ago

scblock 4y ago

Addition of soft wrap is huge. That was the main thing that kept me from sinking more time into this in the past.

deleted 4y ago

[deleted]

_virtu 4y ago

I've finally made the full jump to neovim after using vim bindings in all of my other fully fledged IDES. I've recently been looking at Helix, but the lack of plugin support along with fluid git support is where I'm still stuck. I use lazygit for all of my git operations inside of neovim and it's hard for me to give that up. Anyone have good recommendations for workflows that worked for them regarding these two issues?