abbreviatedman

I like your thinking!

Here's a solution for automatically running the last command:

  (defun repeat-most-recent-shell-command-asynchronously ()
    (interactive)
    (async-shell-command (car shell-command-history)))

It has two drawbacks:

• shell-command-history doesn't differentiate between asynchronous and synchronous shell commands, so you may accidentally repeat an async command synchronously (if you differentiate at all)—there are ways to look through the history for the one you want, however
• you're repeating automatically, not auto filling and giving yourself the chance to decide you want to run a different command instead

Honestly probably not worth solving that second issue, as you could bind a function like the one above and then just use that binding instead of the usual when you want to repeat. (Actually, now that I've thought this through, I think that's exactly what I'm gonna do.)

If you want the auto fill behavior and not the repeat behavior, you could advise the shell-command functions to grab (car shell-command-history) and insert it into the minibuffer.

Thanks for the thought-provoking question! I think I'm gonna go add this function now. : )

Might be able to do it with the hooks that run on entry and exit of the magit-status buffer? Save the window configuration on entry, reload it on exit?

Check the documentation of async-shell-command (M-x describe-function async-shell-command RET), and you'll see that it takes one necessary argument, the command to run.

If you run it interactively (through its keybinding or M-x), it prompts you for that argument. Type in the command for Emacs, and Emacs will pass that as the argument to async-shell-command.

But if you want to, you can call it from Lisp and pass in the argument yourself! Try executing it in the scratch buffer or by running eval-expression (I believe M-: by default).

(async-shell-command "git status")

That will run git status and give you the result

Now if you want to run that bit of code more often, wrap it in a function and assign it a keybinding!

(defun crj-check-git-status ()
  (interactive)
  (async-shell-command "git status"))

(general-define-key (kbd "C-M-&") #'crj-check-git-status)

Would anyone else handle this differently? I'm still learning myself!

if you don't want to jump right into configuring things from scratch, I would recommend you start with Doom Emacs.

I started with Doom Emacs (which I've heard is great even if you're not an Evil user), but eventually found the abstractions frustrating and wanted to make Emacs truly my own, at which point I started over with a clean slate and now understand the configuration of my system a lot better.

I wish I'd started configuring it from scratch on my own sooner, for sure, but I don't know that you need to do so from the outset. If you just want to get work done while slowly getting used to the Emacs workflows, a configuration system like Doom's can make that easier. It can also welcome you into Emacs without scaring you away.

That said, the abstractions hide a lot of details of how Emacs works, so if you're sure you're in it for the long term and can take the time now—which is maybe what you mean by "studying Emacs"... it is a thing to study!—then by all means, start from scratch.

Either way, I'll echo u/nv-elisp above—when you're trying to configure something, look at the documentation and articles online before you ask questions! You'll learn how to learn, which will help you immensely with all future problems.

I'd also recommend a couple of packages to make things easier:

• The Helpful package makes the vital and helpful describe commands even more... helpful.
• The Vertico/Marginalia/Corfu/Embark/Orderless/Counsel set of packages greatly improve your ability to navigate around Emacs.

Good luck, and happy hacking!

Reviewed the code, great job on your first package—wouldn't know it was your first if you hadn't said so! I think you should definitely get it on MELPA.

If you wanted a next step for it, you could consider giving users not just the option of set times, but:

• tying it into the OS dark/light schedule
• or tying into Emacs' solar functions to get their local sunrise/sunset times
• or making an API call to get local sunrise/sunset times.

You could also give them an option to provide an offset to those times... maybe they want light theme 30 minutes after the sun rises and dark theme 45 minutes before the sun sets, for example.

I did some thinking on this because I wanted to write a similar package at some point, before realizing I actually didn't want to switch themes at all. : )

No matter where you go with this, congrats on your first package. Well done!