* bug#50743: Emacsclient not tested vs. Local Variables prompt
@ 2021-09-22 20:16 積丹尼 Dan Jacobson
2021-09-22 20:40 ` Lars Ingebrigtsen
` (4 more replies)
0 siblings, 5 replies; 44+ messages in thread
From: 積丹尼 Dan Jacobson @ 2021-09-22 20:16 UTC (permalink / raw)
To: 50743
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"
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-22 20:16 bug#50743: Emacsclient not tested vs. Local Variables prompt 積丹尼 Dan Jacobson
@ 2021-09-22 20:40 ` Lars Ingebrigtsen
2021-09-23 5:43 ` 積丹尼 Dan Jacobson
2021-09-26 6:53 ` 積丹尼 Dan Jacobson
` (3 subsequent siblings)
4 siblings, 1 reply; 44+ messages in thread
From: Lars Ingebrigtsen @ 2021-09-22 20:40 UTC (permalink / raw)
To: 積丹尼 Dan Jacobson; +Cc: 50743
積丹尼 Dan Jacobson <jidanni@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
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-22 20:40 ` Lars Ingebrigtsen
@ 2021-09-23 5:43 ` 積丹尼 Dan Jacobson
2021-09-23 6:54 ` Phil Sainty
2021-09-24 14:11 ` Phil Sainty
0 siblings, 2 replies; 44+ messages in thread
From: 積丹尼 Dan Jacobson @ 2021-09-23 5:43 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 50743
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.
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-23 5:43 ` 積丹尼 Dan Jacobson
@ 2021-09-23 6:54 ` Phil Sainty
2021-09-24 8:23 ` 積丹尼 Dan Jacobson
2021-09-24 14:11 ` Phil Sainty
1 sibling, 1 reply; 44+ messages in thread
From: Phil Sainty @ 2021-09-23 6:54 UTC (permalink / raw)
To: 積丹尼 Dan Jacobson; +Cc: Lars Ingebrigtsen, 50743
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-23 6:54 ` Phil Sainty
@ 2021-09-24 8:23 ` 積丹尼 Dan Jacobson
0 siblings, 0 replies; 44+ messages in thread
From: 積丹尼 Dan Jacobson @ 2021-09-24 8:23 UTC (permalink / raw)
To: Phil Sainty; +Cc: Lars Ingebrigtsen, 50743
>>>>> "PS" == Phil Sainty <psainty@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%
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-23 5:43 ` 積丹尼 Dan Jacobson
2021-09-23 6:54 ` Phil Sainty
@ 2021-09-24 14:11 ` Phil Sainty
2021-09-24 14:42 ` 積丹尼 Dan Jacobson
1 sibling, 1 reply; 44+ messages in thread
From: Phil Sainty @ 2021-09-24 14:11 UTC (permalink / raw)
To: 積丹尼 Dan Jacobson; +Cc: Lars Ingebrigtsen, 50743
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?
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-24 14:11 ` Phil Sainty
@ 2021-09-24 14:42 ` 積丹尼 Dan Jacobson
2021-09-25 1:12 ` Phil Sainty
0 siblings, 1 reply; 44+ messages in thread
From: 積丹尼 Dan Jacobson @ 2021-09-24 14:42 UTC (permalink / raw)
To: Phil Sainty; +Cc: Lars Ingebrigtsen, 50743
>>>>> "PS" == Phil Sainty <psainty@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?
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-24 14:42 ` 積丹尼 Dan Jacobson
@ 2021-09-25 1:12 ` Phil Sainty
2021-09-25 4:18 ` 積丹尼 Dan Jacobson
0 siblings, 1 reply; 44+ messages in thread
From: Phil Sainty @ 2021-09-25 1:12 UTC (permalink / raw)
To: 積丹尼 Dan Jacobson; +Cc: Lars Ingebrigtsen, 50743
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?)
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-25 1:12 ` Phil Sainty
@ 2021-09-25 4:18 ` 積丹尼 Dan Jacobson
2021-09-25 5:07 ` Phil Sainty
0 siblings, 1 reply; 44+ messages in thread
From: 積丹尼 Dan Jacobson @ 2021-09-25 4:18 UTC (permalink / raw)
To: Phil Sainty; +Cc: Lars Ingebrigtsen, 50743
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."
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-25 4:18 ` 積丹尼 Dan Jacobson
@ 2021-09-25 5:07 ` Phil Sainty
2021-09-25 5:46 ` 積丹尼 Dan Jacobson
0 siblings, 1 reply; 44+ messages in thread
From: Phil Sainty @ 2021-09-25 5:07 UTC (permalink / raw)
To: 積丹尼 Dan Jacobson; +Cc: Lars Ingebrigtsen, 50743
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-25 5:07 ` Phil Sainty
@ 2021-09-25 5:46 ` 積丹尼 Dan Jacobson
2021-09-25 8:33 ` Phil Sainty
0 siblings, 1 reply; 44+ messages in thread
From: 積丹尼 Dan Jacobson @ 2021-09-25 5:46 UTC (permalink / raw)
To: Phil Sainty; +Cc: Lars Ingebrigtsen, 50743
[-- Attachment #1: Type: text/plain, Size: 19 bytes --]
Here's what I see.
[-- Attachment #2: 20210925T133406.jpg --]
[-- Type: image/jpeg, Size: 32332 bytes --]
[-- Attachment #3: Type: text/plain, Size: 1891 bytes --]
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@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.
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-25 5:46 ` 積丹尼 Dan Jacobson
@ 2021-09-25 8:33 ` Phil Sainty
2021-09-25 13:06 ` 積丹尼 Dan Jacobson
0 siblings, 1 reply; 44+ messages in thread
From: Phil Sainty @ 2021-09-25 8:33 UTC (permalink / raw)
To: 積丹尼 Dan Jacobson; +Cc: Lars Ingebrigtsen, 50743
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-25 8:33 ` Phil Sainty
@ 2021-09-25 13:06 ` 積丹尼 Dan Jacobson
2021-09-25 14:02 ` Phil Sainty
0 siblings, 1 reply; 44+ messages in thread
From: 積丹尼 Dan Jacobson @ 2021-09-25 13:06 UTC (permalink / raw)
To: Phil Sainty; +Cc: Lars Ingebrigtsen, 50743
>>>>> "PS" == Phil Sainty <psainty@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.
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-25 13:06 ` 積丹尼 Dan Jacobson
@ 2021-09-25 14:02 ` Phil Sainty
2021-09-25 22:55 ` Mike Kupfer
0 siblings, 1 reply; 44+ messages in thread
From: Phil Sainty @ 2021-09-25 14:02 UTC (permalink / raw)
To: 積丹尼 Dan Jacobson; +Cc: Lars Ingebrigtsen, 50743
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-25 14:02 ` Phil Sainty
@ 2021-09-25 22:55 ` Mike Kupfer
2021-09-26 0:19 ` Mike Kupfer
2021-09-26 0:34 ` Phil Sainty
0 siblings, 2 replies; 44+ messages in thread
From: Mike Kupfer @ 2021-09-25 22:55 UTC (permalink / raw)
To: Phil Sainty
Cc: Lars Ingebrigtsen, 50743, 積丹尼 Dan Jacobson
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-25 22:55 ` Mike Kupfer
@ 2021-09-26 0:19 ` Mike Kupfer
2021-09-26 2:57 ` Mike Kupfer
2021-09-26 0:34 ` Phil Sainty
1 sibling, 1 reply; 44+ messages in thread
From: Mike Kupfer @ 2021-09-26 0:19 UTC (permalink / raw)
To: Phil Sainty
Cc: Lars Ingebrigtsen, 50743, 積丹尼 Dan Jacobson
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-25 22:55 ` Mike Kupfer
2021-09-26 0:19 ` Mike Kupfer
@ 2021-09-26 0:34 ` Phil Sainty
2021-09-26 2:48 ` Mike Kupfer
2021-09-26 6:25 ` Eli Zaretskii
1 sibling, 2 replies; 44+ messages in thread
From: Phil Sainty @ 2021-09-26 0:34 UTC (permalink / raw)
To: Mike Kupfer
Cc: Lars Ingebrigtsen, 50743, 積丹尼 Dan Jacobson
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-26 0:34 ` Phil Sainty
@ 2021-09-26 2:48 ` Mike Kupfer
2021-09-26 6:25 ` Eli Zaretskii
1 sibling, 0 replies; 44+ messages in thread
From: Mike Kupfer @ 2021-09-26 2:48 UTC (permalink / raw)
To: Phil Sainty
Cc: Lars Ingebrigtsen, 50743, 積丹尼 Dan Jacobson
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-26 0:19 ` Mike Kupfer
@ 2021-09-26 2:57 ` Mike Kupfer
0 siblings, 0 replies; 44+ messages in thread
From: Mike Kupfer @ 2021-09-26 2:57 UTC (permalink / raw)
To: 50743; +Cc: Phil Sainty, Lars Ingebrigtsen,
積丹尼 Dan Jacobson
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-26 0:34 ` Phil Sainty
2021-09-26 2:48 ` Mike Kupfer
@ 2021-09-26 6:25 ` Eli Zaretskii
2021-09-26 9:12 ` martin rudalics
2021-09-26 17:02 ` Mike Kupfer
1 sibling, 2 replies; 44+ messages in thread
From: Eli Zaretskii @ 2021-09-26 6:25 UTC (permalink / raw)
To: Phil Sainty; +Cc: larsi, mkupfer, 50743, jidanni
> 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".
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-22 20:16 bug#50743: Emacsclient not tested vs. Local Variables prompt 積丹尼 Dan Jacobson
2021-09-22 20:40 ` Lars Ingebrigtsen
@ 2021-09-26 6:53 ` 積丹尼 Dan Jacobson
2021-09-26 7:12 ` Eli Zaretskii
2021-09-26 7:31 ` 積丹尼 Dan Jacobson
` (2 subsequent siblings)
4 siblings, 1 reply; 44+ messages in thread
From: 積丹尼 Dan Jacobson @ 2021-09-26 6:53 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Phil Sainty, larsi, 50743, mkupfer
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.
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-26 6:53 ` 積丹尼 Dan Jacobson
@ 2021-09-26 7:12 ` Eli Zaretskii
2021-09-26 7:20 ` 積丹尼 Dan Jacobson
0 siblings, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2021-09-26 7:12 UTC (permalink / raw)
To: 積丹尼 Dan Jacobson; +Cc: psainty, larsi, 50743, mkupfer
> From: 積丹尼 Dan Jacobson <jidanni@jidanni.org>
> Cc: Phil Sainty <psainty@orcon.net.nz>, mkupfer@alum.berkeley.edu,
> larsi@gnus.org, 50743@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.
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-26 7:12 ` Eli Zaretskii
@ 2021-09-26 7:20 ` 積丹尼 Dan Jacobson
0 siblings, 0 replies; 44+ messages in thread
From: 積丹尼 Dan Jacobson @ 2021-09-26 7:20 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: psainty, larsi, 50743, mkupfer
[-- Attachment #1: Type: text/html, Size: 151 bytes --]
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-22 20:16 bug#50743: Emacsclient not tested vs. Local Variables prompt 積丹尼 Dan Jacobson
2021-09-22 20:40 ` Lars Ingebrigtsen
2021-09-26 6:53 ` 積丹尼 Dan Jacobson
@ 2021-09-26 7:31 ` 積丹尼 Dan Jacobson
2021-09-26 7:41 ` 積丹尼 Dan Jacobson
2021-09-26 20:49 ` 積丹尼 Dan Jacobson
4 siblings, 0 replies; 44+ messages in thread
From: 積丹尼 Dan Jacobson @ 2021-09-26 7:31 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: psainty, larsi, 50743, mkupfer
[-- Attachment #1: Type: text/plain, Size: 238 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 303 bytes --]
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-22 20:16 bug#50743: Emacsclient not tested vs. Local Variables prompt 積丹尼 Dan Jacobson
` (2 preceding siblings ...)
2021-09-26 7:31 ` 積丹尼 Dan Jacobson
@ 2021-09-26 7:41 ` 積丹尼 Dan Jacobson
2021-09-26 20:49 ` 積丹尼 Dan Jacobson
4 siblings, 0 replies; 44+ messages in thread
From: 積丹尼 Dan Jacobson @ 2021-09-26 7:41 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: psainty, larsi, 50743, mkupfer
[-- Attachment #1: Type: text/plain, Size: 144 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 208 bytes --]
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-26 6:25 ` Eli Zaretskii
@ 2021-09-26 9:12 ` martin rudalics
2021-09-26 9:19 ` Eli Zaretskii
2021-09-27 14:35 ` Jean Louis
2021-09-26 17:02 ` Mike Kupfer
1 sibling, 2 replies; 44+ messages in thread
From: martin rudalics @ 2021-09-26 9:12 UTC (permalink / raw)
To: Eli Zaretskii, Phil Sainty; +Cc: larsi, mkupfer, 50743, jidanni
> 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
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-26 9:12 ` martin rudalics
@ 2021-09-26 9:19 ` Eli Zaretskii
2021-09-26 9:59 ` martin rudalics
2021-09-27 14:35 ` Jean Louis
1 sibling, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2021-09-26 9:19 UTC (permalink / raw)
To: martin rudalics; +Cc: psainty, larsi, mkupfer, 50743, jidanni
> Cc: larsi@gnus.org, mkupfer@alum.berkeley.edu, 50743@debbugs.gnu.org,
> jidanni@jidanni.org
> From: martin rudalics <rudalics@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.
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-26 9:19 ` Eli Zaretskii
@ 2021-09-26 9:59 ` martin rudalics
2021-09-26 11:03 ` Eli Zaretskii
0 siblings, 1 reply; 44+ messages in thread
From: martin rudalics @ 2021-09-26 9:59 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: psainty, larsi, mkupfer, 50743, jidanni
>> 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
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-26 9:59 ` martin rudalics
@ 2021-09-26 11:03 ` Eli Zaretskii
2021-09-26 17:50 ` martin rudalics
2021-09-26 17:51 ` Mike Kupfer
0 siblings, 2 replies; 44+ messages in thread
From: Eli Zaretskii @ 2021-09-26 11:03 UTC (permalink / raw)
To: martin rudalics; +Cc: psainty, larsi, mkupfer, 50743, jidanni
> Cc: psainty@orcon.net.nz, larsi@gnus.org, mkupfer@alum.berkeley.edu,
> 50743@debbugs.gnu.org, jidanni@jidanni.org
> From: martin rudalics <rudalics@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.
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-26 6:25 ` Eli Zaretskii
2021-09-26 9:12 ` martin rudalics
@ 2021-09-26 17:02 ` Mike Kupfer
1 sibling, 0 replies; 44+ messages in thread
From: Mike Kupfer @ 2021-09-26 17:02 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Phil Sainty, larsi, 50743, jidanni
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-26 11:03 ` Eli Zaretskii
@ 2021-09-26 17:50 ` martin rudalics
2021-09-26 18:19 ` Eli Zaretskii
2021-09-26 17:51 ` Mike Kupfer
1 sibling, 1 reply; 44+ messages in thread
From: martin rudalics @ 2021-09-26 17:50 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: psainty, larsi, mkupfer, 50743, jidanni
>> 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
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-26 11:03 ` Eli Zaretskii
2021-09-26 17:50 ` martin rudalics
@ 2021-09-26 17:51 ` Mike Kupfer
2021-09-26 18:26 ` Eli Zaretskii
2021-09-27 8:50 ` martin rudalics
1 sibling, 2 replies; 44+ messages in thread
From: Mike Kupfer @ 2021-09-26 17:51 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: psainty, larsi, 50743, jidanni
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.
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-26 17:50 ` martin rudalics
@ 2021-09-26 18:19 ` Eli Zaretskii
2021-09-27 8:50 ` martin rudalics
0 siblings, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2021-09-26 18:19 UTC (permalink / raw)
To: martin rudalics; +Cc: psainty, larsi, mkupfer, 50743, jidanni
> Cc: psainty@orcon.net.nz, larsi@gnus.org, mkupfer@alum.berkeley.edu,
> 50743@debbugs.gnu.org, jidanni@jidanni.org
> From: martin rudalics <rudalics@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"?
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-26 17:51 ` Mike Kupfer
@ 2021-09-26 18:26 ` Eli Zaretskii
2021-09-26 22:08 ` Mike Kupfer
2021-09-27 8:50 ` martin rudalics
1 sibling, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2021-09-26 18:26 UTC (permalink / raw)
To: Mike Kupfer; +Cc: psainty, larsi, 50743, jidanni
> 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.
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-22 20:16 bug#50743: Emacsclient not tested vs. Local Variables prompt 積丹尼 Dan Jacobson
` (3 preceding siblings ...)
2021-09-26 7:41 ` 積丹尼 Dan Jacobson
@ 2021-09-26 20:49 ` 積丹尼 Dan Jacobson
2021-09-27 4:43 ` Eli Zaretskii
2021-09-27 17:30 ` martin rudalics
4 siblings, 2 replies; 44+ messages in thread
From: 積丹尼 Dan Jacobson @ 2021-09-26 20:49 UTC (permalink / raw)
To: martin rudalics; +Cc: psainty, larsi, 50743, mkupfer
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.
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-26 18:26 ` Eli Zaretskii
@ 2021-09-26 22:08 ` Mike Kupfer
2021-09-27 4:48 ` Eli Zaretskii
0 siblings, 1 reply; 44+ messages in thread
From: Mike Kupfer @ 2021-09-26 22:08 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: psainty, larsi, 50743, jidanni
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-26 20:49 ` 積丹尼 Dan Jacobson
@ 2021-09-27 4:43 ` Eli Zaretskii
2021-09-27 17:30 ` martin rudalics
1 sibling, 0 replies; 44+ messages in thread
From: Eli Zaretskii @ 2021-09-27 4:43 UTC (permalink / raw)
To: 積丹尼 Dan Jacobson; +Cc: psainty, larsi, 50743, mkupfer
> From: 積丹尼 Dan Jacobson <jidanni@jidanni.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, psainty@orcon.net.nz, larsi@gnus.org,
> mkupfer@alum.berkeley.edu, 50743@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.
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-26 22:08 ` Mike Kupfer
@ 2021-09-27 4:48 ` Eli Zaretskii
0 siblings, 0 replies; 44+ messages in thread
From: Eli Zaretskii @ 2021-09-27 4:48 UTC (permalink / raw)
To: Mike Kupfer; +Cc: psainty, larsi, 50743, jidanni
> From: Mike Kupfer <mkupfer@alum.berkeley.edu>
> cc: rudalics@gmx.at, psainty@orcon.net.nz, larsi@gnus.org,
> 50743@debbugs.gnu.org, jidanni@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.
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-26 17:51 ` Mike Kupfer
2021-09-26 18:26 ` Eli Zaretskii
@ 2021-09-27 8:50 ` martin rudalics
1 sibling, 0 replies; 44+ messages in thread
From: martin rudalics @ 2021-09-27 8:50 UTC (permalink / raw)
To: Mike Kupfer, Eli Zaretskii; +Cc: psainty, larsi, 50743, jidanni
> 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
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-26 18:19 ` Eli Zaretskii
@ 2021-09-27 8:50 ` martin rudalics
2021-09-27 14:32 ` Jean Louis
0 siblings, 1 reply; 44+ messages in thread
From: martin rudalics @ 2021-09-27 8:50 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: psainty, larsi, mkupfer, 50743, jidanni
>> 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
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-27 8:50 ` martin rudalics
@ 2021-09-27 14:32 ` Jean Louis
2021-09-27 17:15 ` martin rudalics
0 siblings, 1 reply; 44+ messages in thread
From: Jean Louis @ 2021-09-27 14:32 UTC (permalink / raw)
To: martin rudalics; +Cc: mkupfer, psainty, jidanni, 50743, larsi
* martin rudalics <rudalics@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/
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-26 9:12 ` martin rudalics
2021-09-26 9:19 ` Eli Zaretskii
@ 2021-09-27 14:35 ` Jean Louis
1 sibling, 0 replies; 44+ messages in thread
From: Jean Louis @ 2021-09-27 14:35 UTC (permalink / raw)
To: martin rudalics; +Cc: mkupfer, Phil Sainty, jidanni, 50743, larsi
* martin rudalics <rudalics@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/
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-27 14:32 ` Jean Louis
@ 2021-09-27 17:15 ` martin rudalics
0 siblings, 0 replies; 44+ messages in thread
From: martin rudalics @ 2021-09-27 17:15 UTC (permalink / raw)
To: Jean Louis; +Cc: mkupfer, psainty, jidanni, 50743, larsi
> 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
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#50743: Emacsclient not tested vs. Local Variables prompt
2021-09-26 20:49 ` 積丹尼 Dan Jacobson
2021-09-27 4:43 ` Eli Zaretskii
@ 2021-09-27 17:30 ` martin rudalics
1 sibling, 0 replies; 44+ messages in thread
From: martin rudalics @ 2021-09-27 17:30 UTC (permalink / raw)
To: 積丹尼 Dan Jacobson; +Cc: psainty, larsi, 50743, mkupfer
> 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
^ permalink raw reply [flat|nested] 44+ messages in thread
end of thread, other threads:[~2021-09-27 17:30 UTC | newest]
Thread overview: 44+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-22 20:16 bug#50743: Emacsclient not tested vs. Local Variables prompt 積丹尼 Dan Jacobson
2021-09-22 20:40 ` Lars Ingebrigtsen
2021-09-23 5:43 ` 積丹尼 Dan Jacobson
2021-09-23 6:54 ` Phil Sainty
2021-09-24 8:23 ` 積丹尼 Dan Jacobson
2021-09-24 14:11 ` Phil Sainty
2021-09-24 14:42 ` 積丹尼 Dan Jacobson
2021-09-25 1:12 ` Phil Sainty
2021-09-25 4:18 ` 積丹尼 Dan Jacobson
2021-09-25 5:07 ` Phil Sainty
2021-09-25 5:46 ` 積丹尼 Dan Jacobson
2021-09-25 8:33 ` Phil Sainty
2021-09-25 13:06 ` 積丹尼 Dan Jacobson
2021-09-25 14:02 ` Phil Sainty
2021-09-25 22:55 ` Mike Kupfer
2021-09-26 0:19 ` Mike Kupfer
2021-09-26 2:57 ` Mike Kupfer
2021-09-26 0:34 ` Phil Sainty
2021-09-26 2:48 ` Mike Kupfer
2021-09-26 6:25 ` Eli Zaretskii
2021-09-26 9:12 ` martin rudalics
2021-09-26 9:19 ` Eli Zaretskii
2021-09-26 9:59 ` martin rudalics
2021-09-26 11:03 ` Eli Zaretskii
2021-09-26 17:50 ` martin rudalics
2021-09-26 18:19 ` Eli Zaretskii
2021-09-27 8:50 ` martin rudalics
2021-09-27 14:32 ` Jean Louis
2021-09-27 17:15 ` martin rudalics
2021-09-26 17:51 ` Mike Kupfer
2021-09-26 18:26 ` Eli Zaretskii
2021-09-26 22:08 ` Mike Kupfer
2021-09-27 4:48 ` Eli Zaretskii
2021-09-27 8:50 ` martin rudalics
2021-09-27 14:35 ` Jean Louis
2021-09-26 17:02 ` Mike Kupfer
2021-09-26 6:53 ` 積丹尼 Dan Jacobson
2021-09-26 7:12 ` Eli Zaretskii
2021-09-26 7:20 ` 積丹尼 Dan Jacobson
2021-09-26 7:31 ` 積丹尼 Dan Jacobson
2021-09-26 7:41 ` 積丹尼 Dan Jacobson
2021-09-26 20:49 ` 積丹尼 Dan Jacobson
2021-09-27 4:43 ` Eli Zaretskii
2021-09-27 17:30 ` martin rudalics
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).