Emacs, by default, is dumb only because you should be the wise one. It stays in the background. It's not a maladjusted fucked-up adult who wants to be center stage the whole time. It understands its purpose and stays out of your way. Everything else, including cute cats on the powerline are just useless crap not only not helping but hindering your goal of talking with a computer. It doesn't insist on anything, doesn't try to guess your needs, doesn't give you a lecture on how things should be. Except, maybe, the fundamentals in life: eat, sleep, fart, have sex, use Emacs.
Once, though this question is similar to so many others, a guy asked in an
online forum, how can I suppress the 'unused variable' warnings in my source
code?
. A chorus of admonishes and
righteous people rose up from the ground. "You should really not suppress your
warnings," the first one replied. "This is not the way to structure
your code and name your functions," the others follow. "I would not release such code in
production, fix your warnings first," seemed to be the consensus.
"Call your momma, tell her you love her," another said helpfully. Three hours later, our guy
answered his own question and moved on with life.
The moral: how do you know my development practices are the same as yours? How do you know that what I'm trying to achieve agrees with your mental model of how things should be done. Maybe this is not production code, maybe I'm just learning the language or test a new feature in a playground. It's all just garbage. I've seen the warning tens of times already. I understand it. Now I want to get rid of it to free my mental space at the expense of a little inconsistency. I don't want to see the warning! And how do you know I wanna talk with my momma?
Software sometimes just has too many features, crutches and grand promises it can't deliver. The official tagline for Emacs, "an extensible, customizable, free/libre text editor — and more," is famous for what it doesn't say. Critically, it doesn't say it will "empower your team to achieve more," or "the best text editor since the dinosaurs," or "the future of code is here." It does not promise you'll achieve "ten hours of work in ten minutes." It doesn't. And that's beautiful and also fair and respectful. How could anyone know that? Wouldn't that be a lie?
Emacs wants you to develop your own style and enjoy the process. When you ask "what is the best Emacs configuration" you're approaching it wrongly. There isn't one. It's a similar question to "what is the best programming language" juniors always seem to be asking, or "what is the best perfume?" There isn't one. You are part of that equation. You are unique. Perfume + You or Emacs + You equals something new.
Once, when joining a new company, a fellow developer asked me, "what text editor are you using?" Dangerous question, but I answered, nonetheless and now I can't forget her reply, "Pffff! Eeeeemacs! We are all using VSCode here!!!" She then disappeared without waiting for my reply. At one year of experience she was what one calls a junior. Six months later, she left the company and the software business for good and went into selling medical equipment together with her husband. Honest work, good for her. Somebody has to be keeping them people alive. I understand. Use VSCode. Use whatever if your not gonna be around for too long. It's fine if you don't want to adjust and poke holes in your tools. Get the most affordable and easy to drive car as your first. Maybe it will also be your last, who knows. Maybe you just don't like to drive, after all. Why bother with something more dangerous?
Look, you don't need numbers displayed on the sidebar for every line of code, you can jump to any line with a single command. You don't need your project folder structure with all of its files filling up half of your screen. There's a single command to search and jump to any file within your project, with autocomplete even. You don't need a tab displaying all you opened files. You don't. There's a single command, a single keystroke to open any file you've already visited. And you know what? You can have as many as you want. The most I've had is close to 500. I don't need to close them, it doesn't matter. They don't take up space nor (much) memory. You also don't need to open a new instance of your favorite editor for each and every project you work on. For long-term Emacs users this might be a shock, but I've seen developers happily navigating their codebase with VSCode, only to ask questions like "how do I open and edit this /etc/mongo.conf file?" Since it sits outside their project, it confuses them. They reach out for nodepad or vim or whatever. There are tens of projects in those 500 files I've mentioned, in different languages, some are for work, some are personal, some are playgrounds for new stuff that I'm learning, some are configuration files, some are folder views, or the browser, some shells, some are cooking notes where I keep my eggplant parmigiana recipe. And they all work the same. That is, switching between them, searching for files or code or function definitions or autocomplete or what have you.
You also don't need a menu with all of the commands to click through. All of those commands are available either from a keyboard shortcut or from a single command that lets you search, with autocomplete, through all of the commands available in the editor. I currently have over 8000. After years of usage, after developing my style, after getting a glimpse of what kind of projects I'm working on and how I like to go on developing software, I've defined some keyboard shortcuts for some of the most useful (for me!) commands out of those 8000. I can peek at the source code for inspiration and even modify any of those commands. Maybe I want the up arrow to move up three lines and flash my screen red, if I so fancy. Just because I can. Nobody is stopping me. I can add more commands, some of which can be nothing more that wrappers around a series of already existing ones. What's not to like? What's more that you need?
I understand why juniors are overwhelmed. They are not yet in a position to decide which features they want. No, I'll revise that. They are not yet in a position to decide which features they need. See the difference? That's the problem. It always is. Everywhere. Anywhere. In any industry, for all professions. As a result, they put in everything, "just in case I might need it," just like a kid who doesn't yet know what ice-cream they like best so they want all of them. They don't yet have a use-case for their text editor or for any of the tools or languages they're currently using, Jira included. Hell, they might not even be able to press the keys on the keyboard right yet. As such, choosing a text editor is not an activity to be enjoyed but task to be completed and forgotten about, like a visit to the doctor, maybe.
By the way, have you seen the finishing touches of a WRC rally car? The interior, their dashboards? Horrible! Horrendous! Such bad taste! You know what? It doesn't matter! It's an advantage. The advantage of not being distracted by all the fluff, of not having to take care of all that visual noise, worrying it might break and not knowing how to fix it. Or how expensive will it get. The advantage of gluing it together yourself, on the spot, and be merry.
Those cars are also noisy beasts, rugged, cramped and uncomfortable. Cables are bleeding out from everywhere, windows won't wind down, no stereo system, no navigation system, no place to keep you beverage cold while driving. Those cars are like steel boxes on wheels. And yet, have you seen those flying? One look away from the road to search for the "Delete" key and you're deleted forever. Honestly, go look! click -> file -> open -> dead!! The goal is to go from point A to point B at the fastest speed possible and not die in the process. That's it. Everything else that does not serve this purpose is useless crap. There's no need for labels and stickers telling you what each button does. If, after ten years of programming, you still absolutely need menus to click on and save your latest work of art and labels on your keyboard to tell you what each button does, you got bigger issues than syntax highlighting. Speaking of which, one other area that can be classified as big issue is reaching for the arrow keys every time you want to navigate your code. Stop that!
Flat tires don't impress these drivers, nor broken shields, a missing bumper or a crater in the middle of the road filled with snakes. If the box it rolling, we're going. If you came out of a rally stage without a single scratch, you're driving it wrong! Crashes are to be expected. We survive them. We live with them. Is part of us. Hell, people risk their lives just to be able to see these guys in action! Things need not be pretty, tidy and in perfect running condition at all times. Unused variable warnings need not be shown. Interactive development can happen. And don't ask why they're still using hand-written notes for navigation purposes as we have voice assisted maps now, friendlier and up to date. And prettier. And safer. And eco-friendly. And just shut up already! You digital maps and assistants are too slow for my needs!
Some of these guys bring in their own money to be able to compete. It's a privilege and badge of honor for them to compete. So why complain you have to configure your Emacs and make such a big fuss about it? That should be an honour, too. To have so much code, such a friendly and helpful community, so much history, functionality and power at your fingertips, to do what you want with it, crack it open, reassemble it with a new engine if you want, even to build a new engine if you're so inclined. So what if it doesn't start on the first key? Big deal! There's no life penalty for that! No God will point a finger at you from the high heavens, not even Stallman. Break that engine apart and try again! Know better on the next try.