This is absolutely true. However, if you can make a tool more learnable for new users without sacrificing its optimization for power users, you should. One way to do that is to not gratuitously invent new terms, and to use terms people are familiar with.
Using conventions like "M-x" throughout the documentation, even with a note at the front of the manual that "We refer to Alt as Meta for historical reasons.", is needlessly baroque. Worse yet, maintaining a distinction that those aren't effectively the same thing for almost all users is needlessly unhelpful. (Yes, it's possible to make Alt and Meta different keys under X with use of modifier maps. That explanation belongs in an "advanced keybindings" chapter late in the documentation.)
It's certainly possible to learn that, and a hundred other gratuitous weirdnesses, but they don't actually add value that justifies imposing that weirdness on every user.
I think maybe you're over-emphasizing the problem with this terminology. When I first started learning Emacs it took me all of 5 minutes to get used to the new terms, it isn't that hard. Maybe there's an argument for the lack of value of using older terminology, but again, I think this problem is overblown.
I'm not trying to say this is the most critical problem; I'm saying it's one example of many, and it spends a lot of "weirdness budget" without necessarily providing value in exchange. "kill/yank" is another example, and there are many more where those come from; the volume of them creates a "thousand papercuts" problem.
In the Rust language design, we're careful about what we spend our "weirdness budget" on. We've already spent a fair bit of it on terms related to ownership and borrowing, because those are fundamental and central to the language. We spent some on having a one-character '?' operator for error-checking, because error-checking occurs so often. But we're not going to gratuitously introduce new vocabulary for existing concepts that already have a name people would be more familiar with, and we're extremely hesitant to introduce gratuitous syntax abbreviations just so people can type a little less, because they'd be harder to read and understand.
I agree that a lot of things are weird and could be modernized.
That said, as someone who very slowly got into Emacs and now am full on into it, all this weirdness slowly became more of a an, oh this actually makes a lot of sense, and, you know what, I might like it better.
I still find it weird for a frame to be a window and a window a frame. But logically, I think the Emacs names make more sense. The thing with a frame is a frame, and the sections within it are the windows. I wouldn't mind if it was renamed frame to window and window to panes tough.
Similarly, C-c and M-m used to confuse me a lot. But now I find them way nicer, why have to type all of Ctrl and alt. Also on Mac alt is called command, so having a Meta as a more generic name for the key kind of works.
Kill was weird to me, until I realized kill and delete both exist, but behave differently. There's a kill-ring, text that is killed go in it, text that is deleted doesn't. When you program extensions this is a very important distinction. You don't want programmatic edits to all go in the kill ring and polute it.
Would it be nicer if the more common user used one, which is kill, be named delete which is more familiar to people maybe.
Like I said, I wouldn't mind someone making a big refactor of it all and renaming everything to be less weird to modern times, but I think as you learn those "weirdness" they stop being weird.
Basically, I mean there's a big difference between a quirk, and just something you're not familiar with. I think Emacs names are mostly unfamiliar.
Emacs also has real quirks though, and I think those are more important to address. Like there's a lot of legacy cruft, having to still support working on defunct terminals, and all kind of stuff. Like ESC being a weird Meta key because of terminals that don't support meta. Or the entire UX which is crap by default.
I think you misunderstood. Control, alt, meta, hyper, and super are (at least on my current OS) distinct modifiers. There are also keys bearing some of those names on most keyboards which makes things confusing to talk about.
Each modifier can be mapped to any physical key. For example, I'm one of those control as caps lock people you mentioned. I then have hyper on the left control key, alt and meta (yes both) on the left alt key, level 3 on the right alt key, and compose on the right control key.
I've never seen a keyboard with hyper or super. I doubt many people have, since they were only present on hardware obsoleted decades ago. Meta, aka the windows key on most PC keyboard, is usually present, but most people wouldn't know its name. On Windows, it's not even usefully bindable since Windows uses various shortcuts for it by default. On Linux, it's not bound to Meta by default by most distributions. So for the vast majority of people, it's just Alt.
I don't think Emacs has done itself any favours by using obscure and non-standard terminology based upon machines from the '70s which few people have heard of, let alone experienced. For the vast, vast majority of us, we all have bog-standard PC or Mac keyboards, and have done for the past 30+ years. It would have been in everyone's interest to standardise on terminology and keybindings which were immediately understandable and usable by all.
Given that every other application uses the standard terminology and keybindings, and that I don't see much in the way of compelling advantage to keeping the non-standard bindings other than habit, I think preserving backward compatibility for four decades was laudable but misguided.
Neither have I outside of photographs! The trouble is that they did exist previously and X11 settled on an abstracted model that supports 5 modifiers (in addition to control, shift, and lock). You have to bear in mind that Emacs can't just stop supporting certain (now defunct to the mainstream) modifiers as many users have setups which depend on them.
I suppose that cosmetically they could update the documentation by changing M- to A- or Alt- or something. Would it really make a difference though?
Aside: Not meaning to be pedantic, but at least under X11 Super is the "Windows Key" and Meta doesn't exist by default. I just checked and (on my machine) the keycap with the Windows logo maps to X11 keycode 133 (hardware specific) which produces keysym Super_L at both levels 1 and 3 which in turn maps to mod4.
Unfortunately I didn't notice your reply earlier (the consequence of being productive).
Rereading my previous comment I've realized there are some slight inaccuracies - keybindings are conceptually a bit complicated (at least under the historical X11 model). My Alt keycap actually just produces the corresponding Alt keysym, which maps to mod1. My confusion was due to the Meta keysym also mapping to mod1 (this is the default configuration) even though no key on my keyboard is currently configured to emit it. I set everything up quite a while ago and then forgot some of the details.
* Caps Lock -> Control: This is simply more comfortable for frequent use, particularly in combination with the Vi directional keybindings (hjkl).
* Right Alt -> Level 3: AKA AltGr, this is useful for entering common Unicode characters.
* Right Control -> Compose: Useful for a number of other Unicode operations. I don't seem to make much use of it in practice though.
* Left Control -> Hyper (-> mod3): I had a free key. This gives me an extra modifier for use with things like my window manager that's pretty much guaranteed not to conflict.
* Shift + Space -> Underscore: Makes C programming _way_ nicer.
* AltGr + Space -> Nonbreaking Space: I don't actually remember why I configured this one. I never use it.
* Shift + Shift (ie left & right) -> Caps Lock: I don't actually use it, but this way it's still available.
"M = Alt", "C = Control" is such a trivial thing to remember, yet it is brought up as a critical emacs deficiency every time. Why isn't this argument brought up in every Mac/PC discussion, or Xbox versus playstation?
There's some bad stuff in emacs but to concern yourself with Meta as opposed to M- is plain silly.
> if you can make a tool more learnable for new users without sacrificing its optimization for power users, you should
Yes, but it's incredibly difficult and frankly the emacs devs have enough to do (and they do it well), and UI design is a very different skillset from programming. Frankly the learning curve for emacs is not going to improve, muchas we both might wish it.
The biggest problem is people want the benefits of freely downloadable software but mainly aren't prepared to give anything back. Go and assist with emacs or some other project.
> The biggest problem is people want the benefits of freely downloadable software but mainly aren't prepared to give anything back. Go and assist with emacs or some other project.
I don't really buy this line of argument in general, but I think Josh is a particularly poor candidate to pull rank on because they don't contribute to open source. I don't know Josh, but I recognize his name from his open source contributions.
If you don't recognize Josh's name, you can get an idea of some of what he's done from his website, which is linked in his bio: https://joshtriplett.org/
> I work on Linux, primarily on the RCU subsystem and on Sparse-related code. I maintain the rcutorture test module.
> I co-maintain the X C Binding (XCB). I developed the XML-XCB format to describe the X Window System protocol. I also work on other Xorg projects on Freedesktop.org.
> I maintained the Sparse semantic parser and static analysis tool for C for several years, before passing it on to Christopher Li.
> I maintain several packages in the Debian project.
Consider me very regretful indeed. Most people who moan seem to have nothing to contribute, well I got it very wrong this time. Apologies to @JoshTriplett if you're reading this, and Ill check out your stuff tomorrow.
Ah shit, I recognise your name too. I've just been spanked by Dan Luu. This has not been a good night.
I appreciate the sentiment. I would gently suggest focusing the regret on the message rather than the recipient; it wouldn't have been better if written to a novice user.
Right. I see this point ignored very frequently (sometimes because it's obvious and sometimes because people are being dumb).
A lot of the things that would make emacs more like other editors are extremely difficult to retrofit. I expect there is still SOME low-hanging fruit, but a lot of the low-hanging fruit has already been picked, and a lot of the remaining changes that people would like are a lot of work.
Let's discuss that. Emacs is so flexible it should be possible to do anything. Binding cut/copy/paste functionality to the conventional keys would be trivial. A few rebound key bindings, not a problem, so you're getting at something larger; what is it?
BTW the current key bindings are so good because I can do a lot without my hands leaving the keyboard, or even moving off the home keys. That was the very point of choosing them originally AFAIK. I recall learning these new keys many years ago, it was surprisingly fast and when I'd learnt them, amazingly quick to sink into muscle memory.
Unfortunately the rest of the software world settled on keybindings for cut and copy that generate almost the greatest possible pain for Emacs to migrate to them. C-c and C-x are used for dozens of the most important commands. It's technically feasible, but switching would be hard and existing users would be really upset.
I assure you I'd never propose to change emacs bindings at all, merely have a switchable alternate set. I think that would be possible? But even if you did so, there's too much else, far deeper that couldn't be amended. I think we agree it's not a credible proposition. I suspect emacs' enormous toolkit can't be exposed consistently without making it inconsistent. I can live with emacs as it is, very happily.
Using conventions like "M-x" throughout the documentation, even with a note at the front of the manual that "We refer to Alt as Meta for historical reasons.", is needlessly baroque. Worse yet, maintaining a distinction that those aren't effectively the same thing for almost all users is needlessly unhelpful. (Yes, it's possible to make Alt and Meta different keys under X with use of modifier maps. That explanation belongs in an "advanced keybindings" chapter late in the documentation.)
It's certainly possible to learn that, and a hundred other gratuitous weirdnesses, but they don't actually add value that justifies imposing that weirdness on every user.