One of the best kept secret and one that he should have tried is "Kate".
Good old style editor that is a native app, not an electron app. All the features that you might want and more, but simple and efficient.
And the most important for me, super snappy. I can't bear the latency that you get for typing code when using things like vscode. I don't know how people can appreciate that.
dhruvmittal 9 minutes ago [-]
I'm a big Kate fan as well, used it for years on all my Linux systems. Recently I got a little fed up with vscode lagging on large files, I bit the bullet and installed Kate on my windows 11 work PC as well.
jakkos 2 hours ago [-]
Every piece of KDE software I've tried has been buggy to the point that it's now a red flag to me: Spectacle (silently failed to copy/paste), krunner (refused to close), SDDM (refused to login), Dolphin (ffmpegthumbnailer loops lagged out whole system, SMB bugs), System Monitor (wrong information), KWallet (signal fails to open, data loss)
Imustaskforhelp 19 minutes ago [-]
I am sure that people who use KDE can politely respond to your critique but I can say this that I used to use Kate for sometime and its really great.
Fun fact but Asahi Linux creator uses kate :)
dizhn 2 hours ago [-]
I used Kate a note taking app synced with syncthing for a while. Using only md files. I had another md based app on Android that worked similarly.
Kate has a decent file browser for hierarchy and it'll stay in place and not return to a weird default path when you close it. And as you said, very fast to open and use.
For one off Notepad like things I like Mousepad especially because it has the Notepad++ feature of being able to save a session without asking you whether it should. Featherpad is also nice for this kind of use.
hresvelgr 4 hours ago [-]
I'm quite partial to Zed. Very snappy, and you can turn off all the AI features globally if you like.
lionkor 2 hours ago [-]
Zed is fantastic for Rust, C, C++, and similar languages.
I wouldn't bother using it for Web things like HTML, Js, CSS, because it simply isn't better at that than VSCode. Same goes for C# -- as a Microslop technology, you're better off using Microslop tooling.
3 hours ago [-]
anta40 3 hours ago [-]
Yes, I'm happy with Zed a Sublime replacement, usually for general text-editing.
For coding, I'm still stuck with VSCode and nvim.
roelschroeven 3 hours ago [-]
I know this is just one data point, but I don't notice any latency when typing code in VS Code. It takes a while to start up, and that is annoying especially for quick short editing jobs, but other than that I never notice any sluggishness. Is this something many people experience?
Octoth0rpe 52 minutes ago [-]
Project size is obviously going to be a factor, but so is machine specs. It's much more noticeable on a spinning disk. One can partially compensate for the project size aspect by opening vscode as far into your project as possible (eg, the api subfolder) rather than at the root. No real solution if you don't have an ssd though.
Imustaskforhelp 18 minutes ago [-]
Kate is great but as others have said. Zed is great too. My combination of text editors is probably zed when I need Gui and Micro editor when I need terminal. Both have great user experience
catapart 33 minutes ago [-]
Any chance people in this thread have some recommendations for text-editing libraries? I would love to build my own text editor, to do some things in my own way that no one else seems to have an interest in doing, but one of the big things for me is that it must be a GUI. I won't bore people with the reasons, but that requirement forces me to bring along a lot of stuff, like a font renderer (at least one) and a graphics context.
To do all of that and write a text editing library at the same time is a little more than my nights and weekends can handle. If I start on just the text editor, it'll only work in a terminal console, so I won't actually use it for my own projects. If I start on just the GUI, I won't actually use it because it won't actually work. So, even if I'm going to replace the text editing library at the heart of the project with custom code, eventually, it's pretty much a non-starter if I don't have something to use to get started.
To be honest, I'm kind of surprised to have so much trouble finding a solution here. Everything I find is either a self-contained text editor, or a full-on "mission statement" GUI (development can be easier/better by using our editor's features). I've had a very hard time finding something that is just an API that I can feed input and have it return me reasonable state updates about the text content. CRDTs or whatever.
I'm assuming people just figure you're either going to write a toy text editor, in which case simple text editing will work, or you're going to write a full-blown showcase product, in which case your advanced structural design with performance-focused editing, language servers, multi-cursor support, etc, will be your selling point and functional focus. But that seems to leave this surprising hole where a developer who wanted to "rebuild windows' Notepad app, except that it can handle text files with massive lines without slowing way down" would have to actually implement the advanced text editing line management rather than just use a library for this well-solved problem.
kryptiskt 17 minutes ago [-]
Several of the lean GUI text editors are built on Scintilla (https://scintilla.org/), which provides a cross-platform editing component that can be integrated in GTK, Windows or Mac GUI apps. Maybe that has too much bells and whistles for you, since it's both about editing and presentation.
It's so fascinating how different things people look for in such a simple thing as a text editor. A file browser? Terminal?
embedding-shape 2 hours ago [-]
Indeed, all I need is something that connect to a running background repl so I can evaluate code, everything else basically bells and whistles. Others seem to run entire OSes as their editor.
I'm glad we have so many options, and it seems like each year we have even more options :)
whynotmaybe 9 hours ago [-]
Fond memory of when I wrote an editor in the 90's because we didn't want to use "ms edit" for COBOL and asm files.
Syntax coloring, fast buffering and even a screen saver.
You could even call the compiler directly from it.
All this running on a pentium 120 and it felt a thousands times faster than today's vscode.
But vscode can edit multiple files at the same time...
nickjj 35 minutes ago [-]
Yes, I remember writing a VB6 driven editor. I was so happy when I got find and replace to work.
I still have the marketing page copy from 2002:
<UL>
<LI>Unlimited fully customizable template files</LI>
<LI>Fully customizable syntax highlighting</LI>
<LI>Very customizable user interface</LI>
<LI>Color coded printing (optional)</LI>
<LI>Column selection abilities</LI>
<LI>Find / Replace by regular expressions</LI>
<LI>Block indent / outdent</LI>
<LI>Convert normal text to Ascii, Hex, and Binary</LI>
<LI>Repeat a string n amount of times</LI>
<LI>Windows Explorer-like file view (docked window)</LI>
<LI>Unlimited file history</LI>
<LI>Favorite groups and files</LI>
<LI>Unlimited private clipboard for each open document</LI>
<LI>Associate file types to be opened with this editor</LI>
<LI>Split the view of a document up to 4 ways</LI>
<LI>Code Complete (ie. IntelliSense)</LI>
<LI>Windows XP theme support</LI>
</UL>
Back then we used uppercase HTML tags.
fragmede 7 hours ago [-]
Firing up VSCode on an old laptop, and having it get totally bogged down running a text editor killed a part of my soul. I'm from the vim era of computing, but I have a hard time telling people that's the route to go today with today's tools.
b00ty4breakfast 6 hours ago [-]
Classic electron app. vscode is no doubt a powerful tool but it and other apps in the modern milieu are the software equivalent of those big lifted trucks that like to "roll coal" and get like 5mpg highway.
nurettin 3 hours ago [-]
> But vscode can edit multiple files at the same time
borland turbo pascal and turbo c could also open multiple files at the same time.
bananaboy 8 hours ago [-]
I love this! The line “resist the urge to push the difficult bits off to a box of statistics” particularly resonated with me!
priowise 5 hours ago [-]
Building your own editor seems to be one of those projects that teaches you far more about software design than using any existing one.
Did anything in your approach change how you think about everyday tooling?
zesterer 2 hours ago [-]
Author here. Off the top of my head:
- Software is simpler than you think when you boil it down. There's a massive incentive to over-sell the complexity of the problem a solution is trying to solve, to pull in users. This is true both for proprietary products and, to a lesser degree, FOSS. You can probably replace most of the tools you use day-to-day in a weekend or two - provided you keep practising the art of just building stuff. I'm not saying that you should, but it's worth keeping in the back of your head if a tool is driving you mad.
- You can achieve 80% of the functionality with 20% of the work required to build an off-the-shelf solution. In a surprising number of cases, you can do the same with 20% of the integration cost of an off-the-shelf solution. A lot of software is - to put it quite bluntly - shit (I include a lot of my own libraries in this list!). There are probably only a few hundred really valuable reusable software components out there.
- Aggressively chase simplicity and avoid modularity if you want to actually achieve anything. The absolute best way to never get anything useful out of a project is to start off by splitting it into a dozen components/crates/repositories. You will waste 75% of your time babysitting the interfaces between the components rather than making the thing work.
- Delete code, often. If you look at the repo activity (https://git.jsbarretto.com/zesterer/zte/activity/code-freque...) you'll see that I'm deleting code almost as much as I'm adding it, especially now that I've got the core nailed down. This is not wasted effort: your first whack at solving a problem is usually filled with blunders so favour throwaway code that's small enough to keep in your head when the time comes to bin it and make it better.
- It is absolutely critical that you understand the fundamental mode of operation of the code you've already written if you want to maintain development velocity. As Peter Naur said, programming is theory-building and the most important aspect of a program is the ineffable model of it you hold in your head. Every other effort must be in deference to maintaining the mental model.
alansaber 2 hours ago [-]
Couldn't agree more with this. Particularly re simplicity and deleting depricatsd code.
mllev15 9 hours ago [-]
Josh Barretto is the genius behind the Super Mario 64 GBA port. I would gladly use his editor.
This feels like two steps up from a highly customized vim config. But I want one step up.
I want to be able to piece together an editor from modular task specific executables. Different programs for file searching, input mapping, buffer modification and display, etc.
Probably similar to how LSPs are already separated from most editors.
One step less hardcore than writing a whole editor.
Anyone know of any existing projects along these lines?
kalterdev 9 hours ago [-]
Acme [1]
It steps back from the “customize everything” mantra, believing that approach leaves users with an underdeveloped essential system. But it still has two major APIs: one for window manipulation [2], the other for text-based integration with the surrounding system via plumber [3].
All textual CLI tools (that is, those without pseudographics) work by default and are the heart of its style.
I use Acme for everything except web browsing (although most links are still managed by Acme).
You can already do this in vim. Pretty easy to shell out to whatever command you want and use the result for various purposes.
codazoda 10 hours ago [-]
I use my own text editor too. Nobody else seems to get value from it. I’m still surprised by the value we get from home grown solutions.
marckerbiquet 5 hours ago [-]
I use my own text editor too, written using my own programming language. Fortunately Operating Systems suit my needs and I won't have to write my own OS ;-)
fjfaase 5 hours ago [-]
I use my own editor too. I modified an existing editor to my own needs. But I do use VSC as well for multi file projects. My editor can load images as well and has a scripting language to manipulate images. I primarily use it to edit my website, which is a static website in bare HTML. It also has some 'browser' functions in the sense that F5 opens a link including jumping to an anker if there is one in the link. It does have colour coding for HTML that also checks for matching tags.
willrshansen 9 hours ago [-]
Didn't even link it. :(
mbrezu 7 hours ago [-]
I guess the "link" is the implicit suggestion to write your own :-)
altilunium 9 hours ago [-]
I use my own text editor too.
Sometimes I get surprise questions from my friends whenever they see my screen. “What’s that?” “That’s my own text editor!”
hnlmorg 6 hours ago [-]
I’m currently writing my own text editor (it’s basically a markdown equivalent of Jupyter notebooks).
I’ve also written my own terminal emulator and my own shell. The shell does actually see other contributors and users these days too.
lenkite 4 hours ago [-]
You can perform a legitimate muscle-flex when saying that too.
kleiba 4 hours ago [-]
There's a reason Emacs and vi have been around for decades. They're good.
osmsucks 5 hours ago [-]
I, too, mourn the death of Howl. It was a quirky yet surprisingly "comfortable" editor.
But I am now at home with Helix and Flow Control.
alansaber 2 hours ago [-]
Would like to see someone make their own WYSIWYG editor.
3 hours ago [-]
mudkipdev 9 hours ago [-]
I would recommend using the ropey crate for easy performance gains. A string buffer is quick to implement but you will hit a wall as soon as you need to edit large files.
zesterer 2 hours ago [-]
Unmentioned in the post, but I have since switched to a third-party rope library (crop, not ropey). At some point I'd like to implement one myself, but for now this does the job.
mizmar 7 hours ago [-]
It's not that bad. You need really large files to notice.
The largest realistic file I'll ever touch - sqlite3 amalgamation with 270k lines and 9.1 kB - still takes only 6 ms to memmove it on my poor laptop.
Any regular up-to 10k lines file is memmoved in order of microseconds.
zesterer 2 hours ago [-]
Yes, absolutely. I've since switched to rope-backed buffers, but I don't think the rope itself is actually adding much from a performance standpoint, even for really very large files.
We talk about big-O complexity a lot when talking about things like this, but modern machines are scarily good at copying around enormous linear buffers of data. Shifting even hundreds of megabytes of text might not even be visible in your benchmark profiling, if done right.
When benchmarking, I discovered that the `to_pos`/`to_coord` functions, which translate between buffer byte positions and screen coordinates, were by far the heaviest operation. I could have solved that problem entirely simply by maintaining a list of line offsets and binary-searching through it.
sampullman 7 hours ago [-]
That's true for code editing, but it's nice to not have to reach for a different solution when editing huge files. Sometimes I like to open up big log files, JSON test data, etc.
mejutoco 4 hours ago [-]
I am always surprised even vim chokes on files with one massive line. That could be a useful optimization too.
oneeyedpigeon 5 hours ago [-]
Do you actually edit big log files?
piker 4 hours ago [-]
> Cursor manipulation is difficult! When you’re using a text input widget, much of the behaviour you expect as table-stakes isn’t something you’re even conscious of. Exactly what happens when you hold a keybinding like ctrl + shift + left is probably muscle memory but the logic required to getting it all playing together nicely is not fun to write.
This is so true. And there are a lot of other cases where we just expect the OS or library to do it for us. Instead, we have to reimplement the wheel. Of course if understanding the wheel is part of the goal, then that works, but if you’re venture-backed good luck justifying the use of time to your investors. This is why Electron’s gravity is so strong.
zesterer 2 hours ago [-]
That is certainly true! If your target is end users, use the off the shelf solution that has been inspected by many eyeballs. The best part of building tools for yourself or a small community of people is that you only need to cover the relatively tiny subset of functionality that you actually use.
abktowa 9 hours ago [-]
Should make my own text editor. Would make for an interesting project at least.
croisillon 6 hours ago [-]
on iPhone Safari i don't get the grey middle background layer, only dark text on dark background
zesterer 2 hours ago [-]
That's odd, I've not heard that reported by anybody else. If I get time I'll look into it.
zacklee-aud 9 hours ago [-]
[dead]
genie3io 5 hours ago [-]
[dead]
shablulman 10 hours ago [-]
[dead]
fay_ 6 hours ago [-]
[dead]
givemeethekeys 7 hours ago [-]
I smell money burning.
Rendered at 13:40:27 GMT+0000 (Coordinated Universal Time) with Vercel.
Good old style editor that is a native app, not an electron app. All the features that you might want and more, but simple and efficient.
And the most important for me, super snappy. I can't bear the latency that you get for typing code when using things like vscode. I don't know how people can appreciate that.
Fun fact but Asahi Linux creator uses kate :)
Kate has a decent file browser for hierarchy and it'll stay in place and not return to a weird default path when you close it. And as you said, very fast to open and use.
For one off Notepad like things I like Mousepad especially because it has the Notepad++ feature of being able to save a session without asking you whether it should. Featherpad is also nice for this kind of use.
I wouldn't bother using it for Web things like HTML, Js, CSS, because it simply isn't better at that than VSCode. Same goes for C# -- as a Microslop technology, you're better off using Microslop tooling.
For coding, I'm still stuck with VSCode and nvim.
To do all of that and write a text editing library at the same time is a little more than my nights and weekends can handle. If I start on just the text editor, it'll only work in a terminal console, so I won't actually use it for my own projects. If I start on just the GUI, I won't actually use it because it won't actually work. So, even if I'm going to replace the text editing library at the heart of the project with custom code, eventually, it's pretty much a non-starter if I don't have something to use to get started.
To be honest, I'm kind of surprised to have so much trouble finding a solution here. Everything I find is either a self-contained text editor, or a full-on "mission statement" GUI (development can be easier/better by using our editor's features). I've had a very hard time finding something that is just an API that I can feed input and have it return me reasonable state updates about the text content. CRDTs or whatever.
I'm assuming people just figure you're either going to write a toy text editor, in which case simple text editing will work, or you're going to write a full-blown showcase product, in which case your advanced structural design with performance-focused editing, language servers, multi-cursor support, etc, will be your selling point and functional focus. But that seems to leave this surprising hole where a developer who wanted to "rebuild windows' Notepad app, except that it can handle text files with massive lines without slowing way down" would have to actually implement the advanced text editing line management rather than just use a library for this well-solved problem.
https://git.jsbarretto.com/zesterer/zte
I'm glad we have so many options, and it seems like each year we have even more options :)
Syntax coloring, fast buffering and even a screen saver.
You could even call the compiler directly from it.
All this running on a pentium 120 and it felt a thousands times faster than today's vscode.
But vscode can edit multiple files at the same time...
I still have the marketing page copy from 2002:
Back then we used uppercase HTML tags.borland turbo pascal and turbo c could also open multiple files at the same time.
Did anything in your approach change how you think about everyday tooling?
- Software is simpler than you think when you boil it down. There's a massive incentive to over-sell the complexity of the problem a solution is trying to solve, to pull in users. This is true both for proprietary products and, to a lesser degree, FOSS. You can probably replace most of the tools you use day-to-day in a weekend or two - provided you keep practising the art of just building stuff. I'm not saying that you should, but it's worth keeping in the back of your head if a tool is driving you mad.
- You can achieve 80% of the functionality with 20% of the work required to build an off-the-shelf solution. In a surprising number of cases, you can do the same with 20% of the integration cost of an off-the-shelf solution. A lot of software is - to put it quite bluntly - shit (I include a lot of my own libraries in this list!). There are probably only a few hundred really valuable reusable software components out there.
- Aggressively chase simplicity and avoid modularity if you want to actually achieve anything. The absolute best way to never get anything useful out of a project is to start off by splitting it into a dozen components/crates/repositories. You will waste 75% of your time babysitting the interfaces between the components rather than making the thing work.
- Delete code, often. If you look at the repo activity (https://git.jsbarretto.com/zesterer/zte/activity/code-freque...) you'll see that I'm deleting code almost as much as I'm adding it, especially now that I've got the core nailed down. This is not wasted effort: your first whack at solving a problem is usually filled with blunders so favour throwaway code that's small enough to keep in your head when the time comes to bin it and make it better.
- It is absolutely critical that you understand the fundamental mode of operation of the code you've already written if you want to maintain development velocity. As Peter Naur said, programming is theory-building and the most important aspect of a program is the ineffable model of it you hold in your head. Every other effort must be in deference to maintaining the mental model.
I want to be able to piece together an editor from modular task specific executables. Different programs for file searching, input mapping, buffer modification and display, etc. Probably similar to how LSPs are already separated from most editors.
One step less hardcore than writing a whole editor.
Anyone know of any existing projects along these lines?
It steps back from the “customize everything” mantra, believing that approach leaves users with an underdeveloped essential system. But it still has two major APIs: one for window manipulation [2], the other for text-based integration with the surrounding system via plumber [3].
All textual CLI tools (that is, those without pseudographics) work by default and are the heart of its style.
I use Acme for everything except web browsing (although most links are still managed by Acme).
[1]: http://youtu.be/dP1xVpMPn8M
[2]: http://9p.io/magic/man2html/4/acme
[3]: http://9p.io/sys/doc/plumb.html
Sometimes I get surprise questions from my friends whenever they see my screen. “What’s that?” “That’s my own text editor!”
I’ve also written my own terminal emulator and my own shell. The shell does actually see other contributors and users these days too.
But I am now at home with Helix and Flow Control.
We talk about big-O complexity a lot when talking about things like this, but modern machines are scarily good at copying around enormous linear buffers of data. Shifting even hundreds of megabytes of text might not even be visible in your benchmark profiling, if done right.
When benchmarking, I discovered that the `to_pos`/`to_coord` functions, which translate between buffer byte positions and screen coordinates, were by far the heaviest operation. I could have solved that problem entirely simply by maintaining a list of line offsets and binary-searching through it.
This is so true. And there are a lot of other cases where we just expect the OS or library to do it for us. Instead, we have to reimplement the wheel. Of course if understanding the wheel is part of the goal, then that works, but if you’re venture-backed good luck justifying the use of time to your investors. This is why Electron’s gravity is so strong.