bug#50743: Emacsclient not tested vs. Local Variables prompt

[Eli Zaretskii]

> Date: Sun, 26 Sep 2021 13:34:11 +1300
> From: Phil Sainty <psainty@orcon.net.nz>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 50743@debbugs.gnu.org,
>  積丹尼 Dan Jacobson <jidanni@jidanni.org>
> 
> The key appears to be whether or not we're using a pre-existing
> client frame.  If a new frame is created, the problem does not
> occur (for me).  If we're switching to a pre-existing frame, then
> I can reproduce the problem.
> 
> Here's an alternative recipe:
> 
> emacs -Q --daemon=bug50743 # start a new server
> emacsclient -sbug50743 -c & # create a GUI frame
> emacsclient -sbug50743 <file>
> 
> If <file> contains file-local variables then the pre-existing
> client frame does not get focus; but otherwise it does.

And if you set server-raise-frame to nil, the "problem" happens in
both cases, right?

So I'm not sure this is a bug.  The user should switch to the correct
frame to answer the question.  On my system, there's a prominent
indication that the client frame needs my attention, but even if there
isn't, the user should be vigilant enough to type the response into
the right frame.

If we do want to somehow raise the frame earlier, we should do it
conditioned by server-raise-frame, because some users don't want the
frame to raise and get input focus.  But it isn't clear to me where
would be the correct place to raise the frame "earlier".