Using "buffer" as a name for text being edited is hardly worthy of the title weird, vim does it too. Lots of other text editors as well. "Buffer" != "file", the first exists in the memory of the text editor process, the second exists on the file system. Their contents may differ, and one may exist without the other.
Likewise, calling the subdivisions of the screen "windows" is something which vim does too, and likely other editors also. For a text mode editor, it makes perfect sense. When you then port such an editor to a GUI, you end up with "windows" which are subdivisions of the GUI "window" – vim has that too, not just emacs. (Unlike Emacs, vim doesn't have the "frame" concept, because vim doesn't appear to support multiple GUI windows.)
It doesn't matter. When people talk of editing documents in Word, they speak of opening a file, not a buffer. That's the metaphor people are used to. It may not make sense, but saying "well, ackshually, files refer to the copies on disk while buffers refer to the copies in memory" just confuses people more. Have we learned nothing since Macintosh 1984? Actually, we haven't; we've gone backwards. The spatial Finder was based on very deep psychological notions of how humans relate to the world: through spatial orientation and object manipulation. Meaning that there is only one place on the screen where a given file appears, and it appears at the same place every time unless the user moves it. In short, it works like an actual desktop with real physical pieces of paper. And Apple brushed it aside in favor of NeXT's Unixoid "file manager".
> Likewise, calling the subdivisions of the screen "windows" is something which vim does too, and likely other editors also. For a text mode editor, it makes perfect sense. When you then port such an editor to a GUI, you end up with "windows" which are subdivisions of the GUI "window" – vim has that too, not just emacs.
Again, it doesn't matter. The ordinary user's concept of a "window" maps directly to a GUI window, so if you expect your program to be used in a graphical environment without confusing the shit out of people, you need to adopt that environment's terms and concepts.
Meet. Your. Users. Where. They. Are.
I think you're missing the point. Emacs is an editor that is tied to programmers, where most of its users are programmers. It's not a general purpose text editor.
And while MacOS as an operating system for general purpose usage has done incredibly well due to its intuitive design first approach when it comes to developers many have pointed "your users" have pointed out that its interface and philosophy is restricting.
> It doesn't matter. When people talk of editing documents in Word, they speak of opening a file, not a buffer.
But nothing in emacs says you can't open a file. Just that the contents once it's opened are in a buffer. But if you open files outside of emacs they'll be opened as independent windows. By the same token we shouldn't be able to have a window split in frames, because Word opens each file in a window? The naming is a necessity for disambiguation.
And in fact, the idea of what you have open is a file does introduce problems. How many people you know *ucked up because they didn't save changes? They afterwards learned the hard way what is a buffer that every program uses (even in photoshop, or other software) but didn't learn it's name, just that you should save it every N minutes...
We're talking about the power tools of our profession. Nobody designs a band-saw to meet their users where they are either. These are apps we spend 8hrs+ per day living in, and frankly the buffer wording is superior because a buffer is not a file, but a file is in a buffer.
Meeting your users where they are is how we got everybody moving from Textmate to Atom and now to VSCode as the new hotness that would finally kill Emacs and vi. And yet that's the mentality that prevented those newer editors from having the legs to really last. Meanwhile other power tools like Eclipse which absolutely meet nobody where they are are going strong too.
I'd like to think that too, but the sad fact is that most developers these days use VSCode. It is the new hotness that killed Emacs and vi. Emacs and vi are both mere footnotes compared to VSCode in terms of market and mind share, and even Eclipse has been largely supplanted within its niche by the far easier IntelliJ suite.
I suppose vi and Emacs will be around as long as they have diehards still using them, but they're not capturing new users' hearts and minds like they used to. Most professional developers I've met hear Emacs and think it's something that last ran on dusty old DEC iron -- and that includes people who worked at DEC in the 80s! The fact that Emacs is still maintained and runs on modern systems came as a genuine surprise to them.
Emacs and vi held on for as long as they did because there was a significant contingent of developers and technical people still familiar with a traditional Unix environment up until the 2000s or so. As some of these people aged out of the work force, they were replaced by an even larger contingent of younger developers, who only ever grew up with Windows and Mac, and have a reasonable expectation that programs work the Windows and Mac way. By and large they don't even have much interest in Linux on the desktop. Linux is for servers/the cloud. Their dev workstation is a Mac. And Emacs and vi are relics from the before times, whose 1970s UIs just aren't worth grappling with because there are better options available. Those are the people Emacs has to reach if it is to stay relevant. Which means that one way or another it will be "modernized" whether we like it or not.
Bullshit, a lot of Linux/Unix developers used Emacs in the 90's and early OO's.
I was there.
According to StackOverflow's 2019 developer survey [0], 50.7% of editors used VSCode, 25.4% used Vim. So that doesn't really support your claim that vi is a "mere footnote". 25% of market share isn't 50%, but it is still decent and more than a mere "footnote".
[0] https://insights.stackoverflow.com/survey/2019#development-e...
People overestimate the value of massive community and apply a winner takes all mentality too often. You don't need a giant community, and almost by definition giant communities tend to have a lower average user quality leading to lower quality of libraries and support (looking at you JS ecosystem).
They think the world revolutes around them with JS and hip editors while in the end they are the utter minority in serious IT/dev environments.
But who are your users?
I started using emacs back in the 1990s, when I was in high school; I actually started using it under OS/2 (as part of EMX), later switched to running it under Linux. I never had trouble with the concept or name "buffers". I just read the manual and the manual explains everything very clearly. (I really loved the GNU Emacs manual, it was a pleasure to read.) In more recent years, I've abandoned emacs completely for vim, but vim calls them buffers too. I am totally at home with a text editor with "buffers", and changing the name isn't going to make anything less confusing for me – if anything, the change is going to confuse me.
Tools like emacs and vim are not targeted at "ordinary" users. If a tool isn't aimed at "ordinary" users, it shouldn't be judged for not meeting their needs, since it was never trying to.
I even wrote a text editor myself (half-finished personal project, I've never released it publicly, don't know if I ever will, it was really just to prove to myself I could do it). And it has "buffers" too, because that is the concept and terminology I am comfortable with.
I mean - if you're going to ignore everything that makes Emacs great on your way to cavil about how it's different, why not go all out, right?
Try `C-w`, `C-k` and `C-y` inside a Bash shell sometime, you might be surprised.
`M-w` is an exception, though.
They don't have default bindings (unfortunate), but try installing a recent build of Emacs 28 and binding these commands to the keys of your choice:
- undo-only
- undo-redo
> Emacs also calls "files" "buffers", and calls "windows" "frames" and "frames" "windows"
Well, as someone pointed out, buffers are buffers, files are files, why would your editor try to fool you regarding the fact that what you have in front of you is in a buffer (that might be persisted into a file) and not exactly a file? Every buffer tells you if it's pointing to some file...
Frames aren't windows. Like tabs in a browser aren't browsers or windows either?
> It has weird keyboard shortcuts.
Yeah, the worse part of it all is you can't even change them, right?
> Oh, but if you press another key in between, you get lost in clipboard madness.
Yeap sometimes that happens, on the other hand the times it doesn't and you can cycle through things in ways that are not easy to do in other editors is great.
> Emacs also has an "undo", but no "redo" command
This ties back to the ring design? You can switch the direction you're going with two key-strokes. Granted, if you change the buffer (outside of just navigating the ring or copying into buffer, save, etc) then it does get weird, but it's usually pretty consistent and useful. It's like having a step by step git to your inputs into the buffer.
But `this`, this, this: > I agree that using a JS runtime makes more sense that Emacs's weird e-lisp runtime, with all of its dynamic-scope weirdness.
If the JS runtime, with the million of hours and $ poured into it to make it performant at the runtime engine, libraries and general language improvement, when compared to others created decades ago (and mostly voluntarily kept) didn't have an edge in some things, it would probably be the biggest facepalm in programming history ever.
Having said all this, I'm happy people keep experimenting and building stuff for others to use, even if in JS, or Rust, or Zig, or brainfuck.
Blender is, I think, another example of this... It's quite good, but relative to the other 3D editing tools available, it has an absolute space-alien UI. Quite internally consistent; a bear to get into if you learned 3DS Max or Maya first.
When did you last start Blender? This used to be true. Nowadays it's at least on par with commercial tools if not better.
* Moving an object in Blender: Select, press 'G', now the mouse floats the object without the need to hold a mouse button down, optionally hit 'x', 'y', or 'z' to constrain to those axes. You can also take advantage of the 3D cursor.
* Moving an object in 3DS Max: Select to bring up manipulation widgets, click and drag the image of the widgets to move the object.
Starting to learn Blender if you learned 3D scene creation in Max is like starting to use emacs if you learned word processing in Microsoft Word. The metaphors aren't categorically better or worse; they're very different.
But dynamic scope, and e-lisp, isn't the only thing weird about Emacs. Emacs also calls "files" "buffers", and calls "windows" "frames" and "frames" "windows". It has weird keyboard shortcuts. Every third command also copies to the clipboard as a side-effect, which means you constantly obliterate the contents of the clipboard while getting ready to paste what you thought was there. Oh, but to address this problem, it makes the clipboard into a ring of clipboards, so that when you replace the clipboard with something else, you can still access the other clipboards in a ring by hitting the paste command multiple times in a row. Oh, but if you press another key in between, you get lost in clipboard madness.
Emacs also has an "undo", but no "redo" command. Except that when you "undo", it actually pushes the "undo" itself onto the list of "things to undo", so that you can undo that undo, in order to redo. But people also need to undo multiple undos before getting interrupted with a redo, so Emacs only undoes the undos if you press some other key after undoing a few dos in a row. But hey, this means it doesn't need a "redo" command.
So, I agree that the elisp runtime is a weird thing about Emacs, and something that is rational to change. But the thing is... if you're going to change that... why not everything else about Emacs?
I mean, at some point Emacs looks a lot like Bitcoin Core, or Wikipedia -- a beautiful historical community with weird consensus rules that flowered into a very exotic, strange, and usually-functional artifact. Although sometimes it doesn't work as well as the newer technologies.