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

Previous Next

To reply to this bug, email your comments to 50743 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: bug-gnu-emacs <at> gnu.org
Subject: Emacsclient not tested vs. Local Variables prompt
Date: Thu, 23 Sep 2021 04:16:13 +0800

Big problem.
If a file triggers
------
   The local variables list in Makefile
   contains values that may not be safe (*).

   Do you want to apply it?  You can type
   y  -- to apply the local variables list.
   n  -- to ignore the local variables list.
   !  -- to apply the local variables list, and permanently mark these
         values (*) as safe (in the future, they will be set automatically.)
------
one simply types one of y,n,! . No problem...
unless one used emacsclient to open that file.

In that case one's y,n,! are being sent to the shell,
as can be seen from the hollow prompt there in emacs.

emacs-version "27.1"

Message #8 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Cc: 50743 <at> debbugs.gnu.org
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Wed, 22 Sep 2021 22:40:10 +0200

積丹尼 Dan Jacobson <jidanni <at> jidanni.org> writes:

> In that case one's y,n,! are being sent to the shell,
> as can be seen from the hollow prompt there in emacs.

I'm unable to reproduce this in Emacs 27.1 (or Emacs 28), but the recipe
isn't very clear.

I put the following in /tmp/foo.el:

;; Local Variables:
;; foo: t
;; End:

Then

./src/emacs -geometry -0+0 -Q -f server-start &
./lib-src/emacsclient -t /tmp/foo.el

And I got prompted in the normal way.

Are there any other steps needed to see the problem?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #13 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 50743 <at> debbugs.gnu.org
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Thu, 23 Sep 2021 13:43:52 +0800

All I know is with these
https://www.jidanni.org/comp/configuration/
files, and this file:
$ cat /tmp/m
## --  -*- so-long-action: normal-mode; -*-
$ emacsclient -n /tmp/m
reproduces the bug.

Also typing ^G^G^G just gets sent to the shell.
So one has to switch back to the shell window,
and type ^C.
Then back in emacs, type ^G.

Message #16 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 50743 <at> debbugs.gnu.org
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Thu, 23 Sep 2021 18:54:20 +1200

On 2021-09-23 17:43, 積丹尼 Dan Jacobson wrote:
> All I know is with these
> https://www.jidanni.org/comp/configuration/
> files, and this file:
> $ cat /tmp/m
> ## --  -*- so-long-action: normal-mode; -*-
> $ emacsclient -n /tmp/m
> reproduces the bug.

1. Do you see the same thing with ANY file-local variable?

2. Do you see the same thing if you use '-Q' when starting the server?

3. Do you see the same thing without the '-n' option?


For (1) please test with something like -*- foo: bar; -*- (i.e. any
name which isn't a known variable) so that we have an idea of whether
this is connected to so-long.el in any way.

Also, per our conversation the other day, that 'normal-mode' is a
misleading value -- unless you've defined a custom action by that
name, it's no different to specifying any other invalid action, and
merely means that so-long won't do very much.


-Phil

Message #19 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 50743 <at> debbugs.gnu.org
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Fri, 24 Sep 2021 16:23:41 +0800

>>>>> "PS" == Phil Sainty <psainty <at> orcon.net.nz> writes:
PS> 1. Do you see the same thing with ANY file-local variable?

PS> 2. Do you see the same thing if you use '-Q' when starting the server?

PS> 3. Do you see the same thing without the '-n' option?


PS> For (1) please test with something like -*- foo: bar; -*- (i.e. any
PS> name which isn't a known variable) so that we have an idea of whether
PS> this is connected to so-long.el in any way.

Yup Yup Yup.

I put  -*- foo: bar; -*-  in a file and did all your tests above, and
was able to reproduce the bug 100%

Message #22 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 50743 <at> debbugs.gnu.org
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Sat, 25 Sep 2021 02:11:28 +1200

On 2021-09-24 20:23, 積丹尼 Dan Jacobson wrote:
> Yup Yup Yup.
> 
> I put  -*- foo: bar; -*-  in a file and did all your tests above, and
> was able to reproduce the bug 100%

Ok, so is this the recipe?

$ emacs -Q -f server-start &

$ cat /tmp/m
## --  -*- foo: bar; -*-

$ emacsclient /tmp/m

See the "local variables may not be safe" prompt in the client frame.

Focus on the emacsclient frame in your window manager.

Respond to the prompt (e.g. with "y").

And your keystrokes go to the original terminal, even though the
emacsclient frame has the window manager focus?

Message #25 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 50743 <at> debbugs.gnu.org
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Fri, 24 Sep 2021 22:42:02 +0800

>>>>> "PS" == Phil Sainty <psainty <at> orcon.net.nz> writes:
PS> Ok, so is this the recipe?

Yes.

PS> $ emacs -Q -f server-start &

PS> $ cat /tmp/m
PS> ## --  -*- foo: bar; -*-

PS> $ emacsclient /tmp/m

PS> See the "local variables may not be safe" prompt in the client frame.

Stop right there.

Emacs is asking the user a question.

The user types an answer.

The answer doesn't go to emacs.

That's the problem.

About this frame and that frame, this focus and that focus, that is all
beyond the user's comprehension.

PS> Focus on the emacsclient frame in your window manager.

PS> Respond to the prompt (e.g. with "y").

PS> And your keystrokes go to the original terminal, even though the
PS> emacsclient frame has the window manager focus?

Message #28 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 50743 <at> debbugs.gnu.org
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Sat, 25 Sep 2021 13:12:01 +1200

On 2021-09-25 02:42, 積丹尼 Dan Jacobson wrote:
> About this frame and that frame, this focus and that focus, that
> is all beyond the user's comprehension.

You are using a multi-tasking windowed operating system.  You can't
use the computer at all without knowing that when you type on the
keyboard only one of the many possible windows is receiving the input.
This might be beyond the user's comprehension, but that's nothing to
do with Emacs.

My impression now is that you typed something into a window that
wasn't Emacs and are claiming that it's a bug that Emacs didn't react
to that.  This is like raising a bug report for your painting software
to complain that it didn't draw a picture when you were dragging your
mouse around in your web browser.

Whether a newly-opened window automatically has focus or not is a
matter for your window manager, so you should investigate how you can
make that happen on your system.

Alternatively, consider using "emacsclient -t" so that your client
is running in the same terminal from which you ran the command.


-Phil (can we close this bug?)

Message #31 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 50743 <at> debbugs.gnu.org
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Sat, 25 Sep 2021 12:18:05 +0800

emacsclient -t makes even another (non-x) window.

Anyway, normally if we type abcefg... it goes right into the file, where
it belongs.

If we type M-x abcefg... we are still inputting and outputting to emacs'
minibuffer.

However if we boobytrap the file with  -*- foo: bar; -*-,
now suddenly emacs is asking us questions, but our answers are hijacked
elsewhere!

So we can type until we are blue in the face, but emacs will just sit
there with its question waiting for us to answer forever.

So the message should say "Please enter y, n... if nothing happens, then
next time use emacsclient -t."

Message #34 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 50743 <at> debbugs.gnu.org
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Sat, 25 Sep 2021 17:07:10 +1200

On 2021-09-25 16:18, 積丹尼 Dan Jacobson wrote:
> Anyway, normally if we type abcefg... it goes right into the file, 
> where
> it belongs.
> 
> However if we boobytrap the file with  -*- foo: bar; -*-,
> now suddenly emacs is asking us questions, but our answers are hijacked
> elsewhere!

Are you saying that if you create a second file, /tmp/m2 which does
*not* have any file-local variables, and you go to your terminal and
run "emacsclient /tmp/m2" and type "y" that it inserts the character
"y" into the "m2" buffer; but if you run "emacsclient /tmp/m" which
has the file-local var and you type "y" it gets inserted into the
terminal window?  And you are doing everything else exactly the same
way, so that the sole difference between the two tests is that whether
or not the file has a file-local variable?

To me it still sounds like a matter of OS window focus, but I can't
fathom why those two tests would result in different windows being
focused by the window manager.

To be clear, I've already tried and failed to reproduce your problem,
so not everyone is seeing the same thing as yourself.  It would be
easier to understand what's happening if you could confirm whether of
not the Emacs window actually has focus (which is why I tried to get
that information via a more-detailed recipe a in an earlier message).


-Phil

Message #37 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 50743 <at> debbugs.gnu.org
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Sat, 25 Sep 2021 13:46:56 +0800

[Message part 1 (text/plain, inline)]

Here's what I see.

[20210925T133406.jpg (image/jpeg, attachment)]

[Message part 3 (text/plain, inline)]

I have moved the emacs window to the right a little.
In reality it is exactly on top of the shell window.
I have also shrunk it to make the screenshot smaller.

>>>>> "PS" == Phil Sainty <psainty <at> orcon.net.nz> writes:
PS> Are you saying that if you create a second file, /tmp/m2 which does
PS> *not* have any file-local variables, and you go to your terminal and
PS> run "emacsclient /tmp/m2" and type "y" that it inserts the character
PS> "y" into the "m2" buffer;

Yup. That's normal too.
I see in the minibuffer
"When done with a buffer, type C-x #"
(which is just a statement, not a question waiting for me to answer.)

PS> but if you run "emacsclient /tmp/m" which has the file-local var and
PS> you type "y" it gets inserted into the
PS> terminal window?  And you are doing everything else exactly the same
PS> way, so that the sole difference between the two tests is that whether
PS> or not the file has a file-local variable?

Correct.

PS> To me it still sounds like a matter of OS window focus, but I can't
PS> fathom why those two tests would result in different windows being
PS> focused by the window manager.

I'm just using icewm.
If I do emacs -Q -f server-start &
it makes a window anchored at the upper left,
and covers up my xterm,
so I don't even see where my yyyyy's go too.

PS> To be clear, I've already tried and failed to reproduce your problem,
PS> so not everyone is seeing the same thing as yourself.

Well there is a hollow prompt there in the minibuffer of my image above.
That means input is not going to be seen by emacs.

PS> It would be easier to understand what's happening if you could confirm whether of
PS> not the Emacs window actually has focus (which is why I tried to get
PS> that information via a more-detailed recipe a in an earlier message).

Well my yyyyy's end up in the shell, which is underneath the emacs
window asking me the for the y,n.

Message #40 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 50743 <at> debbugs.gnu.org
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Sat, 25 Sep 2021 20:33:14 +1200

That does sound very strange.

I don't know anything about icewm but a quick search turned up
https://github.com/bbidulock/icewm/issues/37 although that is
probably too old?  Which version of icewm are you using?

I note that _NET_WM_USER_TIME appears in the Emacs code in the
x_set_no_focus_on_map() function, but none of these details are
very meaningful to me, and they may not be relevant.

Are you able to test with a different window manager?


-Phil

Message #43 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 50743 <at> debbugs.gnu.org
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Sat, 25 Sep 2021 21:06:32 +0800

>>>>> "PS" == Phil Sainty <psainty <at> orcon.net.nz> writes:
PS> That does sound very strange.

PS> I don't know anything about icewm but a quick search turned up
PS> https://github.com/bbidulock/icewm/issues/37 although that is
PS> probably too old?  Which version of icewm are you using?

$ apt-cache policy $@
icewm:
  Installed: 2.7.0-1

PS> I note that _NET_WM_USER_TIME appears in the Emacs code in the
PS> x_set_no_focus_on_map() function, but none of these details are
PS> very meaningful to me, and they may not be relevant.

All I know is emacs should not "Ask Ralph for a cookie, but extend its
hand to Laura to receive it."

PS> Are you able to test with a different window manager?

Sorry, I recently tried to replace nodm/icewm and failed. It would be
much easier for some younger user to just test the problem with icewm.

Message #46 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 50743 <at> debbugs.gnu.org
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Sun, 26 Sep 2021 03:02:06 +1300

On 2021-09-26 01:06, 積丹尼 Dan Jacobson wrote:
> PS> Which version of icewm are you using?
> 
>   Installed: 2.7.0-1

The icewm site indicates this is the latest version.

> PS> Are you able to test with a different window manager?
> 
> Sorry, I recently tried to replace nodm/icewm and failed. It would be
> much easier for some younger user to just test the problem with icewm.

I've no idea what anyone's age has to do with it.

Perhaps another icewm user will be able to reproduce the issue.


-Phil

Message #49 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: Mike Kupfer <mkupfer <at> alum.berkeley.edu>
To: 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>
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Sat, 25 Sep 2021 15:55:42 -0700

Phil Sainty wrote:

> Perhaps another icewm user will be able to reproduce the issue.

I don't use icewm, but I can reproduce the problem with MATE, using
either the marco window manager or Openbox, on Debian 10.  I can
reproduce it with Emacs 27.2 (Lucid) built from source and with the
Emacs 26.1 (GTK) that is bundled with Debian 10.  I can also reproduce
it with Emacs master built earlier this year (git hash 13b247c3c4).

> Are you saying that if you create a second file, /tmp/m2 which does
> *not* have any file-local variables, and you go to your terminal and
> run "emacsclient /tmp/m2" and type "y" that it inserts the character
> "y" into the "m2" buffer; but if you run "emacsclient /tmp/m" which
> has the file-local var and you type "y" it gets inserted into the
> terminal window?  And you are doing everything else exactly the same
> way, so that the sole difference between the two tests is that whether
> or not the file has a file-local variable?

Yes.  And yes, in the /tmp/m case, the mate-terminal window still has
the focus.

regards,
mike

Message #52 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: Mike Kupfer <mkupfer <at> alum.berkeley.edu>
To: 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>
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Sat, 25 Sep 2021 17:19:13 -0700

Mike Kupfer wrote:

> I can reproduce the problem with MATE

I can also reproduce the problem on KDE.  But not Xfce, i3, or
Cinnamon.

mike

Message #55 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Mike Kupfer <mkupfer <at> alum.berkeley.edu>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 50743 <at> debbugs.gnu.org,
 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Sun, 26 Sep 2021 13:34:11 +1300

On 2021-09-26 11:55, Mike Kupfer wrote:
> I don't use icewm, but I can reproduce the problem with MATE,
> using either the marco window manager or Openbox, on Debian 10.

Thanks for confirming Mike.

I can now reproduce this as well.  (In fact I'd failed to follow
the correct recipe previously, and was side-stepping the issue.)

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.

I tested with both:

M-x add-file-local-variable
M-x add-file-local-variable-prop-line



-Phil

Message #58 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: Mike Kupfer <mkupfer <at> alum.berkeley.edu>
To: 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>
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Sat, 25 Sep 2021 19:48:18 -0700

Phil Sainty wrote:

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

Yes, that matches what I'm seeing.

mike

Message #61 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: Mike Kupfer <mkupfer <at> alum.berkeley.edu>
To: 50743 <at> debbugs.gnu.org
Cc: Phil Sainty <psainty <at> orcon.net.nz>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Sat, 25 Sep 2021 19:57:53 -0700

And in case it helps narrow down where things are going haywire: I can
also reproduce the problem on MacOS (11.6, NS build of Emacs 27.2).

mike

Message #64 received at 50743 <at> debbugs.gnu.org (full text, mbox):

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: Re: 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".

Message #67 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Phil Sainty <psainty <at> orcon.net.nz>, larsi <at> gnus.org, 50743 <at> debbugs.gnu.org,
 mkupfer <at> alum.berkeley.edu
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Sun, 26 Sep 2021 14:53:43 +0800

EZ> So I'm not sure this is a bug.  The user should switch to the correct
EZ> frame to answer the question.  On my system, there's a prominent
EZ> indication that the client frame needs my attention...

Well like when the elevator door opens, we assume we are stepping into
the elevator and not just the shaft.

Or when we go to the bathroom we assume we are really in the bathroom.

... Please make sure it works for everybody.

Message #70 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Cc: psainty <at> orcon.net.nz, larsi <at> gnus.org, 50743 <at> debbugs.gnu.org,
 mkupfer <at> alum.berkeley.edu
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Sun, 26 Sep 2021 10:12:02 +0300

> From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
> Cc: Phil Sainty <psainty <at> orcon.net.nz>,  mkupfer <at> alum.berkeley.edu,
>   larsi <at> gnus.org,  50743 <at> debbugs.gnu.org
> Date: Sun, 26 Sep 2021 14:53:43 +0800
> 
> EZ> So I'm not sure this is a bug.  The user should switch to the correct
> EZ> frame to answer the question.  On my system, there's a prominent
> EZ> indication that the client frame needs my attention...
> 
> Well like when the elevator door opens, we assume we are stepping into
> the elevator and not just the shaft.
> 
> Or when we go to the bathroom we assume we are really in the bathroom.
> 
> ... Please make sure it works for everybody.

It works for everybody already, assuming they have their eyes on the
screen and not on some imaginary shaft or bathroom.

We had our share of "bug" reports from you, whereby trying to cater to
some obscure use case got us in much greater trouble all over the
place, which then took non-trivial efforts to recover from.  So please
forgive me if I'm skeptical that this is really an Emacs problem and
not a case of cockpit error, when such reports come from you.

Message #73 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: psainty <at> orcon.net.nz, larsi <at> gnus.org, 50743 <at> debbugs.gnu.org,
 mkupfer <at> alum.berkeley.edu
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Sun, 26 Sep 2021 15:20:51 +0800

[Message part 1 (text/html, inline)]

Message #76 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: psainty <at> orcon.net.nz, larsi <at> gnus.org, 50743 <at> debbugs.gnu.org,
 mkupfer <at> alum.berkeley.edu
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Sun, 26 Sep 2021 15:31:19 +0800

[Message part 1 (text/plain, inline)]

As the prompt is security-related in the first place, you might as well
treat the response with the same amount of security as you would with a
password, and make double sure that it goes to emacs, on all systems, and
not somewhere else.

[Message part 2 (text/html, inline)]

Message #79 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: psainty <at> orcon.net.nz, larsi <at> gnus.org, 50743 <at> debbugs.gnu.org,
 mkupfer <at> alum.berkeley.edu
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Sun, 26 Sep 2021 15:41:34 +0800

[Message part 1 (text/plain, inline)]

If, for some reason, you want the user to type his response into the shell,
and not emacs, then print the question in the shell, and not emacs.

[Message part 2 (text/html, inline)]

Message #82 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>, 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: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Sun, 26 Sep 2021 11:12:05 +0200

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

Maybe 'server-raise-frame' does too much when it triggers
'select-frame-set-input-focus'.  Still I consider it a bug when the user
gets prompted and the frame displaying the prompt doesn't have focus.

martin

Message #85 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: psainty <at> orcon.net.nz, larsi <at> gnus.org, jidanni <at> jidanni.org,
 50743 <at> debbugs.gnu.org, mkupfer <at> alum.berkeley.edu
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Sun, 26 Sep 2021 12:19:53 +0300

> Cc: larsi <at> gnus.org, mkupfer <at> alum.berkeley.edu, 50743 <at> debbugs.gnu.org,
>  jidanni <at> jidanni.org
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Sun, 26 Sep 2021 11:12:05 +0200
> 
> I consider it a bug when the user gets prompted and the frame
> displaying the prompt doesn't have focus.

I don't, FWIW.  When exactly to switch focus is deeply personal.
E.g., imagine that emacsclient is called while I'm still typing
something into the original terminal window.

In a windowed environment, it is IMO the user's duty to be aware of
the input focus and switch it as needed.

Message #88 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: psainty <at> orcon.net.nz, larsi <at> gnus.org, jidanni <at> jidanni.org,
 50743 <at> debbugs.gnu.org, mkupfer <at> alum.berkeley.edu
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Sun, 26 Sep 2021 11:59:42 +0200

>> I consider it a bug when the user gets prompted and the frame
>> displaying the prompt doesn't have focus.
>
> I don't, FWIW.  When exactly to switch focus is deeply personal.
> E.g., imagine that emacsclient is called while I'm still typing
> something into the original terminal window.
>
> In a windowed environment, it is IMO the user's duty to be aware of
> the input focus and switch it as needed.

IIUC this issue is about a frame displayed on top of the terminal
window.  While some people are capable of typing into a window they
don't see, we shouldn't ask arbitrary users to do that.

martin

Message #91 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: psainty <at> orcon.net.nz, larsi <at> gnus.org, jidanni <at> jidanni.org,
 50743 <at> debbugs.gnu.org, mkupfer <at> alum.berkeley.edu
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Sun, 26 Sep 2021 14:03:40 +0300

> Cc: psainty <at> orcon.net.nz, larsi <at> gnus.org, mkupfer <at> alum.berkeley.edu,
>  50743 <at> debbugs.gnu.org, jidanni <at> jidanni.org
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Sun, 26 Sep 2021 11:59:42 +0200
> 
>  >> I consider it a bug when the user gets prompted and the frame
>  >> displaying the prompt doesn't have focus.
>  >
>  > I don't, FWIW.  When exactly to switch focus is deeply personal.
>  > E.g., imagine that emacsclient is called while I'm still typing
>  > something into the original terminal window.
>  >
>  > In a windowed environment, it is IMO the user's duty to be aware of
>  > the input focus and switch it as needed.
> 
> 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.

Message #94 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: Mike Kupfer <mkupfer <at> alum.berkeley.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Phil Sainty <psainty <at> orcon.net.nz>, larsi <at> gnus.org, 50743 <at> debbugs.gnu.org,
 jidanni <at> jidanni.org
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Sun, 26 Sep 2021 10:02:30 -0700

Eli Zaretskii wrote:

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

Yes, that's what I see.

mike

Message #97 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: psainty <at> orcon.net.nz, larsi <at> gnus.org, jidanni <at> jidanni.org,
 50743 <at> debbugs.gnu.org, mkupfer <at> alum.berkeley.edu
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Sun, 26 Sep 2021 19:50:00 +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.

If the Emacs frame is not on top of the terminal frame, my argument is
obviously void.

martin

Message #100 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: Mike Kupfer <mkupfer <at> alum.berkeley.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: psainty <at> orcon.net.nz, martin rudalics <rudalics <at> gmx.at>, larsi <at> gnus.org,
 50743 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Sun, 26 Sep 2021 10:51:52 -0700

Eli Zaretskii wrote:

> > From: martin rudalics <rudalics <at> 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.

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.

mike

Message #103 received at 50743 <at> debbugs.gnu.org (full text, mbox):

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

> Cc: psainty <at> orcon.net.nz, larsi <at> gnus.org, mkupfer <at> alum.berkeley.edu,
>  50743 <at> debbugs.gnu.org, jidanni <at> jidanni.org
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Sun, 26 Sep 2021 19:50:00 +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.
> 
> If the Emacs frame is not on top of the terminal frame, my argument is
> obviously void.

What if the Emacs frame is "near" the terminal frame?

Or what do you mean by "on top of"?

Message #106 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mike Kupfer <mkupfer <at> alum.berkeley.edu>
Cc: psainty <at> orcon.net.nz, rudalics <at> gmx.at, larsi <at> gnus.org,
 50743 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Sun, 26 Sep 2021 21:26:45 +0300

> cc: martin rudalics <rudalics <at> gmx.at>, psainty <at> orcon.net.nz, larsi <at> gnus.org,
>         50743 <at> debbugs.gnu.org, jidanni <at> jidanni.org
> From: Mike Kupfer <mkupfer <at> alum.berkeley.edu>
> Date: Sun, 26 Sep 2021 10:51:52 -0700
> 
> Eli Zaretskii wrote:
> 
> > > From: martin rudalics <rudalics <at> 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.

Message #109 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: psainty <at> orcon.net.nz, 50743 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 larsi <at> gnus.org, mkupfer <at> alum.berkeley.edu
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Mon, 27 Sep 2021 04:49:43 +0800

It's even worse than
https://www.youtube.com/watch?v=0f5RxLNnpdI
Your girlfriend's picture now completely covers your wife's.
So naturally you assume you are now talking to your girlfriend.

Message #112 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: Mike Kupfer <mkupfer <at> alum.berkeley.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: psainty <at> orcon.net.nz, rudalics <at> gmx.at, larsi <at> gnus.org,
 50743 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Sun, 26 Sep 2021 15:08:03 -0700

Eli Zaretskii wrote:

> Like I said: an obscure use case with weird window arrangement. 

Perhaps for a desktop system with a decent size display.  I don't find
it all that obscure for a small laptop.  I think the only reason I've
never seen this issue before is because I typically use "emacsclient
-c".

But if fixing Dan's scenario is likely to introduce a regression for
some other scenario, well, I understand.  Sometimes it's better for
users to develop a workaround for a known bug than it is to keep
introducing new bugs.

cheers,
mike

Message #115 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Cc: psainty <at> orcon.net.nz, rudalics <at> gmx.at, larsi <at> gnus.org,
 50743 <at> debbugs.gnu.org, mkupfer <at> alum.berkeley.edu
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Mon, 27 Sep 2021 07:43:01 +0300

> From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  psainty <at> orcon.net.nz,  larsi <at> gnus.org,
>   mkupfer <at> alum.berkeley.edu,  50743 <at> debbugs.gnu.org
> Date: Mon, 27 Sep 2021 04:49:43 +0800
> 
> It's even worse than
> https://www.youtube.com/watch?v=0f5RxLNnpdI
> Your girlfriend's picture now completely covers your wife's.
> So naturally you assume you are now talking to your girlfriend.

I'd be very glad to talk to my girlfriend, who is also my wife.

Message #118 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mike Kupfer <mkupfer <at> alum.berkeley.edu>
Cc: psainty <at> orcon.net.nz, rudalics <at> gmx.at, larsi <at> gnus.org,
 50743 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Mon, 27 Sep 2021 07:48:23 +0300

> From: Mike Kupfer <mkupfer <at> alum.berkeley.edu>
> cc: rudalics <at> gmx.at, psainty <at> orcon.net.nz, larsi <at> gnus.org,
>         50743 <at> debbugs.gnu.org, jidanni <at> jidanni.org
> Date: Sun, 26 Sep 2021 15:08:03 -0700
> 
> Eli Zaretskii wrote:
> 
> > Like I said: an obscure use case with weird window arrangement. 
> 
> Perhaps for a desktop system with a decent size display.  I don't find
> it all that obscure for a small laptop.  I think the only reason I've
> never seen this issue before is because I typically use "emacsclient
> -c".
> 
> But if fixing Dan's scenario is likely to introduce a regression for
> some other scenario, well, I understand.  Sometimes it's better for
> users to develop a workaround for a known bug than it is to keep
> introducing new bugs.

Yes, exactly.

To clarify: if someone comes up with a clearly safe change to avoid
this situation, I won't object.  It's just that we were burned in the
past when we tried to change the order server.el does things when
showing a new file, so any significant changes in that area is from my
POV a non-starter.

Message #121 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Mike Kupfer <mkupfer <at> alum.berkeley.edu>, Eli Zaretskii <eliz <at> gnu.org>
Cc: psainty <at> orcon.net.nz, larsi <at> gnus.org, 50743 <at> debbugs.gnu.org,
 jidanni <at> jidanni.org
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Mon, 27 Sep 2021 10:50:00 +0200

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

"Focus stealing" is not a well-defined behavior and "preventing" it is
even less so.  It may depend on whether the focus-stealing window was
formerly nonexistent, invisible or iconified and/or whether the window
stems from the same application, executable or process.  Focus may also
depend on whether mouse movement can determine which window gets focus
and whether that window should be raised too when it gets focus.

All this is additionally complicated by the fact that there are no APIs
an application can use to tell which policy has been set up to decide
how it should behave.  But in general, any application's focus stealing
behavior has been set up by the user - compliantly or intentionally.

In particular, we all agree that Emacs may steal focus from itself since
otherwise popping up a second frame would never allow that frame to get
focus immediately.  But we probably are not sure whether running a timer
or reacting to a file notification should make Emacs pop up a new frame
and give it focus - the policy here will depend on the case at hand.

Note also that desktop managers like GNOME shell do not show a taskbar
any more, so they cannot even pulse the icon of the application
requesting focus there as, for example, Windows usually does in such
case.  Finally, Wayland seems to ignore requests to transfer focus in
any case.  So applications may have to change their attitude wrt newer
backends, desktops and user behaviors in order to not fall behind or
even be regarded as hostile.

That said, I agree with Mike when he says that "Raising the frame but
not getting the input focus doesn't seem right to me".  Emacs should try
its best to to not drive the user into such a situation.

martin

Message #124 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: psainty <at> orcon.net.nz, larsi <at> gnus.org, jidanni <at> jidanni.org,
 50743 <at> debbugs.gnu.org, mkupfer <at> alum.berkeley.edu
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Mon, 27 Sep 2021 10:50:27 +0200

>> If the Emacs frame is not on top of the terminal frame, my argument is
>> obviously void.
>
> What if the Emacs frame is "near" the terminal frame?
>
> Or what do you mean by "on top of"?

By "on top of" I mean "substantially" obscuring the terminal frame which
means that the current position of the terminal frame's cursor is not
visible because the Emacs frame covers it.

It's obvious that Emacs cannot detect that situation by itself (I even
doubt that it would be always possible for it to find out whether it
partially obscures another frame).  Hence, if possible, we should
probably try to not produce a situation where an Emacs frame is on top
of another frame and does not have focus.  Whether this is always
feasible with all window managers is something I cannot tell.

martin

Message #127 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: Jean Louis <bugs <at> gnu.support>
To: martin rudalics <rudalics <at> gmx.at>
Cc: larsi <at> gnus.org, mkupfer <at> alum.berkeley.edu, psainty <at> orcon.net.nz,
 jidanni <at> jidanni.org, 50743 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Mon, 27 Sep 2021 17:32:07 +0300

* martin rudalics <rudalics <at> gmx.at> [2021-09-27 11:52]:
> >> If the Emacs frame is not on top of the terminal frame, my argument is
> >> obviously void.
> >
> > What if the Emacs frame is "near" the terminal frame?
> >
> > Or what do you mean by "on top of"?
> 
> By "on top of" I mean "substantially" obscuring the terminal frame which
> means that the current position of the terminal frame's cursor is not
> visible because the Emacs frame covers it.
> 
> It's obvious that Emacs cannot detect that situation by itself (I even
> doubt that it would be always possible for it to find out whether it
> partially obscures another frame).  Hence, if possible, we should
> probably try to not produce a situation where an Emacs frame is on top
> of another frame and does not have focus.  Whether this is always
> feasible with all window managers is something I cannot tell.

I have tested many Window Managers and I use either IceWM or EmacsWM,
now much IceWM. I can tell that my configuration is personal and that
window managers have much of the control.

If user has configured Window Manager for specific kind of focus than
Emacs should not interfere with the users' configurations. 

For this:

> if possible, we should > probably try to not produce a situation
> where an Emacs frame is on top of another frame and does not have
> focus."

I think you should leave to Window Manager's configuration however
user wants it.

Let me give you examples:

- sometimes, I do have a single window (tracking issues) on the top,
  and other windows appearing on the bottom, that is called in IceWM
  "Focus always on top", so whatever else appears it will appear under
  that window.

- all the time I use mouse based focus, the window under the mouse has
  focus, and nothing else;

- all the time I don't use window raising under the mouse, if window
  has the focus, I don't want raising it automatically; often I
  overlap windows and do something with it, while I write in the
  window below partially appearing under the window on top of it;



Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Message #130 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: Jean Louis <bugs <at> gnu.support>
To: martin rudalics <rudalics <at> gmx.at>
Cc: larsi <at> gnus.org, mkupfer <at> alum.berkeley.edu,
 Phil Sainty <psainty <at> orcon.net.nz>, jidanni <at> jidanni.org, 50743 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Mon, 27 Sep 2021 17:35:38 +0300

* martin rudalics <rudalics <at> gmx.at> [2021-09-26 12:23]:
> > 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".
> 
> Maybe 'server-raise-frame' does too much when it triggers
> 'select-frame-set-input-focus'.  Still I consider it a bug when the user
> gets prompted and the frame displaying the prompt doesn't have focus.

I can fully understand that viewpoint, though there are special users'
configuration where focus shall remain all time on specific window or
some windows should be always raised, like "on top of everything" and
anything else appearing would come under.

And I will know when it happens or if there is some problem I will
personally know, and I assume that users similar to me would not have
real problem with it.

Giving you just insights as I use such Window Manager options all the
time since years.

Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Message #133 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Jean Louis <bugs <at> gnu.support>
Cc: larsi <at> gnus.org, mkupfer <at> alum.berkeley.edu, psainty <at> orcon.net.nz,
 jidanni <at> jidanni.org, 50743 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Mon, 27 Sep 2021 19:15:39 +0200

> I think you should leave to Window Manager's configuration however
> user wants it.

Traditionally, we don't do that and I doubt we will as long as X is our
major workhorse.  We have a sufficient number of bug reports asking us
to make Emacs tell the WM where and how to position its top-level
windows.  Maybe things will change when the pgtk branch has found its
way into master.

> Let me give you examples:
>
> - sometimes, I do have a single window (tracking issues) on the top,
>    and other windows appearing on the bottom, that is called in IceWM
>    "Focus always on top", so whatever else appears it will appear under
>    that window.

Literally, "Focus always on top" means that the window that has focus is
on top of the Z-order and vice versa.  This means that you can never
type into a window that is not on top - which is the default behavior of
most window managers.  So if you have chosen that option, you cannot
possibly type into a window "partially appearing under the window on top
of it" as described below.  Right?

> - all the time I use mouse based focus, the window under the mouse has
>    focus, and nothing else;

Providing mouse based focus is an arcane art.  xfwm here for example
takes it too literally so when I have two maximized windows, demaximize
the one on top and the mouse cursor is not over the region covered by
the demaximized window, the window below gets focus.  Similar issues may
happen when creating or deleting windows.  Good mouse based focus means
to keep the mouse on the window that has focus until the user manually
moves the mouse and wait for a customizable period for the mouse to rest
in some area before selecting another window.  I've never seen a WM that
does it all right.

> - all the time I don't use window raising under the mouse, if window
>    has the focus, I don't want raising it automatically; often I
>    overlap windows and do something with it, while I write in the
>    window below partially appearing under the window on top of it;

The issue we discuss here is that the window that has focus is obscured
by a window displaying a prompt either completely or at least in the
area where the user is typing.  While some users may handle that without
moving any of the participating windows, let's not assume that everybody
is able to do that.

martin

Message #136 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Cc: psainty <at> orcon.net.nz, 50743 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 larsi <at> gnus.org, mkupfer <at> alum.berkeley.edu
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Mon, 27 Sep 2021 19:30:40 +0200

> Your girlfriend's picture now completely covers your wife's.
> So naturally you assume you are now talking to your girlfriend.

Maybe you can teach icewm some adultery mode by setting either or both
FocusOnAppRaise and RaiseOnFocus to true in your ~/.icewm/preferences.

martin

Previous Next

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