* 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-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-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: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-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 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 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 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-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 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: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-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 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 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-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-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-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 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 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).
![[-- Attachment #2: 20210925T133406.jpg --] [-- Type: image/jpeg, Size: 32332 bytes --]](../../87k0j5cilr.5.fsf@jidanni.org/2-20210925T133406.jpg){kind=link}