bug#37826: Very annoying autoraise client/server behavior with -t option

[Carlos Pita <carlosjosepita@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1454 bytes --]

>
> ). 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.

>
>

[-- Attachment #2: Type: text/html, Size: 2238 bytes --]