I find them awful too but many people are fine with these defaults.
> There's no package pinning or SemVer so you get what you get, packages sometimes break in mysterious ways. So you write more code to work around various broken stuff in packages.
There's however a way around it which you may like, seen your complaint... What I do, and it's not unheard of but definitely not the most common when it comes to Emacs, is that I load specific versions of packages. And I commit my entire Emacs setup in Git.
So when I upgrade packages (or install new ones) if anything goes wrong I can just checkout/restore a known fully working state.
There are trade offs when versioning your entire "emacs.d" directory but honestly I don't see many downsides. And I share that emacs.d between several user accounts / machines and any change I made are one "git pull" away.
When I start Emacs I don't check for packages / refresh package contents or anything like that: I only do that when I actually plan to upgrade packages (which I do maybe once every six months or so).
> I want to just write code, not write code to make just writing code less of a pain.
I'd say that's kinda a big selling point of Emacs though: you can write elisp code to make anything you do (not just writing code) less of a pain.
> I'd say that's kinda a big selling point of Emacs though: you can write elisp code to make anything you do (not just writing code) less of a pain.
I agree in principle, but in practice, I find myself writing a lot of ELisp just to work around Emacs' shortcomings. E.g. on macOS, to support dark/light theme switching integrated with the rest of the system, I need an external program[0], a shell script to tell that program to call emacsclient, a LaunchAgent to keep it running, an unholy build of Emacs with all of the GNU-unapproved Cocoa integrations that some kind soul is maintaining, and only THEN a piece of ELisp (which is also calling out to AppleScript) to actually change the theme[1]. And as I wrote this, I realised half of this glue didn't even make it into version control.
I've been using Emacs for about 20 years, and with every passing year I just wish there was *less* ELisp for me to think about. The actual useful customisations (like adding the +x bit on shell scripts) are few and far between, most of it is just glue and fixes.
> a shell script to tell that program to call emacsclient, a LaunchAgent to keep it running, an unholy build of Emacs with all of the GNU-unapproved Cocoa integrations that some kind soul is maintaining, and only THEN a piece of ELisp (which is also calling out to AppleScript) to actually change the theme[1]
Why isn't your Emacs session running dark-notify itself, reading its output, and switching accordingly? That seems to remove the need for shell script running emacsclient, the launch agent, and the OSA integration. (But also, I thought ns-do-applescript was stock Emacs? At least I had some ELisp using it and I only ever used emacsformacosox.)
> Why isn't your Emacs session running dark-notify itself, reading its output, and switching accordingly?
Thanks for the hint. Maybe I would try that first, if it popped into my head when I was originally writing it; but at this point, it works, and I want less stuff in init.el.
Also I will likely reuse the dark-notify script to change the theme in Terminal.app as well, and Terminal.app doesn't have an ELisp runtime. (Also very weird that Apple's own software doesn't properly support this.)
> But also, I thought ns-do-applescript was stock Emacs?
I don't know. I've switched to macOS only a couple years ago, and the Emacs build I've initially used didn't have it.
I find them awful too but many people are fine with these defaults.
> There's no package pinning or SemVer so you get what you get, packages sometimes break in mysterious ways. So you write more code to work around various broken stuff in packages.
There's however a way around it which you may like, seen your complaint... What I do, and it's not unheard of but definitely not the most common when it comes to Emacs, is that I load specific versions of packages. And I commit my entire Emacs setup in Git.
So when I upgrade packages (or install new ones) if anything goes wrong I can just checkout/restore a known fully working state.
There are trade offs when versioning your entire "emacs.d" directory but honestly I don't see many downsides. And I share that emacs.d between several user accounts / machines and any change I made are one "git pull" away.
When I start Emacs I don't check for packages / refresh package contents or anything like that: I only do that when I actually plan to upgrade packages (which I do maybe once every six months or so).
> I want to just write code, not write code to make just writing code less of a pain.
I'd say that's kinda a big selling point of Emacs though: you can write elisp code to make anything you do (not just writing code) less of a pain.