Hacker News Reader

Comment by tazjin | Hacker News Reader

> as a preserved island of fun and "hacking for the sake of it"

Somehow this sentiment is anything but fun to me. Emacs is the last bastion of a different path down the tree of personal computing than the one our species took, one in which individual users are empowered and not - as is now the case - held hostage by us[0] in our ivory towers of impenetrable layers of cryptic technology.

Emacs was made for humans to use as a real tool. Barely anything else in the tech world really qualifies to the same degree. I'd love to peek into the parallel universe where we stuck to introspectable, malleable software and ended up with something closer to the Houyhnhnm computing stack[1]. Alas, for now that ship has sailed.

See also: That old story about Emacs at Amazon, etc.

[0]: "tech people"

[1]: https://ngnghm.github.io/

View on HN

The "emacs amazon" link makes at least one false claim:

> The original brilliant guys and gals here only allowed two languages in Amazon's hallowed source repository: C and Lisp.

There actual originals (i.e. when it was two people) only allowed C++. There was no Lisp, and no C, although the C++ was a fairly limited subset that was perhaps midway between C and "full C++94".

Then it compounds this error, makes another:

> they didn't allow C++ here, and they didn't allow Perl. (Or Java, for that matter). They knew better.

Numerous early Amazon utilities were written in Perl. I know because I wrote them.

Yegge is entitled to his various views on different languages. But revisionist history about the early development at Amazon is not OK, even when in defense of Emacs, a noble cause if ever there was one.

The site still uses Mason heavily in parts….

> Emacs was made for humans to use as a real tool.

If Emacs was made for humans, why do so many humans get painful RSI trauma ("Emacs pinky") when they try to use it? How many humans can code in something as clunky as EmacsLISP?

No one is saying emacs is perfect, this is such an odd comment. Just because it is made as a real tool, as opposed to a product or something to sell more of, doesn't make it perfect. Table saws are meant to use in productive behaviour too and the fact that people cut their fingers off doesn't make them less of a real tool.

Not a great analogy. Table saws try to prevent you from cutting your finger with flesh-detection saw stops.

Wouldn't hurt emacs to change the default keymap, just like it didn't hurt table saw manufacturers like SawStop or Bosch to include safety mechanisms, it helps.

"How many humans can code in something as clunky as EmacsLISP?"

Apart from some legacy warts, I find eLisp about a million times more elegant than mainstream languages.

Scheme would be even better, and hopefully one day emacs can transition to that.

Agree. Emacs lisp is crappy for silly reasons—archaic names and lack of complete or consistent standard library, but I think the language fundamentally gets a lot of things right, especially for the domain of a user-customisable text editor.

Quick comparison to some other languages:

- vimscript: lol

- JavaScript: the lack of dynamic scoping may be tricky for extensibility, and not having macros is a shame (eg save-excursion and friends). But the language is mostly reasonable. One interesting aspect of elisp is that functions are typically just the symbols of their names, so it is easy to inspect and modify lists of hooks. I also worry about the pervasive use of modularity constructs like IIAFs—a great feature of elisp is the ability to poke and advise other code

- C or Rust: I think it is too hard to do something small or hacky in these languages and the constraints of type systems and manual memory management make ad-hoc extensibility hard.

I’ve also seen emacs (module) extensions written in a strongly typed functional language and they sort of work but can be fragile (eg advising a function but making incorrect assumptions about their types), or needing to use functions and closures for common operations like switching buffer or saving and restoring state. (It also amazes me that more languages don’t have unwind-protect and predictable evaluation order as standard, but that’s another topic)

The advice system is really nice. Is there anything like that in other languages?

Something similar is sometimes discussed under the term "aspect oriented programming". That might help with your Google adventures.

(I know there was one black magic implementation of it for C# on Windows at some point and also similar black magic for Java, but that's as far as I've ever explored it other than in Emacs Lisp. (Black magic in this case refers to splicing in the advice in the compiled bytecode of the program.))

Edit: apparently there's some basic implementation for Perl, too, and it's documentation looks like a neat intro to the idea: https://metacpan.org/pod/Aspect

Hmm. Aspect oriented feels different. I have to put the advice at the spot of what I'm advising there. Still, I can see the similarity.

Monkey patching comes somewhat close. But lacks the communication of intent that is so clear with advice.

> I have to put the advice at the spot of what I'm advising there.

I'm not sure what you mean by this. The idea with aspect-oriented programming is that you can create a bundle of functionality that extends existing functionality but exists as its own separate bundle.

In other words, you specifically do not have to put the advice at the same place as the adviced. That would just be regular procedural/functional/objevt-oriented programming, wouldn't it?

In java, at least, you have to put the annotation in the source where you are going to put the advice. Right?

Compared to elisp, where I can put advice around a function that is defined somewhere else, possibly out of my control.

No. The advice in AspectJ is fully self-contained. You specify -- completely separately in its own place -- what the advice is, and what it is advising. You can advice things that are out of your control.

This is indeed the idea of aspect-oriented programming. I'm not sure where you got a different idea. Could you point me that way?

In the use of aspectj that I have ever seen, it was always an annotation based thing. I could annotate a method as getting logged to get a trace level log. Yes, the logic of doing the trace was somewhere else, but I couldn't place a trace on any invocation of a named method. Say I wanted to log all calls to (make-hash-table), in elisp, that is an easy advice call. In java, I didn't think that was really doable.

That said, thinking on some of the tricks I'm ok with in tests, I guess it has to be possible. Not sure what the code looks like.

It is amusing, as even the annotation based stuff I've seen is near universally disliked by engineers with experience from it. Seems a very common foot gun, in practice.

JS has dynamic scoping via call, apply, and bind.

So you do e.g.

  { option: true, __proto__: bar }.foo(…)

To extend

  bar.foo(…)

(I think you are implying that functions would care about properties of this and that one would achieve “dynamic scoping” by modifying what this is.)

The first issue is that this doesn’t go deep in the stack. E.g. if you want to affect the option used by the foo function on a whole list of objects, it is hard. If you want to affect a call deeper in the stack that can be very hard (elisp example: some extension might want to switch to a buffer but you might want it to pop up the buffer or make some other windowing choice. The solution is that by dynamically binding certain variables around where this extension/function is called, you can make switch-to-buffer call display-buffer and you can override the way display-buffer behaves)

The second issue is that it is ugly.

Compare the elisp example of:

  (let ((option t))
    (bar-foo bar))

bar-foo can call baz which can call whizz which could then depend on the value of option.

I've never actually heard of anyone getting "emacs pinky" since one of the first convenience things you'll do is to make sure Ctrl is somewhere comfortable.

If <<everybody>>'s doing it, wouldn't it make sense to just change the default value?

They probably would, except the change everyone makes (Caps Lock -> Ctrl) is in how their operating system sees their keyboard, which is not something Emacs has direct control over.

It's not that easy if everybody is doing it in a different way...

I prefer both control keys next to the space bar, then alt/meta, then super. I have a short spacebar and can do both control and alt with my thumbs. Others prefer an extra control where caps lock is. Others have special keyboards with thumb clusters. Some may use sticky modifiers. And there's even some people that actually like the "normal" layout(!).

> why do so many humans get painful RSI trauma when they try to use it?

Maybe they should use a different way of mapping keys if the default causes them trouble? Plenty of people do. Emacs has a very popular implementation of vi for example. It's up to the user, you don't need to accept somebody else's choice in this kind of software.

> How many humans can code in something as clunky as EmacsLISP?

People also code in JavaScript and somehow find that acceptable. Anything can be made to work. For what it's worth, elisp has pretty neat libraries and tooling these days (and due to things like magit breaking out UI components into reusable libraries writing interactive Emacs applications is becoming ever easier).

Emacs shouldn't have a default configuration that physically injures users who don't change it.

I have used mostly default keybindings in Emacs for over a decade and what hurts my wrists the most is web applications that force me to use the mouse.

I think Emacs did permanent damage to my hands before I got a special keyboard. "Works for me, wontfix" isn't a good position to take on that kind of issue.

Did you ever remap any keys? Can't imagine what it would be like without setting `caps lock` as `control`.

I use Kinesis Advantage keyboards where one of the keys in each thumb cluster is control, and my capslock is Super. The latter is because Emacs is my window manager and Super is the modifier key for WM commands.

Get Vimium plugin, it will decrease your mouse usage

Vimium is great, the problem is complex web apps that don't use standard HTML elements (so they become invisible to Vimium).

It is perfect on Sun keyboards up to Type 4 and IBM keyboards up to Model F. Starting with Type 5, Sun adopted the giant caps lock key next to the pinky layout that IBM Model M keyboards used, but many Emacs users remap control back to where it should be anyway.

It's actually more appropriate for a space cadet design:

  Hyper | Super | Meta | Control | Spacebar | Control | Meta | Super | Hyper

which was available when emacs keybindings were solidifying (they originated essentially as "hey, what do you people have configured?" poll around the lab/mailing list)

Note that the modifier keys are mirrored, and Emacs' most used key (control) is closest to spacebar. Essentially, you weren't supposed to use control with your pinky while stretching your hand to hit another key - but to use opposite hand for modifier. Suddenly RSI is much less of an issue. Unfortunately not only order of keys on a modern keyboard is different (and often you lose some keys) a full 104 key has

  Ctrl | Super | Alt/Meta | Spacebar | AltGr/Meta | Super | Hyper | Control)

which is noticeably non-mirrored, depending on one's language might also lose right Meta key, and for some reason you now commonly get PrtScr/SysRq in place of Hyper on laptop keyboards.

It's not Emacs at fault, but keyboard manufacturers that put the Control key on the bottom corner of the keyboard instead of the home row.

For what it's worth, it was designed for a keyboard that had ctrl positioned conveniently under the left palm. As others have pointed out, users today just rebind the key and they're good to go.

For decades, I've just been hitting the control key with the part of my palm directly under my left little finger.

No rebinding required, it works great and I don't even think about it.. no issues with RSI either.

On the other hand, I've never liked chording, so I use evil on emacs to make it more vim-like and avoid having to chord much.

Make your alt keys do control, your win keys do alt, and your control keys do win.

No more Emacs pinky.

Emacs pinky is a function of keybindings, which are yours to rebind. Evil and modal editing are quite popular across the Styx.

Elisp is just a product of its time (and Stallman's dogmatism). The lack of namespacing, lexical scoping (until recently) and first class concurrency really show its age. Nothing like the UI locking up because some function is blocking in the background.

I’ve done quite a bit of Elisp hacking and concurrency is really the only annoying part for me. I haven’t run into any issues with namespacing and dynamic scoping.

I usually toss a few modern libs in there like dash, s, f, and cl, and it feels like any other modern lisp at that point.

Dynamic scoping is only a problem because nearly everything is lexically scoped these days so it comes as a surprise. In an environment designed to give users the power to customize everything regardless of if the original plugin designer thought they should be able to or not, dynamic scoping is incredibly powerful.

Agree, an Emacs-like environment might be the only place where dynamic scoping makes ergonomic sense. Sometimes I get actively annoyed when something in Emacs isn’t dynamically scoped because it impedes my ability to get stuff done.

I have Ctrl on capslock and so it's no problem.

To be honest, existing keyboard layouts are so bad that you have to remap a few keys anyway, whether you're an Emacs user or not. Tab and Capslock are gigantic for no reason, backspace is often too far away, Escape is also hard to reach and underused in many applications (or, worse, behaves in unpredictable ways), Enter keys are too small, and so on. As another example, my small 61 key keyboard has an extra large "\" key. Why? No idea.

I've been using Emacs for over 15 years and I've never used the default keybindings. I first started using viper mode (vi keybindings) which was and is still is bundled with Emacs (although I now use evil). And elisp is far from perfect, but I don't think it's much worse than Javascript, Python, Ruby, etc.

The parent should not be downvoted. There is some real feedback here that could lead to a much better product.

I used emacs for 13 years. Then one day I switched to vim and never looked back. My RSI went away.

1/ Regarding the comments about remapping keys as the first thing people do: there are several issues with this. What if I am using a new machine? For example, every time I log into a new EC2 instance or a Cloud 9 environment I would need to do this remapping.

2/ I agree elisp hacking is fun. I prefer that over vimscript—but, evil mode just doesn’t really work in so many msall ways. For example, putting line numbers in the first column is non-trivial.

3/ Chording is unpleasant and I suspect a recipe for RSI if used in a full-time job situation.

I would hope the reason the GP is downvoted isn’t because of disagreement, but because the comment is a cheap potshot. Your comment says a similar thing but is much more substantial and useful to spur further discussion.

As an evil mode user, I agree there are occasions where it isn’t present or doesn’t work, but I’ve generally added mappings for those cases or just memorized the emacs-style chords. What do you mean by putting line numbers in the first column btw? Like inserting the current line number at the start of each line?

The first one has a really simple solution just ask an initial startup which keyboard layout do you want like most modern Ides

> 1/ Regarding the comments about remapping keys as the first thing people do: there are several issues with this. What if I am using a new machine? For example, every time I log into a new EC2 instance or a Cloud 9 environment I would need to do this remapping.

Yeah, but, you know, using Emacs on a terminal that hasn't been produced since 1980 was ergonomic and it's a cardinal sin to change defaults, no matter how many generations of users pass.

This is especially ironic since supposedly all Emacs power users customize their setups, so they shouldn't have to worry about defaults changing, since they don't use them anyway, right? :-p

The common Emacs solution to this is to use your local Emacs to edit files on the remote machine, through TRAMP. That's not always available, but surprisingly often.

> For example, putting line numbers in the first column is non-trivial.

What about linum-mode?

It's obsolete, replaced by display-line-numbers-mode

You're totally right, I always mistake one for the other :)

Reliance of keyboard chording is seriously un-ergonomic. But Emacs provides a number of escape hatches (evil, kakoune.el, god-mode), much more than almost any other computer program.

I started using Emacs before SHIFT-LOCK was always found on the home row next to the 'A' key. The TI 990 minicomputer terminals had CTRL next to the A key, but the popular Dec vt100 and vt220 terminals put the SHIFT-LOCK next to the 'A' key. Sometimes using Emacs required a pinky stretch and sometimes it didn't.

What really changed things was the excellent IBM Selectric typewriter[1]. Every office seemed to adopt it. This typewriter influenced the future of keyboards, the digit 1 was given it own key distinct from lower case L and the ' and " were paired on a single key as were _ and - and it also moved the * key to shift 8. Soon every new typewriter seemed to be adopting the IBM Selectric's placement of the SHIFT-LOCK next to the 'A'.

This is obviously a mistake. SHIFT-LOCK doesn't have to be held down while typing other keys like the SHIFT keys does and it's use is not frequent so SHIFT-LOCK doesn't need to be on the home row next to the 'A'. In my opinion the CTRL key should be placed next to the A key. I was working as an operating system architect when IBM was building the first POWER-PC that was designed to run the new IBM Unix OS called AIX. I remember being in the meeting discussing the design of the AIX keyboard. I gave it my best shot, but I was unable to sway a majority and IBM made the decision to follow the Selectric typewriter and the IBM PC's keyboard layout.

[1] https://en.wikipedia.org/wiki/IBM_Selectric_typewriter

Got a link to the Emacs Amazon stuff?

It's part of a larger post by Steve Yegge[0], of which you can find a copy here: https://sites.google.com/site/steveyegge2/tour-de-babel

Look for the heading labeled "Lisp" or just search for "Emacs" and you'll find the relevant bits :)

[0]: https://en.wikipedia.org/wiki/Steve_Yegge

https://archive.is/isH3s

I believe this is the reference.

Reply on news.ycombinator.com