bug#22068: 25.0.50; Delayed reaction to switching frames?

bug#22068: 25.0.50; Delayed reaction to switching frames?

[David Kastrup]

[-- Attachment #1: Type: text/plain, Size: 367 bytes --]


From a shell in a GUI with sloppy focus (assuming that they are all
similar, I am using GNOME here) do

emacs -Q
M-x set-variable RET focus-follows-mouse RET t RET
C-x C-f /tmp/testfile RET
C-x 5 2    and arrange frames side-by-side
M-! touch /tmp/testfile RET

Now move with the mouse from one frame to the other and immediately
press a key.  I get a message like


[-- Attachment #2: message.png --]
[-- Type: image/png, Size: 41891 bytes --]

[-- Attachment #3: Type: text/plain, Size: 6023 bytes --]


on the _old_ frame (the one I moved out of).  Apparently the frame
switch command gets delivered with some delay and the "changed on disk"
message, arriving late, does no longer manage to switch frames.

I cannot absolutely vouch that the window manager setting "sloppy"
(which can be selected with gnome-tweak-tool) is innocent of the
problem.  But there are no delay settings to select.




In GNU Emacs 25.0.50.2 (i686-pc-linux-gnu, GTK+ Version 3.16.7)
 of 2015-10-28
Repository revision: 869506376f4eb8d402c990318063ae73463a4010
Windowing system distributor 'The X.Org Foundation', version 11.0.11702000
System Description:	Ubuntu 15.10

Configured using:
 'configure --without-toolkit-scroll-bars'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB GTK3
X11

Important settings:
  value of $LC_MONETARY: en_US.UTF-8
  value of $LC_NUMERIC: en_US.UTF-8
  value of $LC_TIME: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix

Major mode: Group

Minor modes in effect:
  gnus-agent-group-mode: t
  global-git-commit-mode: t
  async-bytecomp-package-mode: t
  gnus-undo-mode: t
  shell-dirtrack-mode: t
  TeX-PDF-mode: t
  diff-auto-refine-mode: t
  desktop-save-mode: t
  minibuffer-electric-default-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
Reading active file from /home/dak3/Mail/club via nndir...
Opening nndir server on /home/dak3/Mail/club...done
Reading active file from /home/dak3/Mail/club via nndir...done
Reading active file via nndraft...done
Reading active file from /home/dak3/Mail/family via nndir...
Opening nndir server on /home/dak3/Mail/family...done
Reading active file from /home/dak3/Mail/family via nndir...done
Checking new news...done
Auto-saving...
/ is undefined

Load-path shadows:
None found.

Features:
(shadow emacsbug ispell calc-math calc-stuff calc-frac calc-poly
calc-arith calc-misc view calccomp calc-units calc-alg calc-ext
calc-aent calc-menu calc calc-loaddefs calc-macs gnus-draft pp rfc2368
nndoc tramp-cache git-rebase magit-blame magit-stash magit-bisect
magit-remote magit-commit magit-sequence magit magit-apply magit-wip
magit-log magit-diff magit-core magit-process magit-popup magit-mode
magit-git magit-section magit-utils git-commit log-edit with-editor
async-bytecomp async dash canlock quail mpuz thingatpt log-view
pcvs-util vc-annotate rect dabbrev gnus-dup misearch multi-isearch
shr-color color url-util url-parse url-vars shr dom subr-x browse-url
eieio-opt speedbar sb-image ezimage dframe find-func cus-edit debug
cmuscheme gnus-fun flow-fill sendmail nnir mm-archive gnus-kill sort
smiley gnus-cite mail-extr gnus-async gnus-bcklg qp gnus-ml disp-table
pop3 nndraft gnutls network-stream nsm starttls nndir nnmh nnml nnfolder
nnnil gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg
gnus-art mm-uu mml2015 mm-view mml-smime smime dig mailcap nntp
gnus-cache gnus-sum gnus-group gnus-undo gnus-start gnus-cloud nnimap
nnmail mail-source tls utf7 netrc nnoo parse-time gnus-spec gnus-int
gnus-range gnus-win add-log make-mode tar-mode nxml-uchnm rng-xsd
xsd-regexp rng-cmpct rng-nxml rng-valid rng-loc rng-uri rng-parse
nxml-parse rng-match rng-dt rng-util rng-pttrn nxml-ns nxml-mode
nxml-outln nxml-rap nxml-util nxml-glyph nxml-enc xmltok autorevert
filenotify conf-mode message rfc822 mml mml-sec mm-decode mm-bodies
mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev
gmm-utils mailheader python tramp-sh tramp tramp-compat auth-source
cl-seq eieio eieio-core cl-macs gv password-cache tramp-loaddefs
trampver shell pcomplete format-spec json jka-compr dired-x dired
sh-script smie executable latexenc preview prv-emacs reftex-dcr
reftex-auc reftex reftex-vars tex-bar toolbar-x noutline outline
font-latex byte-opt bytecomp byte-compile cconv latex edmacro kmacro
tex-style tex-buf tex-info texinfo tex dbus xml crm smerge-mode
lilypond-mode compile comint ansi-color ring cl-extra cc-mode cc-fonts
cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs
vc vc-dispatcher scheme vc-git diff-mode easy-mmode advice desktop
frameset minibuf-eldef gnus gnus-ems nnheader gnus-util mail-utils
mm-util help-fns help-mode mail-prsvr wid-edit cl-loaddefs pcase cl-lib
cus-start cus-load preview-latex tex-site auto-loads server finder-inf
info package easymenu epg-config time-date mule-util tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
dbusbind inotify dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 8 1017932 168067)
 (symbols 24 71796 200)
 (miscs 20 2578 3397)
 (strings 16 162221 24070)
 (string-bytes 1 5106618)
 (vectors 8 65023)
 (vector-slots 4 2227032 34692)
 (floats 8 730 1388)
 (intervals 28 64428 4288)
 (buffers 520 516)
 (heap 1024 121896 9257))

-- 
David Kastrup

bug#22068: 25.0.50; Delayed reaction to switching frames?

[martin rudalics]

 > I cannot absolutely vouch that the window manager setting "sloppy"
 > (which can be selected with gnome-tweak-tool) is innocent of the
 > problem.  But there are no delay settings to select.

Did you try with "mouse" or whatever you have to remove focus from a
frame when the mouse leaves it?

Not that I think it would change anything ...

martin

bug#22068: 25.0.50; Delayed reaction to switching frames?

[David Kastrup]

martin rudalics <rudalics@gmx.at> writes:

>> I cannot absolutely vouch that the window manager setting "sloppy"
>> (which can be selected with gnome-tweak-tool) is innocent of the
>> problem.  But there are no delay settings to select.
>
> Did you try with "mouse" or whatever you have to remove focus from a
> frame when the mouse leaves it?
>
> Not that I think it would change anything ...

Well, it would make the timing of the focus change slightly earlier.
Not likely early enough.  Let me try.

No, doesn't help.  I mean, when moving the mouse over, it still takes
half a second for the frame highlighting to change, indicating the
changed focus from the view of the window manager (I guess).  So I
cannot vouch that the window manager isn't involved in the delayed frame
switch.

And indeed: the strange switch-frame- keyboard echo as a reply to the
"changed on disk; really edit the buffer?" prompt in connection with the
minibuffer (and actual keyboard focus) staying in the old frame in spite
of the mouse pointer and the focus highlighting having moved over: that
remains the same even if I keep the apparently perceived order of
events: I cannot switch frames in reply to the "really edit the buffer"
prompt.

If I answer (with focus in the old frame and mouse pointer in the new
frame) "n" to that question, the error message "xxx: changed on disk"
then appears in the new frame, and so does the focus.

So while the delayed switch may or may not be Emacs' fault, the annoying
effect of not reacting to the frame change as long as the prompt is
active does not depend on the timing of the switch.

-- 
David Kastrup

bug#22068: 25.0.50; Delayed reaction to switching frames?

[martin rudalics]

 > No, doesn't help.  I mean, when moving the mouse over, it still takes
 > half a second for the frame highlighting to change, indicating the
 > changed focus from the view of the window manager (I guess).  So I
 > cannot vouch that the window manager isn't involved in the delayed frame
 > switch.

I just tried with xfwm4.  Here a focus_delay of 185 (ms I presume)
behaves as expected while a delay of 1850 shows the behavior you
describe.

 > And indeed: the strange switch-frame- keyboard echo

... which happens also when the prompt appears in the frame the mouse
moved to and I now move the mouse back to the other one - I always
wondered how to get rid of them ...

 > as a reply to the
 > "changed on disk; really edit the buffer?" prompt in connection with the
 > minibuffer (and actual keyboard focus) staying in the old frame in spite
 > of the mouse pointer and the focus highlighting having moved over: that
 > remains the same even if I keep the apparently perceived order of
 > events: I cannot switch frames in reply to the "really edit the buffer"
 > prompt.

All this seems very hardcoded in choose_minibuf_frame.

 > If I answer (with focus in the old frame and mouse pointer in the new
 > frame) "n" to that question, the error message "xxx: changed on disk"
 > then appears in the new frame, and so does the focus.
 >
 > So while the delayed switch may or may not be Emacs' fault, the annoying
 > effect of not reacting to the frame change as long as the prompt is
 > active does not depend on the timing of the switch.

I'm afraid lots of this has been special coded to work for stand alone
minibuffer frames.  These have to pop up and keep focus till the reply
arrives.

martin

bug#22068: 25.0.50; Delayed reaction to switching frames?

[Eli Zaretskii]

> Date: Wed, 02 Dec 2015 11:05:37 +0100
> From: martin rudalics <rudalics@gmx.at>
> Cc: 22068@debbugs.gnu.org
> 
>  > No, doesn't help.  I mean, when moving the mouse over, it still takes
>  > half a second for the frame highlighting to change, indicating the
>  > changed focus from the view of the window manager (I guess).  So I
>  > cannot vouch that the window manager isn't involved in the delayed frame
>  > switch.
> 
> I just tried with xfwm4.  Here a focus_delay of 185 (ms I presume)
> behaves as expected while a delay of 1850 shows the behavior you
> describe.
> 
>  > And indeed: the strange switch-frame- keyboard echo
> 
> ... which happens also when the prompt appears in the frame the mouse
> moved to and I now move the mouse back to the other one - I always
> wondered how to get rid of them ...
> 
>  > as a reply to the
>  > "changed on disk; really edit the buffer?" prompt in connection with the
>  > minibuffer (and actual keyboard focus) staying in the old frame in spite
>  > of the mouse pointer and the focus highlighting having moved over: that
>  > remains the same even if I keep the apparently perceived order of
>  > events: I cannot switch frames in reply to the "really edit the buffer"
>  > prompt.
> 
> All this seems very hardcoded in choose_minibuf_frame.

Could this have something to do with the fact that read-char-choice
calls read-key-sequence-vector with the CAN-RETURN-SWITCH-FRAME
argument nil?

bug#22068: 25.0.50; Delayed reaction to switching frames?

[martin rudalics]

 > Could this have something to do with the fact that read-char-choice
 > calls read-key-sequence-vector with the CAN-RETURN-SWITCH-FRAME
 > argument nil?

When I do a simple (y-or-no-p "") in a single frame emacs -Q and click
the left mouse button, it also gets echoed as "down-mouse-1".  But this
echo disappears almost instantaneously.  With two frames and a click in
the "wrong" frame the echo is persistent.

martin

bug#22068: 25.0.50; Delayed reaction to switching frames?

[Eli Zaretskii]

> Date: Wed, 02 Dec 2015 18:44:10 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: dak@gnu.org, 22068@debbugs.gnu.org
> 
>  > Could this have something to do with the fact that read-char-choice
>  > calls read-key-sequence-vector with the CAN-RETURN-SWITCH-FRAME
>  > argument nil?
> 
> When I do a simple (y-or-no-p "") in a single frame emacs -Q and click
> the left mouse button, it also gets echoed as "down-mouse-1".  But this
> echo disappears almost instantaneously.  With two frames and a click in
> the "wrong" frame the echo is persistent.

The function in question doesn't call y-or-no-p, AFAICT.

When I call the function it does call, that call does not return if it
gets switch-frame events.  IOW, the function that asks the question
doesn't know the frame was switched, and cannot do what David probably
wants: switch frame and reissue the question.

bug#22068: 25.0.50; Delayed reaction to switching frames?

[martin rudalics]

 >> When I do a simple (y-or-no-p "") in a single frame emacs -Q and click
 >> the left mouse button, it also gets echoed as "down-mouse-1".  But this
 >> echo disappears almost instantaneously.  With two frames and a click in
 >> the "wrong" frame the echo is persistent.
 >
 > The function in question doesn't call y-or-no-p, AFAICT.

The effect is the same.

 > When I call the function it does call, that call does not return if it
 > gets switch-frame events.  IOW, the function that asks the question
 > doesn't know the frame was switched, and cannot do what David probably
 > wants: switch frame and reissue the question.

OK.  But how can we get rid of that "switch-frame-" echo at least?

martin

bug#22068: 25.0.50; Delayed reaction to switching frames?

[David Kastrup]

martin rudalics <rudalics@gmx.at> writes:

>>> When I do a simple (y-or-no-p "") in a single frame emacs -Q and click
>>> the left mouse button, it also gets echoed as "down-mouse-1".  But this
>>> echo disappears almost instantaneously.  With two frames and a click in
>>> the "wrong" frame the echo is persistent.
>>
>> The function in question doesn't call y-or-no-p, AFAICT.
>
> The effect is the same.
>
>> When I call the function it does call, that call does not return if it
>> gets switch-frame events.  IOW, the function that asks the question
>> doesn't know the frame was switched, and cannot do what David probably
>> wants: switch frame and reissue the question.
>
> OK.  But how can we get rid of that "switch-frame-" echo at least?

If the function is not supposed to return switch-frame events, why
doesn't it _act_ on them then?

-- 
David Kastrup

bug#22068: 25.0.50; Delayed reaction to switching frames?

[Eli Zaretskii]

> Date: Wed, 02 Dec 2015 19:11:17 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: dak@gnu.org, 22068@debbugs.gnu.org
> 
>  > When I call the function it does call, that call does not return if it
>  > gets switch-frame events.  IOW, the function that asks the question
>  > doesn't know the frame was switched, and cannot do what David probably
>  > wants: switch frame and reissue the question.
> 
> OK.  But how can we get rid of that "switch-frame-" echo at least?

Will this really solve some significant part of the problem?  If it
does, we could perhaps introduce some inhibit-SOMETHING variable to do
that.

bug#22068: 25.0.50; Delayed reaction to switching frames?

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  22068@debbugs.gnu.org
> Date: Wed, 02 Dec 2015 20:58:10 +0100
> 
> >> When I call the function it does call, that call does not return if it
> >> gets switch-frame events.  IOW, the function that asks the question
> >> doesn't know the frame was switched, and cannot do what David probably
> >> wants: switch frame and reissue the question.
> >
> > OK.  But how can we get rid of that "switch-frame-" echo at least?
> 
> If the function is not supposed to return switch-frame events, why
> doesn't it _act_ on them then?

According to documentation, it does act on them, only later:

  Optional fourth argument CAN-RETURN-SWITCH-FRAME non-nil means that
  this function will process a switch-frame event if the user switches
  frames before typing anything.  If the user switches frames in the
  middle of a key sequence, or at the start of the sequence but
  CAN-RETURN-SWITCH-FRAME is nil, then the event will be put off until
  after the current key sequence.

bug#22068: 25.0.50; Delayed reaction to switching frames?

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  22068@debbugs.gnu.org
>> Date: Wed, 02 Dec 2015 20:58:10 +0100
>> 
>> >> When I call the function it does call, that call does not return if it
>> >> gets switch-frame events.  IOW, the function that asks the question
>> >> doesn't know the frame was switched, and cannot do what David probably
>> >> wants: switch frame and reissue the question.
>> >
>> > OK.  But how can we get rid of that "switch-frame-" echo at least?
>> 
>> If the function is not supposed to return switch-frame events, why
>> doesn't it _act_ on them then?
>
> According to documentation, it does act on them, only later:
>
>   Optional fourth argument CAN-RETURN-SWITCH-FRAME non-nil means that
>   this function will process a switch-frame event if the user switches
>   frames before typing anything.  If the user switches frames in the
>   middle of a key sequence, or at the start of the sequence but
>   CAN-RETURN-SWITCH-FRAME is nil, then the event will be put off until
>   after the current key sequence.

Well, the resulting user experience makes the impression of Emacs
dragging its internals behind while it staggers on.  When the desktop
environment already heeded and signaled a focus change, choosing a
behavior where Emacs does not act on it is likely to break the visual
feedback between what the user is doing and what Emacs is doing (how
about changes of virtual desktops?).  The spurious keyboard half-echo of
the frame switch event is just the cherry on top.

-- 
David Kastrup

bug#22068: 25.0.50; Delayed reaction to switching frames?

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: rudalics@gmx.at,  22068@debbugs.gnu.org
> Date: Thu, 03 Dec 2015 08:41:32 +0100
> 
> >   Optional fourth argument CAN-RETURN-SWITCH-FRAME non-nil means that
> >   this function will process a switch-frame event if the user switches
> >   frames before typing anything.  If the user switches frames in the
> >   middle of a key sequence, or at the start of the sequence but
> >   CAN-RETURN-SWITCH-FRAME is nil, then the event will be put off until
> >   after the current key sequence.
> 
> Well, the resulting user experience makes the impression of Emacs
> dragging its internals behind while it staggers on.  When the desktop
> environment already heeded and signaled a focus change, choosing a
> behavior where Emacs does not act on it is likely to break the visual
> feedback between what the user is doing and what Emacs is doing (how
> about changes of virtual desktops?).  The spurious keyboard half-echo of
> the frame switch event is just the cherry on top.

I agree.  The practical question is how to find some reasonable
solution here.

Is it possible for you to try to hack the functions involved in this,
such that read-key-sequence-vector is called with its 4th argument
non-nil, and see if the results are better or worse?  (I presume the
code in userlock.el will have to be changed to do something when this
event comes from read-char-choice, or something.)