facbook hack
The Craft of Text Editing (1999)
11–20 of 51 posts
Re: The Craft of Text Editing (1999)
#12> In its most general form, text editing is the process of taking some input, changing it, and producing some output.
Funny how similar that definition is to the "programming" one.
Re: The Craft of Text Editing (1999)
#13The future of the internets world is in hackers hands.
Hackers are exposed to you by texting 19193076946 for more details on how you can get a real hacker to work for you
Re: The Craft of Text Editing (1999)
#14I once build a text editor using a rope[1] data structure where every line was a node. The tree was augmented[2] with information about line numbers, titles in the document... for very fast navigation. 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.
EDIT: I forgot it was also a self balancing tree! Very cool stuff.
[1] https://en.wikipedia.org/wiki/Rope_(data_structure) [2] https://en.wikipedia.org/wiki/Interval_tree#Augmented_tree
Re: The Craft of Text Editing (1999)
#15I once build a text editor using a rope[1] data structure where every line was a node. The tree was augmented[2] with information about line numbers, titles in the document... for very fast navigation. 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. EDIT: I forgot it was also a self balancing tree! Very cool…
> 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.
Re: The Craft of Text Editing (1999)
#16I once build a text editor using a rope[1] data structure where every line was a node. The tree was augmented[2] with information about line numbers, titles in the document... for very fast navigation. 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. EDIT: I forgot it was also a self balancing tree! Very cool…
> 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 disagree. Although a good rope implementation can handle that. Ropes are nice because it doesn't matter where you edit. Gap buffers have to copy around a lot of data if you are editing in different places.
Btw the memory overhead is not that much. It's just the memory needed to keep the pointers between the nodes. So I'm talking 10% increase or something.
Re: The Craft of Text Editing (1999)
#17I once build a text editor using a rope[1] data structure where every line was a node. The tree was augmented[2] with information about line numbers, titles in the document... for very fast navigation. 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. EDIT: I forgot it was also a self balancing tree! Very cool…
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.
Re: The Craft of Text Editing (1999)
#18I've been learning a lot lately by following along with the development of xi[1], a new text editor written in Rust. Through reading that project's RFCs I've then come across other interesting projects, like swiobe[2] and wi[3]. What are the other canonical resources on this topic? It feels like tons of the interesting thought is scattered around various blogs and usenet posts and the like. I'd love to create a nice…
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.
Re: The Craft of Text Editing (1999)
#19> In its most general form, text editing is the process of taking some input, changing it, and producing some output. Funny how similar that definition is to the "programming" one.
That's because that is just what a Turing machine does.
Re: The Craft of Text Editing (1999)
#20A paper that covers some of the data structures used in editors is: https://www.cs.unm.edu/~crowley/papers/sds.pdf The gap buffer, in particular, is a great example of a simple yet powerful idea that is perfectly suited to the problem domain.
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
Was irony intended?