Just to add: the built-in "Introduction to Programming in Emacs Lisp" is also really really great. I have been using emacs for a while, with one framework or another, but always hesitated actually learning lisp. I was too focused on learning the kinds of languages and systems that might get me a job, and it felt like too big of a venture in learning a whole language just for my development environment. Now, I have a given up on the employable thing, and have been enlightened by SICP and lispey languages, and in general, the simple beauty of Emacs itself, not just what I can make it do. It takes only a little time to get comfortable with the nested (), and weird vocabulary, and it just really will click with you at some point, how simple it all really is, how every function bears on the simple syntactic principles of the language as whole, its lists all the way down!
You can see the language work, by looking at the code.
It may not get me a fancy computer job, but I think I am happier on the whole anyway, giving myself to lisp. Something therapeutic about it.
> ... and have been enlightened by SICP and lispey languages,
Fun anecdote: I've got my copy of SICP signed by both authors for Sussman invited me to have tea in his office and when I arrived the next day, by sheer chance, Abelson was there too! They joked that had I been there 30 minutes early Sussman's wife, who proofread the book, would have signed it too! I've got a cool pic taken at that moment: me standing along these two legends and proudly holding the purple book... I'll post that pic and full story the day I have a blog.
Besides that I pretty much live inside Emacs. The occasional elisp (3000 lines of custom elisp hackery over the decades) and lots of Clojure/ClojureScript.
>It may not get me a fancy computer job, but I think I am happier on the whole anyway, giving myself to lisp.
I am the same way. I have been using Emacs since 1995, but have never had a full-time programming/IT job (although my tech skills have always been integral to my career). Perhaps having the luxury of not having to write code for pay is what makes me want to instead slowly learn Elisp. I read email using VM on Emacs (also since 1995), and over the last few years I have broken out of just knowing enough to maintain Emacs' dotfiles to actually writing substantial routines that expand on/fix VM and Emacs's capabilities.
Another lesson I learned from almost 2+ decades of using Emacs:
Track your customizations in a version control. Using customize package and reading the diff in dot Emacs file has taught me quite a bit about certain aspects of the package.
Side note: It would be awesome if Emacs could do the versioning as part of saving the customizations - build Emacs with libgit2 and make it a native git client.
The customize interface is quite useful. It's probably more adequate if you don't have a huge intricate init. With time, custom.el (or init.el if you keep everything in the same file) can get difficult to manage. When that happen, a lot of people opt for something more readable and human friendly, like use-package or a distribution such as doom-emacs.
The author mentions that some things can be hard to do outside of the customize interface. That is true. When that happens, I just use the interface and then move the setting from custom.el to use-package. But that's rare, I can't remember the last time I did that.
Yes. Also, don't put your own stuff in init.el. Put your own stuff in another file, and load it with load-file from init.el. This massively decreases the chances that Emacs will make a mess when it adds or updates its own stuff.
You could probably write it. Emacs is able to track which settings you've _applied_ but not yet saved; that could serve as the linchpin for generating versioned changes.
for a reason I forgot my .emacs.d/ ("hidden" dir) is a symlink to emacsdotd/ (not hidden) and, yup, it's in git. Some are going to say: "why stop there!? version your entire user dir" and I can see the appeal (but haven't tried yet).
I'm one of those who track everything Emacs: including all the packages. When I upgrade packages, I first check that nothing broke then I commit "Bump avy to 20220114" or whatever. This way I can easily share the exact same config on several machines/several user accounts and I know I can easily roll back to a known fully working setup. YMMV.
It's because it was not a thing in Italy, so accepting it was seen as the sign of being out of touch with "real pizza" traditions. Sadly, a natural reaction of disgusted rejection by Italians has been adopted by snobs all over the world.
Nowadays you'll find it even in Italy, because tourists demand it and they pay hard cash, so fuck it all anyway.
I think that pineapple topping on the pizza meme is designed by pizza elitist to fool normal people from trying it out. Once you try pizza with pineapple toppings, it gives this extraordinary taste. Sweet, sour and salty. All at same time!
Most people in Europe especially, and especially in Southern Europe (Eastern Europe as well, but that's less relevant to pizza), tend to dislike sweet-and-salty combinations, with some limited exceptions (such as carrots or peas).
To be fair when I push the meme I do it because I personally dislike Pineapple, I sincerely don't care what people put on their personal pizza, just don't put it on mine. Counter, I have enjoyed Brussel Sprouts on pizza and I feel that is a much bigger sin.
This meme is so popular because the overwhelming majority of people thinks pineapple on pizza is a disgusting abomination. I empathize with you, it's tough being the contrarian sometimes. I say that as someone who likes the Star Wars prequels :P
If think the joke is that author himself don't side with the (mostly pointless) debate about pizza and pineapple, so whatever your own opinion, you can see his point.
Hawaiian pizza (cheese, ham and pineapple) is normalized here in Canada. I'm not personally a fan, but I have always had a hard time finding it unusual.
Maybe it's me, but starting out with Emacs the previous month, I tried using Doom Emacs the other week, and the number of packages it was being used frightened me. Building your own init.el is much much better, because you know your Emacs in and out, and dont have random keybindings triggering stuff. Maybe I'll never get the popularity of Doom
Some people like ready made Emacs distros, some people like hand coding their init.el (don't forget your early-init.el!) Some people like Arch, some people like Ubuntu. Some people like Linux From Scratch, some people like typewriters. Live your life, be free.
> ... don't have random keybindings triggering stuff.
As a long time Emacs user, I feel that this is slightly unfair. When I first started out, I found that my documents from Emacs were far more common than in other editors. It took me two years to realise that I was often bumping C-t where trying to hit C-r or C-y and silently transposing two characters. In over twenty years of Emacs usage, I have never once used C-t on purpose. I feel that this perfectly matches the "keybindings triggering random stuff" experience and it is fully there in vanilla Emacs.
With twenty years of experience, I have my own, esoteric init file that I would not recommend on any newbie. However, I personally feel that Emacs has succeeded despite its default keybindings.
Honestly its a double edged sword here. Doom has so many built in convenience functions like `set-font!` and `set-repl!` that an experienced elisp programmer would probably love it for building their own configuration.
On the other hand it bundles so much that an inexperienced emacs user might be more keen to do the bare minimum and rely on the packages bundled with doom to give them all the cool stuff without much effort. After all, why "reinvent the wheel"? I personally don't agree with that sentiment, I think learning how to build and maintain a personal emacs config makes a person a better programmer generally, and makes them prone to reading and writing documentation rather than copying solutions.
I started off with doom and even though I don't use it anymore I still find myself reading its source to figure out how Henrik approached a solution. Love it or hate it, Doom is great in both very good and bad ways for emacs users.
Doom Emacs is excellent. I believe you were negatively impressed by the default install, but you can install it without any packages you don't wan't, or any package at all. You can even remove Evil altogether.
You can also easily remove anything afterwards.
Doom is essential for my sanity, and extremely flexible. I can do everything I want, just like on a barebones install. But I do it in a way that is way simpler, more practical, and performant. I'd use Doom even without any of its modules, just for the macros, the speed, and the sane configuration layout.
I tried the build your own route for 2 years, ended up with a huge messy init impossible to maintain. Doom removes a lot of complexity and provides extremely useful macros. The guy really knows what he's doing, and the optimizations that he uses are impressive.
I think doom is really good for inspiration. I used it for a while and it gave me a lot of good ideas on the kinds of things I could do with emacs and elisp.
I now use my own much simpler config, but I've borrowed heavily from the things I like about Doom.
I had a very similar experience when I decided to learn Emacs recently. The first thing I did was try Doom Emacs. It was nice but I felt that there is this big layer of stuff separating me from having complete control over my editor.
So I deleted my config. Went through the tutorial with vanilla setup. Then I continuously kept adding packages and tinkering with my config. After about two weeks, I felt that my productivity was on par with what it was previously in Neovim.
I've been using Emacs for a couple of months now and I'm happy I went this route. It is a tool I use almost daily and thus having a deep level of understanding and control is worth it.
Yes, gradually building your own config is a much better approach on the long run. Start lean, learn the basics and add one thing at a time as you learn. Always have complete mastery of your .emacs and understand every line: why it is there, what exactly it does. Never blindly copy random stuff wholesale without understanding it.
If you have spent years writing your own config, you appreciate all the things doom brings to the table. I know I'd never end up writing such a good system from the ground up.
It follows a similar philosophy as the OP: Start by reading Emacs's built-in tutorial, and then my tutorial shows you how to leverage the built-in help system to figure out how to achieve what you want to do.
I'm the OP. That's a nice tutorial, and I agree with your sentiment that you should build on Emacs's ability to query it to figure out what to do. That's the main focus of my book, too, for the exact same reason.
I agree that the tool and menu bars are helpful for beginners. I disable mine to reclaim the vertical space (precious in a 16:9 world), to focus my attention on using the command keys, and because I'm a relatively experienced Emacs user! If keeping them helps you get your way around Emacs, by all means go nuts!
I do disable those things. But mostly out of aesthetics. That and I am easily distracted. I remember used to trying to find how to accommodate all items in the menu bar into my use.
Completely agree with this article, though. Happy with my purchase of this book a while back.
For those picking up emacs for lisp development, I'll add another piece of terrible advice: enabling paredit mode.
I think these all have a similar theme to them "I am more productive now since I have turned them on, so I wish I had switched sooner" but they ignore the fact that each of those things adds friction to learning the basics, and at some point people will just nope-out.
Feels like these problems mostly relate to the tech-wizard elitism theme. By all means use the help features and GUI menus if that's what you need. I believe when you run these commands via GUI you also get feedback explaining the equivalent keystroke sequence.
Reminds me of the old days of IRC posturing, newbie bashing and RTFMing. Today most info can be obtained by a well crafted search query.
I dunno, everything the menu does can be recreated in the minibuffer (and you have things like apropos if you're really lost). Personally I like to reclaim as much space as possible, so I turn off modelines too (I have a bit of status info written into the minibuffer, but I'd kill that too if you could).
I never leave it enabled any more. When I was a beginner it was helpful but as time goes on you learn more of the system and better ways of finding commands.
One thing I suggest is building emacs without dbus and using only Athena widgets. Both contribute to overall emacs stability.
The menu bar is pretty good for discovery, you'll have to rely more on naming convention and documentation without it.
The toolbar is pretty fungible though, few modes do anything with it and the core functionality you get from the standard chords you find in the tutorial, little bang for the pixels.
I suspect it's because so many Emacs tutorials out there cover the same material as the built-in tutorial. And so many pre-packaged Emacs configuration files disable the menu-bar for no good reason other than that's what everyone else seems to be doing.
Acessing manual, documentation, values, functions, and source code on Emacs is so easy that it would be hard to summarize all the ways you can do it. It's an integral part of your workflow, and literally unlike anything else. Unlike other programs, that really can and should be an integral part of your daily routine.
One thing I dislike about the manual is that it rarely presents examples, but commands like describe-variable and describe-function often help elucidate usage. Not to mention external packages that makes all that even easier.
[+] [-] beepbooptheory|4 years ago|reply
You can see the language work, by looking at the code.
It may not get me a fancy computer job, but I think I am happier on the whole anyway, giving myself to lisp. Something therapeutic about it.
[+] [-] TacticalCoder|4 years ago|reply
Fun anecdote: I've got my copy of SICP signed by both authors for Sussman invited me to have tea in his office and when I arrived the next day, by sheer chance, Abelson was there too! They joked that had I been there 30 minutes early Sussman's wife, who proofread the book, would have signed it too! I've got a cool pic taken at that moment: me standing along these two legends and proudly holding the purple book... I'll post that pic and full story the day I have a blog.
Besides that I pretty much live inside Emacs. The occasional elisp (3000 lines of custom elisp hackery over the decades) and lots of Clojure/ClojureScript.
[+] [-] ylee|4 years ago|reply
I am the same way. I have been using Emacs since 1995, but have never had a full-time programming/IT job (although my tech skills have always been integral to my career). Perhaps having the luxury of not having to write code for pay is what makes me want to instead slowly learn Elisp. I read email using VM on Emacs (also since 1995), and over the last few years I have broken out of just knowing enough to maintain Emacs' dotfiles to actually writing substantial routines that expand on/fix VM and Emacs's capabilities.
[+] [-] gypsyharlot|4 years ago|reply
[+] [-] 0xdky|4 years ago|reply
Track your customizations in a version control. Using customize package and reading the diff in dot Emacs file has taught me quite a bit about certain aspects of the package.
Side note: It would be awesome if Emacs could do the versioning as part of saving the customizations - build Emacs with libgit2 and make it a native git client.
[+] [-] bananamerica|4 years ago|reply
The author mentions that some things can be hard to do outside of the customize interface. That is true. When that happens, I just use the interface and then move the setting from custom.el to use-package. But that's rare, I can't remember the last time I did that.
[+] [-] tom_|4 years ago|reply
[+] [-] mickeyp|4 years ago|reply
[+] [-] TacticalCoder|4 years ago|reply
I'm one of those who track everything Emacs: including all the packages. When I upgrade packages, I first check that nothing broke then I commit "Bump avy to 20220114" or whatever. This way I can easily share the exact same config on several machines/several user accounts and I know I can easily roll back to a known fully working setup. YMMV.
[+] [-] Yuioup|4 years ago|reply
[+] [-] toyg|4 years ago|reply
Nowadays you'll find it even in Italy, because tourists demand it and they pay hard cash, so fuck it all anyway.
[+] [-] going_ham|4 years ago|reply
[+] [-] simiones|4 years ago|reply
[+] [-] szszrk|4 years ago|reply
[+] [-] siver_john|4 years ago|reply
[+] [-] mickeyp|4 years ago|reply
[+] [-] bananamerica|4 years ago|reply
[+] [-] memling|4 years ago|reply
Arnold has an opinion.[0]
[0] https://www.youtube.com/watch?v=pKV74qkokmk
[+] [-] C4stor|4 years ago|reply
[+] [-] Naga|4 years ago|reply
[+] [-] Koshkin|4 years ago|reply
[+] [-] euroderf|4 years ago|reply
[+] [-] black6|4 years ago|reply
[+] [-] mynameismon|4 years ago|reply
[+] [-] thom|4 years ago|reply
[+] [-] rprospero|4 years ago|reply
As a long time Emacs user, I feel that this is slightly unfair. When I first started out, I found that my documents from Emacs were far more common than in other editors. It took me two years to realise that I was often bumping C-t where trying to hit C-r or C-y and silently transposing two characters. In over twenty years of Emacs usage, I have never once used C-t on purpose. I feel that this perfectly matches the "keybindings triggering random stuff" experience and it is fully there in vanilla Emacs.
With twenty years of experience, I have my own, esoteric init file that I would not recommend on any newbie. However, I personally feel that Emacs has succeeded despite its default keybindings.
[+] [-] uncletaco|4 years ago|reply
Honestly its a double edged sword here. Doom has so many built in convenience functions like `set-font!` and `set-repl!` that an experienced elisp programmer would probably love it for building their own configuration.
On the other hand it bundles so much that an inexperienced emacs user might be more keen to do the bare minimum and rely on the packages bundled with doom to give them all the cool stuff without much effort. After all, why "reinvent the wheel"? I personally don't agree with that sentiment, I think learning how to build and maintain a personal emacs config makes a person a better programmer generally, and makes them prone to reading and writing documentation rather than copying solutions.
I started off with doom and even though I don't use it anymore I still find myself reading its source to figure out how Henrik approached a solution. Love it or hate it, Doom is great in both very good and bad ways for emacs users.
[+] [-] bananamerica|4 years ago|reply
You can also easily remove anything afterwards.
Doom is essential for my sanity, and extremely flexible. I can do everything I want, just like on a barebones install. But I do it in a way that is way simpler, more practical, and performant. I'd use Doom even without any of its modules, just for the macros, the speed, and the sane configuration layout.
I tried the build your own route for 2 years, ended up with a huge messy init impossible to maintain. Doom removes a lot of complexity and provides extremely useful macros. The guy really knows what he's doing, and the optimizations that he uses are impressive.
[+] [-] tharne|4 years ago|reply
I now use my own much simpler config, but I've borrowed heavily from the things I like about Doom.
[+] [-] remedan|4 years ago|reply
So I deleted my config. Went through the tutorial with vanilla setup. Then I continuously kept adding packages and tinkering with my config. After about two weeks, I felt that my productivity was on par with what it was previously in Neovim.
I've been using Emacs for a couple of months now and I'm happy I went this route. It is a tool I use almost daily and thus having a deep level of understanding and control is worth it.
[+] [-] donio|4 years ago|reply
[+] [-] mcbuilder|4 years ago|reply
[+] [-] drothlis|4 years ago|reply
It follows a similar philosophy as the OP: Start by reading Emacs's built-in tutorial, and then my tutorial shows you how to leverage the built-in help system to figure out how to achieve what you want to do.
[+] [-] mickeyp|4 years ago|reply
[+] [-] NateEag|4 years ago|reply
It was hugely helpful to me in learning Emacs.
Thank you so much for writing it!
[+] [-] bitwize|4 years ago|reply
[+] [-] taeric|4 years ago|reply
Completely agree with this article, though. Happy with my purchase of this book a while back.
[+] [-] aidenn0|4 years ago|reply
I think these all have a similar theme to them "I am more productive now since I have turned them on, so I wish I had switched sooner" but they ignore the fact that each of those things adds friction to learning the basics, and at some point people will just nope-out.
[+] [-] felideon|4 years ago|reply
[+] [-] aww_dang|4 years ago|reply
Reminds me of the old days of IRC posturing, newbie bashing and RTFMing. Today most info can be obtained by a well crafted search query.
[+] [-] jmclnx|4 years ago|reply
very nice write up
[+] [-] thom|4 years ago|reply
[+] [-] crumbits|4 years ago|reply
I never leave it enabled any more. When I was a beginner it was helpful but as time goes on you learn more of the system and better ways of finding commands.
One thing I suggest is building emacs without dbus and using only Athena widgets. Both contribute to overall emacs stability.
[+] [-] rbanffy|4 years ago|reply
That said, you can always call it up as a pop-up menu.
[+] [-] forgetfulness|4 years ago|reply
The toolbar is pretty fungible though, few modes do anything with it and the core functionality you get from the standard chords you find in the tutorial, little bang for the pixels.
[+] [-] dark-star|4 years ago|reply
I stopped reading after this. If you want to look like you're objective, don't use pizza as an argument
[+] [-] distantsounds|4 years ago|reply
- read the manual - follow the tutorial - customize it to your liking
wow, what enlightening advice! this must be unique to emacs and not _any_other piece of software!
once again, all you need to get FP'd on hackernews is to put the word "emacs" in your title. zoom! to the front page!
[+] [-] drothlis|4 years ago|reply
e.g. "Emacs Prelude", one such configuration or "distribution" of Emacs, used to disable the menu-bar by default as recently as a year ago: https://github.com/bbatsov/prelude/commit/878cffb
[+] [-] bananamerica|4 years ago|reply
One thing I dislike about the manual is that it rarely presents examples, but commands like describe-variable and describe-function often help elucidate usage. Not to mention external packages that makes all that even easier.
[+] [-] alpaca128|4 years ago|reply