Emacs Love Tale by sdp(emacs.love)
emacs.love
Emacs Love Tale by sdp
https://emacs.love/tales/emacs-love-tale-by-sdp.html
88 comments
I appreciate how "fun-oriented" the Emacs community is. Whenever text editors come up, people usually spar over which is the best for various productivity concerns, etc. While I do think there is a strong argument to be made for Emacs as a purely productivity-oriented choice for certain kinds of users today, the community is overall geared more toward hacking it as an end in itself: customizing every little detail, doing willfully goofy things like play mp3s or run tabletop RPGs, etc. These aren't the sort of features that will dethrone vscode in terms of general usage, but I feel that it is valuable as a preserved island of fun and "hacking for the sake of it" in a world of software that increasingly seems to have left those values behind. And as this story shows, sometimes the hackability leads to really positive things.
> 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/
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/
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 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?
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?
> 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).
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.
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:
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
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)
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.
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 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?
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?
> 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.
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.
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.
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
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
"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.
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)
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
(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.
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?
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.
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?
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.
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.
(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:
{ 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))
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.
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.
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.
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.
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.
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.
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'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.
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
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
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.
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 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?
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(!).
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(!).
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.
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.
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
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.
I believe this is the reference.
"the community is overall geared more toward hacking it as an end in itself: customizing every little detail, doing willfully goofy things like play mp3s or run tabletop RPGs, etc."
In my experience the "goofy things" you list are a minority use of emacs.
Most people are mostly in to things like org-mode or coding with emacs as their primary use. Of course emacs customization is very popular too, as if you don't want to customize your editor you might as well use something else.
In my experience the "goofy things" you list are a minority use of emacs.
Most people are mostly in to things like org-mode or coding with emacs as their primary use. Of course emacs customization is very popular too, as if you don't want to customize your editor you might as well use something else.
Yes, I think I could have phrased my comment better in terms of fun and "goofiness." Emacs definitely has a lot to offer for straightforward productivity; I'm an org-mode fanatic. But I think there's a certain lighthearted "spirit" to the community that gets lost in some discussions.
Like emacs coffee mode, https://www.emacswiki.org/emacs/CoffeeMode
I've thought about writing a blog post trying to capture the magic of Emacs.
By "magic" I really just mean having a super low barrier to having your code running and working in Emacs. You just open your config files, put in a line of code, and then you're done.
Of course there are other barriers - Emacs has a huge learning curve and Elisp is harder to learn if you aren't familiar with Lisp like languages.
Still, there are no other programs out there like Emacs. You always have to either create your own extension, modify the source code, etc.
Realizing that you could kinda just make whatever you'd like in Emacs is an amazing feeling. I don't even use Emacs as my primary editor at work and I still think about cool things I could hack in my config files.
By "magic" I really just mean having a super low barrier to having your code running and working in Emacs. You just open your config files, put in a line of code, and then you're done.
Of course there are other barriers - Emacs has a huge learning curve and Elisp is harder to learn if you aren't familiar with Lisp like languages.
Still, there are no other programs out there like Emacs. You always have to either create your own extension, modify the source code, etc.
Realizing that you could kinda just make whatever you'd like in Emacs is an amazing feeling. I don't even use Emacs as my primary editor at work and I still think about cool things I could hack in my config files.
Believe it or not, a lot of it is due to a shared global namespace with global variables as the norm.
It's hard to capture the qualities you mention without that. (Raise your hand if you can think of a system that did; I'd love to know.)
There's more to it than that, of course – the design is excellent – but convention matters, and elisp has a convention not seen in most other large-scale programming systems.
It's hard to capture the qualities you mention without that. (Raise your hand if you can think of a system that did; I'd love to know.)
There's more to it than that, of course – the design is excellent – but convention matters, and elisp has a convention not seen in most other large-scale programming systems.
Definitely this. It just feels so natural to have all those functions in the same scope without dealing with modules, hierarchies or something involving both.
I also believe that none of the languages with module hierarchies are suitable for some kind of REPL driven development. You can't just dump all of your program into the REPL and expect it to work. You need globally unique names for these. And I believe this is a must for a language that is running inside an editor.
I also believe that none of the languages with module hierarchies are suitable for some kind of REPL driven development. You can't just dump all of your program into the REPL and expect it to work. You need globally unique names for these. And I believe this is a must for a language that is running inside an editor.
Common Lisp has packages and is certainly as suited for REPL-driven work as Emacs Lisp.
I'm not convinced that a lack of at least a flat set of namespaces (like CL) wouldn't be an improvement on Emacs' "prefix everything" approach. Perhaps more important to Emacs Lisp is that everything is open. If you took just something like CL's packages but had every symbol exported by default you'd get something that's not a far cry from Emacs' present approach but with better code organization capabilities.
I'm not convinced that a lack of at least a flat set of namespaces (like CL) wouldn't be an improvement on Emacs' "prefix everything" approach. Perhaps more important to Emacs Lisp is that everything is open. If you took just something like CL's packages but had every symbol exported by default you'd get something that's not a far cry from Emacs' present approach but with better code organization capabilities.
But of course Common Lisp has similar qualities: one can still write unexported symbols, there is just the worry that the internals may change. I think the important qualities are that the configuration is typically done with global and buffer-local variables (a super-lightweight and extensible solution to the obvious problem of per-buffer state) with simple types (alists, hooks, etc).
One issue with Common Lisp style packages is that they may interfere with lazy loading. In emacs you can setq a symbol before the package loads and then the defvar will not change the value, but in CL you cannot read the symbol until the package is defined so things like eval-after-load (ie lazy load then configure) suck.
One issue with Common Lisp style packages is that they may interfere with lazy loading. In emacs you can setq a symbol before the package loads and then the defvar will not change the value, but in CL you cannot read the symbol until the package is defined so things like eval-after-load (ie lazy load then configure) suck.
> there are no other programs out there like Emacs
Emacs is the most organic feeling software I've used- it really feels like it has evolved like something in the natural world, with all sorts of warts and wrinkles. Kinda like a piece of DNA with large portions seemingly unused and occasionally dropped or upgraded, but at the end of the day it's all about functionality and adaptability. May it live forever
Emacs is the most organic feeling software I've used- it really feels like it has evolved like something in the natural world, with all sorts of warts and wrinkles. Kinda like a piece of DNA with large portions seemingly unused and occasionally dropped or upgraded, but at the end of the day it's all about functionality and adaptability. May it live forever
This is a huge part of the appeal of emacs to me as well. Other editors / IDEs might offer a comparable level of extensibility but it feel like there's so much more friction involved in taking advantage of it. With emacs you don't even need to restart the application.
By "magic" I really just mean having a super low barrier to having your code running and working in Emacs. You just open your config files, put in a line of code, and then you're done.
Most of the time it isn’t even necessary to restart emacs to do this.
Most of the time it isn’t even necessary to restart emacs to do this.
I started to program when I entered university about 10 years ago, so I guess I'm a little bit younger than the average Emacs enthusiast at this point given that in particular here people's stories often go way further back, but I'm extremely grateful that our professor introduced us to Emacs.
I think I could have easily missed out on truly getting to learn a programmable and customizeable environment because IDEs and finished products in teaching were already pretty dominant at this point and it wasn't as much about tinkering any more and more utilitarian.
But Emacs really made me curious about reading documentation, tinkering with minor modes, doing simple things like writing my own status bar, and I think the great thing about it is that everything is in one place and interacts organically. The ability to introspect everything, change things on the fly, led me down a huge rabbit hole of reading about Smalltalk, papers from Licklider in the 60s about human-computer interaction, at some point later back to Pharo and a whole bunch of stuff I don't think I would have ever heard about in my CS education to be honest.
And all that aside it's still an incredibly useful piece of software practically. It's my editor of choice and people keep building new stuff for it. 'org-roam' is one of the better roam research alternatives out there I think and it's incredible to me how there's always someone who has ported some new thing to emacs.
I think I could have easily missed out on truly getting to learn a programmable and customizeable environment because IDEs and finished products in teaching were already pretty dominant at this point and it wasn't as much about tinkering any more and more utilitarian.
But Emacs really made me curious about reading documentation, tinkering with minor modes, doing simple things like writing my own status bar, and I think the great thing about it is that everything is in one place and interacts organically. The ability to introspect everything, change things on the fly, led me down a huge rabbit hole of reading about Smalltalk, papers from Licklider in the 60s about human-computer interaction, at some point later back to Pharo and a whole bunch of stuff I don't think I would have ever heard about in my CS education to be honest.
And all that aside it's still an incredibly useful piece of software practically. It's my editor of choice and people keep building new stuff for it. 'org-roam' is one of the better roam research alternatives out there I think and it's incredible to me how there's always someone who has ported some new thing to emacs.
Fun fact I learned from Licklider's archive at MIT: he was also an Emacs user! I guess that isn't such a huge surprise given his being at MIT, but it did make me wonder if Emacs is the ultimate interface to his man-computer symbiosis.
The subtext of "the rest of her life" was a gut punch. Beautiful story.
Yes, this was my take away as well.
After reading about the joy the author's partner experienced in using the notepad they built, and the reward they experienced watching them, I couldn't help but feel viscerally the pain expressed in those last words.
After reading about the joy the author's partner experienced in using the notepad they built, and the reward they experienced watching them, I couldn't help but feel viscerally the pain expressed in those last words.
For those eager to begin learning Emacs, I would like to share that Emacs has a very friendly and fun community at #emacs on irc.libera.chat as well as on r/emacs on Reddit.
If you have never been on IRC before, you can quickly try it out via Libera Chat's web interface at https://web.libera.chat/#emacs. If you are worried about missing conversations when you log out but do not want to set up an IRC bouncer (the typical solution), there is a Matrix bridge to the IRC channel at https://app.element.io/#/room/#emacs:libera.chat that you can use to stay connected even after you turn off your computer.
If you have never been on IRC before, you can quickly try it out via Libera Chat's web interface at https://web.libera.chat/#emacs. If you are worried about missing conversations when you log out but do not want to set up an IRC bouncer (the typical solution), there is a Matrix bridge to the IRC channel at https://app.element.io/#/room/#emacs:libera.chat that you can use to stay connected even after you turn off your computer.
I'm an old-timer, having used emacs for 41 (!) years. I started in a LISP class at MIT, but I was always a UNIX-lover so ended up using Gosling's UNIX emacs throughout the 1980's, and when that ended I borrowed gosmacs.el and wrote a short .emacs to kept Gosling's emacs alive as Richard Stallman descended further and further into madness, breaking CTRL-h and trying to create thousands of functions keys ...
I have never done "chording". What is that?
I don't need an editor with more than about 100 function keys (CRTL-[a-z], CTRL-[A-Z], ESC-[a-z], ESC-[A-Z]).
I absolutely hate 'info' and in the age of manpages and webpages it is an embarrassment to emacs.
I absolutely love ESC-j (fill-region) for squeezing text into 77 columns, and ESC-x indent-region for unifying my coding style. Modern shells understand at least 20 emacs key-bindings (CTRL-e, CTRL-a, CTRL-k, CTRL-b, CTRL-f, CTRL-d, etc.) and so does the Chrome browser, apparently.
Mostly these days I am turning off modes written by pedants who want to 'force' me to do things I don't want to do. ESC-x text-mode works just fine for that.
I have never done "chording". What is that?
I don't need an editor with more than about 100 function keys (CRTL-[a-z], CTRL-[A-Z], ESC-[a-z], ESC-[A-Z]).
I absolutely hate 'info' and in the age of manpages and webpages it is an embarrassment to emacs.
I absolutely love ESC-j (fill-region) for squeezing text into 77 columns, and ESC-x indent-region for unifying my coding style. Modern shells understand at least 20 emacs key-bindings (CTRL-e, CTRL-a, CTRL-k, CTRL-b, CTRL-f, CTRL-d, etc.) and so does the Chrome browser, apparently.
Mostly these days I am turning off modes written by pedants who want to 'force' me to do things I don't want to do. ESC-x text-mode works just fine for that.
Slightly younger old-timer here: I feel I've gone on the full spectrum on .emacs files and keybindings, at least for emacs versions commensurate with my own vintage.
In the early 2000s I used emacs while writing C++, I was writing Lisp macros without any idea what I was doing just purely so I could avoid using one of the bloated Motif IDEs[1] or vanilla `vi` on SPARC boxes. No vim here, thanks, and the nice IT folks at the investment bank didn't permit you to install your own software, so emacs was a fantastic end-run around their rules. We used `pine` for email because somebody had done the leg work to get it working with the corporate Lotus Notes servers, but I got email working in emacs too. Somehow. Having to actually use your windows box was either a sign of weakness or an encounter with insurmountable corporate policy. Anyway, it never occurred to me to customize the emacs key bindings. At that stage in my career I assumed some godlike personage had chosen those key bindings for a reason, and I had better just go with the flow.
Then I left emacs behind for too many years, but rediscovered it through spacemacs, which let me put off learning what I was actually doing for a few years more. Then on to doom emacs because it would make it "faster", then I finally had my epiphany and realized I would have to do this myself. Emacs of all things should not be slow, there is no excuse for it to be slow on these supercomputers we take for granted. So my config is now tangled from an org mode file to keep it nice and organized. When I add a new thing and it becomes slow, I stop immediately and figure out why. And I kind of stick to the original emacs keybindings where possible.
I have no idea what people are complaining about when it comes to RSI. My only non-negotiable change is to reassign (at the OS level) caps lock to control, simply because ctrl is such a small target on most keyboards, which are apparently made for FOLKS WHO NEED ALL CAPS way more than you or I use ctrl. Scary thought. I would argue RSI is going to come from the R part: repetitive. You spend most of your time, even when coding, just typing strings over and over. Likely the RSI suffers never learned to touch type and so the real strain comes from well established bad habits. Try using an Ergodox-EZ ortholinear split keyboard, you'll soon learn whether you're truly touch typing or not. I can't see how emacs shortcuts would be the source of pain. Maybe if you're typing on a 2000-era Sony Vaio or Nokia handset and never learned to touch type? Reminder: old curmudgeon talking here, I may have just got lucky.
If you like emacs keybindings and happen to be using macOS (which out of the box in most text fields supports the basic emacs key bindings anyway), a kind soul has put together a KeyBindings.dict that extends support even further: https://gist.github.com/cheapRoc/9670905
Mentoring newer engineers, it's remarkable how many of them are at the terminal holding down the backspace key, waiting for individual characters to be deleted over long seconds. The idea of using option-b or ctrl-a to move backwards blows their mind. Ctrl-k to delete everything forward of point is also revelatory. It's curious that they get stuck in this rut, totally dependent on the shell day to day, but wholly accepting of these inefficiencies. Yet their forebears - who actually wrote and hacked on these shells, if anything went overboard giving you ways to do everything they could conceive of with the bare minimum of keystrokes. How many of them know you can hit ESC-t to transpose the two previous words in bash? (M-t in emacs for the same).
I'm tempted to blame the children but honesty if you give a child a claw hammer and they point at the end with the V shaped prongs and say "what is that for?" you will explain it to them, or they will eventually figure it out. Maybe its purpose will never occur to them, but it's a rare user of hammers who has driven nails but never encountered the need to reverse that operation. How exactly do we design software such that someone notices the existence of option-b and how much time it could save them?
Maybe it's all the fault of the mouse? Better yet: Windows and the mouse!
[1] I'm sure you can empathize with a feeling of horror that once upon a time, Motif felt bloated and slow. Perhaps we are doomed to always be at war with slow abstractions, independent of the hardware capabilities.
In the early 2000s I used emacs while writing C++, I was writing Lisp macros without any idea what I was doing just purely so I could avoid using one of the bloated Motif IDEs[1] or vanilla `vi` on SPARC boxes. No vim here, thanks, and the nice IT folks at the investment bank didn't permit you to install your own software, so emacs was a fantastic end-run around their rules. We used `pine` for email because somebody had done the leg work to get it working with the corporate Lotus Notes servers, but I got email working in emacs too. Somehow. Having to actually use your windows box was either a sign of weakness or an encounter with insurmountable corporate policy. Anyway, it never occurred to me to customize the emacs key bindings. At that stage in my career I assumed some godlike personage had chosen those key bindings for a reason, and I had better just go with the flow.
Then I left emacs behind for too many years, but rediscovered it through spacemacs, which let me put off learning what I was actually doing for a few years more. Then on to doom emacs because it would make it "faster", then I finally had my epiphany and realized I would have to do this myself. Emacs of all things should not be slow, there is no excuse for it to be slow on these supercomputers we take for granted. So my config is now tangled from an org mode file to keep it nice and organized. When I add a new thing and it becomes slow, I stop immediately and figure out why. And I kind of stick to the original emacs keybindings where possible.
I have no idea what people are complaining about when it comes to RSI. My only non-negotiable change is to reassign (at the OS level) caps lock to control, simply because ctrl is such a small target on most keyboards, which are apparently made for FOLKS WHO NEED ALL CAPS way more than you or I use ctrl. Scary thought. I would argue RSI is going to come from the R part: repetitive. You spend most of your time, even when coding, just typing strings over and over. Likely the RSI suffers never learned to touch type and so the real strain comes from well established bad habits. Try using an Ergodox-EZ ortholinear split keyboard, you'll soon learn whether you're truly touch typing or not. I can't see how emacs shortcuts would be the source of pain. Maybe if you're typing on a 2000-era Sony Vaio or Nokia handset and never learned to touch type? Reminder: old curmudgeon talking here, I may have just got lucky.
If you like emacs keybindings and happen to be using macOS (which out of the box in most text fields supports the basic emacs key bindings anyway), a kind soul has put together a KeyBindings.dict that extends support even further: https://gist.github.com/cheapRoc/9670905
Mentoring newer engineers, it's remarkable how many of them are at the terminal holding down the backspace key, waiting for individual characters to be deleted over long seconds. The idea of using option-b or ctrl-a to move backwards blows their mind. Ctrl-k to delete everything forward of point is also revelatory. It's curious that they get stuck in this rut, totally dependent on the shell day to day, but wholly accepting of these inefficiencies. Yet their forebears - who actually wrote and hacked on these shells, if anything went overboard giving you ways to do everything they could conceive of with the bare minimum of keystrokes. How many of them know you can hit ESC-t to transpose the two previous words in bash? (M-t in emacs for the same).
I'm tempted to blame the children but honesty if you give a child a claw hammer and they point at the end with the V shaped prongs and say "what is that for?" you will explain it to them, or they will eventually figure it out. Maybe its purpose will never occur to them, but it's a rare user of hammers who has driven nails but never encountered the need to reverse that operation. How exactly do we design software such that someone notices the existence of option-b and how much time it could save them?
Maybe it's all the fault of the mouse? Better yet: Windows and the mouse!
[1] I'm sure you can empathize with a feeling of horror that once upon a time, Motif felt bloated and slow. Perhaps we are doomed to always be at war with slow abstractions, independent of the hardware capabilities.
> She never lost interest in it, using it for the rest of her life.
Oh no! Did she pass away?
Oh no! Did she pass away?
> I set up a parallel group of keystrokes using super where the Mac had used command. This meant that her existing muscle memory (and mine!)
this is fundamental to me, it's things like this that make me use linux and prefer KDE, but the way he talks about this (along other comments in this discussion and generalized software trends) has got me worried that this level of customization (and its associated mindset) are an 'endangered species' even among software engineers.
this is fundamental to me, it's things like this that make me use linux and prefer KDE, but the way he talks about this (along other comments in this discussion and generalized software trends) has got me worried that this level of customization (and its associated mindset) are an 'endangered species' even among software engineers.
I feel sad after reading the whole story :(
this is the open way, the commercial private way with a marketplace of taxable transactions requires hiring a company or (coming soon---because hacks---licensed contractor) software engineer whom with the proper authorization and certifications will charge hundreds of (taxable) dollars to give you such customized functionality.
That's one of the best love stories I have ever read!
Amazing story. The things we will do for our partners is incredible.
At the beginning I actually thought it was about emacs
I've been using Emacs for more than a quarter century.
My email client is VM, written in Emacs Lisp. I've used it to read mail for almost as long as I've used Emacs. Although I run Emacs in text-only mode, VM (and ancillary tools, like Personality Crisis and mairix)
* does a great of job displaying HTML messages. For the very few that it doesn't, one keystroke sends the message to my web browser.
* sends URLs I select (all from the keyboard) to the web browser
* opens images and attachments
* auto-adjusts the From: line of outgoing messages depending on the recipient
* archives messages to various folders using various criteria
* search my archived mail going back a quarter century at lightning speed
Of course, I can write Emacs Lisp code of my own to extend any or all of the above.
My email client is VM, written in Emacs Lisp. I've used it to read mail for almost as long as I've used Emacs. Although I run Emacs in text-only mode, VM (and ancillary tools, like Personality Crisis and mairix)
* does a great of job displaying HTML messages. For the very few that it doesn't, one keystroke sends the message to my web browser.
* sends URLs I select (all from the keyboard) to the web browser
* opens images and attachments
* auto-adjusts the From: line of outgoing messages depending on the recipient
* archives messages to various folders using various criteria
* search my archived mail going back a quarter century at lightning speed
Of course, I can write Emacs Lisp code of my own to extend any or all of the above.
I have also been using emacs for over 25 years. That is a sobering thought.
Admittedly the way I use it has changed, because things like LSP are a game changer for me, but it’s still been over 25 years.
Admittedly the way I use it has changed, because things like LSP are a game changer for me, but it’s still been over 25 years.
What packages do you use for email?
Most people who use a separate Emacs-based email client seem to use mu4e, Wanderlust, notmuch, or even gnus. It's entirely possible any or all are superior to VM; I use the latter because I'm comfortable with it and it does everything I need.
>What packages do you use for email?
As I said, VM (<https://www.nongnu.org/viewmail/>); 8.2.0b is recommended. Personality Crisis comes with it. Mairix (<https://github.com/vandry/mairix>) is separate and does not require VM.
As I said, VM (<https://www.nongnu.org/viewmail/>); 8.2.0b is recommended. Personality Crisis comes with it. Mairix (<https://github.com/vandry/mairix>) is separate and does not require VM.
I haven't used Emacs as my main text editor for a while now, but Emacs macros are still one of the aces up my sleeve. They save me a lot of time every now and then.