I'm not a fresh set of eyes, per se, but it was clear to me! ✅ On a separate note, (let me know if you would like separate thread), the with-mx-isolation is unique to ClojureDart, yes? I vaguely remember you saying it had to do with a disparity between regular Clojure and ClojureDart in how they handle dynamic variables, but I don't remember the specifics. Perhaps that disparity might be considered a bug in ClojureDart that could be fixed? I'm curious, because aside from lthe pet-peeve of calling with-mx-isolation looking a little noisy, a common point-of-friction I ran into was hunting through code to see if I'd already called it or not. And "calling it again just to be sure" sometimes caused other problems. I.E. fn-A calls fn-B calls fn-C. While writing fn-C (often in a different namespace) I'll forget weather fn-A or fn-B have already run with-mx-isolationor not.

Thx for looking! "with-mx-isolation is unique to ClojureDart...Perhaps that disparity might be considered a bug in ClojureDart that could be fixed?" I never sorted it out, I just plowed ahead. 🙂 I did have an exchange with Team CLJD and explored a little. I decided the threading model might be different. Hmmm, let me compare with CLJS and CLJ sometime this weekend. But yeah, in CL or other CLJS I have never needed this, "I.E. fn-A calls fn-B calls fn-C. While writing fn-C (often in a different namespace) I'll forget weather fn-A or fn-B have already run with-mx-isolationor not." Are you saying C might be called directly by some event handler or async callback, or it might be called by B? I guess one answer is to have with-mx (proposed new name 🙂 ) lexically appear only in a handler etc, sth at the edge of MX. "it was clear to me!" Watching it myself, I think better lighting/ergonomics would make my typing less tortured. Talking and typing at the same time does not help. 🙂 Thx again for the input! 🙏

So I did some digging on dynamic vars. Wow. This: https://clojureverse.org/t/binding-in-the-context-of-future-vs-thread/3718 ...links to this: https://stuartsierra.com/2013/03/29/perils-of-dynamic-scope I found https://clojuredocs.org/clojure.core/bound-fn, which in CLJ copies dynos to a diff thread. (The effective CLJD behavior.) In the first link someone reports futures see dynos because CLJ silently copies them to the thread! I did confirm that in Web/MX aka CLJS dynos are not visible to callbacks. So I think ClojureDart's behavior is arguable, @U013TCGL92T. And it prolly derives from the single-thread thing in Dart, so would take some work to change. The good news is, we only need with-mx-isolation when doing mset!/mswap! in callbacks. And we can shorten the name. 🙂

The punch line is, I made an unrelated change adding a widget and BAM! the volume slider et al blew up, because I had never wrapped their handlers in with-mx-iso! I went back a month of commits and sure enough the critical vars spawning the callback were false (so no problem doing a state change), whereas after the innocuous change they were true. I think I'll shorten it to wmx-iso. 🙂

For the curious:

(defmacro wmx-iso [& body]
  `(binding [tilton.mx.cell.base/*within-integrity* nil
             tilton.mx.cell.base/*depender* nil
             tilton.mx.cell.base/*defer-changes* false
             tilton.mx.cell.base/*call-stack* nil]
     ~@body))