"There is an old saying: Once in your life you should build a house, plant a tree, and write an editor. I decided to start with the last one. ..."

from Vip - Vi-Style Editor in PicoLisp https://picolisp.com/wiki/?vip

This was so nice to read, I've been trying to encourage my friends to write their own editors, there's something really nice about the process of working within your own tool. I've used my own text editor(it's call Left) for nearly 10 years, it took time to get it just right, but I iterated over the years(using Left to edit Left) but that time I spent putting it together is paid back 20x by the joy it gives me opening it and working in it in the morning.

I'd do it all over again if I had to.

I went the same path of writing a text editor from scratch. There are a lot of moving parts, so I tried to outsource as much features as possible - LSP for intellisense, tree-sitter for highlighting and syntax-aware features, fzf for search and file handling, etc. I also tried to design it so that it can be tweaked to one's needs with simple code changes, suckless-style.

It was indeed a pain using it for the first few weeks, where every 5 minutes I found some bug and had to go back and fix it, instead of steadily working on some other project. Good news is more bugs you fix, less bugs is left.

https://github.com/ivanjermakov/hat

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.

I had fun re-implementing antirez's "kilo" editor

https://github.com/antirez/kilo

There's a nice tutorial for it

https://viewsourcecode.org/snaptoken/kilo/

Great way to learn more about terminal modes and write some raw C

The editor:

https://git.jsbarretto.com/zesterer/zte

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

I laughed out loud when the author wrote 'it replaced nano'.

So you are claiming to have tried dozens of editors, discarded them, only to land on nano as your daily driver?

If that's true, this person must be a character.

I love this! The line “resist the urge to push the difficult bits off to a box of statistics” particularly resonated with me!

Josh Barretto is the genius behind the Super Mario 64 GBA port. I would gladly use his editor.

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.

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?

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.

It's so fascinating how different things people look for in such a simple thing as a text editor. A file browser? Terminal?

There's a reason Emacs and vi have been around for decades. They're good.

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.

Greatly i n s p i r i n g ! !

Should make my own text editor. Would make for an interesting project at least.

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.

No comment availabe

Would like to see someone make their own WYSIWYG editor.

As someone who deals with remote servers all day, vi(m) is a must.

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

on iPhone Safari i don't get the grey middle background layer, only dark text on dark background

[dead]

[dead]

[dead]

[dead]

[dead]

[dead]

[flagged]

I smell money burning.