Rendered at 22:08:10 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
fileeditview 4 hours ago [-]
A bit of advice to people that have the urge to try Emacs.
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.
zingar 12 minutes ago [-]
Interesting. I started on spacemacs and never left. My spacemacs is super pimped for the things I want. It feels like if I rolled my own I would end up with something like spacemacs, but not as good.
So I guess you and others here have had the experience of building something that was your own that felt better than the distro?
sph 2 hours ago [-]
Seconded. If you want to learn doing things the Emacs way, I recommend the Mastering Emacs book by Mickey Petersen who roams among these threads. It is excellent.
This provides an excellent base and exploration of the builtin packages, then you can customize your experience on top and make it your own.
stackghost 1 hours ago [-]
I bought a copy of Mickey's book, and it's great, but "read about the inner workings of an editor before you use it" is horrible UX.
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.
skydhash 48 minutes ago [-]
> but "read about the inner workings of an editor before you use it" is horrible UX.
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.
widdershins 4 hours ago [-]
Agreed. Work through the Emacs tutorial to find out how vanilla editing works. Then look at buffer management, window management (Emacs 'windows' are actually more like frames in other apps) and simple tooling like search. Then start to tweak some settings in your config, find the bare minimum of packages you need to scratch your worst itches (for me: Vertico, Corfu, Avy and Dumb Jump). Finally, figure out tree-sitter modes, project/projectile mode and a couple of other foundations.
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.
fileeditview 4 hours ago [-]
Yep. I also forgot one important point. If you come from vim, like myself, you should probably use evil-mode right from the start and then just get used to a few important Emacs shortcuts over time and use them additionally to your evil keymaps.
No one will ever convince me that there is something better than vim mode for editing text (or comparable modal editors).
rpdillon 2 hours ago [-]
Emacs guy since '97, strongly agree. If you build your own config, the Ikea effect takes hold and you feel like you've made something that's "yours", even if it's mostly cutting and pasting (or using AI) to cobble things together.
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.
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.
fileeditview 2 hours ago [-]
There are some good tutorials on youtube to start from zero. E.g. "Emacs from scratch" by System Crafters.
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 :)
vondur 1 hours ago [-]
Yikes, that's over 12 hours of videos in that series. Stuff like that scares me away from trying it out.
zingar 6 minutes ago [-]
I love the way this starts with using emacs badly since 2008. I start my own shorter emacs story similarly: “I’ve been using emacs for 10 years, so I’m only a beginner“.
ashton314 3 hours ago [-]
If you find yourself wanting to try out Emacs but are (understandably) turned off by some of its archaic defaults, I encourage you to check out my Emacs Bedrock [1] project. It is not a framework like Doom Emacs or Spacemacs. Instead, it's just a bunch of better defaults, plus some example configuration for some of the most popular packages. It's meant to just be a starting point, and not a framework to keep up-to-date in the long run.
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.
> The only problem is that, in the name of not breaking backwards-compatibility (or something like that), the archaic defaults have remained.
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.)
gazonk 3 hours ago [-]
It all started in the early eighties. Just got into the university and the machine was a PDP-10 (tops20) and the only option as I remember was Emacs. Has been using it since. Not so much after the introduction of IDEs. But will totally lost for general file editing if there was no Emacs in Linux distrubtions. Hard to grasp? Maybe but for me it was the first thing I learnt and most likely will end with.
dctoedt 2 hours ago [-]
And Brian Reid's Scribe formatter [0] — so much nicer than roff, troff, etc. (descendants of Runoff). In 1981-82 I wrote a user manual and taught my fellow law-review editors — none of whom were computer people — how to use both Emacs and Scribe (PDP-11 / TOPS20). It was a real boon, freeing up our paid secretary from having to repeatedly retype manuscripts after we'd edited them, and cutting down on printer errors that had to be hand-corrected on galley proofs.
As someone who’s only used Emacs for around 5 years, Emacs is awesome even if you haven’t been using it since 1987. I used to get intimidated by the fact that every single Emacs user has been using it for decades. System Crafters was fantastic for getting a handle on things. It’s one of the coolest programs ever.
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.
HeyLaughingBoy 58 minutes ago [-]
LOL. 1987 is just about when I stopped using emacs. Suddenly, I feel really old...
lanycrost 2 days ago [-]
I moved to nvim from vim and it's seems me to easy and handy for everyday use. While emacs like rocket since :D
iLemming 1 days ago [-]
Emacs is most definitely not a rocket science. The problem with people trying Emacs is that they approach it just like any other text editor, instead of understanding the grand, core principle of it - Emacs is first and foremost a Lisp interpreter with a built-in text editor and not the other way around. Therefore it makes much better sense if you approach it from a Lisp perspective. Alas, many, perhaps most, beginners try it after hearing how "powerful this Emacs thingy is", and try to learn "editor features", instead of focusing on the Lisp side of things. Some even admit that they don't like Lisp and don't understand it and plan to never deal with it. Most posts of "abandonment" and "I switch to VSCode after decades of Emacs use", after closer examination, reveal that the person perhaps never even written any elisp code - at most, they'd just [almost] blindly copy&paste existing snippets into their configs.
jr_isidore 24 hours ago [-]
No one, including yourself, approached emacs from a Lisp perspective.
vkazanov 5 hours ago [-]
I did.
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
jr_isidore 2 hours ago [-]
GGP's claim is emacs is better learned as a lisp machine than a text editor, which is akin to saying a monad is just a monoid in the category of endofunctors. In other words, it does a neophyte no good to see the matrix without having lived in it first. It's all one can manage learning emacs's editing primitives if you've never seen it before. Reminding them some (but not all!) of these primitives are in fact elisp expressions is just annoying.
egorelik 3 hours ago [-]
I did - I first came to emacs during my lisp phase. I didn't stay with lisp, but I did stay with functional programming, and in those days emacs was the best environment for a number of functional programming languages (maybe still is).
jr_isidore 2 hours ago [-]
GGP's claim is emacs is better learned as a lisp machine than a text editor, which is akin to saying a monad is just a monoid in the category of endofunctors. GGP's critique is typical of poor exposition. Read the first chapter of any maths textbook from the 1970s. It doesn't make any sense because the author already knows where everything leads and lest he appear a fool to his peers, will insist the reader does too.
iLemming 4 hours ago [-]
And that's why it cost me two-three years of wasted experience. Looking back, I wish I had focused more on understanding Elisp, learning edebug and the built-in profiler. My bona fide Emacs journey began only after I started writing Elisp without fear.
stackghost 1 hours ago [-]
I guess if one's hobby is fiddling with emacs, then I could see why learning edebug and the profiler are valuable first steps. But I view emacs as merely a tool to get vastly more important work done. I just want it to stay out of my way.
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.
stackghost 1 hours ago [-]
>Emacs is first and foremost a Lisp interpreter with a built-in text editor and not the other way around.
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.
saltcured 4 hours ago [-]
Heh. In the early 1990s, I got initiated to the basic Emacs key bindings and editing UI via JOVE for a Scheme programming class. JOVE didn't have elisp behind it, instead being light enough that scores of students could all be running their own editor session and Scheme interpreter processes on the same memory-starved, multi-user server.
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.
teddyh 4 hours ago [-]
> Or rather, my IDE has always been the host OS, shell prompt, filesystem state, and other terminals.
It was always like that before about 10 years ago. You're getting your feet wet in programming, learning about free alternatives, and you learn that all the world's legendary hackers become proficient in one of either vi (vim) or Emacs. So you dig in and you find that, as your awareness of programming languages grows, Emacs is a "good-enough" solution for working in nearly all of them. (Vim is too, but maybe a bit less so in 1995 when I was starting out.) And if you want to program effectively cross-language, there's nothing you can do but lock the fuck in and learn your editor's idiosyncrasies, shortcuts, and programming/customization features.
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.)
greggroth 3 days ago [-]
I used vim for about 15 years and emacs for the last 6 or 7 and never has it been easier to emacs. For years it was searching Google, blog posts and manuals for "how do I do X in emacs?" and now it's trivial to ask AI. I always have a Copilot session open in my emacs config so it can tell me how my emacs does something and can update my config for me.
neutronicus 5 hours ago [-]
> I always have a Copilot session open in my emacs config
Using gptel? Or something else?
cmrdporcupine 5 hours ago [-]
For me what I found was that on early 90s telnet-accessible Unix systems the only pre-installed or easily installed editor that actually let me use... luxuries... like arrow keys and backspace was emacs. Vi was always there but modal editing repulses me and it also didn't work with arrow keys and the like. (I've never understood the fixation with avoiding them in favour of repurposing letter keys, something that is just a holdover from the very anemic terminal keyboard that vi was first developed on.)
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).
bregma 4 hours ago [-]
> I've never understood the fixation with avoiding them in favour of repurposing letter keys, something that is just a holdover from the very anemic terminal keyboard that vi was first developed on.
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.
cmrdporcupine 4 hours ago [-]
I've never had a problem hitting my arrow keys on the fly.
I trained in touch typing in the 80s/early 90s in typing classes, on Selectric typewriters. Beautiful keyboards.
tempfile 6 hours ago [-]
I've been trying emacs for a while. People keep saying it's self-discovering and I have no idea what they mean. Am I missing part of the manual? I google stuff when I don't understand, like any other piece of software. I've never managed to successfully use the help system to find anything.
tikhonj 5 hours ago [-]
The neat thing with Emacs is that the core concepts of the system are all first-class programming entities with their own documentation. So if you want to know what your current mode does, you can use C-h m to get a bunch of information including commands, key-bindings and links to code. If you have a key command, you can use C-h k, enter the keys, and you'll see exactly what function that command runs. You can get info about functions with C-h f and variables with C-h v; coupled with some kind of fuzzy-find-autocomplete (which, unfortunately, isn't set up by default), it's usually pretty quick to find the functions and config options that are relevant to whatever you're trying to do.
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.
a_e_k 18 minutes ago [-]
Yep. `C-h k` to look up what a key does, `C-h f` to look up a function, and `C-h v` to look up a variable/setting will get you pretty far.
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.
iLemming 4 hours ago [-]
> I have no idea what they mean
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.
rpdillon 2 hours ago [-]
It's crazy man, you can get full text search for any concept you want. Here goes:
C-h r (open Emacs manual)
C-s "line numbers"
That's it. Just keep pressing C-s and it will search through every section of the entire manual for the keyword you mentioned. After 5 tries, it lands on "16.24 Customization of Display", and you can read how that works.
Also apropos works.
bogomog 3 minutes ago [-]
I was mildly disappointed the other day when I did a <C-h a>, and instead of "apropos" I saw "search for command". Apropos was one of those killer features that was, as far as I know, unique to emacs (until the "command palette" appeared in one of the newer editors).
Jtsummers 46 minutes ago [-]
Some distros used to (still do?) drop some of the manuals, it was really annoying to discover this on Ubuntu a few years back. As someone who knew the manuals should be there it was easy to get the right google search to find out how to install them, someone new or inexperienced with emacs would likely not recognize that anything was missing in the first place.
matthew-craig 6 hours ago [-]
Having a good completion package (e.g. `vertico` + `unordered`) goes a long way to finding stuff. I regularly find new functions and variables by calling describe-function and describe-command and just searching/auto-completing my way to what I need. It gets even better with the `helpful` package which improves the layout/features of help pages a lot.
jerf 4 hours ago [-]
It's self discovering... once you figure out how to use its very eclectic by modern standards mechanisms for discovery. No sarcasm. Learning how to use it is a skill you have to actively acquire. This is more a criticism of emacs than of you.
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.
hollerith 5 hours ago [-]
I learned Emacs before search engines and can develop Emacs software while disconnected from the internet. My point is that Emacs is more self-documenting than most things.
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.
So I guess you and others here have had the experience of building something that was your own that felt better than the distro?
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.
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.
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 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.
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 :)
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.
[1]: https://codeberg.org/ashton314/emacs-bedrock
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.)
[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.
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
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.
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.
As described by its creators: The Unix Programming Environment <https://en.wikipedia.org/w/index.php?title=The_Unix_Programm...>
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.)
Using gptel? Or something else?
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.
I trained in touch typing in the 80s/early 90s in typing classes, on Selectric typewriters. Beautiful keyboards.
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.
Also apropos works.
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.