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.
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.
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.
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!
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
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.
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.
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.
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.
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.
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.
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
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.
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.
This looks nice, though I already use and like Helix. What is the motivation behind the fork?
I found this post on reddit
https://www.reddit.com/r/HelixEditor/comments/1wpt22a/mitos_...
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!
Helix has not seen any release in a while and PRs stack.
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
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.
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.
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.
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.
Good to know. It looks nice. Any plans for Win version?
Could run the Linux version in WSLg
What does it do differently from Helix?
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.
From the commit history it rather looks like an ai agent speed run of a single guy frustrated about this not moving fast enough.
Treesitter grammar for each language does not count as plugin? I think I had seen some dynamic libs when I tried to build it…
Fuck it all, I went back to nano. > nano -lmx0 is good enough.
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.
I don't even use an editor anymore. Just sed the source files directly via my agent.
I don't even sed anymore. I go directly to ed while characters stream out of an llm
I don't even read code anymore. I just have my agent deploy directly to production.
I don't even have a prod environment anymore. I route any incoming traffic directly to my LLM on Openrouter and let it answer.
I don't even deploy anymore, I just proxy the user credit card directly to my API Key on someone else's provider
This is the way!