Emacs, how it all started for me(xvw.lol) |
Emacs, how it all started for me(xvw.lol) |
Do not use a distribution. Yes I know.. you have read that before and then you used Doom or Spacemacs anyways. That's me in the past. And it never worked out for me. I always ended up trying to configure things and the whole setup was too complex for me, so I failed.
Over the last 10 years I have been a heavy (n)vim user but I tried Emacs multiple times. Always a distro. It never worked out. Now over the last year I was trying Emacs with a vanilla setup and configured everything from scratch. With the AIs this is super simple because they can help you get out of config trouble.
The experience was way better than before. After my one year experience I have switched back to neovim but I still have become a fan of Emacs and I have adapted my nvim config. Stuff like dired, magit, compile-mode I have found equivalent nvim plugins and use them now.
https://www.masteringemacs.org/
This provides an excellent base and exploration of the builtin packages, then you can customize your experience on top and make it your own.
Better to just start using it, and ask your friendly local LLM when you need help. Back in the early 2000s, I think I used emacs for 3 or 4 years knowing only how to open/save/close files, switch buffers, undo, and quit.
It will be a struggle. It was around 2 months before I felt remotely comfortable in Emacs. And nearly a year before I really felt at home. It's a long road, but gradually you mold the editor to yourself so tightly that you'll never be able to go back. The remarkable thing is that the progression never stops. The tool just keeps getting sharper and sharper.
No one will ever convince me that there is something better than vim mode for editing text (or comparable modal editors).
I dont use your "other apps" enough to know exactly what you mean, but it gives me the urge to point out, "Emacs 'frames' are actually more like windows in other apps" :)
Especially if you don't want to use an agent to help you get started. If you're using an agent, starting from vanilla is much more feasible.
I only started using an AI to help fix issues or understand configuration problems when my config was already >1000 lines.
But yea there are several ways to approach this :)
So I guess you and others here have had the experience of building something that was your own that felt better than the distro?
I am not saying they are bad, just not for me.
And I think they make it somehow harder to discover the true power of emacs: bending it to your will & basically forging your own custom environment, not only for editing but so much more (git, mails, pdfs,...).
I think bedrock is reasonable, and so is Prelude (https://github.com/bbatsov/prelude). I used to have a sprawling init.el, but these days is pretty compact (236 lines), mostly using straight to install packages and then configuration for gptel, agent-shell, and various hydras (https://github.com/abo-abo/hydra) to quickly execute various functions.
Every line in init.el is something that you have to maintain and move with you.
And when you're using someone else's computer, their init.el won't be what you expect.
Emacs has come a long way in terms of in-built features. The only problem is that, in the name of not breaking backwards-compatibility (or something like that), the archaic defaults have remained. Just a little bit of simple config (either from Bedrock or, heck, even an LLM) will get you very far.
I'm working on a new version of Bedrock for Emacs 31. If you're using the release candidate (which, because it's Emacs, is more stable than most other operating systems) then check out the `emacs31` branch.
[0] https://apps.dtic.mil/sti/tr/pdf/ADA125287.pdf (Brian Reid's CMU Ph.D dissertation a.k.a. a manual for Scribe).
That said, I’m usually in vim. Emacs is a neverending rabbit hole of a hobby that begs to be tinkered with forever. I find it easier to just do useful stuff in vim and I’m always trying to add a new efficient keybinding or function to my Emacs config.
These days we're all spoiled by Visual Studio Code, Zed, even things like Geany and Notepad++. So it makes less sense for neophytes to start with something as ancient and idiosyncratic as Emacs, and Emacs does not enjoy nearly the prominence or mindshare it had decades ago. (Though I understand its absolute user base has grown.)
As a user since '97, I've often felt that this philosophy is entirely, well, backwards. I know how to read the release notes to learn of such changes and how to edit my personal init.el file to revert a setting if I don't like the new default. As long as no one takes away the option, the default doesn't really matter too much to me. But newcomers who might not yet be comfortable with editing their init.el files could really benefit from a more optimal out-of-box experience.
(And besides that, often the newer option is something that I've already moved on to, so making it the new default means I can now remove it from my init.el. I always enjoy when I discover that I can cut something from my init.el because it's now in base Emacs.)
Then, to change a default from `old` to `new`, you instead change it to `configVersion >= x ? new : old`, and add some kind of non-fatal warning in the else case instructing users to set their config to `old` explicitly.
You don't break people's setups, they become aware of new defaults without reading release notes, and new users get the new defaults.
I've been using emacs as my primary editor since about 2002 and I hate this take. Emacs Lisp is by far the worst part of emacs. It is a horrible language, best kept dark and deep in the vaults, not to be used, unless at the uttermost end of need.
My config, after more than two decades, is about 400 lines, and I consider that excessive.
I'd already known Common Lisp from a prior class, which mostly used some Mac based REPL. Shortly after, I had real Emacs and various CL and Scheme runtimes on my Linux PC. Scheme was my obsession at the time. A lot of my pathway into CS was puzzling over what it would take to implement a Scheme runtime. But, I felt no desire to get into the bizarre-to-me elisp dialect. It just felt gross.
Probably because of early years using shared terminal server rooms and hosts, I also learned that over-customization just became a pain when I had to move between environments. I ran the Emacs that came bundled with my Linux distro, with the extensions that came packaged along with it. Mostly I just tried to have Xresources to get my preferred color scheme and text fonts.
From all of this, I'm nearly some kind of old school Unix fundamentalist. I've never wanted an IDE. Or rather, my IDE has always been the host OS, shell prompt, filesystem state, and other terminals. I use adjacent shells to run builds, tests, debuggers, version control, etc. Emacs is just my editor. I've never, ever wanted any editor to subsume my OS, window management, and these other tools.
My favorite interface feature is creating several "frames" (separate X windows) viewing into the same buffers. Sometimes several files side by side, and sometimes several editing viewports on the same file. I also use the X based menus to find many esoteric features or session settings for which I would never memorize the command names.
But, when I am forced to run Emacs in text terminal mode, I revert to thinking of it like JOVE. I'd rather open multiple terminals (and SSH connections, when remote) and have each one run its own ephemeral Emacs instance with one buffer for a brief foray into one file. Somehow, I've never had the urge to fire up an Emacs server to share state between these. I just find my way back to a proper graphical Emacs when I want that kind of complex editing session.
The only Emacs modes I use are for syntax highlighting and auto-indentation. I also never wanted Emacs "windowing", i.e. text terminal muxing. For me, learning to kill accidental window splits was roughly the same need as learning how to exit/abort out of accidentally launched vi. Repulsed, I head for the exit!
My favorite editing features are just search, find-replace, and find-replace-regexp. But search is mostly just a fast-scroll to me, jumping forward or back to text I know is there. If I'm really searching, I more likely mouse over to a terminal window and run find and/or grep from a shell. My favorite advanced editing feature is buffer-compare (Ediff), which I use for merging changes between two files in side-by-side frames.
Oh, and I despise the GNU infos-style help system too. I much prefer manpages, or secondarily reading docs in a web browser.
I still use web searches to look up Emacs things occasionally, but the built-in help commands are still useful because they're naturally tied to (and organized by) the core code entities that power Emacs.
I'd also add `C-h b` to show you the key bindings. (And `C-h` after a prefix key will usually show you the bindings that start with that prefix.) `C-h a` for apropos to search commands by substring can also be useful.
The thing that makes it really "self documenting" is that these help commands reflect the live environment at the moment you use it. If you've added a new binding in your init.el, `C-h b` and `C-h k` will show it. If you've added a new function in your init.el, or loaded a custom package, all those functions can now be found via `C-h f`. The help system will show you the doc strings for them and provide hyperlinks right to the source.
Moreover, this works for anything that you define on the fly. Open an Emacs lisp buffer, type some elisp code to define a function or variable, execute the definition, and now it'll appear under the above in the help system the next time you invoke help.
Emacs can "describe" anything contextually. Describe current mode, character at point, specific command, any variable, etc. With Wilfred/helpful it gives you even more stuff. If you're not sure what's the exact symbol/command/mode name you're looking for, there are 'apropos' set of commands. Also, absolutely learn Info and how to navigate it - it's enormously descriptive and very useful - it beats googling stuff up, because a) it works offline b) it gives you more accurate info about your current system.
C-h r (open Emacs manual)
C-s "line numbers"
Also apropos works.
I assume you meant orderless?
That said, I've been using it for... uhh... about 30 years now, and I've honestly never picked this skill up myself very much. I can only use it minimally. Just googling is fine, and as others have commented today (although maybe in that other thread about emacs), AI makes it even easier because it can just straight up write the modifications for you if you need them.
Emacs was literally the sanest option unless you could bribe the sysadmin into installing "joe" or similar. ("pico" and "nano" came later).
The other thing is back in the day emacs was often a good option for running clients to connect to things like IRC or MUDs or MOOs, and even Gopher and the early web. It was also an excellent news and mail reader!
And so I used emacs as a general text editor and MOO and IRC client long before I ever used it for writing source code really (for which it was also obviously very good).
It's a holdover from the days when people used to type without looking at their keyboards or waste time and effort taking their fingers off the home row to find and stab around with some kind of multi-axis valuator device sitting on their desk somewhere.
Using gptel? Or something else?
As described by its creators: The Unix Programming Environment <https://en.wikipedia.org/w/index.php?title=The_Unix_Programm...>
I trained in touch typing in the 80s/early 90s in typing classes, on Selectric typewriters. Beautiful keyboards.
You can start using it without reading, but the UX does not follow common patterns like found in Notepad or VSCode. It is its own thing and reading the tutorial, Mickey's book, or the official manual is way faster than fumbling around. Even my bluetooth speakers came with a manual.
I know. Emacs is my daily driver.
>reading the tutorial, Mickey's book, or the official manual is way faster than fumbling around.
Hard disagree. It may be more efficient in terms of total time spent, but you can learn 5 commands and start using emacs immediately.
Compared to spending multiple hours reading a book or, worse, the manual, I know which one I'd choose.
Why multiple hours? You can always skim it.
Say what you want, but I wouldn't trade it for any other (non-homoiconic) language. Sure, it won't win the contest of the "nicest Lisp", nevertheless - it's a Lisp, and therefore far better suited for the things Emacs is designed to do.
Have you ever thought why Org-mode, developed and maintained by a handful of people (perhaps fewer people than the React.js core team has) is capable of carrying features that (despite so many brilliant minds) never appeared in any similar products? Like for example, executable source code blocks in different PLs that can pipe data into one another. Even Jupyter can't do polyglot execution with data passing between the languages. That shit doesn't exist in Neovim, or VSCode (where MSFT poured millions of $), or IntelliJ. It exists because Lisp makes it much simpler to design and build such things.
As someone who's been "using" Emacs just like you (without ever writing much Elisp), and also "properly using" it for a long time and having to see both sides, I can assure you - it's absolutely worthwhile to spend some time grokking Elisp. It's not a horrible language. For what it is - it is incredibly flexible. You just don't know what you're missing.
Its documentation (the manual in Info and M-x describe-function, etc) is exceptionally good. I don't need to be connected to the net when I'm writing something in Emacs Lisp. Try that with Javascript!
What I don't understand is wanting to replace elisp with a mainstream scripting language. None of them are really functional-style languages; it's just a completely different world.
(Non-scripting languages are a different story, but fundamentally a different use case.)
That typically comes from people without any experience in any Lisps. They don't know "REPL-driven development", they haven't heard about "structural editing", Lisp looks like a parenthesized mess to them. I looked at it the same way until I learned. Now I don't even notice parens - I see structure, beauty and reason.
After learning the key bindings, I actually found a library book on a pre-CLisp dialect of lisp by some finnish authors and wrote a tool i later used to write my thesis in electrical engineering.
The tool was parsing my matlab files and generated latex, which i then made into the final pdf, complete with formulaes and calculations.
So instead of writing a decent thesis, i learned about makefiles, latex, emacs lisp and the fact that parsers are very interesting.
Also, Lisp felt sooooooo out of this world after pascal, C, Cpp.
Surely, i did not work a single day as an electric engineer.
PS I keep looking for this book to this very day
My suggestion to focus on Elisp is not like tech-splaining monads, and Lisp is not that difficult. Definitely not even in the same league of difficulty as Haskell. It is an astoundingly simple language. And yet people just ignore it for years, clueless of what they're missing.
I have been using emacs for 20 years and never heard of edebug before today, and have never used the profiler. If I install some new package and it doesn't immediately work, I usually uninstall it right away. I don't have time to fuck around. I would rather chew glass than debug breaking changes in my init.el so I make changes rarely, and deliberately. To each their own, I suppose.
So, you're making assumptions even without ever trying? You just decided it's hard/time consuming/worthless even though you have "never heard" about it?
> I have been using emacs for 20 years
Yeah, well. Like I said: Emacs is first and foremost a Lisp interpreter, "using Emacs" actually means dealing with Lisp. To what extent - it's everyone's own choice. I have seen too many stories of people like you - "using" it for decades and then abandoning it for VSCode or other things, without even realizing what they've given up.
It only takes just a bit of knowing the basics of Elisp to get the genuine Emacs experience, otherwise, you're just riding the car, not driving it.
> I don't have time to fuck around
That is a big misconception. Prolific Emacs users don't waste time ricing their setup just for the sake of it. They apply Lisp to meet their needs. My own work demands certain changes every single day - I have to move between different projects, in different PLs, dissimilar teams; I poke into various APIs; consume data in all sorts of formats; build prototypes, every time with different scope and requirements; analyze huge sets of data; search through documents, hop between different hosts, etc. I can only imagine how miserable my life would've been without my Lisp tools, where Emacs invariably takes the center stage.
It seems like you lack the notion of what it's like to literally shape your tools for your needs as they evolve. It's like having an entire pottery workshop at your disposal, but choosing to only pick up the already finished, dried pieces. Seriously, don't be daft - hook up an AI assistant to your config, the possibilities are virtually endless. It could be just about anything - any small annoyance that you may decide to improve in your workflow. I wish I had developed this "emacs/hacker mindset" where I don't even think twice, if something feels suboptimal - I'd try to automate it. I'd just start typing some Elisp in my scratch buffer. These days, it has gotten even simpler than that - I'd just type a prompt.
So if it takes learning a language, language it was.
But i gave up on teaching Emacs. My current stance is: if you want emacs then you know how to do it.
I'd typically would start by showcasing a single (albeit enormously important) aspect of it, like search. When someone sees the countless ways to search for things in Emacs:
- isearch, query-replace, occur, multi-occur, project-search, find-file (with wildcards), ffap, apropos, xref-find-definitions/find-references, consult-line, consult-ripgrep, consult-fd, consult-hn, consult-omni, browser-hist-search, magit-find-file, magit-dired-log, etc.
That typically, already is enough for them to say - "darn, I want this...". Then next step is to show them that there's nothing to fear - everything is documented, described and can be inspected on the go.
In teams where pair-programming is a normal practice, I would typically watch their efforts with something in VSCode, IntelliJ, or even Vim and ask them if they'd want to see how I'd do the same/similar thing in Emacs. If the person is not interested, I won't push for it, but at that point, someone who worked with me on the same team knows that I can show them something entertaining and interesting to see, even if they don't get the immediate urge to dive into it.
You must mave misread what I wrote, because you're conflating two different statements.
>I have to move between different projects, in different PLs, dissimilar teams; I poke into various APIs; consume data in all sorts of formats
None of this requires elisp beyond the use-package incantations to install a given mode, which is only done a single time.
>It seems like you lack the notion of what it's like to literally shape your tools for your needs as they evolve.
My needs are already mostly satisfied by emacs. It is excellent at editing and composing text out of the box already. I have language servers for auto-completion. I have syntax highlighting. If I am mangling a text file I use the build in transient macro recording feature.
The editor itself is almost never the bottleneck in my work. Elisp is so unpleasant that I have zero desire to hack around in it for fun.
You just sit here stiff-necked without even the slightest clue of what I'm talking about. I don't hack for "fun", I hack with a purpose. Here's a practical anecdote. I was pair programming with Matthew over Zoom and he was showing me certain things. He would navigate to different sites, switch between terminal and his editor, run some scripts etc. I just couldn't bear interrupting him all the time saying, "hey, hey, hey, slow down, please. I'm trying to take notes here... Hey, can you share this link?...", etc. So that bothered me for a minute. I sacrificed my lunch break, sat down and figured that out. I wrote a tiny function that checks if the last thing in the clipboard is an image and sends it to tesseract CLI for OCRing. Took me not even fifteen minutes. Now I can just select an area of my screen (with Flameshot), and the text pops into an Emacs buffer.
This feature never existed - not in a package, not in anyone's config on GitHub. It's a specific problem that I quickly solved for my own needs. Could I have done this with Python, Bash, or AWK? Sure, why not? The thing is - before Emacs distilled this mindset into me, I wouldn't even have bothered about it. It wouldn't be a bottleneck I would ever think of noticing. And that is just a single example of hundreds of different things Emacs helps me with. Anything text-related invariably ends up being routed through Emacs, and majority of programmers have little idea how empowering this could be. I consume much of the content through Emacs - I read HN threads in Emacs. Also Slack, Reddit, Jira, my browser history and other things. This very comment is being typed in Emacs.
I have seen both of these worlds. You are sharing just one side of it, of which I am very familiar. So why don't you take my word for it and give it a try, instead of arguing that the side (you have never even experienced) is not worth your attention? What do you have to lose anyway?
Because you're being too aggressive and unpleasant
>What do you have to lose anyway?
Time spent on more important things
Huh. Well, I guess, fair enough. Would be weird for me to assert that I don't feel like it. What could I say in my defense? Jesus tried to spread the word nicely, have you heard what happened to him later? :)
> Time spent on more important things
There are a bunch of things I had to learn over the years. Three things I have never, not once, ever regretted spending some time getting familiar with - Linux, Vim-navigation and Lisp. All three grand ideas have a profound compounding effect on my workflow. Turns out, later you'd carry regret not for trying random things, but for things you have never tried. I do to a certain degree regret chasing things that turned out to be ephemeral, but that time doesn't feel exactly wasted. The only genuine regret I still carry - I wish I had someone in my life to urge me to try learning these things sooner. I do absolutely regret the time wasted. All three taught me a great deal of wisdom, and I wish I did it when I was much younger.