I'm 19 years into using my own ("aoeui"), and it's one of the best things I ever did for my own productivity.

What were the features that were most important to you in your text editor? Did you try to build it for multiple types of workflows?

Nice work! And yes, that gradual acceleration of productivity where your fixes and tweaks from the past compound on your ability to get things done in the future is a great feeling.

A thing that shocked me as I was working on the text editor was how capable modern terminal emulators are when you account for ANSI extensions. First-class clipboard access, mouse events, precise text styling, focus tracking, system notifications, key press/release events, etc. are all possible with a modern terminal emulator. There's not really anything else you need to build a very competent, ergonomic editor UI.

You can even use tools like trolley to wrap the entire application up in a ghostty-powered shim that presents the application as a native UI application: https://github.com/weedonandscott/trolley

I would mention stb_textedit.h, but I would not recommend it. It was an interesting thing to study. but the library has many shortcomings and is pain to integrate and use. It is used in ImGui, but somewhat modified. Just to illustrate the flaws - it can't be used with utf-8 bytes easily, there is a large switch on keyboard shortcuts to trigger actions so you have to fake keyboard input to script things, the default word boundary detection is pretty bad, and there is no way to nicely provide double or triple click selection.

The two notable functions are stb_text_locate_coord() and stb_textedit_find_charpos(), which connect the physical x,y coordinates with position in text buffer. They both iterate lines of text - accumulating y position; and the chars of last line - accumulating x position.

For windowing, drawing and OS integration, SDL with SDL_ttf is actually pretty good. SDL3_ttf API got an improvement and no longer requires zero-terminated strings so you don't need to relocate every chunk.

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 hard to give you a recommendation without knowing the platform details, but if GUI rendering is not the goal, something like raylib might be a great choice to have a cross-platform GUI API, including text rendering.

https://www.raylib.com/

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.

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.

> 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.

No, the author used Howl for their normal work and Nano occasionally. I would guess when working in the terminal

Love his SM64 videos. Link to the latest one for anyone who's curious: https://www.youtube.com/watch?v=nS5rj80L-pk

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 ;-)

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.

Didn't even link it. :(

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!”

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).

[1]: http://youtu.be/dP1xVpMPn8M

[2]: http://9p.io/magic/man2html/4/acme

[3]: http://9p.io/sys/doc/plumb.html

You can already do this in vim. Pretty easy to shell out to whatever command you want and use the result for various purposes.

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)

I'm quite partial to Zed. Very snappy, and you can turn off all the AI features globally if you like.

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?

I agree about Kate.

In addition while kate has many plugins, like the one that allows running arbitrary command line utilities with std input the current selection, I would like to point you at something else in case you write / debug SQLs.

Kate has a SQL plugin that allows to send the current selection to the connected SQL server for execution. It displays the output in table form below the editor pane and you can copy paste rows or columns.

That allows to organize your SQLs in markdown files. That was such a productivity booster for me that simply there are no words to describe the difference felt.

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.

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.

Unfortunately there's some thing about their "session management" that makes it unusable for me. I've used it in the past, but apparently differently. (Would have to dig up the specifics)

Kate is the editor i'm using these days on Linux (even though i use Window Maker for my WM and not Plasma) but it does have a few weird aspects. One of them, which annoys me, is that every "tab" is really its own entire editor with its own state - if you do something like search for a word in one file then switch to another tab, you can't use F3 to search for the same word again in that file because that's actually a different editor and it doesn't know that you searched for something in the other tab. This extends to other stuff, as if the main Kate window is just a window manager for the editors it launches in it and it just pretends the UI is shared.

I just wish the extension ecosystem was more fleshed out

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

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 :)

there's a reason Unix like systems usually ship with 3 or so

Maybe not good, but tenacious. Once you have a muscle memory, it's rarely worth the effort to switch.

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.

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.

I actually did this back in the late 90s! The editor was called "Scorpio"[1]. It was written for the classic MacOS in some version of C with objects, maybe Think C(?). I'm not 100% sure.

It's an amazing fun thing to do, but I probaby wouldn't wan't to do it again now. This thing didn't handle unicode (I had never heard of it), barely handled spell checking and didn't handle bi-directional input.

Text (1 byte per char) was stored in a big array on the heap. Styles were also an array (again on the heap) of fixed length structs. Font information, in the form of fixed-point width tables, was gathered from system calls and cached.

It did actually support inline pictures though, which was pretty challenging.

Writing an editor is a hugely fun project. Highly recommended.

[1] https://atpm.com/3.03/page11.shtml

Making something highly custom usually contradicts WYSIWYG ideas. Same reason why advanced users use hotkeys instead of toolbars.

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.

That's odd, I've not heard that reported by anybody else. If I get time I'll look into it.

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.