Mitos editor is a fork of Helix

66 pointsposted 10 hours ago
by ambigious7777
(mitos.computer)

57 Comments

jon128

9 hours ago

An articulated rationale for why a fork would go a long way for awareness of why an existing user of Helix might consider to use Mitos instead (or not) really needs to be the first thing we see on the front page of the site for Mitos.

One thing that really sticks out to me and gives me a feeling I won't consider to use Mitos, is the presentation further down on Mitos' front page of rendering of image files inside the terminal emulator. I rather that an image viewing program be opened, maybe called with options to not display interface widgets, and to be displayed in a new window tab. I use i3 or Sway, so I already have macros that do just this, and I don't fail to appreciate that others have this luxury (or not).

Alternative branches, or even forks like this are a good thing. Sometimes these help reach new consensus and merge back into the original project making the new project stronger, provided the original reason for a fork wasn't really issues of conflicting personalities.

I think a fork of Helix can be a step in the right direction. But "view images inside the terminal" doesn't pass the smell test. The mindset of displaying images inside of a terminal window and the macOS window decorations in the example screenshots, those two things together are part and parcel.

nylonstrung

6 hours ago

They allude it at the end by talking about faster iteration but the real, legitimate reason to fork Helix is that it is essentially inactive at this point

The last release was in July 2025

abound

6 hours ago

Release frequency != project activity

The project has had hundreds of commits (incl major features) since that last release.

f311a

6 hours ago

Yeah, and these features are very needed. People have been asking for a new release for half a year. There haven't been a lot of changes in the past 8 months, majority of them are grammar and theme updates.

BTW, if you compile helix from the main branch, source code indentation will be broken.

jswelker

9 hours ago

Loved helix and batteries included philosophy but was wishing for more batteries. Specifically the lack of a good diff viewer. Yes I can create a shortcut to lazygit but the way swapping between processes worked was buggy and uncomfortable.

And even though abstractly I like helix's keyboard model better than vim, I wish there was a way to just switch to vim mode because it is too ingrained.

Maybe this fork can address some of this either directly or by allowing plugins.

weinzierl

8 hours ago

Similar for me. I understand the impetus to stick to only standard Language Server Protocol (LSP) features, but on the other hand support for what e.g. RustAnalyzer offers would be incredibly useful for me.

hmokiguess

9 hours ago

This looks nice, though I already use and like Helix. What is the motivation behind the fork?

OlivOnTech

9 hours ago

Helix has not seen any release in a while and PRs stack.

hmokiguess

9 hours ago

Oh interesting, I went to look more after you said that and noticed the lack of activity indeed, there's even a discussion about it: https://github.com/helix-editor/helix/discussions/16261

That said, fwiw, I haven't felt the need for anything on it and it feels "complete" to me as far as my daily use goes

Maintaining OSS is tough, do you know what the community has been wanting lately that it lacks? Maybe I'm an outlier user or I don't know what I don't know

setopt

9 hours ago

I don’t use Helix myself, but I’ve tried it before.

I believe I’ve heard many users requesting a plug-in system (there were some plans for Scheme?), and that the devs themselves considered many features as more appropriate for plugins than first-party support (code folding and non-LSP snippets, if I recall correctly?). I don’t know how Helix developed the last couple of years, but if features like that didn’t materialize yet, that sounds like sufficient impetus for a fork to me.

notnmeyer

8 hours ago

fwiw it’s incredibly easy to build from master

benrutter

9 hours ago

Yeah I wondered this too! The website explains the features, but from what I can tell it's just the feature set of Helix. I'm sure there's a plan behind what the forker wants to do with the project, would be awesome if the website explained!

fcoury

8 hours ago

I have been building a batteries-included vim-like editor for a couple of years. It all started as a series of streamings but I really like where it is right now.

https://youtu.be/eX1ZhXY0VZU?si=hUufOFS5ifTGeh-g

If you're looking for something like that I'd love if you could take it for a spin:

https://getred.dev

ddrdrck_

8 hours ago

I'm on my phone so I did not try it yet, but I find your use of red color way too agressive on the front page.

fcoury

8 hours ago

It bothers me too, I might make it a bit less aggressive. Thanks for taking the time!

safehuss

7 hours ago

This looks very cool - would be cool if could use our claude logins aswell as codex...

lekevicius

8 hours ago

It's a fascinating time to launch a new code editor. I haven't properly used one for months (except some small .env changes and the like). Even Zed seems to be moving away from the "editor" part, into Delta.

alberth

3 hours ago

Seems like 90% of helix community frustration would go away if it had a fixed released schedule (eg every 6-months).

This is a lesson for any maintainer. Previously, helix was releasing approx every 6-months. It was unofficial but that was the rough cadence.

Then they stopped. But still committing updates.

Communities get accustom to convention and when even unofficial convention changes, the community will get frustrated.

joefreeman

9 hours ago

I've been building my own personal editor, borrowing some of the features I enjoyed in Helix and other editors - https://github.com/joefreeman/aether - being able to deeply customise has been satisfying.

sixtyj

9 hours ago

Good to know. It looks nice. Any plans for Win version?

LoganDark

9 hours ago

Could try the Linux version in WSLg

sixtyj

8 hours ago

I will. Thanks.

integricho

8 hours ago

In the grim dark future, there is no longer need for a text editor

mrsssnake

5 hours ago

You mean humans stop using written text? No documentation, science papers, todos, longer form async communication, transcription, etc.?

msub2

10 hours ago

What does it do differently from Helix?

evanjrowley

10 hours ago

Commenting as an outsider to both projects, one possible motivation to fork Helix might be this PR:

https://github.com/helix-editor/helix/pull/8675

Helix was originally meant to be a "batteries included" editor without any scripting/plugins. That PR intends to change this and so there is a bit of controversy around it. Overall it looks like the PR will eventually be merged.

The Mitos fork could have be made for totally unrelated reasons. This is really just my speculation.

riedel

9 hours ago

From the commit history it rather looks like an ai agent speed run of a single guy frustrated about this not moving fast enough.

__m

2 hours ago

The most recent activity in that PR comes from mitos.

notnmeyer

8 hours ago

helix has a plugin system in the works, but unsure when it’ll actually land. lots of folks are already daily driving it, myself included.

srott

9 hours ago

Treesitter grammar for each language does not count as plugin? I think I had seen some dynamic libs when I tried to build it…

user

9 hours ago

[deleted]

Muhammad523

7 hours ago

The logo looks like Mixtral's, the name sounds like Anthropic's Mithos..

user-

8 hours ago

I understand its not cool to not be fluent in Vim, but all I want is a better version of `micro`. is it possible to setup Mitos like that?

sn0n

9 hours ago

Fuck it all, I went back to nano. > nano -lmx0 is good enough.

tomtom1337

8 hours ago

Thanks for sharing those options!

benrutter

9 hours ago

Really? What did you not like about Helix that you get from Nano? (No judgement, I'm just curious!)

I don't have anything against Nano, but for something I use every day, I'd really miss go-to-definition, and being able to jump between sections of text quickly.

rfgplk

9 hours ago

I don't even use an editor anymore. Just sed the source files directly via my agent.

incognito124

9 hours ago

I don't even sed anymore. I go directly to ed while characters stream out of an llm

sumnole

9 hours ago

I don't even read code anymore. I just have my agent deploy directly to production.

hmokiguess

9 hours ago

I don't even deploy anymore, I just proxy the user credit card directly to my API Key on someone else's provider

schrodinger

7 hours ago

Oh, you work at Anthropic?

Pardon the snark, but they literally wrote an article [1] about giving up on code reviews because they push 30k _changes_ (I assume that means commits, but they don’t clarify), and were bottlenecked on reviews.

Instead, they claim to just review the _intent_ of the PR and presume correctness will be caught by more AI.

To me, the more absurd part is that they’re pushing that much code.

To put it in perspective:

    Software     # Commits     Equiv. Time
    --—-----     ---------    -----------
    Nginx            8,758              7h
    uv              11,081              9h
    Vim             24,608             20h
    Go              67,914            2.3d
    Git             82,513            2.8d
    VS Code        168,140            5.6d
    Emacs          183,611            6.1d
    Rust           343,063           11.4d
* Equiv time equals the amount of time it would take Anthropic to push that many commits, given their 30k changes/day estimate provided in the article linked below.

It generated some interesting discussions here on hacker news [2] [3].

1: https://www.anthropic.com/engineering/redesigning-source-con...

2: https://news.ycombinator.com/item?id=50073633

3: https://news.ycombinator.com/item?id=50118863

FYI: The last is a blog post at simonwilliamson.net about the source post, which was flagged appropriately, but I left since it had a few dozen comments as well.

stephbook

9 hours ago

I don't even have a prod environment anymore. I route any incoming traffic directly to my LLM on Openrouter and let it answer.

ejpir

9 hours ago

This is the way!

notnmeyer

8 hours ago

last time i looked at it i couldn’t figure out what the difference was or why anyone would choose this over helix.

bbor

8 hours ago

Ok I'd like to bring up something a bit more bold/controversial: why are we building big TUIs at all? Like... ever? Isn't it pretty trivial to make your rust GUI native across the three major operating systems these days, or am I underestimating that?

I prefer a TUI to a heavy Electron app, don't get me wrong. But Helix (& Mitos!) seem like a baffling choice compared to Sublime Text. Not worse: I literally don't understand the appeal.

__m

2 hours ago

It’s just more convenient to stay in the terminal where I already do a lot of other things. Switching between guis is more of a hassle, since they try to support both keyboard and mouse but often not equally well

saghm

7 hours ago

I think you're underestimating this. I released a GUI app in Rust earlier this year, and I already feel like it was a headache because there was pretty much no way to avoid dynamically linking a bunch of stuff, at which point any confidence of it working across various distros went out the window, so I had to settle for an AppImage as the only binary that I distributed. I wasn't even trying to target Windows or MacOS but I have to assume that would complicate things at least as much.

I'm not saying it's insurmountable, but I don't think it's accurate to call it "trivial". There are comments on this thread mentioning that Helix hasn't released in a while but that it's relatively straightforward to build from source; I'm not confident that would be easy to preserve for a full GUI.

redrobein

7 hours ago

It's a lot easier to write and customize tuis. And it works over ssh. The appeal is probably that it's good, performant, functioning software. As a counterpoint what's the appeal of sublime over vim? What is the gui providing that I don't already have?

schrodinger

8 hours ago

How would you do it? Honestly curious?

If I were to build an editor, I’d want the GUI platform-native so would probably go straight for Xcode and Swift.

If I had a strong aversion to Swift, I might consider a hybrid design where the UI is Swift and write a backend in a modern, fast language I prefer (Go/Rust/C# come to mind, but this isn’t a call-to-arms in the language wars). I believe this could be achieved since LSP works well as a backend server supplying IDE-level niceties, so I could keep most functionality implementations there. I’d have to have a strong reason though since Swift is a fine language, and AI does much of the writing now.

Then again, most devs live on a Mac and deploy to Linux, and are increasingly using Agents which may be better off cloud-hosted or at least sandboxed, so lightweight Swift UI and most logic in a headless cli app could be an interesting design choice.

But the important part to me would be low-bloat and native UI, and I’ve never found cross-platform UI frameworks to hold up in practice — even if only because different OSes necessarily have different ideas of idiomatic design, so you’d either be using least common denominator UI components that feel uncanny, or reimplementing the UI for each platform.

Have you found a language / framework combo that’s fast, fits into the OS well, and is _fun_ to write and use? Or is your idea that separate implementations are now so low cost — who cares — let the AI maintain them?

Legitimately asking in good faith, so please don’t interpret anything as snippy in there — it’s just my understanding of the state of the world. I’d genuinely love to learn about how cross-platform options have expanded if I’m missing something!

saghm

7 hours ago

> lightweight Swift UI and most logic in a headless cli app could be an interesting design choice

With absolutely no hard data to back this claim, my instinct is that a library would be even better. Anything you can manage to fit into a library can be much more easily tested, and then you can define whatever frontends you want (CLI, SwiftUI, etc.) that wrap it, and even leave the door open for people to implement whatever UI they might want.

schrodinger

3 hours ago

Depends on the split. You’re probably right — even after worrying about cross-language ABI stuff, compiled libraries would have many advantages.

But especially with Agentic AI, I could imagine some scenarios where being able to run the guts of your editor out of process, e.g. on a cloud box or even a local docker container, being pretty advantageous.

This is how Claude Code GUI works but to be fair that’s less of an editor.

vc14

8 hours ago

[flagged]