Why Emacs has buffers
masteringemacs.org
masteringemacs.org
> 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
The most common machines at the time had all sorts of strings and buffers of various character widths (on a single machine) and I remember back then I often encountered and used the term "string" in a more abstract way to refer to contiguous set of symbols rather than the more concrete way it is used today that was starting to evolve at that time.
> A skeuomorph is a derivative object that retains ornamental design cues (attributes) from structures that were necessary in the original. Skeuomorphs are typically used to make something new feel familiar in an effort to speed understanding and acclimation. They employ elements that, while essential to the original object, serve no pragmatic purpose in the new system. Examples include pottery embellished with imitation rivets reminiscent of similar pots made of metal and a software calendar that imitates the appearance of binding on a paper desk calendar.
It makes regular ol' .txt files in mostly the traditional way, but you write text documents as an eldritch tentacle monster with a magic mechanical typewriter inside a steampunk sandbox.
Wow. Thanks for sharing.
I think one of the coolest features is that you learn different spells depending on what you write.
For example, if you write horror you'll learn spookier spells than if you write romance or technobabble.
https://twitter.com/LeapJosh/status/1519398797079625733 and then you create rituals using those spells powered by yet more writing.
(I don't mean to detract from the parent comment, which is helpfully defining an unintuitive term, I'm just happy to see the conversation has moved on!)
Oh my goodness this word applies to a lot of mainstream programming language design.
I think keyboards on smartphones are an example: they tend to resemble regular, physical desktop keyboards, rather than just a grid of letters. It seems like that's the main reason for the 'A' to be offset from the 'Q'. (Whereas, say, a Blackberry's keyboard was a grid of keys; and entering the symbol mode of smartphone keyboards is also a grid).
Can someone expand on this? I don't understand it.
(defun kill-paragraph (string cursor)
...) ; resulting in a new string/cursor
If things were bifurcated, then as morelisp notes there would be one suite of functions for complex string manipulation, and there would be some binding of keys to commands, and there would be some glue code between them which would have to be written for anything exposed to the user. Which means someone would have to write that glue, someone would have to make choices about it, someone would have to maintain it. That would have required quite a lot of activation energy to move from being a user to being a programmer, as Mr. Petersen points out in his excellent entry.
Instead, in Emacs users can program and programmers can use. Famously, secretaries learned to program Emacs without any guidance or prompting! There is no artificial boundary between user and developer. This is very similar to how Excel enables business users to develop solutions, to be honest, but an order of magnitude more powerful (because Emacs exposes so much more to the user-programmer than does Excel).
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.
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.
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.
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.
(the ‘keep in sync’ part is the reason the additional fields are part of the buffer. Also, the actual implementation may use a gap buffer, rope, or whatever for the string, but that is an implementation detail)
In other words: the Emacs buffer, together with those functions, implements the backend of a text editor. Front-ends could be programming languages calling those functions or UIs that call those functions in response to user key presses, and may show buffer contents on the screen. The standard emacs UI is a mix of the two: a lisp that can call those functions and a binding of key presses to functions (either built-in ones or ones defined in that lisp) to call.
A wasted an opportunity to implement it using 7 or 8 microservices.
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.
https://github.com/emacs-mirror/emacs/commit/1ab256cb9997cf1...
Until you save the buffer to disk, that's exactly what it's doing.
You can have buffers that are views of many different things: directories, shells, REPLs, email boxes, etc. People might not know what a buffer is, but I think they'd be surprised to see those "in" a document, which might be worse.
A "buffer" is a transition zone the user can work/interact with (and sync to it's source if any)
However, I think it doesn't really matters, because people who choose to use Emacs (or Vim) - even among developers - are much more likely to be aware of those "low level" details or understand and adapt easily. So how they are named doesn't matters more than the odd "frame" term Emacs uses instead of "Windows".
You could choose a different name (view?) but it's a different abstraction compared to a "document".
> 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'm guessing the answer is "more than I think...")
How do I know what it looks like to press a wax seal with a ring? Or send a message with a telegraph, or climb the rigging of a square-rigged ship?
I know there are people who carefully avoid any media that isn't obviously by and about the present moment, and they'll continue to be clueless about the past like they always have been, but there will also be plenty of people who can identify a CRT into the 22nd century.
As someone who has used multiple CRT's and both 5.25" and 3.5" floppy disks, this thread makes me feel old.
Who would that be?
Emacs buffers are not the reason why functions like forward-paragraph exists.
That’s just normal abstraction (in programming).
A buffer is essentially a tuple
(contents, point, mark, definition of a "paragraph", ...)
Not that I don’t love how Emacs does it, but I just think it’s not that closely correlated to the notion of what is a buffer as the header of the article implied