Top
Best
New

Posted by todsacerdoti 10 hours ago

Writing my own text editor, and daily-driving it(blog.jsbarretto.com)
123 points | 40 commentspage 2
piker 3 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 1 hour 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.
mudkipdev 7 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 1 hour 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 6 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 1 hour 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 6 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 3 hours ago|||
I am always surprised even vim chokes on files with one massive line. That could be a useful optimization too.
oneeyedpigeon 4 hours ago|||
Do you actually edit big log files?
abktowa 8 hours ago||
Should make my own text editor. Would make for an interesting project at least.
croisillon 5 hours ago||
on iPhone Safari i don't get the grey middle background layer, only dark text on dark background
zesterer 1 hour ago|
That's odd, I've not heard that reported by anybody else. If I get time I'll look into it.
zacklee-aud 8 hours ago||
[dead]
genie3io 4 hours ago||
[dead]
shablulman 9 hours ago||
[dead]
fay_ 5 hours ago||
[dead]
givemeethekeys 6 hours ago|
I smell money burning.