dark-notify VS emacs-buttercup

I found this neovim plugin for macos https://github.com/cormacrelf/dark-notify that does exactly that, looking at the source code, it spawn a new macos application and looks for changes

I use https://github.com/cormacrelf/dark-notify

> 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.

[0]: https://github.com/cormacrelf/dark-notify

[1]: https://github.com/rollcat/dotfiles/blob/7f6a6d7/.emacs.d/in...

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.

If you’re struggling with background toggling, I suggest having a look at https://github.com/cormacrelf/dark-notify. Its Lua plugin doesn’t require macOS, it can be used through a mapping as a generic background toggler between two different schemes, and you get to run arbitrary code when it does toggle, which is useful for integration with themed status bars etc.

ERT doesn't have much to help with this, but Buttercup has a number of facilities to help with controlling the environment around each test: https://github.com/jorgenschaefer/emacs-buttercup/

> (For example, when trying to test things out I haven't really found a way much better than typing into scratch, selecting code and running it while staring at messages....)

Are you talking about when you're noodling, trying to figure how things work, or actually trying to build something?

For playing around, I found that scratch works ok, but I found a better workflow.

I end up using a daily note in org-roam, with #begin_src elisp... I then tag the heading with :REFILE:ELISP: so I can always find it later. Basically evaluate everything inline within that org-babel block.

When I'm building something, or driving towards a specific goal, I use buttercup [0] to write actual unit tests. If I squint, it kinda looks like TDD.

Finally, for debugging of running elisp, take a look at edebug [1]. It's a pretty standard looking debugger (if you used something like gdb). By default emacs uses debug which is not as friendly.

[0]: https://github.com/jorgenschaefer/emacs-buttercup

[1]: https://www.gnu.org/software/emacs/manual/html_node/elisp/Ed...

Ok, before posting this I looked up a bit and found this and this. Buttercup seems great. Links or tips from experienced developers are welcome.