Reference implementations of medium sized applications are incredibly useful for leveling up as a programmer. While there are many large successful open source applications, many are overwhelming to read and learn from.
Having something that outlines the key features and components and which ignores the important but complicated edge cases assists in keeping the attention focused.
Now if there are annotation within the source code, that would be truely incredible.
Minix (mini Unix) is a teaching operating system that goes with the well known os book "Operating Systems Design and Implementation". We used it at Cal. Very fun.
Corrode is absolutely incredible. This file is literate Haskell, which means there's more documentation than code (I guess), and it transforms C into Rust.
Wholeheartedly agree. Making my own lisp was an eye opener on how programming languages work - and that's after I've read a lot of theory on the matter.
By the way, is there are similar resource for building your own relational SQL-based database?
I found that another hard thing that feels like a prerequisite for leveling up further is getting the feel for design/architecture of medium-sized systems. There's a pretty awesome resource for that particular need - the series of books called "The Architecture of Open Source Applications".
I'm just through the few first chapters of the first book, and I must say it's absolutely amazing. Each chapter gives some understanding of the thought process people designing (and iterating on) a known open-source project had.
> getting the feel for design/architecture of medium-sized systems
Yes. This is exactly the kind of thing I was once looking for, only I didn't know how best to phrase at the time. Think I've since found some of the details I needed then, but will look into these nonetheless and see what I missed, if anything.
> While there are many large successful open source applications, many are overwhelming to read and learn from.
As long as the first commit isn't something like 'import to git' or 'add the code' (which seem to be tragically frequent) I find VCS a huge help here. The problem is that large OSS applications are (tautalogically) large. VCS allow cutting it back, and showing the evolution.
A trivial thing, but README.md for me says "Micro Emacs in D", where it should say "Micro Emacs in C" (the repo description on Github is correct though).
It's my primary editor. I'm so used to it I don't even know what the commands are - I just watch my fingers do it.
The first thing I do with a new system is port ME to it. I'll use vi to do what's necessary to get there (usually get ssh working so I can edit the files with ME on another machine).
I've worked out how to do syntax highlighting on it, but never got around to doing it.
Another thing to like is it has no configuration files. This mattered a great deal in the DOS days because floppies were so slow! But even today, who wants to futz with such? If it needs configuring, I just tweak the code and recompile it.
Back in the 80s, I handled configuration by having ME directly patch the ME executable. (This was a trick I learned from the old ADVENT Fortran game.) It was marvelously simple and bulletproof to do that.
Unfortunately, programs that patched their own executables became huge no-nos as malware took off, and I had to abandon that.
I wrote quite a few DOS programs in the late 80's/early 90's that used ini files appended to the .exe as the configuration. All you had to do was run `copy prog.exe + config.ini program.exe` to build a single file that could be passed around without worrying about either a lost or changeable config file. Your code just needed to read its own exe header to figure out where to offset into it to pull out the ini contents after opening the file in read-only mode. It worked very well for apps where you didn't want users to mess with the config.
Mine was a matter of grouping the global variables for configuration together. Take the address of it, compute the offset of that address in the .exe file, and write.
It's my birthday today and after a peaceful morning routine I hadn't yet decided what I would do today except that I would do whatever I felt like doing. I felt like writing a text editor in C.
I think Kilo is a great little project, well-structured and very educational.
Another useful resource I've relied upon in the past, dates back to the 1990s: Freyja, which is Craig Finseth's emacs-like editor written in C.
Here is a list of features:
* deletions are automatically saved into a "kill buffer"
* ability to edit up to 11 files at once
* ability to view two independent windows at once
* integrated help facility
* integrated menu facility, with help on all commands
* can record and play back keyboard macros
* supports file completion and limited directory operations
* includes a fully-integrated RPN type calculator
It was designed for MS-DOS with the Cygwin terminal library.
I found the architecture to be very clean, and it is well explained in Finseth's classic book ("The Craft of Text Editing"). The book is worth reading even if you never touch the code: http://www.finseth.com/craft/
It uses a multi-buffer architecture roughly similar to Walter Bright's text editor (see sibling posting). (I knew about Finseth's editor years ago, but was not aware of Bright's work until now, thanks Walter!)
Scite is a barebone open source text editor created by Neil Hodgson to exercise his "Scintilla" text-editor c++ library which is used in others like notepad++.
In hindsight, I would have a bit more caution programming text editors. I started tweaking and modifying Scite years ago, it was very interesting but it was no small undertaking and I came to understand why Neil advised in the support forum, to customise it using the inbuilt Lua scripting. Im still using this 6 year old customised version of Scite that I never managed to sync with the latest version, and it has 10 thousand lines of custom Lua facilities like file encryption, navigation panels, multi-edit mode etc.. which I wrote and stabilised a few years ago. I rarely venture to alter it now that I am at last comfortable with it, but its going to need serious attention sooner or later...
Okay, I won't lie, this is a bit of a side-swipe but...
... it sounds like you kind of wanted emacs. One of the most impressive things I find about emacs (especially since semi-proper packages became a thing) is just how easy it is to get stuff that is 5-10-15 years old working on it. No word of a lie, it's amazing how they've managed to break so little over the years.
No I appreciate the tip and have often considered diving into Emacs or Vim. Im very fond of the Scite and Lua combo as well now, and i would like to have the time to share and develop it more than to set up on a new system - but yes those other systems do look good...
Yes its great --a super efficient and fast little VM and comfortable syntax and scoping. I realised how great Lua is for separating user-complexity from an applications core as my customisations got more substantial.
Over at howl.io we've been working on another Lua/moonscript based editor. Incidentally it used scintilla as well until we switched to an in-house engine called aullar. The author wrote a blog post about it: https://howl.io/blog/2016/05/26/introducing-aullar.html
Yes it's great. Interfacing with new libraries is easy with LuaJIT's FFI and implementing low level stuff works well too (e.g. something like reverse find on a string basically gets JITted to C speed).
I also tried to make an editor 5 years ago, because I was not satisfied by either notepad++ or sublime text. I was checking out notepad++'s code, and I was quite amazed by the fact that making a text editor was not some simple task.
The syntax highlighting functionality alone is a combination of something as complex as what a compiler/parser does, and you have to do it almost in real time.
So if you want to color every different part like operators, symbols, braces, with a different color, and you try to do this on C++, it is not going to be a small task...
> So if you want to color every different part like operators, symbols, braces, with a different color, and you try to do this on C++, it is not going to be a small task...
I wrote an open source editor with some buddies 10 years ago and still use it on a daily bases. That was built around codemax. A month ago, me and one of those friends picked it up again for a new revision and started retooling using Scintilla. Scintilla is an amazing control, very well documented and it has a lot of features.
Some of the standard features from codemax have to be rebuilt, but I'm still very impressed.
Oh and before somebody plugs their favorite editor and why I should be using that instead, if it doesn't know DataFlex it won't help ;)
Quickly looked at your source without the slightest knowledge of Nim language. It was certainly Python-like in ease of reading like some here told me. Nice, clean look to it vs the C stuff. Exception is types.nim file that just looks syntactically rougher than others with the asterisks. It looks like class or struct definitions but I'm curious if the asterisk has an effect like it does in C or what's it do?
The asterisks are what define a symbol as "exported" from a module -- every symbol is private to the module scope by default, but able to be exported by applying the asterisks to it; types.nim is funky because I was exploring a slightly different file/module structure (and having a singular place for top-level shared types that most other modules import is quite useful at times, and gets around circular dependencies), except it does end up looking slightly odd!
That's it. For the most part, one would just export the symbols from given modules as needed (and a lot of the properties on some of the ref object types are needlessly exported, too, which makes it worse)
One other thing is that the {.compile.} pragma in term.nim is not needed anymore, as Nim's stdlib has added a lot of those in[0], but it does show how easy it is to bridge between the two languages (and I'm not much of a C developer!)
Under 50 lines for a text editor written in K by the language's author. Way beyond my present understanding, but the promise of very small, powerful code is incredibly attractive.
Just to be that guy. Yeah, it's cool that the language author built a text editor in under 50 lines, and there's a sort of geeky hacky appeal to trying to cram as much functionality as possible into as small a space as possible.
But what does it actually mean in terms of programming? How maintainable is "small code"? How readable is it? (Well, you answered that question already.) How hackable is it?
It's a curiosity, and a really fun one! But it's not practical.
But super-compact code could be very practical/readable/hackable, as long as there's the prerequisite knowledge. Fewer symbols means less complexity to parse. This works, provided that those symbols map to powerful operators that can be really understood and effectively combined to produce the desired outcome.
And there's no need to scroll: perceive everything in one glance!
> But what does it actually mean in terms of programming?
Without trying to be too trite, what does this question mean in terms of English?
> How maintainable is "small code"?
Once you get the hang of it it's as maintainable as any other code base
> How readable is it? (Well, you answered that question already.)
There is a learning curve, but the code is actually reasonably readable. It takes time to get used to many operations occurring in one line but there are benefits (eg you can see everything that the CTRL-Z function for undo does at a glance).
> How hackable is it?
Again, I'm not sure what you're asking here.
The editor is very bare bones so isn't a great example of production code. In a real system generally people are a bit more verbose.
I wouldn't say the code is really that small in its language context, which is why comparing code by lines is inherently fallacious.
It's just that a large percentage of languages are quite similar in how they're structured. Since Pascal and at least until Java/C#, most mainstream languages ended up roughly doing "one thing" per line. Quite often one function call or simple mathematical operation. Then each function or block of a larger one does one larger thing. And so forth.
Code and/or languages that break that paradigm are often confusing to "switchers" and thus often abandoned or maligned way too early.
But most often, they're just scanned differently.
Assembly would be the opposite end. It basically takes "do one thing per line" to the extreme. But quite often, experienced asm programmers scan the program by blocks, as some patterns are quite common or you find some constant/string to attach your focus to, then continue from there into the details.
Forth programmers obviously read slightly differently, due to the high level of decomposition and the stack based nature (fewer parameters).
Lisp looks a bit weirder at the first glance, but I wouldn't even say that it's read all that differently from the Algol family, if written imperatively enough.
Functional code, in almost any language, often has to be read differently, as a lot of things can happen in one line.
APL and some DSLs (regular expressions for example) are the opposite end of the spectrum. But line length would be the wrong axis to judge things, the amount of operations isn't necessarily that much smaller.
Data exchange (arrays vs. stacks vs. function parameters) is the bigger change, as is symbolic density (APL symbols vs J shorthand vs. function names vs. HiHowYouDoingIAmAnAbstractJavaBeansFactoryConsumerImplementationNiceToMeetYou)
It is, but the little I've seen of K implies that it's small size comes from a combination of two things:
1) A standard library / set of operators that are a very good fit for the typical domains it works on.
2) Minimizing symbol length.
E.g. I translated one example I saw into Ruby, and ended up with something of similar length once I 1) implemented equivalent methods, 2) dispensed with all idioms for how to write Ruby and went for single character variable names and method names etc.
In other words, there's nothing particularly "magic" there.
K code gets to where it is largely by because its author and users are willing to violate every convention from other languages in terms of how to write and structure code in pursuit of a philosophy that is fundamentally different in terms of e.g. focusing more on code size.
That could be a good thing, but I'm not convinced that the extremely sparse code is worth the (to me at least) extreme lack in readability.
Code golf can be fun in any language, but it seems few of us have gone back to writing other code and decided it's worth aiming for code that small. In fact, I've more than once rewritten code to be longer because it made it easier to read.
That said, there are good parts in terms of language constructs etc. that'd be worth learning from. If only it wasn't so incredibly annoying to decipher the code (yes, I'm sure it gets faster when you get used to it).
If you are looking for an interesting project that uses terminal input modes try writing a command line utility that reads in a password correctly. (eg. Masks the password input so it does not appear on screen whilst it is being typed, prevents someone from scrolling up in terminal and copy/pasting the typed password and zeros out the password after use to prevent it being visible in process address space).
It is surprisingly tricky to get right. There used to be a POSIX function in the c standard library - "getpass" to handle this but the implementation was not thread safe and thus it was depreciated from posix spec - the only portable way I know to do this is to "roll your own code" using termios - not ideal.
Yeah, this is still a problem. Trying to write a simple CLI in node and the library I'm using to prompt a user for their credentials only replaces the user's input with asterisks. There is still an open issue for properly masking the password input: https://github.com/SBoudrias/Inquirer.js/issues/177
I'm curious if anyone here regularly codes in a text editor they wrote themselves?
I've often thought of coding one for fun, with no intention to share it, just for the purpose of having a long-term project that evolves along with my skills. I've never made time for it, but I still consider it once in a while.
I would not say that I use it regularly, but I have a somewhat working version of what I remember to be the Norton Editor in C++ / ncurses. It was 100% motivated by seeing antirez's artistic triumph, and my effort is sadly lacking in comparison. Still, I look at it every few weeks and add a new feature, and now I am mostly editing the code in the editor itself, which is gratifying.
I actually need to get off my duff and code what I really want, which is a version of what I remember the best parts of the Norton Editor implemented as an emacs mode. I have great memories of writing pascal code in ne.com, so it is a big nostalgia item for me.
I had a copy that I found on an old floppy about 15 years ago and I tried to see if I could use it in a Windows command window, but unfortunately it did not seem to work at all. Now that you mention a virtual machine though, I regret that I did not try and setup a FreeDOS VM.
Googling "norton editor manual pdf" lead me to a few old copies of the manual, so that is what I have used as a guide in my work, but most of it is just driven by how I remember it.
I made significant changes to antirez's kilo editor myself, adding in support for Lua-based scripting. I use that for composing emails, again in a lua-based mail client that I wrote myself.
For coding though? I usually use emacs. It's just so damn customizable..
Regularly? No, but I got https://github.com/oconnor0/build-your-own-editor to the point that I use it for small editing tasks or occasional remote work. I have a few commits that were done entirely in it. I don't think I'd use it over vi except that I wrote it and want to use it. It also has keybindings far closer to what I'm used to in Sublime Text 3.
I do, sort of. I bought a text editor a number of years ago that was very popular. I still maintain it and use it daily and have often thought about putting out a new version. I have it running on many OS's and devices now. I have also added a lot of features specific to what I wanted. I'm not really sure if they are useful to others or not.
Example: I have an iPad version where I can use an Apple Pencil and handwrite my code on the screen. To me it is very useful when my wife is driving me someplace and I still want to work. Recline in the passenger seat and code.
I don't know of others that do this at this time. I didn't actually do any research. It is something that I wanted for myself and the way that I like to work. I prefer to hand write as much as possible. I was trying out a Surface Book just because I could hand write my e-mails!
It is working pretty well for me. I used OpenAI and basically started asking my friends to hand write samples for the NN to learn from. They write them various levels of neatness and various slants, font size, etc. I store the handwriting strokes as a series of points and convert to digital text when they are ready. I save the handwriting along side the digital version. It is possible to hand write, then come back days later and your work is still there. Maybe I could make a video to show if it is useful.
QEdit's configurability was amazing. Back in the early 90s I had a completely hand built config, a feat I have never dared to repeat with subsequent editors. I wrote a lot of code in it at home, and nagged my employer into buying some licenses for the sophisticated programmers among the staff (it was a bank, so not many, but a few!). I would edit locally and FTP to the server rather than use vi directly there!
When my computer illiterate aunt decided to write a book back in the early 90s, I set her up with a minimalistic QEdit, a few bat files to perform backups, versioning, etc automatically and a floppy disk for each day of the week plus a daily backup one. Simple instructions and process, simple editing setup, and two years later the 670-page book was finished and published, and she was ready to actually learn how to use a computer.
So a big thank you for creating such an excellent tool!
I used to ~20 years ago. It was a curses-based mini-emacs in C; the fun part was a notebook-style interface to a Forth-like language I added in. Eventually I wanted the same kind of interface for Python programming in Emacs, and moved on to that with https://github.com/darius/halp.
I got fed up with the standard offerings back in '07 or so and hammered out my idea of a code editor that's perfect for me over a long weekend. It mmaps files initially for instant response, it has a small sensible command set that I can remember completely, it depends on nothing more than the standard C library and a terminal emulator, and it's not many more lines of code than some Emacs configuration files that I've seen. I still use it for everything.
If you're so sensitive to superficial syntactic issues you're gonna miss out on a lot of reading/learning pleasure in this life. (It's one of my pet peeves: http://akkartik.name/post/readable-bad)
I was taking about the ability to debug code. Various IDEs/compilers have sometimes issues and bugs on multistatement lines in DWARF/etc. I've worked on a low level debugger, so it was a big problem, even few years back.
Two function calls plus arithmetics plus step-return.
Depending on the debugger interface(eclipse with gdb, vs, etc), one will have to press some form of Step 1 to 4 times to advance the line. Depending on the complier that was supposed to provide correct debug info (GCC vs msvcc vs xlc) and bugs, these steps may or may not work.
It is short, but when you do multi platform code, a real pain to deal with.
Consider aix and Linux multiplatform code for one of my past projects. My choice would have been:
1. Step and maybe hit a bug, msg the complier team, proceed writing register values on paper.
2. Break up the line, recompile. Few minutes on Linux, over half an hour on aix.
This is a pretty common way to write C, though, it's not something specific to this particular codebase. You just had a non-standard use case where you were constantly running into low-level bugs. (In an embedded platform?) If you aren't in that domain anymore, it's worth revisiting the trade-off. In most domains, gdb's continue command is super useful.
No. Parent is correct. Writing code just to show how clever you are, at the expense of others who need to debug and understand it later, is poor taste.
It's pretty weird to see "correct" justified by calling the opposite "poor taste". We're talking about a mismatch between a style of code and certain tools; a better answer is to use tools that work well with the style of code you like.
I agree that naming expressions often helps understanding, and that's worthwhile -- I guess I just disagree about this code at first glance. Maybe if I tried to delve into it.
Thanks for making this! It is obviously a labor of love. This kind of incremental building is a lot of work, but adds a revealing dimension not seen in a flat annotated source.
The next fun experiment is to handle gigabyte files without undue performance troubles with a lively ui thread! This is where scintilla et al run into limits.
Scintilla is an editor for source code. Normally code isn't gigabytes in size and doesn't need a lexer, code folding or syntax highlighting. Not saying that it can't be done, but if you open a file like that then turning off those features would already make it a lot easier to handle huge files.
Just have to say, this is ridiculously detailed, which is great. I'm not looking to build a text editor in C, but I learned a good amount just skimming the first few chapters.
Great site, great presentation, thanks for digging into it with so much detail.
Would something like this be a way for a beginner to C (barely any experience) to get their feet wet? Or is there an expectation of basic familiarity with C already?
Yep, lots of Ruby/PHP/Python/Javascript, some Java. So I can comfortably read syntax in most languages, but obviously none of the languages I've used are as low level as C.
Yeah, brush up on pointers a tad bit (just have a look at some youtube videos, honestly), if you are uncomfortable with them, and then you should be good to go.
I'm working on an editor in JavaScript. You would be surprised how fast string operations, like concatenation, are in JavaScript! You can hold the entire buffer in a String! While browsers renders text very well, the DOM is relative slow to interact with, but there are other ways to render in JavaScript, for example the Canvas, or into a terminal, or even stream a video, or talk directly to a display.
marginally relevant: I was looking for a terminal text editor for git commits and other similarly simple tasks: my only requirement is that I can save&leave with ^D. Any suggestions?
You can add simple Emacs-like keybindings by changing that into
$ echo 'rlwrap cat > "$@"' >editor
Or just learn ed:
$ GIT_EDITOR=ed git commit --amend -a
256
1c
stuff and more stuff
.
w
271
[master c5092a6] stuff and more stuff
Date: Thu Apr 6 12:58:18 2017 +0200
1 file changed, 1 insertion(+)
(the numbers are ed telling me how much was read and written; `1c` means change the first line; `.` means I'm done inserting (go back to command mode) and `w` means write/save; exit with ^D)
for some strange reason the 'Fira Mono' google font is displaying all &s as |s. Anyone else seeing this? Cool book though, I'm going to work through it this weekend.
You may have a broken version of the font locally. If you download the offline version of the tutorial, it'll come with all the fonts it uses and hopefully will work.
For better portability, terminfo should be used instead of using hard-coded terminal sequences. Otherwise, this is a really great intro. I liked the beginning with how to put your configure your terminal.
Reference implementations of medium sized applications are incredibly useful for leveling up as a programmer. While there are many large successful open source applications, many are overwhelming to read and learn from.
Having something that outlines the key features and components and which ignores the important but complicated edge cases assists in keeping the attention focused.
Now if there are annotation within the source code, that would be truely incredible.
Do you have anything similar that you would recommend?
Xv6 is a pedagogical implementation of UNIX v6 that MIT created for an operating systems course.
https://pdos.csail.mit.edu/6.828/2012/xv6.html
http://www.buildyourownlisp.com/contents
Minix (mini Unix) is a teaching operating system that goes with the well known os book "Operating Systems Design and Implementation". We used it at Cal. Very fun.
was about to post a link. Minix is great.
This comes to mind:
https://cheatdeath.github.io/research-bittorrent-doc/
Do you know a good example which implements a GUI, e.g. a drawing program or a graphical editor?
You could check out http://www.catch22.net/tuts/neatpad
It is Windows specific but very informative.
https://github.com/jameysharp/corrode/blob/master/src/Langua...
Corrode is absolutely incredible. This file is literate Haskell, which means there's more documentation than code (I guess), and it transforms C into Rust.
> This file is literate Haskell, which means there's more documentation than code (I guess)
That's the intent, but to the compiler, the meaning of literate Haskell is that comments are the default, and only lines starting with > contain code
I know. The "I guess" was because I hadn't actually counted the lines to see if there were more comments.
Wholeheartedly agree. Making my own lisp was an eye opener on how programming languages work - and that's after I've read a lot of theory on the matter.
By the way, is there are similar resource for building your own relational SQL-based database?
Maybe peek at H2? http://h2database.org
I found that another hard thing that feels like a prerequisite for leveling up further is getting the feel for design/architecture of medium-sized systems. There's a pretty awesome resource for that particular need - the series of books called "The Architecture of Open Source Applications".
http://aosabook.org/en/index.html
(The books are CC and free to read on-line :))
I'm just through the few first chapters of the first book, and I must say it's absolutely amazing. Each chapter gives some understanding of the thought process people designing (and iterating on) a known open-source project had.
Ooh, the matplotlib chapter looks super-relevant for a project I'm working on. Thanks!
> getting the feel for design/architecture of medium-sized systems
Yes. This is exactly the kind of thing I was once looking for, only I didn't know how best to phrase at the time. Think I've since found some of the details I needed then, but will look into these nonetheless and see what I missed, if anything.
Thanks!
Both, the tutorial and the aosabook are very, very, helpful ressources. We certainly need more like that.
> While there are many large successful open source applications, many are overwhelming to read and learn from.
As long as the first commit isn't something like 'import to git' or 'add the code' (which seem to be tragically frequent) I find VCS a huge help here. The problem is that large OSS applications are (tautalogically) large. VCS allow cutting it back, and showing the evolution.
Here's one from the 1980s, which I still use and keep up to date:
https://github.com/DigitalMars/me
and translated to D:
https://github.com/DigitalMars/med
Nice! Btw, I think you are missing browse[.c|.o] for SRC|OBJ in osx.mak
A trivial thing, but README.md for me says "Micro Emacs in D", where it should say "Micro Emacs in C" (the repo description on Github is correct though).
That's it, I'm upgrading to Windows ten.
Still use for occasional quick edits instead of vi/notepad or for proper, longer development tasks?
It's my primary editor. I'm so used to it I don't even know what the commands are - I just watch my fingers do it.
The first thing I do with a new system is port ME to it. I'll use vi to do what's necessary to get there (usually get ssh working so I can edit the files with ME on another machine).
I've worked out how to do syntax highlighting on it, but never got around to doing it.
Linus Torvalds also has his own version of MicroEmacs:
https://git.kernel.org/pub/scm/editors/uemacs/uemacs.git
I wonder if he still uses it?
If he publicly mentioned a change, I haven't seen it. His turd-polishing comment about micro-emacs is a couple of years old at this point.
Thanks for sharing. Seeing a working emacs clone that compiles to a 66k executable is pretty awesome.
Another thing to like is it has no configuration files. This mattered a great deal in the DOS days because floppies were so slow! But even today, who wants to futz with such? If it needs configuring, I just tweak the code and recompile it.
Back in the 80s, I handled configuration by having ME directly patch the ME executable. (This was a trick I learned from the old ADVENT Fortran game.) It was marvelously simple and bulletproof to do that.
Unfortunately, programs that patched their own executables became huge no-nos as malware took off, and I had to abandon that.
I wrote quite a few DOS programs in the late 80's/early 90's that used ini files appended to the .exe as the configuration. All you had to do was run `copy prog.exe + config.ini program.exe` to build a single file that could be passed around without worrying about either a lost or changeable config file. Your code just needed to read its own exe header to figure out where to offset into it to pull out the ini contents after opening the file in read-only mode. It worked very well for apps where you didn't want users to mess with the config.
That's an interesting technique.
Mine was a matter of grouping the global variables for configuration together. Take the address of it, compute the offset of that address in the .exe file, and write.
It's my birthday today and after a peaceful morning routine I hadn't yet decided what I would do today except that I would do whatever I felt like doing. I felt like writing a text editor in C.
Happy (belated) birthday, friend! I hope you had a good day.
How far did you end up getting with the C editor? :)
I think Kilo is a great little project, well-structured and very educational.
Another useful resource I've relied upon in the past, dates back to the 1990s: Freyja, which is Craig Finseth's emacs-like editor written in C.
Here is a list of features:
It was designed for MS-DOS with the Cygwin terminal library.
I found the architecture to be very clean, and it is well explained in Finseth's classic book ("The Craft of Text Editing"). The book is worth reading even if you never touch the code: http://www.finseth.com/craft/
It uses a multi-buffer architecture roughly similar to Walter Bright's text editor (see sibling posting). (I knew about Finseth's editor years ago, but was not aware of Bright's work until now, thanks Walter!)
The Freyja source can be downloaded from: http://www.finseth.com/parts/freyja.php
Look for the link to "freyja30.exe" which turns out to be freyja30.zip (not an executable).
Scite is a barebone open source text editor created by Neil Hodgson to exercise his "Scintilla" text-editor c++ library which is used in others like notepad++.
In hindsight, I would have a bit more caution programming text editors. I started tweaking and modifying Scite years ago, it was very interesting but it was no small undertaking and I came to understand why Neil advised in the support forum, to customise it using the inbuilt Lua scripting. Im still using this 6 year old customised version of Scite that I never managed to sync with the latest version, and it has 10 thousand lines of custom Lua facilities like file encryption, navigation panels, multi-edit mode etc.. which I wrote and stabilised a few years ago. I rarely venture to alter it now that I am at last comfortable with it, but its going to need serious attention sooner or later...
Okay, I won't lie, this is a bit of a side-swipe but...
... it sounds like you kind of wanted emacs. One of the most impressive things I find about emacs (especially since semi-proper packages became a thing) is just how easy it is to get stuff that is 5-10-15 years old working on it. No word of a lie, it's amazing how they've managed to break so little over the years.
No I appreciate the tip and have often considered diving into Emacs or Vim. Im very fond of the Scite and Lua combo as well now, and i would like to have the time to share and develop it more than to set up on a new system - but yes those other systems do look good...
Those features sound really nice. Any links/screenshots?
Ive put just a couple of snaps here: http://imgur.com/a/QMhpf
I really must get round to sharing the source but it needs a bit of preparation.
Lua is great for extensions, isn't it?
I forked antizez's editor to add Lua support, and posted it here in the past:
https://github.com/skx/kilua/
That works well for me, even with the minor omissions, and is well-paired with my console-based mail-client - again scripted by lua:
https://github.com/lumail/lumail2/
Yes its great --a super efficient and fast little VM and comfortable syntax and scoping. I realised how great Lua is for separating user-complexity from an applications core as my customisations got more substantial.
Over at howl.io we've been working on another Lua/moonscript based editor. Incidentally it used scintilla as well until we switched to an in-house engine called aullar. The author wrote a blog post about it: https://howl.io/blog/2016/05/26/introducing-aullar.html
I want to get into that when I get time - an editor with LuaJIT - that should be brilliant.
Yes it's great. Interfacing with new libraries is easy with LuaJIT's FFI and implementing low level stuff works well too (e.g. something like reverse find on a string basically gets JITted to C speed).
I also tried to make an editor 5 years ago, because I was not satisfied by either notepad++ or sublime text. I was checking out notepad++'s code, and I was quite amazed by the fact that making a text editor was not some simple task.
The syntax highlighting functionality alone is a combination of something as complex as what a compiler/parser does, and you have to do it almost in real time.
So if you want to color every different part like operators, symbols, braces, with a different color, and you try to do this on C++, it is not going to be a small task...
Also something you learn about text editors is the rope data structure. https://en.wikipedia.org/wiki/Rope_(data_structure)
> So if you want to color every different part like operators, symbols, braces, with a different color, and you try to do this on C++, it is not going to be a small task...
For a lot of modes, Emacs does this using regex.
Running a regex each time you type a character seems a little heavy to me...
Regex'ing languages like HTML or C++ can be quite mind breaking... I think.
Ropes are pretty sweet. I still prefer a piece table, just because of the sheer simplicity.
I wrote an open source editor with some buddies 10 years ago and still use it on a daily bases. That was built around codemax. A month ago, me and one of those friends picked it up again for a new revision and started retooling using Scintilla. Scintilla is an amazing control, very well documented and it has a lot of features.
Some of the standard features from codemax have to be rebuilt, but I'm still very impressed. Oh and before somebody plugs their favorite editor and why I should be using that instead, if it doesn't know DataFlex it won't help ;)
Neat! I have been trying to, in Nim, but I've had so little experience working with raw terminals and the IOCTL handles, I've been struggling!
https://github.com/girvo/te
This looks like a great tutorial to work through with it :)
Quickly looked at your source without the slightest knowledge of Nim language. It was certainly Python-like in ease of reading like some here told me. Nice, clean look to it vs the C stuff. Exception is types.nim file that just looks syntactically rougher than others with the asterisks. It looks like class or struct definitions but I'm curious if the asterisk has an effect like it does in C or what's it do?
The asterisks are what define a symbol as "exported" from a module -- every symbol is private to the module scope by default, but able to be exported by applying the asterisks to it; types.nim is funky because I was exploring a slightly different file/module structure (and having a singular place for top-level shared types that most other modules import is quite useful at times, and gets around circular dependencies), except it does end up looking slightly odd!
I appreciate it. So, it looks weird because it's an experiment with something non-standard? Makes sense. Things stay clean overall.
That's it. For the most part, one would just export the symbols from given modules as needed (and a lot of the properties on some of the ref object types are needlessly exported, too, which makes it worse)
One other thing is that the {.compile.} pragma in term.nim is not needed anymore, as Nim's stdlib has added a lot of those in[0], but it does show how easy it is to bridge between the two languages (and I'm not much of a C developer!)
[0] https://nim-lang.org/docs/terminal.html
Ah. That link is the cleaner look I was expecting. Makes sense.
1000 lines of code is considered small. But check this out
http://kparc.com/edit.k
Under 50 lines for a text editor written in K by the language's author. Way beyond my present understanding, but the promise of very small, powerful code is incredibly attractive.
Just to be that guy. Yeah, it's cool that the language author built a text editor in under 50 lines, and there's a sort of geeky hacky appeal to trying to cram as much functionality as possible into as small a space as possible.
But what does it actually mean in terms of programming? How maintainable is "small code"? How readable is it? (Well, you answered that question already.) How hackable is it?
It's a curiosity, and a really fun one! But it's not practical.
Fine questions.
But super-compact code could be very practical/readable/hackable, as long as there's the prerequisite knowledge. Fewer symbols means less complexity to parse. This works, provided that those symbols map to powerful operators that can be really understood and effectively combined to produce the desired outcome.
And there's no need to scroll: perceive everything in one glance!
> But what does it actually mean in terms of programming?
Without trying to be too trite, what does this question mean in terms of English?
> How maintainable is "small code"?
Once you get the hang of it it's as maintainable as any other code base
> How readable is it? (Well, you answered that question already.)
There is a learning curve, but the code is actually reasonably readable. It takes time to get used to many operations occurring in one line but there are benefits (eg you can see everything that the CTRL-Z function for undo does at a glance).
> How hackable is it?
Again, I'm not sure what you're asking here.
The editor is very bare bones so isn't a great example of production code. In a real system generally people are a bit more verbose.
I wouldn't say the code is really that small in its language context, which is why comparing code by lines is inherently fallacious.
It's just that a large percentage of languages are quite similar in how they're structured. Since Pascal and at least until Java/C#, most mainstream languages ended up roughly doing "one thing" per line. Quite often one function call or simple mathematical operation. Then each function or block of a larger one does one larger thing. And so forth.
Code and/or languages that break that paradigm are often confusing to "switchers" and thus often abandoned or maligned way too early.
But most often, they're just scanned differently.
Assembly would be the opposite end. It basically takes "do one thing per line" to the extreme. But quite often, experienced asm programmers scan the program by blocks, as some patterns are quite common or you find some constant/string to attach your focus to, then continue from there into the details.
Forth programmers obviously read slightly differently, due to the high level of decomposition and the stack based nature (fewer parameters). Lisp looks a bit weirder at the first glance, but I wouldn't even say that it's read all that differently from the Algol family, if written imperatively enough.
Functional code, in almost any language, often has to be read differently, as a lot of things can happen in one line.
APL and some DSLs (regular expressions for example) are the opposite end of the spectrum. But line length would be the wrong axis to judge things, the amount of operations isn't necessarily that much smaller.
Data exchange (arrays vs. stacks vs. function parameters) is the bigger change, as is symbolic density (APL symbols vs J shorthand vs. function names vs. HiHowYouDoingIAmAnAbstractJavaBeansFactoryConsumerImplementationNiceToMeetYou)
It is, but the little I've seen of K implies that it's small size comes from a combination of two things:
1) A standard library / set of operators that are a very good fit for the typical domains it works on.
2) Minimizing symbol length.
E.g. I translated one example I saw into Ruby, and ended up with something of similar length once I 1) implemented equivalent methods, 2) dispensed with all idioms for how to write Ruby and went for single character variable names and method names etc.
In other words, there's nothing particularly "magic" there.
K code gets to where it is largely by because its author and users are willing to violate every convention from other languages in terms of how to write and structure code in pursuit of a philosophy that is fundamentally different in terms of e.g. focusing more on code size.
That could be a good thing, but I'm not convinced that the extremely sparse code is worth the (to me at least) extreme lack in readability.
Code golf can be fun in any language, but it seems few of us have gone back to writing other code and decided it's worth aiming for code that small. In fact, I've more than once rewritten code to be longer because it made it easier to read.
That said, there are good parts in terms of language constructs etc. that'd be worth learning from. If only it wasn't so incredibly annoying to decipher the code (yes, I'm sure it gets faster when you get used to it).
> extreme lack in readability.
understatement of the year.
Nice guide, especially the terminal raw mode stuff. I haven't seen much on that before, I really appreciate that this guide goes over that.
I've been messing around with a little text editor component myself in golang:
https://github.com/briansteffens/tui/blob/master/editbox.go
For a SQL editor project:
https://github.com/briansteffens/prequel
tui looks pretty interesting! Can you please add a README? I would love to go over the source code :)
Thanks! It's still pretty rough but I'm hoping to put some notes up soon.
If you are looking for an interesting project that uses terminal input modes try writing a command line utility that reads in a password correctly. (eg. Masks the password input so it does not appear on screen whilst it is being typed, prevents someone from scrolling up in terminal and copy/pasting the typed password and zeros out the password after use to prevent it being visible in process address space).
It is surprisingly tricky to get right. There used to be a POSIX function in the c standard library - "getpass" to handle this but the implementation was not thread safe and thus it was depreciated from posix spec - the only portable way I know to do this is to "roll your own code" using termios - not ideal.
see: http://man7.org/linux/man-pages/man3/getpass.3.html note the comment: "This function is obsolete. Do not use it" - there is a heap of potentially vulnerable code out in the wild that uses getpass.
Yeah, this is still a problem. Trying to write a simple CLI in node and the library I'm using to prompt a user for their credentials only replaces the user's input with asterisks. There is still an open issue for properly masking the password input: https://github.com/SBoudrias/Inquirer.js/issues/177
Just getting further into C and this is fascinating. But I still have to share this: http://www.catb.org/esr/writings/unix-koans/editor-wars.html
I'm curious if anyone here regularly codes in a text editor they wrote themselves?
I've often thought of coding one for fun, with no intention to share it, just for the purpose of having a long-term project that evolves along with my skills. I've never made time for it, but I still consider it once in a while.
I would not say that I use it regularly, but I have a somewhat working version of what I remember to be the Norton Editor in C++ / ncurses. It was 100% motivated by seeing antirez's artistic triumph, and my effort is sadly lacking in comparison. Still, I look at it every few weeks and add a new feature, and now I am mostly editing the code in the editor itself, which is gratifying.
I actually need to get off my duff and code what I really want, which is a version of what I remember the best parts of the Norton Editor implemented as an emacs mode. I have great memories of writing pascal code in ne.com, so it is a big nostalgia item for me.
Norton Editor.
Interesting that you mention this. I loved the Norton Editor. I have wanted to for years add a more Norton feel to the text editor that I write.
I wonder if I can still get a copy to play around with and run in a virtual machine. Any idea?
I had a copy that I found on an old floppy about 15 years ago and I tried to see if I could use it in a Windows command window, but unfortunately it did not seem to work at all. Now that you mention a virtual machine though, I regret that I did not try and setup a FreeDOS VM.
Googling "norton editor manual pdf" lead me to a few old copies of the manual, so that is what I have used as a guide in my work, but most of it is just driven by how I remember it.
You might also try dosbox, which is easier to use than a normal VM and works amazingly well.
I made significant changes to antirez's kilo editor myself, adding in support for Lua-based scripting. I use that for composing emails, again in a lua-based mail client that I wrote myself.
For coding though? I usually use emacs. It's just so damn customizable..
Why are you posting the same thing more than once?
Different thread, related topic, same post. Didn't feel out of place.
I've spent enough time tweaking, extending, and rewriting emacs lisp that I sometimes feel like I wrote my own emacs.
I still remember the first time I tried to use a vanilla emacs and was frustrated because all of my customizations were missing... ;-)
I have been careful to always carry a recent copy of my .emacs.d around with me on a thumb drive.
Regularly? No, but I got https://github.com/oconnor0/build-your-own-editor to the point that I use it for small editing tasks or occasional remote work. I have a few commits that were done entirely in it. I don't think I'd use it over vi except that I wrote it and want to use it. It also has keybindings far closer to what I'm used to in Sublime Text 3.
I do, sort of. I bought a text editor a number of years ago that was very popular. I still maintain it and use it daily and have often thought about putting out a new version. I have it running on many OS's and devices now. I have also added a lot of features specific to what I wanted. I'm not really sure if they are useful to others or not.
Example: I have an iPad version where I can use an Apple Pencil and handwrite my code on the screen. To me it is very useful when my wife is driving me someplace and I still want to work. Recline in the passenger seat and code.
That's pretty interesting, care to elaborate on how well that works? Know of any other editors that have that same capability?
I don't know of others that do this at this time. I didn't actually do any research. It is something that I wanted for myself and the way that I like to work. I prefer to hand write as much as possible. I was trying out a Surface Book just because I could hand write my e-mails!
It is working pretty well for me. I used OpenAI and basically started asking my friends to hand write samples for the NN to learn from. They write them various levels of neatness and various slants, font size, etc. I store the handwriting strokes as a series of points and convert to digital text when they are ready. I save the handwriting along side the digital version. It is possible to hand write, then come back days later and your work is still there. Maybe I could make a video to show if it is useful.
Um... Can I use it too? That sounds amazing.
really? I mean, I could probably make a version for folks to test. It only has git support and SFTP.
Committing to git currently works, push works, but sometimes says it fails. Still looking into this.
Color syntax highlighting works with your handwriting, but in the "worksheet" (an interactive shell) it does not yet.
Yea, I think it would be cool to use. The only thing I'm missing on my iPad Pro is a good way to work on programming.
alright, let me see what I can do :-) Contact me if you wish.
Yes, pretty much all of my code is written in an editor called "The Hammer". It is written in DataFlex and some C++ bits and pieces.
I wrote one back in 1984-85 that I called QEdit, and have been using and updating it ever since.
I have several former co-workers that wouldn't use anything but QEDIT/TSE.
QEdit FTW! Thank you! It was my go to editor for ages. Used it to write all my AutoCAD shareware.
It took me forever to unlearn the Wordstar key bindings.
I'll have to look it up.
Thanks for the kind words. I was forced to change the name a few years back (1992) - it is now called TSE, or The Semware Editor.
Unlearn Wordstar key bindings? Isn't that sacrilege? :-)
QEdit's configurability was amazing. Back in the early 90s I had a completely hand built config, a feat I have never dared to repeat with subsequent editors. I wrote a lot of code in it at home, and nagged my employer into buying some licenses for the sophisticated programmers among the staff (it was a bank, so not many, but a few!). I would edit locally and FTP to the server rather than use vi directly there!
When my computer illiterate aunt decided to write a book back in the early 90s, I set her up with a minimalistic QEdit, a few bat files to perform backups, versioning, etc automatically and a floppy disk for each day of the week plus a daily backup one. Simple instructions and process, simple editing setup, and two years later the 670-page book was finished and published, and she was ready to actually learn how to use a computer.
So a big thank you for creating such an excellent tool!
I used to ~20 years ago. It was a curses-based mini-emacs in C; the fun part was a notebook-style interface to a Forth-like language I added in. Eventually I wanted the same kind of interface for Python programming in Emacs, and moved on to that with https://github.com/darius/halp.
I just tried halp, it seems pretty cool, thank you for making it available!
You're welcome! It does hardly anything compared to systems like IPython, but I'm reluctant to learn interfaces.
A long time ago I put some components together and built ProgEdit using Delphi, with resources that reminded me of SideKick Plus.
I've used that editor daily to write source code, mainly in Clipper, and I think some of my coworkers used that too.
But then I moved on and knew vi, and now I can't take my hands from the center row :)
ProgEdit: https://sourceforge.net/projects/cpstools/
SynEdit, the base of the editor: https://github.com/SynEdit/SynEdit (confession: I was only a user of SynEdit, not a developer).
I got fed up with the standard offerings back in '07 or so and hammered out my idea of a code editor that's perfect for me over a long weekend. It mmaps files initially for instant response, it has a small sensible command set that I can remember completely, it depends on nothing more than the standard C library and a terminal emulator, and it's not many more lines of code than some Emacs configuration files that I've seen. I still use it for everything.
Cool. Is it public? What data structure do you use for the modifications?
It's called aoeui, it's now on github, and it uses simple gap buffers.
If you enjoy "redis style" C code, take a look at vis https://github.com/martanne/vis
Long return statements and everything crammed into one line is horrible coding approach. It makes it a pain to debug.
Don't do it.
Example?
It's in the parent's "redis style" link.
If you're so sensitive to superficial syntactic issues you're gonna miss out on a lot of reading/learning pleasure in this life. (It's one of my pet peeves: http://akkartik.name/post/readable-bad)
I was taking about the ability to debug code. Various IDEs/compilers have sometimes issues and bugs on multistatement lines in DWARF/etc. I've worked on a low level debugger, so it was a big problem, even few years back.
Fair enough. But where do you see multistatement lines in the link?
For example: https://github.com/martanne/vis/blob/master/buffer.c
bool buffer_prepend0(Buffer buf, const char data) { return buffer_prepend(buf, data, strlen(data) + (buf->len == 0)); }
Two function calls plus arithmetics plus step-return.
Depending on the debugger interface(eclipse with gdb, vs, etc), one will have to press some form of Step 1 to 4 times to advance the line. Depending on the complier that was supposed to provide correct debug info (GCC vs msvcc vs xlc) and bugs, these steps may or may not work.
It is short, but when you do multi platform code, a real pain to deal with.
Consider aix and Linux multiplatform code for one of my past projects. My choice would have been: 1. Step and maybe hit a bug, msg the complier team, proceed writing register values on paper. 2. Break up the line, recompile. Few minutes on Linux, over half an hour on aix.
Ok, I understand now. Thanks.
This is a pretty common way to write C, though, it's not something specific to this particular codebase. You just had a non-standard use case where you were constantly running into low-level bugs. (In an embedded platform?) If you aren't in that domain anymore, it's worth revisiting the trade-off. In most domains, gdb's continue command is super useful.
Mhm. One was an actuall driver/firmware developmwnt. The other one a cross platform debugger.
I will in few hours, thanks.
No. Parent is correct. Writing code just to show how clever you are, at the expense of others who need to debug and understand it later, is poor taste.
It's pretty weird to see "correct" justified by calling the opposite "poor taste". We're talking about a mismatch between a style of code and certain tools; a better answer is to use tools that work well with the style of code you like.
It's not just tooling. The more complex the expression, the more likely it would aid in understanding if you gave it a name.
I agree that naming expressions often helps understanding, and that's worthwhile -- I guess I just disagree about this code at first glance. Maybe if I tried to delve into it.
How would you rewrite it? Would you use a local variable for the result from strlen(), for example?
Basically. The compiler will optimize it anyways in the end.
I had a quick look at a random module and found stuff like "return true".
Thanks for making this! It is obviously a labor of love. This kind of incremental building is a lot of work, but adds a revealing dimension not seen in a flat annotated source.
Great work.
The Craft of Text Editing, by Craig A. Finseth:
http://www.finseth.com/craft/
this is great, thanks
The next fun experiment is to handle gigabyte files without undue performance troubles with a lively ui thread! This is where scintilla et al run into limits.
Scintilla is an editor for source code. Normally code isn't gigabytes in size and doesn't need a lexer, code folding or syntax highlighting. Not saying that it can't be done, but if you open a file like that then turning off those features would already make it a lot easier to handle huge files.
If that sounds fun to you, do it!
I suppose that would be more along the lines of a hex editor, which is probably interesting to implement too.
Just have to say, this is ridiculously detailed, which is great. I'm not looking to build a text editor in C, but I learned a good amount just skimming the first few chapters.
Great site, great presentation, thanks for digging into it with so much detail.
Would something like this be a way for a beginner to C (barely any experience) to get their feet wet? Or is there an expectation of basic familiarity with C already?
Do you have general programming experience?
Yep, lots of Ruby/PHP/Python/Javascript, some Java. So I can comfortably read syntax in most languages, but obviously none of the languages I've used are as low level as C.
If you understand pointers then from a cursory glance at this tutorial you should be fine.
Yeah, brush up on pointers a tad bit (just have a look at some youtube videos, honestly), if you are uncomfortable with them, and then you should be good to go.
It seems to be trying to explain the C as it goes along, but I don't think I'd get it if I hadn't done C programming in the past.
But, if you've done any Java or Objective C, you can probably infer the gist of it without serious C study.
If you can write C at the level of K&R, you'll probably be fine.
Hanson's C Interfaces and Implementations is another great book that would better prepare you for this.
I'm working on an editor in JavaScript. You would be surprised how fast string operations, like concatenation, are in JavaScript! You can hold the entire buffer in a String! While browsers renders text very well, the DOM is relative slow to interact with, but there are other ways to render in JavaScript, for example the Canvas, or into a terminal, or even stream a video, or talk directly to a display.
That's really what JavaScript was made for: editing HTML (strings) on-the-fly. It has been optimized well, indeed.
What kind of data structure are you using for edits?
Some time ago I went overboard and wrote an editor in PHP with the 'main' feature being auto encrypted files. Completely bananas.
https://github.com/ziqbal/pubscripts/tree/master/logos
my toy 300 loc text editor for python, https://github.com/jquast/blessed/blob/master/bin/editor.py
Does anyone have similar links but written in Java? If yes, please share here.
This is a really cool hacking primer.
The guy who made this (Jeremy Ruten, I think) should be commended for taking something complicated and boiling it down into accessible terms.
I hope we see more documents like this on HN in the future.
kilo.c code referenced in the tuturial if you're interested in compiling and hacking around.
https://github.com/antirez/kilo/blob/master/kilo.c
I wonder how mouse clicking and scrolling in editor works? Would love to make html/js/css for terminal node module. I think that would be fun.
Sometimes when I configure my vim, I feel like I am building an editor too :D
But at least that is more of a LEGO style of putting different bricks (plugins) together.
I rememeber when some years ago, I wrote a CLI aventure game, using ncurses to handle windowsing, raw input, etc. How easy made my life....
Pretty sure that this is the same as the first project for Oxford ComSci students in first year
This is excellent. Having a lot of fun going through it. Always wanted to start writing some C.
marginally relevant: I was looking for a terminal text editor for git commits and other similarly simple tasks: my only requirement is that I can save&leave with ^D. Any suggestions?
Simplest I can think of:
You'll need to hit enter before ^D.
You can add simple Emacs-like keybindings by changing that into
Or just learn ed:
(the numbers are ed telling me how much was read and written; `1c` means change the first line; `.` means I'm done inserting (go back to command mode) and `w` means write/save; exit with ^D)
Thanks for the tips!
If anyone is having trouble getting the first one working, you need a shebang at the top of the file!
But the second point is more valid. Ed is the standard editor.
What system are you on that needs the shebang? bash 4 on Ubuntu seems to just run it in bash, though I guess it probably shouldn't :-)
Emacs?
for some strange reason the 'Fira Mono' google font is displaying all &s as |s. Anyone else seeing this? Cool book though, I'm going to work through it this weekend.
See https://github.com/snaptoken/kilo-tutorial/issues/4
You may have a broken version of the font locally. If you download the offline version of the tutorial, it'll come with all the fonts it uses and hopefully will work.
This was a great read and well explained. Thanks for the share.
Thanks for the share.
For better portability, terminfo should be used instead of using hard-coded terminal sequences. Otherwise, this is a really great intro. I liked the beginning with how to put your configure your terminal.
Why would you need to care about portability? Do people use terminals that are incompatible with xterm?
That's what I like
Great work, thanks.
Great documentation
Looks like it's been slashdotted.
It seems to be doing fine now, but you can always download a local copy (it's all static HTML) from https://github.com/snaptoken/kilo-tutorial/releases