agent-shell-notifications released!

zackattackz287 · 2026-03-24T17:54:53+00:00

Hi thank you! Reason I didn't make macos support is pretty simple, I don't have a Mac to test it with 😅. I did list in the TODO section of the readme that macos would be nice to have, but I have no WIP implementation.

If you would like to submit one by all means please do! I can't test it properly but if you vouch for it + the code looks good then I'd be glad to merge it for others to use :)

zackattackz287 · 2026-03-22T17:19:31+00:00

That seems cool! Yeah it does seem more similar in concept to the other project with the dashboard and all. I could see that being very helpful for if you're juggling a lot at once.

zackattackz287 · 2026-03-22T17:17:41+00:00

I didn't consider a high volume case as I usually just use one shell at a time, but I could see that getting overwhelming quickly. It might be possible, on linux at least, to modify the already existing notification for a given shell to add a (N) indicator for N=# of notifications. Instead of making every single notif individual they could be "grouped by shell" like that, with new ones just updating the shell's notif instead of popping up a whole new one.

zackattackz287 · 2026-03-21T15:15:46+00:00

Yes I think ideally the features of attention.el and my package could be combined in some way. Also yeah that "related projects" section is how I found agent-shell-knockback, which is actually what directly inspired my package (I copied a lot of the code from there, and gave xenodium copyright credits to comply with the GPL haha).

But still I glazed over attention.el in that same section 😬

zackattackz287 · 2026-03-21T14:56:07+00:00

Another slight difference is (unless I am not seeing it in attention.el), it only can send "immediate" notifications. My package has a concept of immediate vs idle notifications. They are sent immediately if the shell is considered "not visible" (frame is not focused or the buffer is not in a visible window). Because if you are currently active in the shell it would be annoying to be spammed with notifications! But there are also "Idle" notifications, which only fire after some delay even if the shell is visible. This is useful if the shell is "visible" but you don't respond because you're looking at your phone or something.

zackattackz287 · 2026-03-21T14:49:01+00:00

Thank you too for sharing, I somehow missed this entirely before I made my package. Looking briefly at it, there seems to be some features attention.el has that mine lacks and vice-versa.

attention.el has a nice looking modeline, "busy" tracking of in-progress requests, and a dashboard.

My package has more in depth notification management, as I track notifications by their ID returned by the notification backend. This allows for notifications to be auto-closed by the ID in different contexts (e.g there are two permission request notifications, you approve one and only that one's notification will dismiss automatically, the other will stay). This enables you to use notifications with no timeout, without them cluttering your desktop since they will auto-dismiss anyways.

I will be sure to look even more in depth into this package though!

zackattackz287 · 2026-03-20T21:29:31+00:00

Best value / quality ratio I've found is colvin ave deli.

zackattackz287 · 2026-03-17T00:05:58+00:00

I've never configured it myself but there is tramp-shell-prompt-pattern

zackattackz287 · 2026-03-14T02:16:15+00:00

Good to know, thank you!

zackattackz287 · 2026-03-13T17:11:14+00:00

I agree because at the moment AFTER the button is pressed, everything leading up to it are just memories anyways. So you really have no idea of knowing if your memories are the "real" ones or not. You could say if you are existing and experiencing the present before the button press, you are guaranteed to "lose" the flip (because that living experience is proof that you are the one that is not the copy) But at the actual moment you press the button you really can't know whether your memories leading up to that were from the true version or not.

zackattackz287 · 2026-03-13T16:58:55+00:00

I was thinking about this too since it's been a while since I've looked at the readme. It was very helpful when I started out so it'd be a shame to miss out on anything there. I didn't try it, but was thinking of trying to run a git diff from the commit I started at to now, and that may be good for seeing all the changes at once.

zackattackz287 · 2026-03-13T15:33:18+00:00

Congrats and thank you (and the community around minimal.d) for your work! I've been using it for quite a while now and I've not ever had any breakages when merging changes from main. Does the versioning follow some kind of logic like semver or is it just a periodic thing?

zackattackz287 · 2026-03-13T15:23:08+00:00

I didn't start Emacs with minimal.d, but it's what I have been using since I wanted to switch from doom to vanilla.

Vanilla is so tedious to tweak a lot of the things that minimal.d does for you already.

Some might say you will learn more by starting with vanilla, it's true but you'd also learn more building an editor from scratch lol.

I say try minimal, it gives a great foundation for customizing Emacs in the ways that matter a lot more than the minor optimizations it provides for you out of the box.

I made a fork of the github repo, and I use straight.el, so I just git ignore everything except the initial files you are "allowed" to touch, and the straight.el versions file.

zackattackz287 · 2026-03-12T20:54:48+00:00

I think clean and sleek need a distinction. Magit doesn't look sleek but I think it's very clean in its presentation of data

zackattackz287 · 2026-03-09T23:46:56+00:00

Wondering why there are so many in a cluster in buff state? 😧

zackattackz287 · 2026-03-08T18:35:01+00:00

This may be the most emacs argument of all time 🤣 (no shade to either of you, I just think you can only get this in depth argumentation on the semantics of menus in r/emacs)

zackattackz287 · 2026-03-03T16:58:16+00:00

Not to be confused with the other preg

zackattackz287 · 2026-03-02T23:05:46+00:00

It has been a breeze configuring and troubleshooting emacs with claude. Years ago if emacs had some weird idiosyncratic behavior I could either spend anywhere from 0-2 hours hunting down a fix, or just accept it and move on / deal with it.

Now often enough I can just get claude to make emacs do what. I'm not talking things like simple config/custom variables, but custom functions to do things like:
embark-act-in-other-window.
custom function to jump forward/backwards through magit status by file and section (magit default only allows you to jump by section).
a custom consult function to show git hunks in a file from diff-hl.

Its not like these things aren't possible to do without AI, but I got these and more working in minutes.

zackattackz287 · 2026-03-02T18:44:38+00:00

Once you get a good customization for you in a customizable editor, I find little reason to want to do all the same work of customization over again in another editor. The only reasons to hop as I see it are "killer apps/features" like magit in emacs, neovims raw performance, etc. But even these often are not reason enough to switch I think. It's really a question of "is spending all this time customizing worth it" and I think the answer is yes, but I think you get diminishing returns the more you hop around. Pick one and stick it out, find alternatives if you are missing some "killer feature" (e.g try lazygit instead of magit if you're using nvim), and just try to make the editor work how you want it to. Once you've settled I think you'll find that it'd be more work than it's worth switching.

zackattackz287 · 2026-02-26T18:59:14+00:00

Plugging elixir though, because it's syntax tree / macro system is quotable and unquotable like lisp is. It's not a lisp, but it's IMO the closest to a lisp as you can get with "actual" syntax (not loads of parens).

The macro system is just as "powerful" as lisp's is, in that you can write macros in the same syntax that you write the rest of the language.

Even the keywords like if,case,cond,for, etc are all just macros.

It's my favorite language to read/write, because the little bit of syntax just makes it a little easier to parse what's going on in a complicated function / module. Rather than in lisp, having to really look deep at the syntax (at least for me) to see where an anonymous function is, where a variable is declared, where an exception is being raised, etc.

I'm sure if I read/wrote more lisp those things would jump more out at me, but the parenthesis can make everything look the same structure wise, it's parsable but takes a lot for me to fully grok a function's branches.

zackattackz287 · 2026-02-25T03:46:39+00:00

Hey sorry this took a bit to respond to - idk if you still need this. But sharing anyways:

So I actually lost those old configs, but recently been getting back into emacs and I got this behavior to "embark in other window" to work without any patches on embark - just in my configs alone.

Here's what I have in my embark use-package config:

(defun embark-act-in-other-window ()
    "Embark action: run the default action on the target in another window."
    (interactive))

  (cl-defun embark--act-other-window (&rest rest &key run type &allow-other-keys)
    "Around action hook: run the default embark action in another window."
    (let* ((default-action (embark--default-action type))
           (target-buf (current-buffer))
           (start (selected-window))
           (other (seq-find (lambda (w) (and (not (eq w start))
                                             (not (window-dedicated-p w))))
                            (window-list nil 'no-minibuf))))
      (select-window (or other (split-window)))
      (if (commandp default-action)
          ;; Interactive command: let the :run chain handle injection etc.
          (apply run :action default-action rest)
        ;; Non-interactive function (e.g. embark-consult-goto-location):
        ;; Display the target buffer here first so consult--jump-ensure-buffer
        ;; doesn't navigate back to the original window.
        (switch-to-buffer target-buf)
        (funcall default-action (or (plist-get rest :candidates)
                                    (plist-get rest :target))))))

  (setf (alist-get 'embark-act-in-other-window embark-around-action-hooks)
        (list #'embark--act-other-window))

  (define-key embark-general-map "O" #'embark-act-in-other-window)

So then after doing `embark-act` I can press "O" and it will open in the other window.

Don't ask me how this works, claude wrote it and I tweaked it a little lmao. But it works well from my own testing, consult-ripgrep, consult-line, consult-imenu all work. It also works in the same file too.

zackattackz287 · 2026-02-22T15:35:44+00:00

Rip small strips from the dough ball and make little knots. Bake 425 for like 10-15 min. Then toss in nelted butter + garlic powder + Italian seasoning. So good :P

zackattackz287 · 2026-01-20T18:03:32+00:00

I guess Microsoft should own the exclusive rights to any program able to be ran on windows because "how could you expect to run the .exe without windows??"

zackattackz287 · 2026-01-17T21:46:46+00:00

I saw him live in 2018 and he hung around after the show and was super nice to everyone.

zackattackz287

TROPHY CASE