One of these days, I will get around to making the ultimate emacs UI: zero defaults.
Give me a way to set and organize keybinds, good documentation, and nothing else. Every time I need a new keybind, I must explicitly decide what it will be. Inconvenient? So is learning the default, or worse, figuring out how my unique config accommodates that default.
It would be more work now for less work later. It would also move the work of UI/UX design into the same step as UI/UX learning; which I consider the most sensible place and time to do that work.
That sounds really neat. I spent a couple weeks trying to publish all my notes using org-mode, and it was pretty frustrating to find all these key bindings on the net that didn't actually work in my setup. A bare setup where you could opt-in to keybinding "packages" with a global way to see conflicts would be cool.
It's been a pet idea of mine for a while, but every time I have tried to implement it, I have gotten tripped up on some UX design decision, or some fundamental, but poorly documented, part of the codebase.
My dream is a doesn't-resemble-vim modal editor from scratch. When I want more functionally, I will give it an intentional home in my normal mode config.
At its core, both Spacemacs and Doom Emacs are configuration frameworks. If you remove all the default packages/layers, you end up with a way to organize all your custom configs, and nothing else.
And under the hood they are complicated wrappers around use-package. With good reason, of course, but that reason doesn't really exist when you aren't using the distribution's configuration packages.
This sounds way more inconvenient to me when you figure in the amount of mistakes you are going to make creating keybindings in the fly. What might make perfect sense at first will seem really dumb once you've added 20 more shortcuts, and then you'll have to either stick with it or start over and relearn.
And seriously, emacs does so much! You won't even know what you don't know if you don't use the work others have done creating the UI (keybindings and shortcuts). Unless you really want to read all the source code yourself too
> mistakes you are going to make creating keybindings in the fly.
I have no clue what you mean. What is a mistake? In the fly? I'm talking about my permanent (until I intentionally change it) config, not some temporary real-time thing.
> What might make perfect sense at first will seem really dumb once you've added 20 more shortcuts, and then you'll have to either stick with it or start over and relearn.
Yes, but the alternative is starting with someone else's mistakes. I would rather deal with my own, because at least then I know what they are.
> You won't even know what you don't know if you don't use the work others have done creating the UI
Isn't that the status quo? If you want to use an unfamiliar feature, looking up the default keybind should be no easier than looking up the function itself.
As someone who works on many different machines during the day the defaults are the only thing that matters. Moving your environment around to every machine you touch is completely impractical and in some cases straight up disallowed by the rules of the lab.
I used to think this way until I spent some time working with and tuning my TRAMP setup. Now that Eglot is shipped with Emacs 29 I've switched from lsp-mode, and lo and behold, dealing with remote LSP servers is a lot easier.
I was a hardcore terminal Emacs and tmux user, but have since switched to GUI Emacs and multi-vterm and was able to retain much of my tmux muscle memory. I now am routinely editing files on a handful of different machines every day, and it's mostly great. I still have to call tramp-cleanup-all-connections to deal with the occasional hangs after a few days of idle time, but I'm pretty happy.
Thankfully for me, 9999/10000 times, I'm using my own system. On the off chance I am using someone else's system, I probably won't be doing anything particularly interesting or staying very long. On top of that, I can usually bring my keyboard, which itself contains most of my divergence from norm.
If customisability were really as available as it should be, it would be trivial to change between configurations. After all, the only technical hurdle is that most software is built on UI/UX assumptions.
Give me a way to set and organize keybinds, good documentation, and nothing else. Every time I need a new keybind, I must explicitly decide what it will be. Inconvenient? So is learning the default, or worse, figuring out how my unique config accommodates that default.
It would be more work now for less work later. It would also move the work of UI/UX design into the same step as UI/UX learning; which I consider the most sensible place and time to do that work.