Yeah, that one took some digging! I found the relevant bit in the Elisp manual. I should have some elisp for you to access the area of the manual within Emacs but I’m not there yet. : ) Here’s the HTML version.

That bit of a code is a cons pair, a list of the symbol shell-command-history and the number 1. The history argument to completing-read (and therefore by extension read-shell-command) can take in either a symbol for a history variable or a cons pair of a history variable symbol and an index to start with.

This was a great little ergonomic improvement, and thanks for taking us on that journey!

My final version is in my config now. The only improvements are skipping the most recent command when scrolling back through history (a nice improvement IMO) and some probably unnecessary refactoring.

Thanks for finding that advice solution, which is like 98% of my version. : )

Good call on Treemacs. Few long-term or even medium-term Emacs users use it, because it’s not actually an efficient workflow, but it can ease the transition.

Heck, I have it installed just for when someone’s looking over my shoulder and I want them to follow along better!

There’s something to be said for easing folks in with idioms they’re used to, before they find the more powerful idioms on their own.

Yeah, you’ve convinced me… let’s not make fun of new people!

… I guess that shouldn’t be a controversial stance. Whoops!

The two things that I would miss the most if I didn’t have them would be Evil Mode (even if my vanilla Emacs keybindings skills are getting a lot better) and the interlocking completion/filtering/sorting/querying/gosh-what-don’t-they-do systems of Vertico/Corfu/Orderless/Embark/Marginalia/Cape/Consult.

When I mess up my config and have to use vanilla Emacs to find the silly thing I did, those are what slow me down.

But once you have those (skipping Evil if you’re not a Vim user), for IDE-ness you probably want to explore the main major mode packages for those langauges, plus an LSP system (I like Eglot) to give you project-aware completion.

Oh! And if you’re a big terminal user, Vterm will give you something powerful, something flexible, and the kind of terminal experience you’re used to. You can always explore Eshell later!

Okay, and if you’re working with Git, which who isn’t, Magit is a must.

Okay, I’ll stop before I’m simply listing all the packages I use!

Ugh, I hate to defend someone with “it was just a joke”, but I do think he was lightly mocking the OP’s approach.

The link is also worth sharing with new folks—they WILL get better information if they learn to look for stuff on their own, and if new folks do a lot of research BEFORE they ask in a forum, they’ll understand their question better as well.

All that said, while I don’t think he was being a total dickhead, yeah, it would be nicer if people shared that folks should do their own research in a kinder way.

Either way, though, thanks for calling him out and making me think about how we approach newcomers!

It can be overwhelming getting started with Emacs, but if configuring your editor feels like a waste of time to you, then this probably isn’t the right time for Emacs in your life.

But! If you see something you really like in Emacs, and you want to try to get a quick start and get to work, search the web for some articles on how to set it up as an IDE for ONE of those languages. Copy the code, make sure you’re putting it in the right place, and give it a shot! You may find yourself really liking the editor.

I also recommend Doom Emacs, whether you’re coming from Vim or not, because it makes it easy to get yourself 90% of the way to what you want, configuration-wise, with RELATIVE ease.

Good luck!

I want to praise the package mini-mode-line, which allows you to collapse your mode-line into your echo area. Saves you some screen estate (especially in multi-window setups), and also makes it easy to toggle the modeline on and off by playing with the format.

There are different ways to do all of that, sure, but I really like the way this package handles all of that—which is basically all I want out of a modeline. Discovering this package last month has been a nice change in my setup.

Thanks, u/kiennq!

Slight improvement on your advising function, OP: this version starts the shell history you scroll through at index 1, so that after you go up one from your most recent-command, you don’t see the most recent command again.

(defun crj--auto-fill-shell-commands (args)
  (list (car args) (car shell-command-history) '(shell-command-history . 1) (cdddr args)))

(advice-add 'read-shell-command :filter-args #'crj--auto-fill-shell-commands)

Is there a cleaner way to handle the args than this unpleasing cdddr? Something I can do with &rest?

I tweaked the answer somewhat, as it bothered me that we were getting the most recent command inserted and having it show up again when you decide to go back to an earlier command. In other words, with the OP’s advice, we get the most recent command in the minibuffer history twice, once auto-filled and once in the regular history.

I’m sure there are cleaner ways to do it than using a custom global variable no other functions know about, which could I think lead to some weird side effects at some point… but for now, I like the behavior:

(defvar crj-most-recent-shell-command (car shell-command-history))

(defun crj--pop-shell-command-history (fn &rest _args)
  (setq crj-most-recent-shell-command (car shell-command-history))
  (let ((shell-command-history (cdr shell-command-history)))
    (apply fn _args)))

(defun crj--auto-fill-shell-commands (args)
  (list (car args) crj-most-recent-shell-command))

(advice-add 'read-shell-command :around #'crj--pop-shell-command-history)
(advice-add 'read-shell-command :filter-args #'crj--auto-fill-shell-commands)

Let me know if anyone has improvements/objections!

Well done finding an answer.

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!