A pretty bad article to be honest, just creating confusion. Emacs buffers are not the reason why functions like forward-paragraph exists. That’s just normal abstraction (in programming).
[deleted]
Why Emacs has buffers
51–60 of 88 posts
Re: Why Emacs has buffers
#52“Buffer” is just as bad or good a name as “file” or “document”. Files and documents can be in-memory and temporary, and the primary purpose of an Emacs buffer arguably isn’t buffering.
> the primary purpose of an Emacs buffer arguably isn’t buffering.
Until you save the buffer to disk, that's exactly what it's doing.
Re: Why Emacs has buffers
#53Small correction: > Emacs is not bifurcated, but a lapse of judgment 40 years ago could’ve made it so Emacs uses a gap buffer because TECO used a gap buffer (before it became Emacs, it was just gene ciccarelli’s TECO init file) and that decision goes back 60 years
I don't think this is about using a gap buffer specifically, but rather about making buffers first-class objects. With respect to the line you quote, what matters is not the specific implementation of a buffer which is chosen, but the fact that code works in terms of buffers rather than strings.
Re: Why Emacs has buffers
#54Off topic but … > Most people have heard of files and documents in real life I don’t think so. I’m late 30s and I learned of files and folders on windows long before I was introduced to the physical concept. I still feel a small tickle in my funny bone when I see a real life version of the folder icon in an office.
I'd venture to guess everyone here knows what YouTube is even if they never use it. I wonder how many (even on this list) have seen a CRT? (I'm guessing the answer is "more than I think...")
I was going to agree "more than you think", but in tech years I'm also old. Maybe people have seen CRT tv's in parents' or grandparents' houses.
As someone who has used multiple CRT's and both 5.25" and 3.5" floppy disks, this thread makes me feel old.
Re: Why Emacs has buffers
#55This conflates the user concept of a buffer with the gap buffer implementation emacs happens to use.
This is a pity, because buffers as a user sees them are a strength of emacs, the article covers several of the reasons for this. Other editors have files which don't happen to be saved to disk or have a name, and that might sound like the same idea as a buffer but in practice it isn't, and emacs does a lot of neat stuff because it has buffers.
But this gets folded in with a sort of handwavy argument about the gap-buffer enabling a certain kind of low-level programming which I don't view as at all justified. It's a historical accident of emacs that it uses an adequate-but-by-no-means-optimal data structure.
We're talking about lisp here, it's high level. Providing a user abstraction of a string with a cursor into it, and some line information, that's basic.
The reason Emacs is built on gap buffers is because of TECO, as a sibling comment points out, and we shouldn't confuse the practical impossibility of moving emacs over to something like a rope, with the viability of having a programmable editor with good user ergonomics which does use a rope, or some other enriched data structure with more useful qualities than the gap buffer.
Re: Why Emacs has buffers
#56Re: Why Emacs has buffers
#57This conflates the user concept of a buffer with the gap buffer implementation emacs happens to use. This is a pity, because buffers as a user sees them are a strength of emacs, the article covers several of the reasons for this. Other editors have files which don't happen to be saved to disk or have a name, and that might sound like the same idea as a buffer but in practice it isn't, and emacs does a lot of neat stu…
> But this gets folded in with a sort of handwavy argument about the gap-buffer enabling a certain kind of low-level programming
Did we read the same thing? The article explicitly disclaims the underlying data structure as irrelevant!
Fancier programmers may talk about ropes and gap buffers as a way of optimizing how you store and modify text, and yet I must insist that this is still not a good enough answer to explain what a buffer is in Emacs. It’d satisfy the technical answer, but not the philosophical one.
The words "gap", "data structure", etc. don't appear at all in the article after that.
Re: Why Emacs has buffers
#58Earlier quoted context omitted.
I thought eMacs was lisp.
Depends on the Emacs, but GNU Emacs has a low-level core written in C with most high-level functionality implemented in various Elisp packages.
And to clarify, in Emacs "move the cursor forward one paragraph" or "kill (~cut) this text" counts as high-level functionality.
Re: Why Emacs has buffers
#59This conflates the user concept of a buffer with the gap buffer implementation emacs happens to use. This is a pity, because buffers as a user sees them are a strength of emacs, the article covers several of the reasons for this. Other editors have files which don't happen to be saved to disk or have a name, and that might sound like the same idea as a buffer but in practice it isn't, and emacs does a lot of neat stu…
> 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.
Re: Why Emacs has buffers
#60Earlier quoted context omitted.
6,477 LOCs. A wasted an opportunity to implement it using 7 or 8 microservices.
I think this is sarcasm. But talking to proponents of microservices I am not sure. Can you confirm please
Haha. It is.
But looking at the code made me think how we are capable of shipping software products that are hundred of thousand of lines of code and then we have people trying to break things some much and we end up in a spaghetti of microservices and their connections.