Why do old editors like Vim and Emacs expose the difference between a File and a Buffer in the interface?

Question

Does my question make sense? Using either Vim or Emacs, you come to understand that the interface exposes the code's representation of the state of the file you are editing in the buffer, the file is the on-disk storage you can fill a buffer from or write a buffer to. All these things a programmer would know, but when just editing text, why is it exposed? Any newer editor just tells you "Here is a file. Edit it."

Yes, I understand the technical meanings, but that isn't my question. This is a question not even about if it is a good idea to do it or not. Vim and Emacs are our two oldest editors in common use today, and they share this behavior. I know of no new editor that does the same. When did editors stop doing this and why?

Answer 1

I think the new editors quit doing it for the reasons you stated, that it is an abstraction that just gets in the way. Also most modern editors have unlimited undo, so the idea of the "buffer" is sort of implicit.

Answer 2

I guess I'm just an old fogey (in the die-hard vim camp), but the other editing packages I use, such as MS Word or Open Office, preserve the distinction between the copy of the file that I'm editing and the last saved version. That is utterly invaluable -- I don't want the editor to trample over my last good version until I'm ready for it to do so. Indeed, there's a decent chance (say one in a thousand) that I'll create a new file with the buffer I'm editing on.

On the other hand, the ability to create a file image by reading multiple files (either several copies of the same file, or copies of several different files) is also useful. There are faintly similar facilities in other documents.

So, I could be missing the point - I don't know which editors you are referring to as removing the distinction. But I think that all editors preserve the distinction between the copy of the file that you're editing and the last version saved to disk.

Answer 3

Because several buffers can show you different view of the same file. I do not know of other editors but this is true of Emacs. And what do you mean exactly with Old?

Answer 4

For starters, Emacs uses plenty of buffers that aren't associated with any file. Any time you open a directory, read your mail, open a terminal, compile a program, launch an interactive Python session, or connect to a database, you get a buffer. Hence, Emacs's basic unit of work is a buffer and not a file, and the same logic holds for Vim.

New applications that only edit files make no distinction because every screen or window or tab directly represents a file. More capable applications like Emacs and Vim are a lot more flexible in that respect.

Answer 5

When applications started becoming used heavily by non-geeks who didn't want to trouble themselves with irrelevant detail.

Answer 6

Because developers of those editors didn't care to hide implementation details from users.

Answer 7

OK, here's my weird philosophical answer :

because late binding between the buffer in the editor and the actual concrete thing you're working on, gives the editing environment more flexibility and power.

Think this is out of date? One place where the idea is back with a vengeance is in the browser, where you don't have 1-1 correspondence between tabs and web-pages. Instead, inside each tab you can navigate forwards and backwards between multiple pages. No-one would try to make an MDI type interface to the web, where each page had it's own inner window. It would be impossibly fiddly to use. It just wouldn't scale.

Personally, I think IDEs are getting way too complicated these days, and the static binding between documents and buffers is one reason for this. I expect at some point there'll be a breakthrough as they move to the browser-like tabbed-buffer model where :

a) you'll be able to hyperlink between multiple files within the same buffer/tab (and there'll be a back-button etc.)

b) the generic buffers will be able to hold any type of data : source-code, command-line, dynamically generated graphic output, project outline etc.

In other words, much of the Vim / Emacs model, except tweaked to be more in-line with discoveries that browsers are making.