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.
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...
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).
headerText, body = text.split('\r\n\r\n', 1)
headerLines = headerText.split('\r\n')
method, path, protocol = headerLines.split(' ')
headers = dict(line.split(':').map(str.strip) for line in lines[1:])
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.
Perl can not be parsed, making accurate synthax highlighting impossible: http://www.perlmonks.org/?node_id=663393
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é.
Is there anything I can do to tempt you to switch back to plain-text emails?
I think of it as 99% text/html with format=flowed, and if gmail ever added format=flowed to text mode I'd switch back in a heartbeat.
 The remaining 1% of the time I'm composing something long enough that it has more in common with publishing than 1-1 communication.
 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..
I think he means that wether nano is derived from an email client or not is not important
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.
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.
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>
Lower-case 'k' has an ascender, lower-case 'j' has a descender.
Another example: There are several passwords that I can type instantly, but I wouldn't be able to recite them.
You rotate it the same direction you're about to rotate the wheel. The vi navigation keys have no such convenient correspondence.
set -o vi # bash
bindkey -v # zsh
set editing-mode vi # ~/.inputrc i.e readline
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.
What is ESC-k supposed to do in Bash?
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!
I don't even have to think, it's automatic. Likewise with the other directions.
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.
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
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).
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 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.
I just used @antirez's 1k LOC kilo editor to edit his 1K LOC editor and it was an oddly pleasurable experience :)
asciinema - Record and share your term sessions
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.
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.
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").
anyone who thinks vim isn't simple just hasn't had a good instructor / tutorial.
And yes, I know about signed distance fields.
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.
Antirez's posts are hardly ever really "useless" :) Awesome stuff, as always.
Neovim also does not depend on ncurses. Vim optionally links to it for termcap/terminfo access.
But editor without undo/redo is a bit surprising these days, next release?
How much time did this take? From start to finish. :)
Have you seen what e.g. Notch can do in a few hours of live coding?
Judging from the screencast he use around 10 seconds per line. That would be, (10s * 1000 loc)/3600 = 2.7 hours just to type 1000 lines of code. Programming is of course not typing, but a mental activity first and foremost. Let's say he is incredible smart  and helped by copy and past, so on average he uses 90 seconds to program one line. That is, 25 hours. Of course it will take a few days to create a 1000 line C program that does anything useful.
And of course I know that "a few hours" is just something one say to look cool. I just don't think it is cool.
1. His naive redlock and following discussion on HN a while ago was not convincing, https://news.ycombinator.com/item?id=11065933
You'd be surprised. Especially if you have done C for 1 or 2 decades, you can write 1000 lines in 5-6 hours easily, even without thinking, especially since those lines are for a very specific, and not surprising domain and functionality. It's not like you need novel thinking or to solve some unique challenges to build a text editor of this level. It reads and saves text files, moves the cursor around, and does some crude syntax highlighting. Big fucking deal.
Most of those lines, of course, are also quite easy to fill given C's verbose nature, e.g implementing a few standard data structures you'll need can easily fill 200 or more lines.
>And of course I know that "a few hours" is just something one say to look cool. I just don't think it is cool.
You keep insisting that he lied, without proof. That's untactful. You also keep acting as if this is some huge feat that nobody can pull off and people can only claim to do for "coolness factor".
Are moderns developers so out of touch with C?
"In Oct. of 1978, a month after introduction, Barnaby began coding Wordstar with new features. According to Rubenstein, who carefully tracked Barnaby’s work, it took four months to code Wordstar. This was done in assembler from scratch. Only 10-percent of Wordmaster code was used. That was the text buffering algorithms. In four months Barnaby wrote 137,000 lines of bullet-proof assembly language code. Rubenstein later checked with some friends from IBM who calculated Barnaby’s output as 42-man years."
Lines of code is surely a measurement, which makes the use of 'less' here acceptable.