Thoughts on Helix Editor after 1 year

Oct 3, 2025
6 min read

Background

Last year, I switched to using Helix Editor as my primary code editor. For context, I primary use C++ and Rust. I've tried many other text editors and IDE's, but none ever really stuck. Typically, I cycle between Visual Studio Code, CLion, Qt Creator and Visual Studio every month or so just for a change of scenery.

All of these are great tools honestly, and I still use them, but I will most likely reach out to using Helix for most of my work. Helix has tons of features, but you can be productive with only knowing a handful of common commands.

Switching to a Modal Interface

Helix Editor is a terminal text editor, similar to Vim. In other words, cursor movements will be done using the keyboard.

There are different modes that exist in Helix:

Normal Mode: Moving around the editor and editing commands Insert Mode: Let's you type in the editor Selection Mode: Makes selections, and allows you to manipulate them.

The commands are utility actions that are common across text editors, such as copy, paste, open file, etc. Many of the utility actions that you might do in an IDE will most likely exist in Helix, but you have to use specific key strokes to perform them. IDE's tend to be very "clicky" when you are navigating through projects. I initially thought using a mouse for editing was not that big of a deal, but once you start to use the keyboard for navigation through your text, it makes for a much better experience.

Minimal UI

Helix only has one component, the editor. This mean that there is no outliner, debugger, console, buttons, or any IDE features you might be used to. You also can not extend Helix by using plugins (coming soon though!). Most text editors have a plugins system where developers from all corners of the industry can create a tailored feature for their workflow. Part of why I used Sublime Text and Visual Studio Code in the past was due to so much feature support.

Even though I would say Helix is quite feature rich for my use case by default, the only real option to add more features is to modify the source code yourself.

Zen

I am not sure of this section will make sense, but there is something quite cathartic to me when my entire development tool is a single text field.

It is easy to get overwhelmed in Visual Studio with all the menus, layouts, buttons, panes, settings. Of course, Visual Studio has many features that have been built through decades, but it is quite daunting at first glance.

I initially thought that not using a file explorer, buttons, or menus was a bit counterintuitive - but you really do get used to it as your workflow naturally adapts. Helix does support file exploring and lookups, but it is not a dedicated UI element that sits adjacent to your text editor field.

But I do acknowledge that my experience might contrast with others, where using a single window pane for the entirety of development seems counterintuitive. Looking back at it, maybe it is, but it is a workflow that personally works for me.

Starting from Scratch Might Take a Minute

In IDE's, you can go from a new project to compile fairly quickly. Depending on which tool you use, it will most likely either us MSBUILD or CMake for the building and linking.

Helix uses a Language Server Protocol (LSP) for its autocomplete feature, so C++ developers will have to ensure the proper compile_commands.json gets generated from whatever build system you are using.

And unlike an IDE, where there is a big button to run code, you will have to go through the CLI and use your build system commands. I usually opt to just use a build script to do all those steps in a single shot.

Debugging

Helix does technically have debugging that was added recently, but I find it to be difficult to use.

Alternatively, using a CLI debugger like gdb or LLDB is not as intuitive to me. Perhaps I've been spoiled by the use of debugger frontends that exist plenty nowadays, but visually stepping through code to inspect the granular details of your program is a must.

When I have a serious bug where my usual printf spamming failed me, I used to bring my project over to Visual Studio to only use the debugger.

Presently, I use RAD Debugger when I have to use the debugger. It is very fast stepping through code, and the UI is highly customization to cater to whatever menus you might need to diagnose bugs. Unfortunately, as of right now, it is only supported on Windows. I'm eager waiting for a Linux version which hopefully will release soon.

Slow Updates

Updates are slow. This one does not bother me that much, but I've seen a fair share of complaints online how some pull requests are taking years to get merged.

Helix usually has 2 to 3 major updates per year where at least 1 feature might be of use to most programmers.

Multipurpose

I prefer a single, unified, and multiple purpose application to do all development on.

In my personal workflow, I work on Windows, MacOS and Linux. Since Helix is terminal based, it is trivial to get it working on all those operating systems. If you want synced settings, setting up repo of your settings folder is recommended.

Helix also supports many languages, and setting up formatting and autocomplete is just adding a few lines in a .toml file.

Moving Forward

I will continue to use Helix as my first development tool of choice, but at the end of the day, it is purely a tool. Using an editor can be a very personal thing, since you will be staring at it for the entire time.

I'm always curious about new tools that pop up, and open to trying them out. Afterall, if my own personal curiosity didn't get the best of me, I probably will still be cycling through multiple editors.

Tools