The Craft of Text Editing (1999) (opens in new tab)

As pointed out elsewhere, the post is from 1999. You're effectively asking the author to, apart from creating the content, to also maintain it over the years to someone else's arbitrary satisfaction. I'm not sure if that's fair. The author likely has other project's they're working on, and maintaining the look of something they wrote 18 years ago isn't a priority.

Consider what would have happened if they had just published a book. Likely the book would be out of print and no longer available. This is definitely a step up from that.

If this is something that you truly care about, you may want to reach out to the author and offer to provide a maintenane update on your own. That said, be prepared for the author to perhaps consider even the little time it would take coordinating with you and performing any updates not worth their time. Then again, they may welcome your interest and willingness to help.

Maybe because the author's expertise is something other than writing HTML, so he picked up an old book on HTML, marked it up, and that's it. That the browser can render HTML written 20 years ago is quite a virtue. If it only takes 4 lines of CSS to make it more readable, then the page's lack of readability is more an indictment of the browser (which could do this tidying itself) rather than of the author, who should not have to continually update HTML so it renders well on recently-invented devices.

Looks great on my phone. Symantic HTML is responsive by default.

What 4 lines would those be?

Kakoune[1] has been posted recently here on HN to great reception. As a C++ developer, I think it has a very high quality codebase, especially considering how non-trivial it is. As a user, it's been my main text editor for over a year. It also has a vibrant community, jump in on IRC if you have questions or ideas.

[1] https://github.com/mawww/kakoune

REmacs is a very interesting development...

https://github.com/Wilfred/remacs/blob/master/README.md

Sam comes to mind as an interesting project in this area:

http://doc.cat-v.org/plan_9/4th_edition/papers/sam/

There is some theory of operation stuff for JOE:

https://sourceforge.net/p/joe-editor/mercurial/ci/default/tr...

A dissent: Saving memory isn't strictly orthogonal to editing performance.

A paged gap buffer (as described with an array index) remains ideal when you need to make a small number of surgical changes (insertions, deletions, etc) to a very large file, especially given the fact that all modern systems have page mapping hardware, so anything you implement is effectively on top of a paged gap buffer anyway. What we're really searching for is a better program-visible structure.

To that end, the biggest difficulties in efficient text editor, is that most text editing is (ahem) textbook, and neglects the fact that fork() copies on write making most real operations asynchronous, and combining writev() and mmap() can be used to produce whatever memory layout you want (a plain old stupid byte array if that's convenient); The kernel will memcpy your page table for you, so there's no sense in also doing it in user-space. And so on.

If you consider at which point a write() and a mmap() (or on OSX a mach_vm_remap()) will be faster, just how much faster it will be -- imagine: programming something as simple as a plain byte array but with instant inserts (memmove) across multi-gigabyte buffers. Then consider the cost of a write()+mmap() syscall combination in the worst case (a couple hundred micros?) and you'll never use a complicated (linked list) data structure again.

> I don't think primitive data structures like a gap buffer are useful anymore. They come from a time where saving on memory was more important than it is now.

I beg to differ. I routinely open multi-gigabyte log files and SQL dumps in text format, and would not like to have to resort to “sed” to edit them.

>I don't think primitive data structures like a gap buffer are useful anymore.

Emacs seems to do just fine with gap buffers. And thinking about algorithms with greater complexity as being less primitive can obscure the fact that the complexity isn't always worth the tradeoff; see "Gap Buffers, or, Don't Get Tied Up With Ropes"[1]

[1] http://scienceblogs.com/goodmath/2009/02/18/gap-buffers-or-w...

The text in that PDF didn't show up correctly for me, but there's an HTML version of the paper here:

https://www.cs.unm.edu/~crowley/papers/sds/sds.html

Glad to see someone remembers that! (I was a cofounder.)

The sources for the original version of Mince were lost long ago. It's too bad; they were very clear (thanks to the skills of Jason Linhart, the primary author, as well as Craig) and would have made a great example for study.

That's because that is just what a Turing machine does.