I enjoyed reading this. I'm not criticizing, but having used emacs for more than a quarter-century now, I keep things a lot more vanilla.
My .emacs file is 63 lines right now.
If you have emacs with vim keybindings, a purple flying toaster, and a whole bunch of custom hotkeys, if you ssh into a server, set up a new machine, or use a friends' computer, it's all very foreign. It's not in your muscle memory.
Generic emacs works the same everywhere. My typical .emacs disables the flash screen, the top menu + toolbar, loads a few modes for the programming languages I currently work in, configures paths for my local machine, and has two or three minor custom scripts.
That's it.
I've gone through the same exercise as OP did one I first started using emacs, and I highly recommend doing the same. You learn a lot about how emacs works. Sharing it is good too. I learn a few new things each time I read one of these, and even sometimes add a line or two to my .emacs.
However, not long after I did my super-custom-emacs, I upgraded machines, and was back to vanilla emacs, and I've been very happy there ever since.
I know a couple people who subscribe to this philosophy. I think that, like customizing Emacs itself, the decision of how much to customize is an important consideration when optimizing your workflow.
Personally, I do 99.9% of development on one machine. If I need to edit a file while ssh-ing, I use vim. I put my .emacs.d in a private repo so setting up a new machine is done with `git clone`. Upgrading emacs does sometimes break things (which can be quite frustrating), but that also is rare enough that I wouldn't want to let that constrain my daily workflow. So since all of those things fall in the 0.1% for me, I have no problem tweaking things to my liking.
In the generic (integrated over a 20-year timespan), actually, yes, I do use other peoples' computers often. I do that less since Covid, since everything has switch to working-from-home, but:
* Nowadays, technical development occupies a plurality, but not a majority, of my time.
* Much of the time on technical development is spent mentoring people more junior than myself, rather than coding myself.
In the in-person version of the above, I'd spend a lot of time sitting next to someone, either at a keyboard or a whiteboard.
Working with the right junior developer (bright, inexperienced, ambitious, open-minded), I find it very rewarding, and they do too:
* I'll usually pose a problem to them to solve.
* They'll come back with questions, or perhaps a little bit of prototype code.
* I'll usually explain some complex algorithm, piece of systems programming, or architecture, with a lot of theoretical background about not just what but why.
* They'll implement that, or sometimes, something better I didn't think of.
* I'll review their code in-depth, line-by-line, sitting together talking through it.
* They'll make changes, and by that point, we'll usually be ready to merge.
At this point, people half my age implement things faster than I could. Part of that is youthful energy, but just as much are distractions (meetings with stakeholders, home/family/etc. constraints, administrative overhead, keeping funding flowing, etc.). I put a lot of energy into making sure they have room to focus.
For me, it's rewarding to see systems built quickly, and it's rewarding to see the level of personal growth which comes with this. Very obviously, a lot of information flows both ways too, and I learn a lot through the process.
The right junior developers find this very rewarding as well. We're solving hard problems, and it's a much faster, deeper way to learn than e.g. a grad school course. The process also results in very high quality code.
Footnote: A lot of this requires building a close personal relationship and a lot of trust to work well too. That's important to me too. If I spent 40+ hours at work, I want a village. I feel better in that sort of workplace, than a 3-year mercenary-style career job-hopping and keeping a clean work/life split. I am not pushing that on anyone else, but the way my brain is wired, that's the kind of workplace I feel good in. For someone to sit at my terminal (or vice-versa) it's very intrusive with people one doesn't know well and trust.
I‘ve always tried to use defaults, not only in Emacs, but pretty much everthing. Unless I work 24x7 with a tool, I go away from customization, because of mentioned reasons.
Also, defaults are generally not very bad, there was some thought into defining the default.
In a twist worthy of a Christmas fairytale miracle, the emacs users recognised the error of their ways, and embraced the workflow their hearts had secretly always longed for: vim. Peace returned to the kingdom, RSI was defeated, they lived happily ever after and had many children.
I don't quite see it that way. Spacemacs' motto sums it up best: "The best editor isn't Emacs or Vim, it's Emacs and Vim!" Mixing and matching the strengths of both editors results in a much better experience.
Great article. I currently use Doom Emacs and this series is making me question if I really need it. The two articles have covered almost 80% of my workflow. The 3rd article might round it to 100.
My .emacs file is 63 lines right now.
If you have emacs with vim keybindings, a purple flying toaster, and a whole bunch of custom hotkeys, if you ssh into a server, set up a new machine, or use a friends' computer, it's all very foreign. It's not in your muscle memory.
Generic emacs works the same everywhere. My typical .emacs disables the flash screen, the top menu + toolbar, loads a few modes for the programming languages I currently work in, configures paths for my local machine, and has two or three minor custom scripts.
That's it.
I've gone through the same exercise as OP did one I first started using emacs, and I highly recommend doing the same. You learn a lot about how emacs works. Sharing it is good too. I learn a few new things each time I read one of these, and even sometimes add a line or two to my .emacs.
However, not long after I did my super-custom-emacs, I upgraded machines, and was back to vanilla emacs, and I've been very happy there ever since.