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.
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.
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.
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?
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).
> 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.
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.
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 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.
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.
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.
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.
I'm quite partial to Zed. Very snappy, and you can turn off all the AI features globally if you like.
There's a reason Emacs and vi have been around for decades. They're good.
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...
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.
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.
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?
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
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.
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?
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.
> 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.
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.
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.
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 ;-)
Didn't even link it. :(
I guess the "link" is the implicit suggestion to write your own :-)
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!”
You can perform a legitimate muscle-flex when saying that too.
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.
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.
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.
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.
I am always surprised even vim chokes on files with one massive line. That could be a useful optimization too.
Do you actually edit big log files?
on iPhone Safari i don't get the grey middle background layer, only dark text on dark background
Should make my own text editor. Would make for an interesting project at least.
I smell money burning.