Txt: A fast, keyboard-driven terminal text editor for engineers
txt.hellman.io
txt.hellman.io
And for the use case of "I built txt because I spend most of my time in the terminal, and switching to a different tool just to make a quick edit always felt like friction I did not want. The editors that live in the terminal either have steep learning curves built around modal paradigms, or they are too limited to be genuinely useful."
it's literally only a handful of vim commands and shortcuts you need.
We should be introducing people to vim long before they are learning it under pressure. As you say, it's really not a lot to remember.
That sounds like an amazing investment, really makes me want to learn it too!
Instead of "verb object" (eg. delete word or "dw"), it is "object verb" (eg. word delete, or "wd").
In particular, it seems to obsolete "visual mode" from vim (which I use often), because you're essentially always in visual mode. You always get to see a selection before you perform an action. Or at least that's what I understand, I haven't tried it yet.
^1: kakoune doesn't have multi character shortcuts. You create a "mode" which works basically like a namespace for keystrokes (https://igor-ramazanov.github.io/doc/pages/modes.html).
> txt is not trying to replace your main IDE. It is the editor you reach for when you just need to edit something
These two are in conflict. If you just want to edit something, and don’t know [n]vi[m] or emacs, then use nano. If you want line numbers, code folding, syntax highlighting, etc. then it sounds like you should spend the time to learn a more powerful editor.
Honestly, vi isn’t that hard to learn the absolute basics, and you should spend the 15 minutes to do so, because it’s practically guaranteed to be available everywhere. :wq and i are about all you need to “just edit something.”
I get why people prefer not to use it actively - everyone has their own preference, but choosing to not to know it, at all? Knowing basics of vim for a programmer is like understanding basics of git. It is a must.
What I would ask is this: why should I use your software when I could generate my own?
For a relatively low cost in tokens, I could use Cursor & Fable 5.1 to generate a decent text editor of my own, if I constrained it to use high quality dependencies
So this is kind of the real quandary of OSS development: is there really any point creating tools for developers any more?
Also keep in mind that it is software which requires a little bit maintenance from time to time. And access to LLM (mostly paid) and (or - depends on if we want to understand something) domain knowledge (in this case how to build editor, how to do parsing etc.).
However if somebody wants to do custom things then let him/her do it. And yeah first editor, then programming language, then... OS and so on.
With the amount of new seemingly well polished personal projects being built (thanks to the help of LLMs) I feel increasingly concerned by how easy it is becoming to get a worm/virus/troyan to a lot of people.
- it would be absolutely amazing if one of the guys writing posts along the lines "here is our super duper text editor"...
- would actually explain in a series of blog posts how they built a text editor from scratch and I am not talking about code...
- I am talking about architecture, methodology, how each feature is implemented on paper before coding it, thought process behind one..
- I am amazed that we live in a world where people create all types of software and yet little to no blog posts ever discuss the thought process and methodology behind them...
- like why did you do this...
- why is this feature implemented in this way and what are the alternative implementations and why did you pick this implementation over the others
You don't need to reach for the mouse, are you not aware you can launch, switch apps, and type just with your keyboard?
But also, how is your demo using a mouse of your whole selling point is anti-mouse?
So, I ain't reading all of that.
It's what I'd hope a well-written readme should look like, I think.
While vim and emacs have their advantages which I don't want to discuss here, they are also the "big players" with their own philosophy, shortcuts and commands. Which is a hassle to learn when you're used to GUI editors.
Why not let a little space for users who don't want to re-learn how to edit a file ?
Emacs's closest competitor for such orchestration is not an editor. It is shell plus tmux plus fzf plus CLI tooling, and now agent harnesses. Those orchestrate fine, but they have no shared runtime and no shared language and the entire model feels clunky.
There's nothing analogous to Emacs that exists today, with the exception of maybe Lem, but this one doesn't have a comparable ecosystem of packages and the community [yet]. And nobody knows if it ever will. Even though it has real threads, the CL condition system, Quicklisp, and sane compilation - none of that helps against forty years of accumulation plus the network effect.
When the machine occupies the entire cycle of SDLC, why should living, breathing people bother to be the consumers, if there's no proof of human involvement? What if the entire "product" got generated within a loop that started from a tweet. Which was posted by a bot.