GNU bug report logs - #50743
Emacsclient not tested vs. Local Variables prompt

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: larsi <at> gnus.org, jidanni <at> jidanni.org, 50743 <at> debbugs.gnu.org, mkupfer <at> alum.berkeley.edu
Subject: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Sun, 26 Sep 2021 09:25:31 +0300

> Date: Sun, 26 Sep 2021 13:34:11 +1300
> From: Phil Sainty <psainty <at> orcon.net.nz>
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 50743 <at> debbugs.gnu.org,
>  積丹尼 Dan Jacobson <jidanni <at> 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".

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.