rIDE: a composable non-IDE for terminal junkies

Table of Contents

Premise

This is just my opinion and a very subjective affair. YMMV. I express preferences that may not match yours. And that’s fine. I neither pretend nor imply to lay down this as a paper nor as a definitive solution for everyone. There’s nothing scientific about this. Paraphrasing a Grace Jones song: this is not perfect, but it’s perfect for me.

That being said, I’m passionate and I like sharing things I believe have merits and could benefit others. This is the spirit you should keep in mind, while reading this.

Credits

I first heard of non-IDE in a Zed video. That made me realize I was assembling a non-IDE. I had recently switched to Helix. I decided to name it rIDE and to blog about it, there and then. I believe they deserves credits for inspiring this blogpost.

The Elevator Pitch

I’ve used every text editor under the Sun1 and I’ve editor hopped for years, while sticking with (n)vim, looking for the perfect IDE. One that would fit my needs and tick all checkboxes2. Until I heard about Helix Editor and decided to give it a go. Helix is fast. It’s modal. It’s featureful. It requires no maintenance. It supports all I need. The learning curve and switching costs were minimal. I never looked back.

Helix, despite the name, is an IDE. However, it doesn’t have - to name a few - a file manager, a terminal emulator, nor git porcelain. By design. Helix’s focus is to offer core IDE features - no more3 - out of the box. A choice akin to the UNIX philosophy. One that other editors users may find limiting or lacking. On the other hand, it’s an approach that enables comprehensive modularity, which is rIDE4 core principle.

rIDE, simply put, is: use the best tool for the job. Each with its own configuration5. Easy to integrate with Helix. Easy to replace, when you want to swap a specific tool for another. All within your favorite terminal emulator. Live happily ever after. 🥳 🎉

Having to compose external tooling may seem unnecessary extra-work, at first. I thought so too, after some usage and when pondering the switch. It didn’t take me too long to accustom to this new normal, though. Which is comparable, for the most part, to using extensions. That said, the perks of the rIDE approach are numerous. Most importantly: a level of flexibility and peace of mind I haven’t had in a long time.

The Full Story

Holy Wars

In my early days of involvement and falling in love with Copyleft6, I’ve ideologically been closer to FSF than OSI7. Thus, for reasons as silly as the editor war, I was tempted to join The Church of Emacs. Although, as I was looking into a Linux System Administrator career, I made a pragmatic choice. Systems shipped vi(m). Thus, I learned vi(m) and extensively used (n)vim - vanilla, custom, with plugin managers, or distros - for about 20 years. It would still be my backup editor, should the need arise.

Terminal Mon Amour

As system administrators do, I live(d) in the terminal (with or without a multiplexer). The terminal is my preferred environment. When feasible and reasonable, I rely on and prefer terminal applications. Not a brag. It’s relevant for later. Put a pin on this 📍

GUIsclaimer

Later, I’ll get into some of the editors I explored and used for a varying amount of time and degree of satisfaction. Some of them are graphical. A common issue I have with graphical editors: they slow me down. In this context, GUIs are distracting. I often have found myself fighting them and having to think about most interactions.

It’s Not You, It’s Me

(n)vim is a great modal editor I love(d). It became second nature to me, and it’s the one I’ve always went back to during my editor hopping explorations. That being said, personal pain points motivated me to seek out alternatives. Lately, more intensely.

Every Text Editor Under The Sun

Amongst the many I explored1, whilst still using (n)vim8 as my GOTO and fallback, the three alt-editors shortlist, for features-related merits, comes down to:

  • VS Code: supports basically everything; Live Share / pair programming tooling.
  • DOOM Emacs: the meta key; the bottom drawer; which-key; the pickers; ease of configuration; one stop shop. Org Mode / Roam / Agenda. The list could go on9.
  • Zed: fast; written in Rust; native AI integration; great communication tooling.

These are some of the features I wished a definitive editor would pack in by default. The single most important of the list - can you tell!? 😜 - is, arguably, DOOM Emacs. Lazyvim also plays a major role, when it comes to features set. We’ll get to them next.

Not So Unique, Pal

Nowadays, the most widely used editors all share many features. Influencing and inspiring each others. Thank Ceiling Cat for Open Source! Nothing I’m about to say next is intended as unique to, nor distinguishing for, any particular editor. Helix is, however, the main subject of this whole story; and it’s used as basis of comparison.

So Many Checkboxes

While Helix didn’t implement all the desired features, it ticked enough checkboxes to convince me that it was worth sticking with it. To make the switch. To get used to it. Only then, ponder how to fill in the blanks. In no particular order, they all rock:

To me, these clearly were solid foundations I could build upon, at a later stage. 🍾 🎊

So Many Blanks To Fill In

Alas, early on in the switch, it still felt like Helix missed important bits I was used to. Let’s address the elephant in the room: how was I gonna fare without Vim’s mode and editing approach? Action first vs Selection first? Surely, the filliest elephant to filly-fill.

And what about tooling? Helix doesn’t have, to name a few: extensions3 nor package managers, a file manager, a terminal emulator, nor git porcelain. What you mean I have to install things externally? Can I easily integrate Lazygit? So on and so forth.

The blanks didn’t end there either. What about what’s left from the earlier shortlist?

The Meat Of The Tomato

Before discussing how to fill in the blanks and develop the rIDE4 concept, let’s first expand on the checkboxes. Hereby grouped by their common characteristics. You should consider each of them as something absolutely indispensable, in this context.

Modal and terminal based text editor

Being accustomed to (n)vim, with a long-serving experience, and suffering graphical text editors, the perfect editor had to be both modal and run in my favorite terminal.

Written in Rust. Fast and Featureful

I love Rust for personal, technical, and social reasons. You may love Zig (I’m Zig-curious), Go, or C++. For different reasons. That’s absolutely fine. As you’ll see in the next section, when we’ll get to rIDE, I do tend to go all-in but I’m not a maximalist.

There are more specific points of the utmost importance - besides, of course, the responsiveness of executables built with it - in wanting the perfect editor to be written in Rust. I.e: its guarantees - like memory safety and error handling - and its language design. These may seem frivolous reasons but there’s a common thread: I’m not willing to cope with entire categories of bugs and annoyances, if I can help it.

This leads into the last point: extensions vs core IDE features out of the box. In this case, less is more. Specifically, less dependencies and things that can go wrong or that I have to manage. While no language is immune to supply chain attacks, this to me - I may be wrong, of course - feels like having a smaller attack surface, overall.

Support for languages and tools

While Helix bakes in plenty core IDE features by default, to support languages it relies on LSP, Tree-sitter, and external tooling. Such as language servers and, for example, external formatters. This is, of course, common to other editors and pretty much the standard. With a difference: most editors rely on package managers (or extensions) to install them. With Helix, one is required to install external tooling. Initially, this seemed a nuisance and a bug. It soon turned into a welcome feature. This was also the moment where modularity as a plus bubbled up my neural paths.

Minimal configuration and maintenance

(n)vim configurations can get out of hand and turn into a PITA. Even an expert11 admits not touching it for a year; that must mean something. Distributions like Lazyvim (or DOOM Emacs) may do a great job at handling and hiding them for end users, however, this was still too high maintenance and my main paint point with it.

On the other hand, Helix comes with great defaults and only has two main TOML configuration files. One for the editor. One for customizing languages support. Needing to tweak the editor settings or languages support is, pretty much, set and forget. Something that doesn’t happen that often either. Mostly when swapping tools.

Support for a keyboard-only workflow

Arguably, this is the most subjective preference of the checkboxes. It does, however, tie in with my difficulties with graphical editors. Moerover, it is a preference shared by most - if not all - terminal text editors users. Nonetheless, this is worth mentioning because Helix’s selection first editing works amazingly for a mouseless workflow.

Here’s the kicker: even more so than (n)vim’s action first approach. “HERESY!!!”

As greatly stressed in this whole story, I’ve been using (n)vim for the best part of two decades. I enabled Vim Mode everywhere I could. This obviously was a huge blank to fill in. Unlike others, however, I neither think Helix made a bad design choice nor seek out an evil-mode. Like I previously did by choosing DOOM Emacs over vanilla. This time, I wanted to see if it was worth making the switch. To get used to it. I love it.

Minimal learning curve and switching costs

The cat is out of the bag. The learning curve and switching costs mainly comprised the editing style: selection → action model vs action → selection model. Other differences were negligible enough. Missing features and tools? Easy to deal with. Moreover, exploring so many editors widened my perspectives. Adjusting to Helix mode, pickers, commands, and shortcuts, was never an issue in the first place.

So, What Is rIDE?

By now, it should be clear that rIDE is nothing new under the Sun. The non-IDE concept pre-dates it. What it is, is my own approach to it and a funny - inside joke4 - name; and, of course a tooling set of choice. To wit, there are distros for Helix too. Like Yazelix. This is something I looked up and gave it a miss. I was not going down that path again. No thanks. It would have meant picking a different distro lock-in, configuration-hell, and someone else’s (often maximalist) restrictive choices.

Let’s start from what Helix does not feature by design, and compare my choices and differences with Yazelix. The most important is definitely the terminal emulator. This is where everything runs, after all. I made a different choice, for a few key reasons.

GhosTTY

Most Rust aficionados run with WezTerm. I did to, until I heard about GhosTTY. Yazelix (and most people using WezTerm) relies on Zellij to multiplex and resemble an IDE layout to run Helix and other tools. Whatever floats their boats. I did try the Zellij approach to run Helix on my own and it felt like a GUI editor all over again. 😱

GhosTTY has many other great qualities that made me prefer it. Above all, it behaves natively on all platforms. Using the same keystrokes and macros on my ZSA Voyager (with Colemak DHm) in all of my terminal based environment is a huge plus. Besides, GhosTTY ships with clever split functionality and great tabs management.

Final note on Zellij: I’d still use it instead of tmux for system administration on a daily basis. Until: GhosTTY delivers on its promise to revolutionize multiplexing as well. When it will eventually be implemented, this feature will certainly spawn a number of tools and pave the road for wide open possibilities. I look forward to it to have native remote pair programming, sessions sharing, and communication integration. For the time being, I would like to try out EtherSync and see how that works out.

Fish Shell and Starship

As a system administrator, the command line interface is my habitat. I don’t need a fancy shell trying too hard. I extensively used BASH and Zsh and lately have switched to Fish and Starship for QoL improvements. That’s plenty already.

Helix, Of Course

This should go without saying, however, it is worth mentioning for a reason: why run a terminal emulator within a terminal text editor within a terminal emulator; when you can run Helix within GhosTTY and that’s it? Missing feature? Quite the contrary.

Yazi and Lazygit

Let’s address the other two missing features: the file manager and git porcelain. Yazelix name is a portmanteau of Yazi and Helix. Yazi is a great TUI file manager. I do have it installed but rarely use it. I navigate the filesystem in the terminal when I need to. From there I open what’s needed, directly in Helix. Should I need to open more files, I rely on Helix file picker and fuzzy find. Lazygit? I constantly rely on it.

All it takes to integrate both with Helix - provided one has previously installed them - is just to add two lines to ~/.config/helix/config.toml to map them as pleased:

[keys.normal]
C-g = [":new", ":insert-output lazygit", ":buffer-close!", ":redraw"]
A-f = [":new", ":insert-output yazi", ":buffer-close!", ":redraw"]

Side note: if you prefer Magit, give gitu a try. Wanna use GitUI instead? No problem! Just replace the name of the binary in that specific one liner! Easy peasy!

Catppuccin

This is subjective, of course, but all it takes to theme Helix - and all of rIDE - is to choose or install a theme and add a one liner to ~/.config/helix/config.toml:

theme = "catppuccin_frappe"

Amazon Q CLI

I don’t rely on AI too often and don’t subscribe to vibe coding (at all!), however, when using Zed I tried out AI and it was useful to some extent12. I went from fully skeptic to cautious user and I still agree with most criticisms. Especially with the argument about AI in the hands of a knowledgeable user vs a cheap lazy sod. I do like to use Claude Sonnet with Amazon Q CLI for small, boring, and repetitive stuff; or when I struggle with an issue for too long and can’t understand it nor find my own solution.

Harper and Typos

For grammar checks and typos avoidance, Harper and Typos are great. ’Nuff said.

Typst

There’s one last missing desired tool from editors shortlist to talk about: Org Mode. When I used DOOM Emacs as my daily driver, I fell in love with Org Mode. Its features set allows for great documents; especially with LaTeX export to anything. I wanted to migrate all my writings to it and even replace LibreOffice. That’s how powerful it is. When I left DOOM Emacs behind, I switched to Zed and Obsidian.

To wit: 1) Obsidian is OK; 2) I’ve since fantasized with the idea to create an office suite with Org Mode as its engine, in Rust. So, I sought out and found some ports and libraries but a) they don’t have features parity and b) I’m not that good (yet?!).

And then one day, I stumbled upon Typst. They do a fantastic job indeed. So now, I’m thinking to migrate everything writing to it instead. At the moment I’m only using the web app to manage my CV with it. That being said, Typst engine is written in Rust and it’s Open Source. Anyway, momentarily I’d be content with using Typst with Helix for my writings. Guess what: Helix supports it out of the box or with minimal tweaks.

[language-server.harper-ls]
command = "harper-ls"
args = ["--stdio"]

[language-server.typos]
command = "typos-lsp"
environment = { "RUST_LOG" = "error" }
# How typos are rendered in the editor, can be one of an Error, Warning, Info or Hint.
config.diagnosticSeverity = "Warning" # Defaults to Warning.

[language-server.tinymist]
command = "tinymist"

[[language]]
name = "typst"
language-servers = ["tinymist", "harper-ls", "typos"]
formatter = { command = "typstyle" }
auto-format = true

scope = "source.typst"
file-types = ["typst", "typ"]
comment-token = "//"
injection-regex = "typ(st)?"
roots = ["typst.toml"]

[language.auto-pairs]
'(' = ')'
'{' = '}'
'[' = ']'
'$' = '$'
'"' = '"'

Markdown Oxide

While Typst would work great to replace everything writing, I’d still like to rely on Markdown Oxide for PKMS. I’ve been fascinated by Zettelkasten and Org Roam, for a while. However, I never went farther than using The Archive app for my creative writings; then replaced by Obsidian. Mostly because it offers a mobile app - should I need to jot down a story on the go - and sync. My Obsidian is very minimal and I rarely use it for anything else. I’m not a researcher nor an academic but I like things organized and systematic. I’m bringing all of this up to let you know that Helix does support Markdown Oxide (and Marksman) out of the box. Preview? Soon(?)

You Get The Gist

I could go on about Helix languages support and how to configure them, or about adding more tooling to rIDE, but that would be pointless. I wanted to expand on the most frequent critics and exemplify my idea to give meaning to it all. Not to mention this story is way too long already. If you like the concept behind rIDE, the sky is the limit. Therefore, I’d like to conclude by inviting you to try out Helix, if you please:

Thank you so much for your time and for putting up with this. I appreciate you.

🍻🚌

  1. A non-exhaustive and non-chronological list of the ones I do remember exploring: Gedit. BBEdit. Notepad++. TextMate. Sublime. Atom. VS Code. Zed. Rust Rover. DOOM Emacs. Possibly more, but probably not worth recalling. ↩ ↩2

  2. During my explorations, I always missed (n)vim - not the pain points that made me look for others in the first place, though - and always came back to it. Having said that, I really liked some of the features of some of the other editors too. This made me long for an editor that would Frankenstein those into a single package. ↩

  3. If you are wondering: yes, Helix will eventually be extensible with plugins - should you need those. However, this would not mean that Helix will distort its core philosophy. ↩ ↩2

  4. The r in rIDE stands for Regular. It is both an inside joke for Ken’s listeners and a play on the fact that it’s technically not an IDE. Let alone a regular one. ↩ ↩2 ↩3

  5. As opposed to having a humongous (n)vim configuration you have to schedule maintenance for; one would install and configure external tooling independently from Helix. We’ll get into this, when expanding on rIDE, much later. ↩

  6. Care to read My Linux Story or: How I Fell in Love with Copyleft and Revolution? ↩

  7. There are pretty good arguments to be made. I’ll blog about this too, soon-ish. ↩

  8. With custom configurations and / or plugins managers; or distros like Lunarvim, AstroNvim, and Lazyvim. ↩

  9. When I switched to DOOM Emacs for a short while, I realized many of the tooling I was used to and loved in Lazyvim (for sake of argument) that the amazing and incredibly prolific folke develops, were concepts inspired from Emacs counterparts. It was revealing. These were the catalysts toward the final step. Please, correct me if I’m mistaken. ↩

  10. I cite every JavaScript framework motto mainly as a joke. Anyway, if you hate yourself you could watch this fasterthanlime take instead. ↩

  11. I can’t pin point exactly where The Primagen said it. I think it was during his appearance on Lex Fridman. A great watch. I’m not a regular follower of neither but I genuinely appreciated their conversation and felt (not as in pity) for him. I may not agree with most of his takes and only occasionally watch his content for light entertainment - I don’t mean this derogatorily - however, I have plenty respect for The Primagen story. You should make time for it and watch it. ↩

  12. When relying on AI, however, I won’t just let it do stuff. When I need help to understand an issue it’s analysis first. In the case of help me code this, I like prompt engineering. ↩