Helix 23.03

https://helix-editor.com/news/release-23-03-highlights/

by emerongi • 3 years ago

228 93 3 years 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• 3 years ago

What language are you programming in?

Casperin• 3 years 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• 3 years 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

shzhdbi09gv8ioi• 3 years 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.

dragonelite• 3 years 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• 3 years 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• 3 years 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• 3 years ago

The rate of progress is impressive.

catfishx• 3 years ago

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

strus2• 3 years 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).

bioemerl• 3 years 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• 3 years ago

Something close to that is available for macOS. https://vim.tonisives.com/

rgoulter2• 3 years 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.

strus2• 3 years 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

paulsmal• 3 years ago

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

armchairhacker• 3 years ago

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

fileeditview4• 3 years 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• 3 years ago

Yes, just rewriting NeoVim in Rust would be a perfect solution.

lordnaikon3• 3 years ago

Helix does not want to limit itself by what NeoVim is:

If Neovim is the modern Vim, then Helix is post-modern.

efficax2• 3 years ago

why would you want to go and do a silly thing like that. what’s the benefit

lordnaikon3• 3 years 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.

efficax2• 3 years ago

i agree that the plug-in chaos of vim and even emacs is exhausting. there’s so much churn, abandoned packages, and all this decision making that you have to do to get started. but at the same time you can’t expect to be able to build all the functionality into the editor. my workflow is greatly simplified by using tpopes vim-fugitive, it’s a fantastic git interface and it makes total sense to be part of an editor, and the lack of a similar thing in helix was the first reason i went back to vim after trying it out. if helix had plug-ins i’d probably be implementing that functionality myself! there are tons of other things like that. sure i could start building a git interface into helix itself but that both seems like a failure to separate concerns and a possible waste of time if it gets rejected by the maintainer etc.

fileeditview4• 3 years ago

As far as I remember they stated that plugins won't be supported back when I tried it. No idea if that has changed.

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.

eviks6• 3 years ago

The ability to use plugins is no quality in itself

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

maherbeg• 3 years ago

What plugins do you miss in particular? I'd be curious how much of a delta it would be to getting to exactly what you needed.

fileeditview4• 3 years ago

A bit late but here is a list of plugins I could not live without:

- 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 ;)

ciuncan2• 3 years 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• 3 years ago

You can move windows around, put them side by side

Why wouldn't you be able to do that with a CLI editor?

ciuncan2• 3 years 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• 3 years ago

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

EligibleDecoy• 3 years 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• 3 years 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• 3 years ago

Easy-Motion, or whatever the new version of that is.

NeutralForest• 3 years 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.

aseipp2• 3 years 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.

frankjr2• 3 years 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"

aseipp2• 3 years 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• 3 years 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.

ParetoOptimal3• 3 years 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 which I think is the best combination of fast, stable, well-integrated, similar to the kakoune model.

exDM69• 3 years 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.

jmmv2• 3 years 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 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.

jeremyjh2• 3 years 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• 3 years 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_lk2• 3 years 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.

rgoulter2• 3 years 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.

ParetoOptimal3• 3 years ago

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.

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.

cassepipe• 3 years ago

Same. Helix made me realized vim is a walled garden and I willingly helped buidling those walls.

bestouff• 3 years ago

Oh thank you for the pointer. I'm exactly at your point where I tried it a few times, but >30 years of VIM keybindings in my fingers make it too painful to switch and stick to it. I'll try those.

BTW: nearly 500 stars for this simple config, that should send a clear message to Helix devs.

setr• 3 years ago

Has any vim-like ever not had the complaint that it was insufficiently vim so as to be impossible to switch to?

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.

haarts• 3 years ago

I don't think this is such a big deal. Yeah, you'd spent a couple of days cursing at your fingers. The bindings are an improvement and they require an investment, like all things worthwhile in life.

mi_lk2• 3 years ago

"not a big deal" and "[Helix] bindings are an improvement" are rather subjective in this case I'm afraid

vaylian• 3 years ago

The thing that worked for me: Don't try to be focused on coding efficiency when learning Helix. I've used Vim for well over a decade and I'm very fluent in it. But when I decided to learn to use Helix, I shifted my mindset to a Notepad.exe-like experience. A lot more scrolling, a lot less jumping. And then I started prioritizing the most needed shortcuts one by one. Helix also has a nice command search that is available via "space ?" that helped me find the commands and key combos that I wanted to learn.

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

irusensei• 3 years ago

Same here. The vim muscle memory is too strong.

sir_eliah2• 3 years 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.

jmmv2• 3 years 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• 3 years 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• 3 years 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'?

sir_eliah2• 3 years ago

Yeah, you can use registers or the system clipboard, however this takes more actions and puts stuff into your clipboard history. Maybe it's just my way of working, but I move lines above or below when reorganizing lists in markdown or other basic text operations. For me it's as useful IDE feature as multiple cursors and in fact I often use them together.

All the major IDEs like sublime/jetbrains/vscode have both of these functionalities.

bamazizi2• 3 years 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• 3 years 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.

bamazizi2• 3 years 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.

ParetoOptimal3• 3 years 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.

eviks6• 3 years 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• 3 years 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.

frankjr2• 3 years 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-th.... Oh and you can search though all available commands with space+?.

hadjian2• 3 years ago

Does debugging work? I think the dap support was experimental.

Can somebody share his/her experience?

hadjian2• 3 years ago

Ah, the release notes still say: „ and experimental support for Debug Adapter Protocol (DAP).“

They’ll get there eventually.

weakfish• 3 years 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• 3 years 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.

kkoncevicius2• 3 years 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/editin...

guiraldelli• 3 years 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

kkoncevicius2• 3 years 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• 3 years 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• 3 years 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.

klaussilveira6• 3 years ago

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

gecko• 3 years ago

Can you explain what you mean? Multiple insertion points is kind of The Point Of Helix (and Kakoune, for that matter)

klaussilveira6• 3 years 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.

eviks6• 3 years ago

there are plenty of things missing from Helix, but it does support multiple carets via `copy_selection_on_next_line`

klaussilveira6• 3 years 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.

scblock• 3 years ago

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

_virtu• 3 years 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?

Helix 23.03

Related Stories