> 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?
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?
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).
Hyper | Super | Meta | Control | Spacebar | Control | Meta | Super | Hyper
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)
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.
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 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.
What about linum-mode?
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
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.
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)
(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
Monkey patching comes somewhat close. But lacks the communication of intent that is so clear with advice.
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?
Compared to elisp, where I can put advice around a function that is defined somewhere else, possibly out of my 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?
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.
{ option: true, __proto__: bar }.foo(…)
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))
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.
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.
No more Emacs pinky.
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 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.
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.
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 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(!).