Writing an editor in less than 1000 lines of code, just for fun | Hacker News Reader

Writing an editor in less than 1000 lines of code, just for fun

antirez.com

535 pointsdwaxe139 comments

Awesome. When I saw all the things it could do in so little code, I assumed a higher level language would be used. But, nope...plain old C with the usual standard libraries.

The parser for the syntax highlighting is super cool. Concise and declarative definition of the syntax (well, the keywords, anyway), in HL_keywords, and then maybe 150 lines of code for the parser. I doubt it would work well for a much more complex language than C (say, JavaScript, or Perl), without a lot more smarts. But, it works really well on the C I looked at. Colors are handled in a cute way, too.

All around, I'm just astounded at how concise this is, while still being entirely readable and comprehensible. This isn't clever/tricky golfing code, this is actually human-readable C code.

Edit: Also, I'm struck by how nice/simple the editorProcessKeypress handling is. Trying to do something like this in JavaScript/HTML5 is crazily more complex and verbose. Seeing something like this reminds me how messy user interaction still is in the browser, compared to old CLI and desktop paradigms.

The syntax highlighter isn't really a parser, per se. It's just a lexer / tokenizer / scanner / what-have-you, which tend to be fairly compact state machines.

As an aside, I agree with your edit. As someone who started programming back in the DOS days, whenever I do Web development, I'm always floored by how much it feels like one step forward and two steps back. So many simple things just aren't simple when it comes to the browser, and even certain protocols on the backend like FastCGI seem way more complicated than they need to be (SCGI seems pretty nice, though I feel it's missing a way to signal out-of-band information to the Web server, the way you'd use stderr in CGI, for example (though perhaps I'm missing something there)).

As much as I love the idea of sending semantic markup over the wire for document transfer, I can't help but wonder if a more terminal-like protocol would be better for application "delivery", the way we used to do with telnet and BBSs in the 90s, with an upgrade for multimedia. But I digress...

FastCGI/SCGI were obsoleted by having app servers simply speak HTTP; the web gateway just needs to function as a simple reverse proxy. HTTP is about as simple as it gets to parse - you can write a passable (not quite production quality, but works) parser in about 10 minutes.

A lot of the difficulty in webapps is because every webapp is inherently a distributed system, which are always hard. Single-page apps with no connection to a server are actually quite simple, but they're also about as commercially viable as DOS programming (i.e. not at all).

A while back I'm sure I saw a HTTP state diagram posted here that showed writing a HTTP parser is anything but simple. I guess if you only have to be a (reverse) proxy you might get away with it.

You're thinking of https://github.com/for-GET/http-decision-diagram

That's the state diagram for processing the full complement of HTTP requests. Nothing to do with parsing. The parsing bit is trivial.

While you're correct that it's a state diagram processing HTTP semantics and not parsing; parsing a text-based protocol is far from trivial. In fact, the HTTP2 FAQ explicitly mentions [1] that reducing parsing complexity was a motivation for going binary with HTTP2.

[1] https://http2.github.io/faq/#why-is-http2-binary

I've done perfectly adequate HTTP parsing with this Python 4-liner:

  headerText, body = text.split('\r\n\r\n', 1)
  headerLines = headerText.split('\r\n')
  method, path, protocol = headerLines[1].split(' ')
  headers = dict(line.split(':').map(str.strip) for line in lines[1:])

For production use you'd probably want something a bit faster & more robust like Mongrel's HTTP parser (itself only 166 lines of Ragel), which powers several million websites out there:

https://github.com/mongrel/mongrel/blob/master/ext/http11/ht...

That's a perfectly adequate 4-line HTTP/1.0 parser :) But for HTTP/1.1, which must support chunked transfer coding [1], this won't work.

[1] https://tools.ietf.org/html/rfc7230#section-4.1

I'm going to convert this into a poster and get this printed

Maybe you were thinking of and-httpd's rant about HTTP/1.1:

http://www.and.org/texts/server-http

Speaking HTTP is worse in almost every way to using CGI: harder to implement, loses meta information (suppose you put an application at /app/ on your server... CGI handles it well, HTTP doesn't unless you do some extension since your server will see GET / anyway) and is harder to centrally log too.

I think app servers speak HTTP more because it is kinda convenient for developers to run the local server without setting up the http server.. convenience rather than superiority.

Nah, it's not worse: as nostrademons mentioned, you have your gateway server be a reverse proxy server, e.g. HAProxy, and then you can do whatever you want in there. Serve an application under /app/? No problem. Centrally log? Of course. Harder to implement? Not really, every major language has well-supported HTTP libs. And since you only need to know how HTTP works, rather than needing to understand HTTP and CGI, it's conceptually simpler too, assuming that you're running more than one backend server and thus needed a load balancer anyway.

It is interesting to note that most those HTTP libraries end up looking like CGI to the programmer anyway, even sometimes using X-Whatever headers for additional information, because that's the relevant information to an app server.

I started programming in the same era, and feel the same way about "web apps" being a step backwards. The problem is we're building apps on top of a platform originally intended as a document viewer, with kludge upon kludge piled on...

If only we can take out HTTP and only use JSON (or something even simpler) end-to-end.

> I doubt it would work well for a much more complex language than C (say, JavaScript, or Perl), without a lot more smarts.

Perl can not be parsed, making accurate synthax highlighting impossible: http://www.perlmonks.org/?node_id=663393

Off topic, but my biggest takeaway was that I could aspire to be someone who isn't a twenty something, with a family, with superb work life balance, not living in the valley, sitting in a garden without three 27 inch monitors, not using the latest programming language or fad and still writing beautiful code that a lot of the world runs on.

I agree. I LOVE how his post weaves in his normal life, having time for doing things he actually loves outside of work, while still continuing to work on passion projects. It just goes to show you that you don't need to always buy into the cowboy coding hype that is often on display here.

> Let’s say this again, “email client”. The notion of email client itself is gone at this point.

Really? Is it lame to be using an email clients these days?

I still use an email client (Thunderbird) because I can't stand the thought of all my mail sitting forever on Goggle's or whoever's servers. Yes, I know that they could have secretly archived all of my email the moment it was sent or received, and that my privacy is not necessarily enhanced by downloading and storing my mail offline.

That's my main reason, but I can think of many other reasons to prefer email clients to a web interface.

I'm surprised by the sentiment that email clients are passé.

Gmail's web client also non-optionally auto-wraps text before sending, which is very annoying when you're trying to send a patch or part of a log file.

That issue basically forced me to switch from plain-text to html emails, and thence to the slippery slope of using italics and the OCD of syntax highlighting my code snippets..

I dread the slow insinuation of "the web" into email. Specifically, the need to use a rendering engine like Blink or Gecko to read an email.

Is there anything I can do to tempt you to switch back to plain-text emails?

In my defense, I still eschew html as far as possible. Even when I use html the messages are multipart, and the text versions usually are complete. I do this thing when I reply where I open the gmail menu, switch to plain text and then switch back to html. This has the effect of stripping out all styling from the message I am replying to, replacing html block quotes with conventional '>'s, and so on. That makes it easier for me to quote passages and so on.

I think of it as 99%[1] text/html with format=flowed, and if gmail ever added format=flowed to text mode[2] I'd switch back in a heartbeat.

[1] The remaining 1% of the time I'm composing something long enough that it has more in common with publishing than 1-1 communication.

[2] I wouldn't hold my breath: http://productforums.google.com/d/topic/gmail/Z42NibAOzjc/di.... More likely I'll stop using gmail one of these years..

Only in plain text mode, sadly. If you send an HTML message, a plain text version gets included, too, which isn't auto-wrapped. It's encoded as quoted-printable instead, which keeps lines short enough to be legal for SMTP but can be turned back into the original text by the client on the other end.

Also my android phone has an email client. It's pretty nice to be able to view offline.

I've actually been working on a new email client, and a terminal one at that. Shameless plug: https://github.com/SirCmpwn/aerc

Very cool! Going by the acronym, are you trying to make a Stallman-ish IMAP client that works well offline and only needs an occasional Internet connection to sync?

No, just that it does networking on a different thread. This is my main (but not only) problem with mutt. I'm not opposed to going in the direction you suggest, but think more mosh less stallman.

Are you planning to delegate editing and is it purely for reading?

Yes.

Me too. Mine has Lua-based scripting.

https://github.com/lumail/lumail2/

> Really? Is it lame to be using an email clients these days?

I think he means that wether nano is derived from an email client or not is not important

You might be right; I may have misinterpreted. He might be saying, "The notion of email client itself is gone from Nano at this point, everything changed about Nano".

For what is is worth, I read it in the same way as you. And found it kind of an odd statement, for a guy who has a website with a monospaced font...

And yet I read, on Hacker News, a number of people writing how they were often saved by the availability of nano on random systems

All the time, but I even use nano all the time on OS X for full on programming, mostly for quick edits or starting things off before I can be bothered opening a full project in Sublime. (Sure, I can 'get around' in vi, but I just don't seem to have the brain for it and nano is 90% fine. I grew up on GWBASIC so anything is an improvement ;-))

That aside, this feels like it could be a kinda cool command line level equivalent of ToDoMVC. Port this simple editor into Go, Rust, and a few similar languages - see what the differences are, etc.

Nice thing about Nano is that they arrow keys always seem to do what they are supposed to, no matter the system, shell, TTY, etc. Vi seems to have issues sometimes, and needs extra config

I don't know about vi (I think it's still rare on Linux systems), but Vim typically does what is expected from it.

If you ever happen to bork your kernel badly enough to prevent it from booting, you'll find a classic VI pretty quickly, and probably be grateful for it.

Well, not really. My system doesn't have vi installed. Vim, of course, any time of the day. Stripped Vim (vim-tiny, as Debian calls it), sure, just after installation. But vi -- no, I don't have it installed.

For quite a long time Linux didn't have vi even ported. There were several clones, like Elvis and nvi (and Vim, of course). Few years ago I learned that somebody took the effort and actually ported traditional vi to Linux. I doubt mainstream distributions cared to include it, though. Why should they? They already have plethora of clones packaged, and those clones typically do much more than traditional vi.

The lesson from this tale is this: don't call vi what is merely a vi clone. vi is a name of a quite concrete project.

And as for kernel unable to boot: if it can't boot, then how the heck am I supposed to run anything under this kernel? Unless you meant kernel can't run OS from local disk. I know Linux well enough to manage to run my things. You would be surprised how much could you hack through if you knew how ELF binaries work.

You are being needlessly pedantic. The point is that typing "vi" into a terminal runs some application that implements a "vi-ish" interface. Whether it is ported vi or vim or vim-tiny has some effect on how nice that interface is to work with, but I would argue that most vim users would be able to get their configuration fixed or whatever

> You are being needlessly pedantic.

I assure you I am not pedantic needlessly. The claim was "vi has some issues with arrow keys". Now tell me: which vi clone was elsurudo talking about? Because those are different projects. And Vim doesn't have a smallest issue with arrow keys (unless with "compatible" option set, I think, but I didn't use it for years and I may remember wrong).

As a cranky old man, I'd argue all of them that support arrow keys have issues. Arrow keys are an abomination.

Presumably h, j, k, l will always get you around in vi?

j and k behavior may vary depending on your config.

Everything can vary depending on your config, but unless they were explicitly remapped, j and k should pretty much do the same thing everywhere.

Have you seen somewhere where that isn't the case?

> Have you seen somewhere where that isn't the case?

I use the dvorak keyboard layout and used to remap (among other things) j and k in vim, since they were not on the home row for me. I stopped doing that after a while though.

Yeah but that is so much less usable. Quick, which one is up?

k of course. Having said that, experienced vi/vim users rarely use jk to get around. Instead we use { } / f etc.

Just look at your keyboard :-)

(https://en.m.wikipedia.org/wiki/ADM-3A#Legacy)

I always try to remember them by noting that the leftmost key moves left, the rightmost key moves right (not too hard), and that 'K climbs' (using alliteration to remember that). That leaves 'J' for cursor down.

In practice, though, I use the cursor keys. Luckily, they work on the editors/systems I work on nowadays. Side effect is that I am very bad at remembering those mnemonics.

I stole the following from a colleagues `.vimrc` which finally allowed me to learn `hjkl`. Now I forget I have this set, and when I do accidentally use an arrow key it makes me laugh.

    map <Left> :echo 'damnit!'<cr>
    map <Right> :echo 'you suck!'<cr>
    map <Up> :echo 'this is why you fail'<cr>
    map <Down> :echo 'nooooo!'<cr>

Off-topic: I love your username. See https://news.ycombinator.com/item?id=12068116

> K climbs

Lower-case 'k' has an ascender, lower-case 'j' has a descender.

https://en.wikipedia.org/wiki/Ascender_(typography) https://en.wikipedia.org/wiki/Descender

I know k is up, because I constantly <ESC> k in bash, bit the point of using hjkl is exactly not to know which one is what. You set your finger on the keyboard in home position, now your muscle memory does the rest.

>I know k is up, because I constantly <ESC> k in bash

What is ESC-k supposed to do in Bash?

The poster probably changed his bash to use vi editing mode with set -o vi. In this mode, <ESC>k would put the text of the last command entered back on the prompt.

I do switch deadline to vi mode, since that's the editor I use the most.

I'm always surprised by people who are on the vi/vim side of vi/emacs debates but then use the defaults emacs mode in deadline!

"k", as "k" glyph reaches higher from the two. And conversely, "j" reaches lower, so it moves down.

You're right, that is much more usable than having an up button in the up position with an up arrow on it...

Erm... what? I didn't claim it's more usable (though it is for me). I just provided mnemonics I saw once which I liked, for a question "which k/j moves up and which moves down?".

I use hjkl consistently in vim and in the shell. Just think about how long it takes you to move your fingers to the cursor keys. You should spend some effort getting used to it, as using hjkl means you can keep your hands in the middle of the keyboard. I have also never had any problems with strain, and I suspect this is part of the reason.

How do you use them in the shell?

    set -o vi           # bash
    bindkey -v          # zsh
    set editing-mode vi # ~/.inputrc i.e readline

The point is, they are no longer in symbolic memory. At this point they are muscle memory. Quick, which muscle do you use to move your right thumb in? Does it matter?

Exactly: muscle memory. In your car, do you move the turn signal lever up or down to indicate a right turn? It actually takes longer to answer this question than to do the action in real life.

Another example: There are several passwords that I can type instantly, but I wouldn't be able to recite them.

> In your car, do you move the turn signal lever up or down to indicate a right turn?

You rotate it the same direction you're about to rotate the wheel. The vi navigation keys have no such convenient correspondence.

The J kinda looks like an arrow pointing down. If you squint.

I also like what Someone (literally their username, lol) pointed out on another comment, that you can think of K as "klimb" to move up.

h is left because it is on the left of the movement keys, l is right because it is on the right of the movement keys... a fairly convenient correspondence.

Just have to imagine the motion. I remember left/right by literally right clicking & feeling my middle finger be to the right of my index. I got a little mixed up when I switched my mouse to my left hand

'k' is up, because the author is typing quite a few of it in the screencast before going up. :)

The leftmost one is left, the rightmost one is right. Of the two that remain, the one that looks vaguely like an arrow pointing downward, that one goes down. There's one key remaining, and that one goes up, k?

As everyone says, it doesn't take a lot of practice before you know it well enough that you'll never forget. Unbind the arrow keys, or go play some nethack (no-keypad), or whatever.

I have no idea is a muscle memory thing :-)

Middle finger goes up ;) (K), index down, stretch left to go left (H) or right to go right (L).

The one under my middle finger on my right hand.

I don't even have to think, it's automatic. Likewise with the other directions.

Not in insert mode, it will insert 'h', 'j', 'k' and 'l' ;-)

I also use nano for my alternative notepad++ in windows. If normal ide i only use vscode in osx.

This is the kind of magic that got me excited about programming in the first place.

I remember being in high school and one day, after class, a friend of mine mentioned that the best programmer we knew had once written a breakout clone with ANSI "graphics." We found him and he said he didn't have the source any more, but we asked him how he did it. He then proceeded to rewrite the whole thing, in Pascal, in about an hour, this time adding animations. Thanks antirez for bringing back that feeling (and, oh yeah, for redis too ;))

PS. the "Low level terminal handling" is gold here.

I love seeing little projects like this, and I wish I were better at finding time to do them myself. It’s all too easy when you’ve been programming professionally for a long time, often working on the same projects every day for months or years, to lose that sense of wonder at what we can achieve in a few hours with a modest amount of code. Sometimes it’s good to just sit down for a day or two and hack together a kind of program you’ve never written before, whether that’s a text editor or a puzzle game or rendering a pretty 3D fractal landscape or an IRC chat bot. It’s always nice to see someone else who’s created something that way too, so thanks for sharing.

Honestly, this is the most exciting and inspiring project I've seen on HN in years, by far. I love that it's a fully usable terminal-based text editor that has zero dependencies. Just perusing the source code has been extremely interesting and educational for me already, and it's only been 5 minutes. Definitely gonna bookmark this project and hack on it! The TODO list looks like a good start, especially the xterm-based feature.

You can tell it's going to be good when, on a Mac, you download the source and compile it, and a) it compiles b) it doesn't give a single warning. It's nice when portability actually works.

Yay, this is delightful.

I wrote a nano-inspired TTY-based editor, too, and have used it to do virtually all of my coding work for the last couple of years. There's nothing particularly noteworthy about it, technologically, but it does exactly what I want in exactly the way I want it to, and that was enough to make the time spent feel worth my while.

There's something really satisfying about the exercise of creating one's tools. I think there is a lot of value in projects like this whether anyone else ever uses them or not, as an exercise in software craftsmanship.

Looking at this project, I am inspired to see if I could simplify my editor's codebase. I was never fully convinced that ncurses did enough good to justify its complexity; it might be interesting to adopt this author's approach instead.

When I started programming, the basic digital world already existed for me. I never had the experience of typing in a program from a magazine. This is one of those odd experiences where you remember that self-hosting[1] can involve far more components than just the compiler, spiraling an unexpectedly deep path into the development stack.

I just used @antirez's 1k LOC kilo editor to edit his 1K LOC editor and it was an oddly pleasurable experience :)

[1]: https://en.wikipedia.org/wiki/Self-hosting

This is the programming equivalent of a food blog post (technical details interspersed with what's happening in the author's life). It's great and I think there should be more of it!

Cool; now embed it into a 150 MB Electon app and you have a state of the art editor (maybe introduce several arbitrary delays in the range 300 ms - 2 sec for the authentic Atom feeling)!

Wow! I love this!! Thanks for the post antirez, if just for introducing me to this now indispensable tool ;)

asciinema - Record and share your term sessions

https://asciinema.org/

Yes, asciinema is a wonderful thing I learned about from this blogpost too. And another one from the asciinema.org: lolcat! Command line forever!

This is great! I love seeing how experienced programmers write small programs like this, especially "from scratch".

Can anyone explain how to do a full-screen UI using only VT100 codes? If I had to write a small editor, I'd probably reach for something like Termbox for display.

You could look at the code to see how it's done, but basically, you send a special sequence of characters that update the screen.

The VT100 (and a lot of terminal emulators these days) use what are called ANSI escape sequences. For instance, to move the cursor, the CUP (CUrsor Position) sequence is used, which is "<ESC> [ <row> ; <col> H" where <ESC> is the ESCAPE ASCII character, <row> is the row number (as ASCII, so for row 12, it's the string "12"), <col> is the column number ("40" for column 40) and the rest are the literal characters. So, in hex, it's 1B 5B 31 32 3B 34 30 48 (<ESC>[12;40H).

There are more sequences (move the cursor up, down, left, right, clear various portions of the screen, change colors, etc).

Conversely, the terminal will send ANSI escape sequences representing certain keys, such as "<ESC>[A" for the up arrow key, "<ESC>[D" for the left arrow key and such. It's then just a matter of recognizing these sequences and doing the appropriate thing ("I received <ESC>[A so the user is moving the cursor up. Update my internal structure to represent that, and send to the terminal <ESC>[A so it moves the cursor on the screen up").

First, switch it to alternative screen mode... printf("\033?1047h"); then clear and move and such with other similar prints. See the list here : http://invisible-island.net/xterm/ctlseqs/ctlseqs.html

It really is pretty simple. The big benefit of ncurses is if you want to target terminals other than xterm compatible ones, and they are so rare nowadays that you can really just ignore them....

Input is quite a pain though (however, ncurses sometimes get it wrong too), but the same thing applies, you just need to switch to raw mode with tcsetattr and then have some kind of select() loop or something to watch for escape sequences then translate them into interesting key presses.

Mouse events are the same btw: you write out a sequence to turn them on, then the terminal sends them as sequences to stdin.

I wrote a terminal library myself for the D programming language (and a terminal emulator too!), it is kinda ugly code but it isn't hard.

I wonder if these codes work in cmd.exe now that Windows 10 TH2 supports (some of) the features.

I haven't checked but I kinda doubt it... and I kinda hope not - the windows console API is so much nicer than the unix terminal system it would be a pity to make it an ugly hybrid.

Of course, you can run a terminal emulator inside the windows console and handle those sequences too! If I had to guess, I'd say that's what Microsoft would have implemented.

Thanks for the info, very useful info; I was most interested to learn that ncurses provides compatibility for terminals that are rare.

Pretty cool. Something like this would make for a nice school project, I would have loved being assigned to write a simple editor back in uni

@Antirez please please please let this thing have a future: there is a great need for a modern, simple and usabile CLI editor.

I think the whole point of this post was that it's a lot of fun to write code if you know it's not going to be taken seriously or used in the long-term, so what you're asking seems to be the exact opposite of why this was created.

Try vis: https://github.com/martanne/vis

I find it funny that a person named _acme suggests vis :)

Neovim https://neovim.io/ is a modern, simple, usable, and powerful CLI editor.

anyone who thinks vim isn't simple just hasn't had a good instructor / tutorial.

It would be fun to see this project replicated using some other underlying data structures, e.g. the buffer-gap data structure used by emacs.[0] Does the code become shorter/prettier? etc.

0: https://en.wikipedia.org/wiki/Gap_buffer

What challenges might you have if you wanted to implement something like this inside a game framework like Unity or MonoGame with C#, where it renders everything via DirectX or OpenGL?

The main challenge is that, even now, in the year 2016, there is no objectively good, fast, reliable way of rendering arbitrary text with formatting in a texture. Hell, even just plain text is kind of a pain in the ass.

And yes, I know about signed distance fields.

The nice thing about a framework like Unity is that they do have a textfield object that behaves a lot like a standard text object in the .NET Framework. It has a lot of shortcomings but rendering the text is the easy part.

Unity only supports Unicode BMP. Unity doesn't support surrogates, RTL rendering/input etc. Rendering the text performantly for none western scripts is definitely not the easy part, especially on mobile (where Unity also fails to behave properly).

Proper Unicode and RTL support is something Jonathan Blow recently spent a lot of time getting just right for The Witness. I wonder if he'd ever consider open sourcing that work.

It's hard enough to just render high quality ASCII text. But when you consider the layout problems if you want to support full unicode, with rtl and combining characters, Indic script, etc it's very difficult.

If you were looking to do this and wanted a text library that is more flexible than MonoGame's bitmap fonts, I maintain the QuickFont library for text rendering with OpenTK: https://github.com/opcon/quickfont. It doesn't have very good unicode support though.

Nice work. I clearly remember writing a full screen editor in a few hundred lines of Turbo Pascal back in '86 because I hated using EDLIN to edit .BAT files in DOS... :D

Anyone up for converting it to Swift (3) or Rust?

I am currently learning Rust, would be happy to give it a shot! My email can be found in my profile

Back in the 90's I took a class in Visual Basic, where one of the assignments was to write a rules-compliant tic-tac-toe game. The teacher apologized for the amount of repetitive code we'd have to write to implement it in Windows forms (or whatever it was called back then). I got it down to one printed page.

When I taught V that was a class assignment (along with create a 4 function calculator). I don't remember any of the programs being that long.

For extra credit for people that had problems I'd allow a resubmission of an assignment if you did the logic in a different way. One of the students did a table that let them look up the current board and say what the new move was.

> WARNING: Long pretty useless blog post

Antirez's posts are hardly ever really "useless" :) Awesome stuff, as always.

What's especially impressive to me is that it even has syntax highlighting.

> a text editor in less than 1000 lines of code that does not depend on ncurses and has support for syntax highlight and search feature.

Neovim also does not depend on ncurses. Vim optionally links to it for termcap/terminfo access.

Cool :)

But editor without undo/redo is a bit surprising these days, next release?

That's what git is for ;-p

If antirez is reading:

How much time did this take? From start to finish. :)

The GitHub page states: "The project is in alpha stage and was written in just a few hours taking code from my other two projects, load81 and linenoise."

https://github.com/antirez/kilo

Yes, thanks for pointing that out. I'm more interested in total time. Not time to write. :)

Hello! It was a few hours (probably 6-8) across a total of two weekends (so a total span of 9 days where I did 2 "days" of work, 5 days of pause, 2 days of work).

Thanks for answering.

I'm reading the code as a Primer. Fantastic stuff you don't see often.

Id like to see people have competitions to write an editor in the most readable amount of lines of code

Bonus points for being in C

cough cough fewer than... cough cough...

He mentioned using cloc to get that metric, so not including comments, formatting, etc.

I think you missed the point: the point is that the correct English usage is "fewer than" when discussing quantifiable items (e.g., lines of code). The title should be "...an editor in fewer than 1000 lines of code."

Thank you for clarifying. I thought for a second it could have been a grammatical nitpick but discounted that since this thread is re: an Antirez post. I personally would be very sad if his writing style became more forced and began to feel like excerpts from The Elements of Style.

This page [0] seems to suggest that "less is also used with numbers when they are on their own and with expressions of measurement or time".

Lines of code is surely a measurement, which makes the use of 'less' here acceptable.

0: http://www.oxforddictionaries.com/words/less-or-fewer

Reply on news.ycombinator.com