
Build Your Own Text Editor - tosh
https://viewsourcecode.org/snaptoken/kilo/index.html
======
tzs
Quote (from memory) from Rob Pike, a few years before he wrote the editor
"sam": "Everybody writes a screen editor. It's easy to do and makes them feel
important. Tell them to work on something useful".

This was not long after he had left Caltech, where he had been a system
admin/system programmer for CITHEP (Caltech High Energy Physics), for Bell
Labs. CITHEP hired a few undergraduates as the new admins and system
programmers. I was one of those undergraduates.

Most of us used the line-oriented editor QED, but as programmers were wont to
do in the early '80s, said that someday we were going to write ourselves
awesome screen editors.

One evening, Karl Heuer and I were both boasting about how great our screen
editors would be, and it somehow turned into an editor writing throw down. We
took terminals at opposite sides of the room, and both started hacking away,
designing as we coded.

This continued all night, mostly in silence, with the occasional boast ("I've
got text search working!") and counter-boast ("I had that an hour ago--I'm
doing regular expressions now!"), and frequent trips downstairs to the vending
machines for soda and snacks.

Another of the undergraduate system admin/programmers, Norman Wilson, then
arrived, and saw what Karl and I had been doing all night. He sent an email to
Pike about it, and the quote at the start was Pike's reply.

~~~
markus_zhang
Thanks for sharing.

Just wondering how did ones write an editor in one night.

------
proverbialbunny
In case anyone hasn't seen it this CppCon talk
[https://youtu.be/sPhpelUfu8Q](https://youtu.be/sPhpelUfu8Q) talks about rrb-
trees and how they're a great data structure for writing a text editor that
can handle unlimited sized documents without locking up, and allows for
editing while saving and opening, and an easy way to support an undo command.

Most text editors today do not support such functionality. With lockless data
structures like an rrb-tree it becomes easy. It really is an ideal way to do
write a text editor.

~~~
mekanicalsyncop
Are there any good ones that exist? I'm a security analyst and I frequently
work with large text files, 200MB-1GB and the text editors I've tried are
incredibly slow.

A lot of the time I can use grep and other command-line tools to find what I
need, but given the nature of the job I don't always know what I'm looking for
so having the raw file open in a text editor is sometimes the only way.

~~~
diegoperini
As an ultimate noob of this area of expertise, can I ask if Sublime Text
works? If not, why?

~~~
diegoperini
I'm the noob, not the parent. No sarcasm intended.

------
userbinator
To contrast with most of the "write your own small text editor" articles out
there, I feel compelled to post this:

[http://kparc.com/$/edit.k](http://kparc.com/$/edit.k)

This is a text editor written in K, an APL-family language. Determining how it
works is left as an exercise to the reader. I wonder whether an explanation
would be longer or shorter than the tutorial in the article...

~~~
max_
Wow! a text editor in 3 lines of code?

It would be nice if a short write up accompanied this?

~~~
LfLxfxxLxfxx
Probably most of the work is hidden in the underlying "framework" or
"language". Here's a text editor in 1 line of html: <textarea></textarea>

~~~
Sir_Cmpwn
APL is an extraordinarily concise programming language, even without taking
its environment into account. This is a well known implementation of Conway's
Game of Life in APL:

↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵

------
dpc_pw
Shameless plug. I'm working on a somewhat novel modal text editor:
[https://github.com/dpc/breeze](https://github.com/dpc/breeze)

It's written in Rust, and it tries to improve on Kakoune, which tries to
improve on Vi/Vim.

If you feel like hacking on a text editor, and would be interested - let me
know.

~~~
asdjlkadsjklads
Cool! I wanted to do similar things, neat idea. These days i'm wanting to try
something similar but with a nice UI - i'm so tired of the Terminal, but it's
hard to get away because editors like Kakoune and Vim are just so powerful.

My wish is that you or I _(if i ever have the time)_ will implement something
like this onto XiEditor. Ie, implement this as a feature to a lower level
editor backend, so that you get the frontends "for free".

It drives me nuts that there's so much work done for the frontend side of
things, but the backend of editors are being reinvented repeatedly for little
gain.

I hope Xi can make a performant, hackable backend to plug into solid
frontends.

~~~
dpc_pw
I doubt this will ever happen. It's all about complexity, and in case of text
editors there are layers and layers of abstractions that often (for UX
reasons) have to be integrated tightly. Trying to unpack all pieces into fully
generic bring-your-own implementation is going to be a lot of work upfront and
in maintenance, and complexity explosion.

I really like some technical aspects of Xi, but I view it as a typical
wishlist project/technical showcase. In the meantime projects like kakoune,
with much smaller scale but better focus, in shorter time, build ecosystems
that can be a practical Vim alternative.

------
frogfish
What I instantly liked is, how literally it starts from scratch and builds a
couple of lines at a time.

Can anybody refer to a similar step by step guide to building a compiler?

~~~
jauntbox
There are several super long (8+ hr) live coding videos of building an
assembler and compiler for CP/M here: [http://cowlark.com/2019-07-15-cowgol-
prototype/index.html](http://cowlark.com/2019-07-15-cowgol-
prototype/index.html)

I haven't had the stamina to go through one but have watched some sizable
chunks and it's pretty cool, even with me not really knowing much about low-
level stuff like that.

There's also a session where he live codes a vi-like text editor here:
[http://cowlark.com/2019-06-28-cpm-
vi/index.html](http://cowlark.com/2019-06-28-cpm-vi/index.html)

~~~
chairmanwow
Thanks a lot for sharing this video! This is absolutely the kind of thing that
I hope to find on HN. Plan to spend all of tomorrow on this.

------
Ididntdothis
A long time ago I had to write a Windows custom control for text rendering.
This was really hard to do in a performant way once you dealt with different
fonts, pages sizes, scrolling and all the other stuff we usually take for
granted. One of the most painful months in my life but I learned a lot since
nobody told me how to do this so I had to make it all up.

~~~
kevas
I’d love if you go into more detail.. dealing with similar ish right now and
would love to hear other war stories

------
bArray
Shameless plug - Text editor in 512 bytes (1kb if you include the kernel):
[https://bitbucket.org/danielbarry/saxoperatingsystem/src/mas...](https://bitbucket.org/danielbarry/saxoperatingsystem/src/master/PROGRAMS/EDIT/EDIT.ASM)

~~~
emmanueloga_
In the same vein there's kilo by antirez:

[https://github.com/antirez/kilo](https://github.com/antirez/kilo)

Edit: oops, yours is in assembly, so definitely not in the same vein :-p
(except for both trying to be small!)

Edit2: ... and, the article is about kilo. D'oh. This is what happens when you
go first through HN comments, only to later open the article (which I do
often!).

------
jokoon
My big fear about implementing a text editor is writing a rope data structure
to be able to edit large files. I don't really know if it's mandatory for all
text editors though.

I was a little frustrated with sublime text folding code using indentation
instead of syntax (there's an issue but they don't want to fix it). I have
large C++ files, and it seems visual studio does a better jobs at folding.

~~~
abainbridge
In my text editor, I just use a doubly linked list of lines, instead of a
rope. It doesn't limit the performance in any situation I've found. A
performance problem I do have is large column mode edits. eg if I want to
delete the first columns of the entire file (typically some log file with
timestamps at the start). I suspect the rope data structure would make that
worse.

I like the simplicity of the doubly linked list of lines. I'm not sure what
advantage the rope data structure would bring.

~~~
PeterisP
Doubly linked list of lines tends to be slow on, for example, editing
documents with very long "lines" e.g. doing a find/replace on a 10mb json
that's not pretty-printed and is a single line.

------
samatman
I very much enjoyed this article, as a sort of kata.

I started a clean repo, loaded stock vim, and typed every line in order.

Learned a lot! Kudos to the author and antirez, and may I suggest that it's
worth working through slowly, as presented.

------
jason_slack
As the author/maintainer of a once popular text editor I feel it is easy to
get started then very hard to finish. Modern text editors require a lot of
details and even more demands from those who use it. It’s a fun programming
challenge. I still find myself thinking about awesome features to add.

------
dang
Thread from 2017:
[https://news.ycombinator.com/item?id=14046446](https://news.ycombinator.com/item?id=14046446)

------
nesadi
This looks like fun. Does anybody know of other guides for different kinds of
programs (other than compilers, which I've seen tons of here on HN)?

~~~
a_e_k
How about ray tracing? Peter Shirley (whom I learned a ton from in grad
school) wrote a trilogy of mini-books beginning with "Ray Tracing in One
Weekend."

[https://github.com/RayTracing/raytracinginoneweekend](https://github.com/RayTracing/raytracinginoneweekend)

------
be5invis
I don't see any references to things like HarfBuzz or DWRITE, which are
__NECESSARY __to properly display any scripts that 's not European. All
properly implemented text editors are rich text — because you will need to
support font fallback and BiDi and all the Unicode complexity

~~~
coldtea
You absolutely don't need any of these for a tutorial text editor... Those are
all things you can hook-in later, after you've understood how to make text
editors...

------
teddyh
I prefer _The Craft of Text Editing_ by Craig A. Finseth:

[https://www.finseth.com/craft/](https://www.finseth.com/craft/)

------
ankuranand
shameless Plug: I'm working on writing this in Go(Golang).
[https://github.com/ankur-anand/goditor](https://github.com/ankur-
anand/goditor)

~~~
japanoise
Even more shameless: I used it as a base for my own ersatz-emacs in golang!
[https://github.com/japanoise/gomacs](https://github.com/japanoise/gomacs)

This is actually my go-to editor for small files/quick edits now

------
retpirato
if you use windows (or linux with wine) you can write self-contained apps
using Autohotkey. It's free from autohotkey.com. It's usually advertised as a
macro-recorder which it also does.

------
baby
This is a pretty awesome resource! I wish this existed for Rust.

~~~
bluecheese33
I followed this guide but implemented it in rust.
[https://github.com/khadiwala/kilo-rs](https://github.com/khadiwala/kilo-rs)
If you’d like to take a look.

~~~
dancek
I had the same plan. Thanks for the link, nice to have a reference if I get
stuck (as a Rust noob).

------
pawelduda
Disclaimer: I haven't read the article just yet. Saving it for later.

An alternative approach to this is to open vim with a blank .vimrc and add
config as you need it. Nothing except what you REALLY need NOW to get things
done. That's how I started my adventure with vim a few years ago and it's
still paying off.

~~~
AsyncAwait
This is about _programming_ your own text editor, not configuring one to your
requirements.

~~~
pawelduda
Which is what writing vim script essentially is. Or if vimscript is not
enough, you can use literally any other language and integrate it via
vimscript. I'm not an expert though but I have spent quite a lot of time on
doing that.

~~~
AsyncAwait
I get that ViM is really powerful, so is Emacs and the like, however I'd guess
a large part of going into the trouble of building your own text editor would
be to learn about the algorithms and data structures used, something you can't
do by writing ViM configuration files.

~~~
pawelduda
Good point - if someone is after that, then what I wrote isn't the best way to
achieve this

