Actually, its an extremely important point. Tools which optimise for the professional are better than those which do so for the noob. Whenever you can achieve both, do so, but never side with the beginner otherwise. People should learn their tools, and they shouldn't be beginners for long, so making things "friendly" at the cost of rewarding expertise is poor design.
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.
> 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.
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.
Ah shit, I recognise your name too. I've just been spanked by Dan Luu. This has not been a good night.
I have a freaking book to write...
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.
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.
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.
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.
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.
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.
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.
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.
In emacs, I have absolutely no idea how to discover features, and if I find something I still have to understand what the M- and C- mean
The built-in "help" functionality[1] is really great. C-h a will find useful documentation for what you need 90% of the time, and the manual is there for most of the rest. It's particularly useful for keybindings - C-h w for "what's the keyboard shortcut for this command" and C-h k for "what command does this keyboard shortcut run.
[1] https://www.gnu.org/software/emacs/manual/html_node/emacs/He...