Hacker News Reader

Comment by jrimbault | Hacker News Reader

> "Perhaps we should implement a mode that puts cosmetics on Emacs so it will appeal to those who judge by the surface of things."

I'm sorry to react to first quote, but as I kept reading I kept coming back to it. My thoughts on that : how you present yourself is how you want (and are going) to be judged.

In general I think Emacs has been user-hostile, as said here, just by its terminology. Nobody outside a minority of devs (a minority even among programmers) refers to Ctrl+c as C-c.

> Yes, make Emacs appealing and user friendly. But don't forget that a masterful tool in the end requires mastery, which can't come for free.

And the old "I have suffered therefore the others have to suffer".

View on HN

I don't think emacs is "user-hostile" on purpose. You have to keep in mind, it's nearly 45 years old. This is almost unprecedented in computing.

Today's users expect different things than users did in the 70s (who expected different things than users in the 80s, 90s, so on). Emacs has been relatively consistent through time, which has been a huge boon to emacs users. The tradeoff is against current user's intuitions -- for better or worse, emacs does not work like other popular software today.

Calling this "user-hostile" comes off somewhat entitled. Emacs developers in the 70s/80s/90s/00s simply didn't know enough about today's users to cater to us, even if they wanted to. That's hardly their fault.

So, todays way and the emacs way have diverged some, and it does take a bit of effort to learn. Not because emacs hates you! But because emacs is ancient. The (objective, non-stockholm-syndrome) reward for your efforts to understand it are a) mastery of a system useful enough to survive this long, and b) mastery of a system that isn't likely to change out from under you.

> You have to keep in mind, it's nearly 45 years old. This is almost unprecedented in computing.

We can acknowledge Emacs's longevity without straying into unsupportable hyperbole. Emacs is nowhere close to unprecedented in its age and not remotely close to the oldest piece of software still in existence.

GNU Emacs is from 1984. It is a reimplementation of the earlier 1972 Emacs. This matters, since if you're including reimplementations then obviously Unix itself, which is used by many of us every day, it older. And if you start counting from 1984...that's not especially old.

Fair enough! But the point stands, no?

I pointed out emacs' age to note how users expectations of editors have evolved over that time. Certainly there is older software -- but is there any other user-facing software that has survived such a dramatically shifting landscape? That is the part I find unprecedented (and the part relevant to GP).

> is there any other user-facing software that has survived such a dramatically shifting landscape?

Yes. Microsoft Word, for example, is older than GNU Emacs.

Just because something is old doesn't make it not user hostile. If anything it encourages it as we are always getting better at making better interfaces.

Cars from the 70's don't have airbags. So, by comparison to what is available today, they are user hostile.

Hm. I take your point, but I'm not sure the analogy works.

Maybe better: "Old" (pick a date) cars had a manual transmission. Compared to automatic transmissions, you might consider that user hostile. But back then no one knew what they were missing and got along just fine.

Nowadays, some people still like manual transmissions! Not everyone, but some folks still buy them. Some even claim they're better than automatics! "They're cheaper, easier to maintain!" Are they user-hostile? I guess it depends on who the user is.

(Airbags seem like a strict improvement, sure. But part of that comes from them not being part of the "interface" of the car -- we don't interact with them, we don't form preferences about them, gain familiarity with them, etc. Perhaps they correspond better to multi-cored CPUs, multithreading, or high-res color displays (features emacs has kept with the times on, more or less). It's much harder to come up with similar strict improvements in the UI world.)

> "user-hostile" on purpose

I seem to recall reading that the keyboards that emacs was originally developed for had the CTRL key in the middle left (where the modern, useless, "caps lock" key is). The awkwardness of the CTRL key on modern keyboards makes emacs seem unnecessarily user-hostile as well, but that's also not something that Stallman could reasonably have predicted.

> And the old "I have suffered therefore the others have to suffer".

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.

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.

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.

Heh. My website is drastically outdated (by a decade), but thank you nonetheless.

> Go and assist with emacs

I have a freaking book to write...

> it's incredibly difficult

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.

I misread what you were saying, sorry. Too late to delete other post, please ignore it.

Meta is not always Alt. Some people use ESC for the Meta keybindings.

So? Alt is not always Alt either, and apparently for a lot of people Ctrl is actually Caps Lock (to help with RSI?).

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.

Could you explain your rationale for this configuration?

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.

Thanks! I like the underscore idea. First time I've seen it. (As you can see I'm not the fastest replier myself. ;-)

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.

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.

"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?

You can absolutely do both. In VSCode, if I don't know how to perform an action, I just hit Ctrl+Shift+P and the fuzzy search panel with all the possible action shows up, with the associated keyboard shortcut next to it so I can remember it for next time.

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

> In emacs, I have absolutely no idea how to discover features

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

When it was written, there were no widespread GUIs. Standardized keyboard layouts on computers were just starting to be a thing. Many of its users were using terminals, not workstations or PCs. So they adopted, and probably more often invented, terminology and conventions for a world that predated almost everything people today know and understand.

So it's not user-hostile, it's just really old. The knee-jerk answer would be 'well just update the conventions/terminology'. The problem is, update it to what? There is no timeless terminology they can use. As the tech industry increasingly resembles the fashion industry, they'd need to slap a new coat of UI paint on it at least every 10 years to keep up... as what was 'user friendly' terminology today won't be in not too many years. So now the developers are spending a big chunk of their time 'modernizing' it rather than actually making it better... not something most developers are interested in doing for a passion project.

> Many of its users were using terminals

Perhaps an example will be more vivid. In the eighties most people who were on the internet worked on a 24 line by 80 column terminal. Some people used Emacs buffers as a predecessor to multiple windows on large screens:

- Edit your code, perhaps splitting the screen in two buffers to look at different files or places in a large file.

- Split yet again one buffer for compilation error messages.

- Split the other one for a shell subprocess to run the program, check mail, etc.

Basically all-Emacs all day. Not my setup, but I saw it done often enough.

> So it's not user-hostile, it's just really old.

Expecting people to adapt to 1984 - which, just a reminder folks, is more than 30 years ago - rather than updating your documentation and maybe some keybindings to better reflect today is in fact incredibly fucking user hostile.

> I think Emacs has been user-hostile

I don't agree. It requires a bit of learning if you are used to something else.

>I have suffered therefore the others have to suffer

This isn't true. Try, instead "I put some effort into learning it, and you can too."

Deeper understanding leads to higher productivity.

Ah yeah, the minutes of saved effort after pouring hours of effort into trying to understand esoteric arcane emacs-only concepts and writing some Elisp.

seriously though, it's a rabbit hole. Been there myself, now I just us vscode and it's a breeze!

> Nobody outside a minority of devs refers to Ctrl+c as C-c.

First, C-c is not Ctrl + c; second, it really helps to use compact notation when you read a lot of keybindings; and third, this is approximately the most minor complication in the learning curve of Emacs (otherwise nobody would learn vim, with its insane key mappings and invisible mode transitions).

Exactly what I mean. It is insane. I can't get it straight. I really tried years ago. But it is plain and simple stupid.

Words once written don't need to be abbreviated. Abbrevation is only useful when writting for speed. When writting for being read don't use them.

I think that is wrong actually.

I find it harder to scan my eyes over Ctrl+Alt+a than C-M-a (notice that Apple, too, uses single glyphs for modifier keys).

I've used macOS for ten years now and I'm still regularly confused by Apple's modifier key glyphs.

Those aren't "Apple's glyphs", they're part of the ISO/IEC 9995 standard for common keyboard layouts. https://en.wikipedia.org/wiki/ISO/IEC_9995 Perhaps Emacs and the Linux desktop should start using these characters by default, seeing as they now have good Unicode support.

Control and Option/Alternate are different. Most keyboards and most software don't use either set.

What is C-c? I have never used emacs so these comments are very confusing.

It's the notation for the shortcut Ctrl+c, which would be used in windows to copy and Ctrl+v for paste.

It's written in most emacs documentation as C-c for brevity.

It's usually the Ctrl key, but most emacs users would rebind that. So it's not the Ctrl key.

Some users will rebind it, I don't think we can say "most" unless we have some data to support that.

Emacs' notation for keybindings uses C for indicating the Ctrl/Cmd key and M for the Meta (alt).

Things like C-c C-v are chords. <Ctrl+c> and <Ctrl+v>.

I might be wrong, but I believe that the reason that parent commenter said that "C is not Ctrl" is due to the fact that you can map these keys to any where you want. Most emacs and lispers prefer to have C key bound to caps lock.

> I might be wrong, but I believe that the reason that parent commenter said that "C is not Ctrl" is due to the fact that you can map these keys to any where you want. Most emacs and lispers prefer to have C key bound to caps lock.

Yeah, but it's still a control key. I mean, xev literally registers "Control_L" when I press the key that is physically labeled "Caps Lock".

C-c is a chord (two keys pressed at once); C-c C-v is a chord progression (first one chord, then the other), more often referred as a sequence in this context.

Right you are. Using Emacs for 20 years and I still can't get to explain it to people properly.

"You have to press these 2 keys at the same time" I don't understand your difficulty.

That just proves OP’s point, imo.

Were this an actual conversation where someone wants to start with emacs, I would be showing the sequences (as in "see, Ctrl-x and Ctrl-f gives you a prompt to write a file. Now try Ctrl-x and Ctrl-s...") and I would show the part of emacs that gives the user feedback about the command.

Discussions about terminology are totally secondary, and honestly, I was just trying to find a polite way to show that I don't want to get into an argument about terminology.

That's to avoid overstretching your pinky

On an ordinary PC keyboard with sufficient travel, you can use your palm instead of your pinky, and I highly recommend it.

My keyboard doesn't have a 'ctrl' key, it has 'control'. I don't know why removing all the vowels from the word is considered more 'correct' than referring to the key by the first letter. Both 'C-' and 'Ctrl+' are ways of shortening the word.

It also takes what, five minutes to get accustomed to? Even old dogs can learn this new trick.

Reply on news.ycombinator.com