Live data from Hacker News

Why Emacs has buffers

masteringemacs.org

71–80 of 88 posts

Re: Why Emacs has buffers

#71
post #42

“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.

In the most general sense, “Document” is a better name, because more people understand what a document is than understand what a “buffer” is.

What happens if you open two buffers to view two parts of the same document (easy in Emacs, not possible in lots of editors)? If you switch focus or close one, what are you manipulating? Not the document.

You could choose a different name (view?) but it's a different abstraction compared to a "document".

Re: Why Emacs has buffers

#72
post #42

“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.

I wouldn't consider an index of my email, or an ongoing IRC conversation, or a calculator to be a file or a document. Buffer is certainly a better name. There might be an even better name, but I don't know what a better name for "visual output from anything" is. Monitor?, but that would be kind of weird because people would think of the hardware.

Another name for the API provided by "buffet" could have been "console" (combination of monitor+keyboard: read/write API).

Re: Why Emacs has buffers

#73

Earlier quoted context omitted.

In the most general sense, “Document” is a better name, because more people understand what a document is than understand what a “buffer” is.

What happens if you open two buffers to view two parts of the same document (easy in Emacs, not possible in lots of editors)? If you switch focus or close one, what are you manipulating? Not the document. You could choose a different name (view?) but it's a different abstraction compared to a "document".

Did you mean two windows in the same buffer? Or did you mean opening the same file in two buffers, each attached to its own window?

Re: Why Emacs has buffers

#74

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).

> Emacs buffers are not the reason why functions like forward-paragraph exists. A buffer is essentially a tuple (contents, point, mark, definition of a "paragraph", ...) So the article is correct - without buffers 0-ary (or implicitly 1-ary, since all evaluation is in the context of a buffer) functions like `forward-paragraph` could not exist. And without a wide library of such functions, the correspondence between n…

Thank you! This single comment explained why Emacs had buffers much more concisely than the article did (although I still liked the article).

Re: Why Emacs has buffers

#75

Earlier quoted context omitted.

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.

Sure, I meant things like interfacing with the OS, the Elisp interpreter itself, performance-sensitive tasks like redisplay, etc.

Re: Why Emacs has buffers

#76
I think a better way to describe Emacs buffers is: Emacs has a structure called buffer that logically contains a string and various fields useful for use in a text editor (e.g. to mark positions in the string) and many, many functions working on such a struct that keep the additional fields in sync with the string content (e.g. moving marked positions when characters are inserted) and are geared towards using that structure in a text editor.

(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.

Re: Why Emacs has buffers

#77
post #46

Earlier quoted context omitted.

I only used 5 1/4 and 3 1/2 floppy disks, and I assume you refer to the 3 1/2 ones as the cover on those was hard. I always thought the 'floppy' part was to refer to the disk itself, which, even on the 3 1/2 ones was flexible, but now you make me question that and perhaps they name just stuck even if they stopped being floppy? I never thought of this because in my country they were referred to as "diskettes" , a word…

I think I stopped calling them floppies when we started using 3.5" disks and just called them disks. Because the 5.25's were floppy on the outside, but the 3.5's weren't.

The inside is floppy though. Disk implies solid in my world.

Re: Why Emacs has buffers

#78
post #18
post #7

Earlier quoted context omitted.

If I may, I'd like to mention a text editor that I am making as an example of relevant skeuomorphism. It's called Tentacle Typer. 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. https://twitter.com/LeapJosh/status/1469737611824713739

That some serious... hem... serious... well, I'm not sure of what I've seen but that's really serious ! :-)

I have been doing my best!

Re: Why Emacs has buffers

#79

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).

> Emacs buffers are not the reason why functions like forward-paragraph exists. A buffer is essentially a tuple (contents, point, mark, definition of a "paragraph", ...) So the article is correct - without buffers 0-ary (or implicitly 1-ary, since all evaluation is in the context of a buffer) functions like `forward-paragraph` could not exist. And without a wide library of such functions, the correspondence between n…

I think of it more as dynamic extent but don’t want to be splitting hairs.

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

Re: Why Emacs has buffers

#80
post #76

I think a better way to describe Emacs buffers is: Emacs has a structure called buffer that logically contains a string and various fields useful for use in a text editor (e.g. to mark positions in the string) and many, many functions working on such a struct that keep the additional fields in sync with the string content (e.g. moving marked positions when characters are inserted) and are geared towards using that st…

Although I’d argue that it isn’t necessary for all those functions to be part of the buffer object themselves - they could receive the relevant details vi dynamic extent and not burden the user with an API that requires passing in an Editor State object (which is the key benefit of Emacs - I just don’t see how this is related to the naming of buffers).
Post reply on HN