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

[Eli Zaretskii]

> cc: martin rudalics <rudalics@gmx.at>, psainty@orcon.net.nz, larsi@gnus.org,
>         50743@debbugs.gnu.org, jidanni@jidanni.org
> From: Mike Kupfer <mkupfer@alum.berkeley.edu>
> Date: Sun, 26 Sep 2021 10:51:52 -0700
> 
> Eli Zaretskii wrote:
> 
> > > From: martin rudalics <rudalics@gmx.at>
> > > Date: Sun, 26 Sep 2021 11:59:42 +0200
> 
> > > IIUC this issue is about a frame displayed on top of the terminal
> > > window.
> > 
> > Is it?  That's not my understanding.  My understanding is that this
> > happens when the client frame already exists when emacsclient is
> > invoked, so it's probably elsewhere.
> 
> It could be elsewhere, but in Dan's scenario, the terminal window and
> Emacs frame are over each other.  And the exact behavior in that
> situation varies depending on the window manager.

Like I said: an obscure use case with weird window arrangement.  And
we are supposed to cater to it because...?

> If I run the experiment in MATE, with Emacs behind mate-terminal, and
> run "emacsclient /tmp/m" (from Phil's example) in mate-terminal, the
> mate-terminal window stays on top and retains the input focus.
> 
> But if I repeat the experiment in KDE, with Emacs behind mate-terminal
> (or Konsole), Emacs is brought to the top, hiding the terminal emulator,
> even though the terminal emulator still has the input focus.  But even
> that depends on what settings I have in KDE.  The behavior I just
> described is with "focus stealing prevention" set to None.  If I set it
> to Low, the terminal emulator window remains in top (and retains the
> focus).
> 
> Still, if I have "focus stealing prevention" set to None, the Emacs
> frame is raised in both the prompting case and the non-prompting case,
> but the input focus is handled differently in the two cases.  Raising
> the frame but not getting the input focus doesn't seem right to me.

There's limit to what Emacs can do with different policies regarding
raising the frames and redirecting input focus that different WMs can
apply.  Users should be aware of what is happening on their systems,
and if some WM tricks them, my advice is to switch to another WM.  I'm
definitely not interested in starting yet another adventure in
changing the order of things server.el does to pop up the buffer,
because of such weird and unpredictable situations.  We are going to
break more things than we fix.  We've been there in Emacs 26, I can
show the bruises.  No, thanks.