3 ms·

> This conflates the user concept of a buffer with the gap buffer implementation emacs happens to use. I did not conflate these things at all. Gap buffers, etc

> This conflates the user concept of a buffer with the gap buffer implementation emacs happens to use. I did not conflate these things at all. Gap buffers, etc. are irrelevant; a boring implementation detail. Unfortunately, _most_ editors leave it at that, or with a thin veneer on top of it, and call it a day. That's why I go to great pains to elucidate why "string-based" editing is a Bad Idea, and why Emacs _does not_ make it a first-class citizen in elisp. I dedicate the rest of the article explaining why Emacs does not operate on such a low level; that in Emacs, in fact, the buffer and elisp are twinned, and that almost all of Emacs operates on the level of a "buffer" as that concept exists in Emacs and Emacs lisp.

samatman 4y ago
In light of what you've said, I reread the What Of Strings section a few times. I've gone from misunderstanding it to not understanding it, which is an improvement I suppose. Because you conclude by saying that the buffer is the same as the string, so that makes the string-based versus buffer-based comparison feel like a matter of terminology. If that section isn't about some tight matching of the data structure to the user experience (including programming) then I don't understand it. > Emacs is not bifurcated, but a lapse of judgment 40 years ago could’ve made it so: a complex, string-fiddly world for Serious Programmers; and a safe, boring, but disjointed, world that “users” are expected to use. If the above isn't about the gap buffer (I don't dispute that, you wrote it) then I don't know what's being referred to, maybe that could be bolstered a bit for those of us who don't have a detailed knowledge of emacs history.