). This change is similar to my first patch except that mine
> also covered the handful of hooks surrounding that part.
Most importantly, it affected the question we ask there if the file is
gone.
I don't think so, my first patch set the
(let* ((minibuffer-auto-raise (or server-raise-frame minibuffer-auto-raise))
environment specifically for those questions, instead of also affecting everything else. Now you keep the "raisy" environment for everything else, but disable it specifically for find-file-noselect. My approach was more risky in the sense that it could have masked more situations requiring intervention than yours, but the risk is still there, it's just a different type I vs type II error trade-off.
You mean, errors inside find-file-noselect? Maybe I'm missing
something, but I'd expect such an error to be displayed as usual. Can
you simulate an error there and see what happens?
I probably couldn't find a situation requiring intervention for the random examples I would pick now, I admit it would be a rare case, but there are tons of minor and major modes out there and some of them might ask some questions at startup. It comes to my mind that pdf-tools sometimes wants to recompile it's C part after an upgrade, but AFAICR this is done when the server starts and not when the file is visited, so the question is lost in the stdout of the daemon, which is an instance of a closely related issue.