Since going through the hassle of learning vim I can't use anything else anymore.
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.
Vim is great and I have 25 years of muscle memory for it. But I'm also interested in trying Kakoune (https://kakoune.org/why-kakoune/why-kakoune.html) -- which I understand also has a VSCode plugin called Dance (https://github.com/71/dance) -- as I've seen somewhat convincing arguments that it is a more powerful model for modal editing.
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.
I've been using kakoune for the past 2-3 years and it has been great. My main reason for switching from vim was the adherence to the Unix philosophy, but the editing model has been great. Seeing your selections change after each command + the clippy help text when entering a different "mode"^1 has made learning different editing patterns very easy. The only thing I really miss from vim is the number increment/decrement shortcut. There is a plugin for it, but I haven't tried it out yet (incrementing each selection by a different amount hasn't come up often enough for me).
vim is not a single concrete editor - it's rather an abstract idea, and ideas do port (if done properly). But some substrates have poor foundation for porting, some have much more flexible base. Every vim plugin for major editors - VSCode, IntelliJ, Sublime, etc. have tons of deficiencies, partly because the platform itself might be prohibiting. In comparison, evil-mode in Emacs is absolutely great, in some cases it is even better than what Vim/Neovim have natively. And that's because of flexibility and malleability of the host platform.
Came here to write exactly about those 2 editors which IMO are the best without a hassle to re-learn the shortcuts like ctrl-f to find, ctrl-s to save, ctrl-z to undo,...
Less known, there is also tilde : https://github.com/gphalkes/tilde
I can understand startups relying on AI tools to test out the ideas. But personal/hobby projects? Feels weird. This is not the place to go fast. Take your time, enjoy the process, learn/make things.
> 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.
> 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 honestly don't get software engineers who don't know basic vim motions and don't even care to learn them. Seriously? They plan never to use `less` and `more`, they won't be reading manpages, they are okay with not knowing what `sed` can do?
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.
I'm not going to criticise you for using Claude to build this. Honestly, for me as a consumer, it is a neutral thing provided the software is high quality
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?
I think yes because there are people who prefer picking up something rather than building their tool. Recreating just everything from scratch or make custom solutions are not the one way to go. I do not want to create editor/IDE because it is not in my interests. I choose VS Code, Kate, Notepad++, Nano instead. If I have paid LLMs I will use them different way than reinventing editor lol.
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.
I live in emacs over ssh connections. I never use the GUI, just TUI version (so `emacs -nw`) and love it. You can edit files over ssh hops or docker hops using tramp. I don't believe there is a tramp equiv. in other terminal tools. VS Code over SSH is much too heavy handed for quick single file edits but emacs handles it gracefully.
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.
Yes and how we here on HN have a front row seat for these brand new repos (no shade on OPs project)
Hold on to your crypto/fiat credentials ladies and gents! I bet the anti virus labs are having a hoot in this LLM enhanced craze.
And how is this different from downloading a file from a GitHub releases page? Or even installing from FlatHub with full fs perms (which would make sense for a text editor)?
- 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
The linked post is not that long. The readme in the linked project happens to be longer, but it's clearly because the author put tables of keymap bindings in the readme.
It's what I'd hope a well-written readme should look like, I think.
A comparison with editors like micro https://github.com/micro-editor/micro or fresh https://github.com/sinelaw/fresh (discussed in the comments) would make more sense than one with vim and emacs. The shortcuts are CUA based. And to me these editors feel more like using GUI editor like sublime text for example. And that's nice.
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 is not an editor, it's a text-based orchestrator - a live Lisp image that happens to ship an editor, where every function is introspectable, redefinable at runtime, and written in the same language. Any external tool becomes something you can wrap into one uniform interaction model - Emacs can control just about anything text-related in its computation vicinity and remote computers.
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.
I miss the days when people would release software not touched by AI. And I wish at least there'd be a disclaimer saying that this was AI-assisted, so I could avoid it.
I'm not opposed to the use of AI in programming but sometimes it seems like there's a direct relationship between the amount of thought and understanding that went into a project and the reliance the coders had on AI to build the thing.
Yes, we need transparency. And it needs to be brutal. We need a new conventional, agreed and respected model for all OSS contributions. Any creator of anything shared publicly must adhere to agreed standards - they should explain the vision, design and their thinking in the "human-readable", simple, digestible form.
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.
When the creator has spent a day to create it, chances are that they are going to abandon it just as fast. Why spend time to learn something like that?
Since going through the hassle of learning vim I can't use anything else anymore.
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.
It's a shame that it ever felt like a hassle.
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.
Vim is great and I have 25 years of muscle memory for it. But I'm also interested in trying Kakoune (https://kakoune.org/why-kakoune/why-kakoune.html) -- which I understand also has a VSCode plugin called Dance (https://github.com/71/dance) -- as I've seen somewhat convincing arguments that it is a more powerful model for modal editing.
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.
I've been using kakoune for the past 2-3 years and it has been great. My main reason for switching from vim was the adherence to the Unix philosophy, but the editing model has been great. Seeing your selections change after each command + the clippy help text when entering a different "mode"^1 has made learning different editing patterns very easy. The only thing I really miss from vim is the number increment/decrement shortcut. There is a plugin for it, but I haven't tried it out yet (incrementing each selection by a different amount hasn't come up often enough for me).
^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).
vim is not a single concrete editor - it's rather an abstract idea, and ideas do port (if done properly). But some substrates have poor foundation for porting, some have much more flexible base. Every vim plugin for major editors - VSCode, IntelliJ, Sublime, etc. have tons of deficiencies, partly because the platform itself might be prohibiting. In comparison, evil-mode in Emacs is absolutely great, in some cases it is even better than what Vim/Neovim have natively. And that's because of flexibility and malleability of the host platform.
> Since going through the hassle of learning vim I can't use anything else anymore.
That sounds like an amazing investment, really makes me want to learn it too!
While they play up the keyboard-driven functionality, they showcase a pointer-driven workflow in the demonstration gif. Curious choice, no?
I came here to say this.
Me too.
Since https://github.com/micro-editor/MICRO exists for some years now, a comparison would be welcome.
Also https://github.com/sinelaw/fresh which is micro "on steroids" (i dislike the expression but can't think of a better one now)
Came here to write exactly about those 2 editors which IMO are the best without a hassle to re-learn the shortcuts like ctrl-f to find, ctrl-s to save, ctrl-z to undo,... Less known, there is also tilde : https://github.com/gphalkes/tilde
“turbo charged”
I can understand startups relying on AI tools to test out the ideas. But personal/hobby projects? Feels weird. This is not the place to go fast. Take your time, enjoy the process, learn/make things.
> 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.
> 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 honestly don't get software engineers who don't know basic vim motions and don't even care to learn them. Seriously? They plan never to use `less` and `more`, they won't be reading manpages, they are okay with not knowing what `sed` can do?
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.
I'm not going to criticise you for using Claude to build this. Honestly, for me as a consumer, it is a neutral thing provided the software is high quality
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?
I think yes because there are people who prefer picking up something rather than building their tool. Recreating just everything from scratch or make custom solutions are not the one way to go. I do not want to create editor/IDE because it is not in my interests. I choose VS Code, Kate, Notepad++, Nano instead. If I have paid LLMs I will use them different way than reinventing editor lol.
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.
I live in emacs over ssh connections. I never use the GUI, just TUI version (so `emacs -nw`) and love it. You can edit files over ssh hops or docker hops using tramp. I don't believe there is a tramp equiv. in other terminal tools. VS Code over SSH is much too heavy handed for quick single file edits but emacs handles it gracefully.
> curl -fsSL https://raw.githubusercontent.com/ErikHellman/txt/main/insta... | sh
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.
Yes and how we here on HN have a front row seat for these brand new repos (no shade on OPs project) Hold on to your crypto/fiat credentials ladies and gents! I bet the anti virus labs are having a hoot in this LLM enhanced craze.
And how is this different from downloading a file from a GitHub releases page? Or even installing from FlatHub with full fs perms (which would make sense for a text editor)?
This is gonna be a hard name to google :)
FYI: Claude has committed to the repo.
- one of these days...
- 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
> GUI editors are the opposite problem — they are powerful, but reaching for the mouse to edit a config file or fix a typo breaks your flow.
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?
I can tell a README which is a long as that is not written by the author, but of course by Claude.
So, I ain't reading all of that.
The linked post is not that long. The readme in the linked project happens to be longer, but it's clearly because the author put tables of keymap bindings in the readme.
It's what I'd hope a well-written readme should look like, I think.
A comparison with emacs and vim would be nice.
A comparison with editors like micro https://github.com/micro-editor/micro or fresh https://github.com/sinelaw/fresh (discussed in the comments) would make more sense than one with vim and emacs. The shortcuts are CUA based. And to me these editors feel more like using GUI editor like sublime text for example. And that's nice.
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 is not an editor, it's a text-based orchestrator - a live Lisp image that happens to ship an editor, where every function is introspectable, redefinable at runtime, and written in the same language. Any external tool becomes something you can wrap into one uniform interaction model - Emacs can control just about anything text-related in its computation vicinity and remote computers.
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.
reminds me of https://zed.dev/ ?
Is this even still under development? Last non-renovate commit was early June
Why is it better from Fresh or micro?
I miss the days when people would release software not touched by AI. And I wish at least there'd be a disclaimer saying that this was AI-assisted, so I could avoid it.
Why avoid them ?
I'm not opposed to the use of AI in programming but sometimes it seems like there's a direct relationship between the amount of thought and understanding that went into a project and the reliance the coders had on AI to build the thing.
Yes, we need transparency. And it needs to be brutal. We need a new conventional, agreed and respected model for all OSS contributions. Any creator of anything shared publicly must adhere to agreed standards - they should explain the vision, design and their thinking in the "human-readable", simple, digestible form.
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.
When the creator has spent a day to create it, chances are that they are going to abandon it just as fast. Why spend time to learn something like that?