Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- The section under "User Lisp Directory" seems incomplete. I was expecting a second paragraph.by CodeCompost
- I thought the same, but later on in the article they go into more details and explain that lisp files under that directory will be auto loaded and commands they add should just work! Really good stuff.by brabel
- The part the author shared about the huge overhead cost of firing up emacs, especially in a multi-user environment (I learned about emacs vs vi holy war back on a multi-user Solaris environment), our Unix professor strongly encouraged us to learn vi. He said "vi is part of every standard Unix install, so when you ssh into a box, you'll always have your editor and it won't steal all the CPU from the other users when you fire it up."
Feels monumental to see that come to an end decades later.
by prometheus76 - That's funny, because our professor didn't tell us that and I remember doing my projects with four terminal windows logged into the server and three of them running separate instances of emacs :D. I wonder how much I bogged down that mid-90s HP-UX machine.by jasperry
- > The part the author shared about the huge overhead cost of firing up emacs
TFA's wording on that is a bit misleading.
My Emacs with no config starts in 0.1s (110 ms). My Emacs with my huge config (between 3 000 to 4 000 lines of custom Elisp code) starts in 1.2s or so.
And then of course modern day Emacs is so stable that the thing can stay up for weeks without needing a restart.
It's been a very long time that the "cost of firing up Emacs" is smaller than the cost of firing up 99% of all the software out there (looking at you AppImage , flatpaks, browsers, any desktop app really, etc.).
Stock Emacs: 110ms (Debian Trixie / AMD 7700X / WD-SN850X SSD).
Boom.
- I think you're quite confused. Emacs always avoided a huge startup hit by loading elisp code into temacs (bare bones emacs that only exists when building it) and then dumping it with unexec to produce the emacs that is distributed. A decade ago, glibc stopped supporting unexec and emacs had to switch to a different method of incorporating the elisp code and avoiding the startup time, but the unexec code was still there. Now, a decade later, that code--which was not being used--has finally been removed.
None of that has anything to with emacs vs vi -- the point that your professor was making was that vi was distributed by default with UNIX so it was always there, whereas emacs needed to be installed (which wasn't even an option on servers).
by jibal - I’ve heard that the graphical browser is back on emacs! Xwidgetwebkit was dead since emacs 29, and for a while I was left pining for a good graphical browser in emacs.
Since then, friendly AI emacsers stuffed usable versions of graphical browsers into emacs, but those never felt truly emacs-native and did leave quite a bit to be desired (embr, the least unusable of the pack, being referred to here; among its warts - unreliable link detection; forcing “tabs” within a buffer; non deterministic unresponsiveness; causing C-g to lag).
Finally I can rid myself of such impurities from core emacs!
by qazxcvbnm - Unfortunately the NS/macOS version still needs work as far as I can tell. Even not fully featured it's still useful: I prefer reading PDF in xwidget-webkit than pdf-tools, and it's great to have Jupyter notebooks running inside a browser inside Emacs.by kkylin
- I went from `vi` to `vim` to `neovim` to a spiritual successor `helix`, and here's Emacs at release 31 still the dominant fork of the emacs family of editors. Impressive.by markstos
- GNU Emacs isn't the first Emacs, although it's still an impressively long-lived and vivacious one.by whimblepop
- I've just started getting into emacs and am almost done with what I think is my final config (just adding vertico, consult and marginalia, haven't added them all, but got vertico and consult working in a mostly default state, still need to tweak a bit).
Then I am going to try to learn more of the navigation keys (I got some of the basics (mostly)) but still need more experience beyond the basics. I am able to get my odin/raylib code to compile with C-c C-c. I even hand compiled 30.1 from github to update from Debians older defaults. The only problem I ran into was forgetting how I got it so when I launched the client it didn't duplicate the icon on my kde taskbar/panel. Uninstalling the old setup must have removed my copy of the start up rules/desktop window name. But got that settled after a bit of searching.
I am trying my hardest not to use EVIL, but it's so tempting, because I've gotten used to modal. But I want to use the full power as mostly established with the key combos.
I'm not sure how much of these features will matter to me as I'm not sure I've used much of the full system. Anything that makes it faster is nice. So far it's been smooth, but I do wonder if running the server (via sysvinit in mx) does cause some lag, as I've felt the system have little hiccups (not when using emacs actively, the client not even open. I did try to adjust the GC settings I found as a tip to reduce lag and do more GC when not heavily used).
Finally does anyone know where to get a 'Meta' 1.25u mechanical keycap???
Even "spacecadet" themed caps I've seen still use "Alt" as the title. Anybody have thoughts on like colemak-dh vs qwerty or other layouts. I think it was protesilaus saying he liked chocofi with colemak-dh (and very insistent that it was "THE" way) so I'm curious if anyone had experience with that (or maybe it was another emacs user).
by wormius - I can't say it has any particular bearing on the usage of emacs, but within the last year or so I started using a "ortholinear" keyboard (an ergodox-ez) and found that qwerty was uncomfortable on that with how lousy my typing form is. I tried a couple different layouts and landed on something called "middlemak"[1]. Of all the ones I tried, it really felt like the one with the least overall finger travel and awkward things to type in my day to day software development work (though there are still some odd letter combinations courtesy of english borrowing from everyone), and it's not a massive change from qwerty so a lot of muscle memory actually could carry over. Workman and Colemak both had some awkward motions or finger strains that just didn't work for me.
That's been both a good and a bad in that on the one hand, I didn't have to relearn every key, but on the other, especially because I swap between middlemak on the external keyboard and qwerty on the built-ins I'm sometimes mistyping because the qwerty key is one key over from where the middlemak version is. But at least for how my brain works, having that familiarity made sticking with the learning curve a lot easier.
I also can't speak for how it feels on a "normal" staggered keyboard since I only use it on the ergodox but I don't have a reason to think it would feel worse. If it helps, this is the keymap I use on the ergodox[2].
[1]: https://www.reddit.com/r/Middlemak/ [2]: https://configure.zsa.io/ergodox-ez-st/layouts/wzKWq/latest/...
by tpmoney - > As always, my book, Mastering Emacs is 31% off for the next week to celebrate the release also.
Eventually, Mastering Emacs will be free!
by uutangohotel - As the Techlead says, only if you're time is worthless.
- Is there a better way to get started with Emacs than the built in tutorial? I've tried a couple times (due to increasing annoyance with VS Code), but have struggled to get to a point where I feel productive enough.by bpye
- I'm in the minority and think the tutorial is awful. "Here's this software everyone says is so great. Before you can actually use it, be sure to spend 20 minutes doing a bunch of stuff for which you don't have context/don't have motivation for"
No thanks.
Instead, literally just start using it and ask an LLM for help as you go.
by stackghost - It's no different from learning vim. Just stick with it until the shortcuts become cognitively automatic.
It also helps to learn upfront the idiosyncratic terms and concepts like buffers, windows, frames, yanking, killing, etc.
Most of these terms map one-to-one to more familiar nomenclature like copy, paste, etc.
Buffers is a concept a bit more unique and integral to emacs. It's easier to understand in practice than in reading.
Most importantly though, emacs is a lisp machine, and exposes the highest level of granularity, and enables the finest level of customization for the user.
by sinker - Start with Doom Emacs. I haven't felt the need to customize almost anything since I switched (from VSCode) 4 years ago.
TBH, I had used Emacs before VSCode and had accumulated a bunch of cruft in my .emacs configuration, and I never felt it was "mine" anyway...
by jmmv - Mastering Emacs: worth every cent. (ignore what author says about it costing money) It is what got Emacs to “stick” for me.
Just get it already
by roundcan7998 - I recommend the tutorial (Help -> Tutorial) from the menu bar inside Emacs to get you started. Don't listen to people telling you to disable this or that. Use your mouse and arrow keys to get started. Don't worry about what other people are doing with their Emacs too much. Pick one thing you want to do with Emacs and focus purely on that (writing Go, taking notes in Org, etc.) and avoid a wholesale move unless you have infinite time and patience.
See also my reading guide: https://www.masteringemacs.org/reading-guide
My book is of course an option also, but it costs money.
by mickeyp - I'm excited for the user-lisp/ changes. It'll let me create custom lightweight packages and have them lazily loaded by just sprinkling ;;;###autoload over interactive commands and modes.by wmedrano
- How unfortunate that glibc has removed support for unexec. Although it wasn't a very widely used feature, it seems like the kind of orthogonal powerful feature that distinguishes one platform from another, like Unix's fork(), or I/O redirection, or strace, or not needing different system calls to write text and binary files. In an alternate universe, you could imagine unexec support being generalized to support broader classes of applications for purposes such as process migration, high-availability failover, and bug reproduction (as with rr), instead of being removed.by kragen
- That was 10 years ago.by jibal
- I always assumed it was a bit of a common practice from image based development practices. I'm now assuming I was incorrect on that being the case?
I'd love to read a good history of the different development styles. I know we often have a good exploration of the parts of an executable file. I don't recall seeing a good exploration of different compilation/build styles through the years.
by taeric - There was a lot of discussion around the time it was being removed[0], but it seems the glibc people simply didn't want the support burden and Emacs was the single user of that interface. I think the issues could have been resolved by checking if all shared libraries are exactly the same as when unexec was called, that the kernel is the same and that the CPU is the same, and failing if anything doesn't match, thus falling back on slow startup. That said, portably serialising the state and loading it back is a better solution IMO.by Asooka
- Bit of a tangent but does anyone have good learning materials on doing things with Emacs Lisp beyond just staring at the source of packages?
I have the Mastering Emacs book and read through most of it, which gives me a good idea for some stuff... but I really would like to have good ideas for the right kind of design patterns for common things.
by rtpg - I started getting a little more into ELisp after reading The Land of Lisp, though its probably a bit basic. If I were to try to get better at ELisp through reading books/docs, I'd look into Common Lisp material.by wmedrano
- https://github.com/protesilaos/emacs-lisp-elements
Protesilaos has a book on this topic. Might be what you are looking for.
- > does anyone have good learning materials on doing things with Emacs Lisp
Pick a quality model, even good local ones are fine, you don't need to feed greedy capitalistic machine. Talk to it. Your first step would be to find a way for the model to "peak into" and change actively running Emacs instance - that's typically done through emacsclient.
Next step - choose a harness package - ECA, gptel, agent-shell, etc., with the goal of running the AI from inside Emacs. You can use external tools - pi, claude, copilot-cli, etc. to get there.
And then just ask questions. With utmost curiosity. Like: "What is lexical binding", "why did you write it this way", "how pattern matching is done in Elisp", "how do I make this type of window to always appear on the right", etc.
Best way of learning is by building something practical. In your case, you'd be building your own Emacs. Just the way you imagine it. And that's virtually the only limitation to it - your own imagination.
by iLemming - Have you read through the Emacs Lisp Intro and Elisp manuals in Info? The latter is especially helpful as a reference.by MarsIronPI