bug#18722: 25.0.50; UI partly unresponsive after re-focus of Emacs' window.

bug#18722: 25.0.50; UI partly unresponsive after re-focus of Emacs' window.

[Titus von der Malsburg]

Actions that trigger the bug:

1. Start emacs -Q.
2. Unfocus the application window, e.g., by clicking on another
application.
3. Re-focus Emacs.
4. Write something.

Result: The typed text does not appear.  When I click on a menu-item,
the typed text appears and the UI is responsive again.

I'm using the FVWM2 window manager under Ubuntu 14.04 and the latest
Emacs from git.  The problem first appeared when I recompiled Emacs two
weeks ago.  However, I can't pin down which commit introduced it because
I hadn't updated Emacs for several weeks before. 



In GNU Emacs 25.0.50.3 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8)
 of 2014-10-14 on montana
Windowing system distributor `The X.Org Foundation', version 11.0.11501000
System Description:	Ubuntu 14.04.1 LTS

Configured using:
 `configure --prefix=/home/malsburg/usr/ --with-x-toolkit=yes
 --with-sound=no --without-gpm --without-dbus --without-gconf
 --without-gsettings --without-selinux --with-file-notification=yes
 --with-x PKG_CONFIG_PATH=/usr/local/X11R6.8/lib/pkgconfig'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK NOTIFY GNUTLS LIBXML2 FREETYPE
XFT ZLIB

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

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-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
  line-number-mode: t

Recent input:
M-x r e p o r t <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message dired format-spec
rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util help-fns mail-prsvr mail-utils time-date tooltip
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-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 cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer 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 make-network-process
gfilenotify dynamic-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty emacs)

Memory information:
((conses 16 76554 5486)
 (symbols 48 18069 0)
 (miscs 40 46 113)
 (strings 32 11447 4270)
 (string-bytes 1 302141)
 (vectors 16 10017)
 (vector-slots 8 392276 11577)
 (floats 8 70 167)
 (intervals 56 185 0)
 (buffers 976 11)
 (heap 1024 36984 901))

bug#18722: Correction

[Titus von der Malsburg]

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


The problem seems to appear when I iconify and reopen the Emacs
window.  Unfocusing the Emacs window alone is not enough to trigger the
bug.  Also it seems that Emacs is responding to my input.  It just
doesn't render changes in the windows and the minibuffer.

  Titus

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

bug#18722: Correction

[martin rudalics]

 > Actions that trigger the bug:
 >
 > 1. Start emacs -Q.
 > 2. Unfocus the application window, e.g., by clicking on another
 > application.
 > 3. Re-focus Emacs.
 > 4. Write something.
 >
 > Result: The typed text does not appear.  When I click on a menu-item,
 > the typed text appears and the UI is responsive again.

 > The problem seems to appear when I iconify and reopen the Emacs
 > window.  Unfocusing the Emacs window alone is not enough to trigger the
 > bug.  Also it seems that Emacs is responding to my input.  It just
 > doesn't render changes in the windows and the minibuffer.

I see something similar when I minimize the maximized window of another
application and (presumably, implicitly) re-focus the Emacs window.  But
I have no good recipe to trigger it reliably.  It would help so much if
you were able to bisect this ...

martin

bug#18722: Correction

[Eli Zaretskii]

> Date: Thu, 16 Oct 2014 10:52:23 +0200
> From: martin rudalics <rudalics@gmx.at>
> 
>  > Actions that trigger the bug:
>  >
>  > 1. Start emacs -Q.
>  > 2. Unfocus the application window, e.g., by clicking on another
>  > application.
>  > 3. Re-focus Emacs.
>  > 4. Write something.
>  >
>  > Result: The typed text does not appear.  When I click on a menu-item,
>  > the typed text appears and the UI is responsive again.
> 
>  > The problem seems to appear when I iconify and reopen the Emacs
>  > window.  Unfocusing the Emacs window alone is not enough to trigger the
>  > bug.  Also it seems that Emacs is responding to my input.  It just
>  > doesn't render changes in the windows and the minibuffer.
> 
> I see something similar when I minimize the maximized window of another
> application and (presumably, implicitly) re-focus the Emacs window.  But
> I have no good recipe to trigger it reliably.

I think we are relying on X expose events in these cases.  Maybe this
particular window manager doesn't send them?

I'm not sure I understand this part:

 > Also it seems that Emacs is responding to my input.  It just
 > doesn't render changes in the windows and the minibuffer.

If Emacs doesn't redisplay the changes, then what does "is responding
to changes" mean?  How do you even kn ow Emacs responds to changes, if
it doesn't redisplay?

bug#18722: Correction

[martin rudalics]

 >> I see something similar when I minimize the maximized window of another
 >> application and (presumably, implicitly) re-focus the Emacs window.  But
 >> I have no good recipe to trigger it reliably.
 >
 > I think we are relying on X expose events in these cases.  Maybe this
 > particular window manager doesn't send them?

The problem is fairly new.  I think I noticed it about a month ago.  And
I didn't change my window manager in the past year.  But I might have
changed some of its settings :-(

The behavior seems time related: The longer another application's window
covers that of Emacs, the higher is the probability that the Emacs frame
is not redrawn.  Clicking on a menu item, resizing the frame, or
switching do it via M-TAB gets it out of the situation.  Clicking with
the mouse into the frame doesn't.

martin

bug#18722: Correction

[Eli Zaretskii]

> Date: Thu, 16 Oct 2014 13:41:09 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: malsburg@posteo.de, 18722@debbugs.gnu.org
> 
> The behavior seems time related: The longer another application's window
> covers that of Emacs, the higher is the probability that the Emacs frame
> is not redrawn.  Clicking on a menu item, resizing the frame, or
> switching do it via M-TAB gets it out of the situation.  Clicking with
> the mouse into the frame doesn't.

Is Emacs consuming any CPU, before you click on it?

bug#18722: Correction

[Titus von der Malsburg]

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


On 2014-10-16 Thu 03:04, Eli Zaretskii wrote:
> I'm not sure I understand this part:
>
>  > Also it seems that Emacs is responding to my input.  It just
>  > doesn't render changes in the windows and the minibuffer.
>
> If Emacs doesn't redisplay the changes, then what does "is responding
> to changes" mean?  How do you even kn ow Emacs responds to changes, if
> it doesn't redisplay?

As I said in the original post, correct rendering is resumed when I
click on a menu and I see that Emacs has in fact updated the buffers
according to my inputs.  Even before clicking on a menu item I see that
Emacs processes my input when for example menus change in response to
inputs: e.g., when I switch buffers, I see different menus at the top
according to the modes that are active in the respective buffers but the
windows are not updated.  So it seems that the problem really is
updating of the window displays.

I'm fairly sure that the problem was introduced by a recent change in
Emacs because I didn't change anything else at the time when the problem
first occurred.  Specifically, I did not change the window manager or
its configuration.

  Titus


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

bug#18722: Correction

[Eli Zaretskii]

> From: Titus von der Malsburg <malsburg@posteo.de>
> Cc: martin rudalics <rudalics@gmx.at>, 18722@debbugs.gnu.org
> Date: Thu, 16 Oct 2014 07:46:45 -0700
> 
> > If Emacs doesn't redisplay the changes, then what does "is responding
> > to changes" mean?  How do you even kn ow Emacs responds to changes, if
> > it doesn't redisplay?
> 
> As I said in the original post, correct rendering is resumed when I
> click on a menu and I see that Emacs has in fact updated the buffers
> according to my inputs.  Even before clicking on a menu item I see that
> Emacs processes my input when for example menus change in response to
> inputs: e.g., when I switch buffers, I see different menus at the top
> according to the modes that are active in the respective buffers but the
> windows are not updated.  So it seems that the problem really is
> updating of the window displays.

I'm not sure.  What you see is the result of Emacs updating the
display, but you cannot know whether the changes to buffers according
to your inputs happened while the display was outdated, or immediately
prior to updating the display as result of your clicking.

IOW, it could be that all your inputs are processed in one go when you
click, and the display updated right after that.

Or do you have evidence that the scenario I described did not in fact
happen?

> I'm fairly sure that the problem was introduced by a recent change in
> Emacs because I didn't change anything else at the time when the problem
> first occurred.  Specifically, I did not change the window manager or
> its configuration.

It would be helpful if you could quantify "recent" to the best of your
knowledge and records, if not bisect the trunk.  Thanks in advance.

bug#18722: Correction

[Titus von der Malsburg]

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


On 2014-10-16 Thu 07:54, Eli Zaretskii wrote:
> I'm not sure.  What you see is the result of Emacs updating the
> display, but you cannot know whether the changes to buffers according
> to your inputs happened while the display was outdated, or immediately
> prior to updating the display as result of your clicking.
>
> IOW, it could be that all your inputs are processed in one go when you
> click, and the display updated right after that.
>
> Or do you have evidence that the scenario I described did not in fact
> happen?

I can enter text and save the buffer before clicking menu items.  When I
inspect the content of the file with another editor, I see that it
contains the text that I entered before saving.

>> I'm fairly sure that the problem was introduced by a recent change in
>> Emacs because I didn't change anything else at the time when the problem
>> first occurred.  Specifically, I did not change the window manager or
>> its configuration.
>
> It would be helpful if you could quantify "recent" to the best of your
> knowledge and records, if not bisect the trunk.  Thanks in advance.

Given on how rarely I update to the latest development version of Emacs,
I can't say anything more precise than that the problem was introduced
during this summer.  I know, not very helpful.

What do you mean with bisect?  Checkout earlier versions and test them
until I find the bad commit?  Given the high volume of commits in Emacs
this would take quite a while even when using an efficient
search strategy.

  Titus



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

bug#18722: Correction

[Titus von der Malsburg]

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


On 2014-10-16 Thu 04:41, martin rudalics wrote:
> The behavior seems time related: The longer another application's window
> covers that of Emacs, the higher is the probability that the Emacs frame
> is not redrawn.  Clicking on a menu item, resizing the frame, or
> switching do it via M-TAB gets it out of the situation.  Clicking with
> the mouse into the frame doesn't.

In my case, I can't see an influence of time but perhaps I haven't tried
hard enough.  I can make Emacs behave correctly, by clicking menu items,
by focusing it using M-TAB, and by resizing.  However, resizing does not
have this effect when Emacs is in fullscreen mode.

  Titus


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

bug#18722: Correction

[Eli Zaretskii]

> From: Titus von der Malsburg <malsburg@posteo.de>
> Cc: rudalics@gmx.at, 18722@debbugs.gnu.org
> Date: Thu, 16 Oct 2014 08:10:37 -0700
> 
> I can enter text and save the buffer before clicking menu items.  When I
> inspect the content of the file with another editor, I see that it
> contains the text that I entered before saving.

Do you see the changes in the file before or after you click on the
Emacs frame?  If before, then indeed it sounds like Emacs is reacting
to your inputs, but the display is not refreshed.

But a situation where Emacs acts on your input, but does not update
the display is inconceivable, unless some external factor is at work.
That's because the same loop where Emacs reads input also calls
redisplay, and since saving a buffer displays a message in the echo
area, calling redisplay must have updated at least the echo area.  I
cannot understand how could Emacs save a buffer, but not display the
echo area message that is part of saving that buffer.

> Given on how rarely I update to the latest development version of Emacs,
> I can't say anything more precise than that the problem was introduced
> during this summer.  I know, not very helpful.

Do you still have the previous binary you built?  Can you run it now
and make sure the problem does not exist in that binary?

> What do you mean with bisect?  Checkout earlier versions and test them
> until I find the bad commit?  Given the high volume of commits in Emacs
> this would take quite a while even when using an efficient
> search strategy.

Both bzr and git have a bisect command that will converge on the
offending revision logarithmically.  Since there were about 1000
commits since the beginning of the summer, you will need about 10
different builds.

bug#18722: Correction

[Titus von der Malsburg]

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


On 2014-10-16 Thu 08:34, Eli Zaretskii wrote:
>> From: Titus von der Malsburg <malsburg@posteo.de>
>> Cc: rudalics@gmx.at, 18722@debbugs.gnu.org
>> Date: Thu, 16 Oct 2014 08:10:37 -0700
>> 
>> I can enter text and save the buffer before clicking menu items.  When I
>> inspect the content of the file with another editor, I see that it
>> contains the text that I entered before saving.
>
> Do you see the changes in the file before or after you click on the
> Emacs frame?  If before, then indeed it sounds like Emacs is reacting
> to your inputs, but the display is not refreshed.

Of course I checked the file before clicking on a menu items,
otherwise the test would not be informative.

> But a situation where Emacs acts on your input, but does not update
> the display is inconceivable, unless some external factor is at work.
> That's because the same loop where Emacs reads input also calls
> redisplay, and since saving a buffer displays a message in the echo
> area, calling redisplay must have updated at least the echo area.  I
> cannot understand how could Emacs save a buffer, but not display the
> echo area message that is part of saving that buffer.

I don't know enough about the inner workings of Emacs to say anything
useful about this but one possibility might be that there is a bug in
GTK that is triggered by recent versions of Emacs but not by earlier
versions.

>> Given on how rarely I update to the latest development version of Emacs,
>> I can't say anything more precise than that the problem was introduced
>> during this summer.  I know, not very helpful.
>
> Do you still have the previous binary you built?  Can you run it now
> and make sure the problem does not exist in that binary?

Unfortunately, I don't have this binary anymore.

>> What do you mean with bisect?  Checkout earlier versions and test them
>> until I find the bad commit?  Given the high volume of commits in Emacs
>> this would take quite a while even when using an efficient
>> search strategy.
>
> Both bzr and git have a bisect command that will converge on the
> offending revision logarithmically.  Since there were about 1000
> commits since the beginning of the summer, you will need about 10
> different builds.

Ok, I'll see what I can do.

  Titus


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

bug#18722: Correction

[Stefan Monnier]

> according to my inputs.  Even before clicking on a menu item I see that
> Emacs processes my input when for example menus change in response to
> inputs: e.g., when I switch buffers, I see different menus at the top
> according to the modes that are active in the respective buffers but the
> windows are not updated.

Hmm... so the menu-bar is updated in a timely manner according to your
actions, but the windows's content inside the frame aren't?  I guess
mode lines aren't updated either.  What about scrollbars?

[ Just a shot in the dark: ]
Could you try a non-Gtk build (i.e. --with-x-toolkit=lucid)?


        Stefan

bug#18722: Correction

[Titus von der Malsburg]

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


On 2014-10-16 Thu 09:07, Stefan Monnier wrote:
>> according to my inputs.  Even before clicking on a menu item I see that
>> Emacs processes my input when for example menus change in response to
>> inputs: e.g., when I switch buffers, I see different menus at the top
>> according to the modes that are active in the respective buffers but the
>> windows are not updated.
>
> Hmm... so the menu-bar is updated in a timely manner according to your
> actions, but the windows's content inside the frame aren't?  I guess
> mode lines aren't updated either.  What about scrollbars?

As you guessed, the mode lines are not updated and the scrollbars
aren't either.  The only thing that shows responses is the GTK menubar
at the top.

> [ Just a shot in the dark: ]
> Could you try a non-Gtk build (i.e. --with-x-toolkit=lucid)?

With the lucid toolkit I can't reproduce the problem.

  Titus


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

bug#18722: Correction

[Titus von der Malsburg]

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


On 2014-10-16 Thu 08:34, Eli Zaretskii wrote:
> Both bzr and git have a bisect command that will converge on the
> offending revision logarithmically.  Since there were about 1000
> commits since the beginning of the summer, you will need about 10
> different builds.

Ok, I used git bisect as described here:

  http://git-scm.com/docs/git-bisect

In every iteration I did the following:

  make distclean && make clean && ./autogen.sh && ./configure && make && src/emacs -Q

According to this procedure, the following commit introduced the problem:

  6fcdb247c460ae52018a970c189969620c959465

Does that make any sense at all?

  Titus

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

bug#18722: Correction

[Titus von der Malsburg]

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


On 2014-10-16 Thu 14:17, Titus von der Malsburg wrote:
> On 2014-10-16 Thu 08:34, Eli Zaretskii wrote:
>> Both bzr and git have a bisect command that will converge on the
>> offending revision logarithmically.  Since there were about 1000
>> commits since the beginning of the summer, you will need about 10
>> different builds.
>
> Ok, I used git bisect as described here:
>
>   http://git-scm.com/docs/git-bisect
>
> In every iteration I did the following:
>
>   make distclean && make clean && ./autogen.sh && ./configure && make && src/emacs -Q
>
> According to this procedure, the following commit introduced the problem:
>
>   6fcdb247c460ae52018a970c189969620c959465

For those who are not using git, it was this commit:

https://lists.gnu.org/archive/html/emacs-diffs/2014-09/msg00085.html


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

bug#18722: Correction

[Stefan Monnier]

> For those who are not using git, it was this commit:
> https://lists.gnu.org/archive/html/emacs-diffs/2014-09/msg00085.html

Hmm... kind of hard to imagine how that could have such an effect.
OTOH the next commit after this one looks like a possible candidate:

    === modified file 'src/ChangeLog'
    --- src/ChangeLog       2014-09-10 16:52:50 +0000
    +++ src/ChangeLog       2014-09-10 17:02:42 +0000
    @@ -1,3 +1,8 @@
    +2014-09-10  Jan Djärv  <jan.h.d@swipnet.se>
    +
    +       * xterm.c (handle_one_xevent): Detect iconified by looking at
    +       _NET_WM_STATE_HIDDEN.
    +
     2014-09-10  Paul Eggert  <eggert@cs.ucla.edu>
     
            * lisp.h (DEFINE_GDB_SYMBOL_ENUM): Remove.
    
    === modified file 'src/xterm.c'
    --- src/xterm.c 2014-09-09 03:22:36 +0000
    +++ src/xterm.c 2014-09-10 17:02:42 +0000
    @@ -6860,6 +6860,14 @@
                 inev.ie.kind = DEICONIFY_EVENT;
                 XSETFRAME (inev.ie.frame_or_window, f);
               }
    +        else if (! FRAME_ICONIFIED_P (f)
    +                 && f->output_data.x->net_wm_state_hidden_seen)
    +          {
    +            SET_FRAME_VISIBLE (f, 0);
    +            SET_FRAME_ICONIFIED (f, 1);
    +            inev.ie.kind = ICONIFY_EVENT;
    +            XSETFRAME (inev.ie.frame_or_window, f);
    +          }
     
           x_handle_property_notify (&event->xproperty);
           xft_settings_event (dpyinfo, event);

Can you try the patch below (applied to the latest trunk code) to see if
your problem is really triggered by this commit?


        Stefan


=== modified file 'src/xterm.c'
--- src/xterm.c	2014-10-12 06:09:50 +0000
+++ src/xterm.c	2014-10-17 00:51:47 +0000
@@ -6864,14 +6864,6 @@
 	      inev.ie.kind = DEICONIFY_EVENT;
 	      XSETFRAME (inev.ie.frame_or_window, f);
 	    }
-	  else if (! FRAME_ICONIFIED_P (f)
-		   && f->output_data.x->net_wm_state_hidden_seen)
-	    {
-	      SET_FRAME_VISIBLE (f, 0);
-	      SET_FRAME_ICONIFIED (f, 1);
-	      inev.ie.kind = ICONIFY_EVENT;
-	      XSETFRAME (inev.ie.frame_or_window, f);
-	    }
 	}
 
       x_handle_property_notify (&event->xproperty);

bug#18722: Correction

[Titus von der Malsburg]

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


On 2014-10-16 Thu 17:53, Stefan Monnier wrote:
> Can you try the patch below (applied to the latest trunk code) to see if
> your problem is really triggered by this commit?

Yes, this patch seems to solve the problem.

  Titus

>
>
>         Stefan
>
>
> === modified file 'src/xterm.c'
> --- src/xterm.c	2014-10-12 06:09:50 +0000
> +++ src/xterm.c	2014-10-17 00:51:47 +0000
> @@ -6864,14 +6864,6 @@
>  	      inev.ie.kind = DEICONIFY_EVENT;
>  	      XSETFRAME (inev.ie.frame_or_window, f);
>  	    }
> -	  else if (! FRAME_ICONIFIED_P (f)
> -		   && f->output_data.x->net_wm_state_hidden_seen)
> -	    {
> -	      SET_FRAME_VISIBLE (f, 0);
> -	      SET_FRAME_ICONIFIED (f, 1);
> -	      inev.ie.kind = ICONIFY_EVENT;
> -	      XSETFRAME (inev.ie.frame_or_window, f);
> -	    }
>  	}
>  
>        x_handle_property_notify (&event->xproperty);


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

bug#18722: Correction

[martin rudalics]

 >> Ok, I used git bisect as described here:
 >>
 >>    http://git-scm.com/docs/git-bisect
 >>
 >> In every iteration I did the following:
 >>
 >>    make distclean && make clean && ./autogen.sh && ./configure && make && src/emacs -Q
 >>
 >> According to this procedure, the following commit introduced the problem:
 >>
 >>    6fcdb247c460ae52018a970c189969620c959465
 >
 > For those who are not using git, it was this commit:
 >
 > https://lists.gnu.org/archive/html/emacs-diffs/2014-09/msg00085.html

Many thanks for bisecting this.  How comes that (according to Stefan's
later investigation) bisecting was off by one commit here?

martin

bug#18722: Correction

[Stefan Monnier]

> Many thanks for bisecting this.  How comes that (according to Stefan's
> later investigation) bisecting was off by one commit here?

I don't have an answer, but I've seen this kind of off-by-one a few
times already in previous "bisect", so whenever someone tells me he
bisected to some particular revision, I generally assume it might be
another (nearby) revision.


        Stefan

bug#18722: Correction

[Titus von der Malsburg]

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


On 2014-10-17 Fri 02:23, martin rudalics wrote:
> Many thanks for bisecting this.  How comes that (according to Stefan's
> later investigation) bisecting was off by one commit here?

Perhaps I misunderstood how git's bisect feature works.  I finished the
bisection process and then reported the commit at the top of `git log`.

  Titus

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

bug#18722: Correction

[Jan Djärv]

Hi.

17 okt 2014 kl. 06:02 skrev Titus von der Malsburg <malsburg@posteo.de>:

> 
> On 2014-10-16 Thu 17:53, Stefan Monnier wrote:
>> Can you try the patch below (applied to the latest trunk code) to see if
>> your problem is really triggered by this commit?
> 
> Yes, this patch seems to solve the problem.

If it does, your window manager is broken.
What does the window properties look like when Emacs is unresponsive?

	Jan D.

> 
>  Titus
> 
>> 
>> 
>>        Stefan
>> 
>> 
>> === modified file 'src/xterm.c'
>> --- src/xterm.c	2014-10-12 06:09:50 +0000
>> +++ src/xterm.c	2014-10-17 00:51:47 +0000
>> @@ -6864,14 +6864,6 @@
>> 	      inev.ie.kind = DEICONIFY_EVENT;
>> 	      XSETFRAME (inev.ie.frame_or_window, f);
>> 	    }
>> -	  else if (! FRAME_ICONIFIED_P (f)
>> -		   && f->output_data.x->net_wm_state_hidden_seen)
>> -	    {
>> -	      SET_FRAME_VISIBLE (f, 0);
>> -	      SET_FRAME_ICONIFIED (f, 1);
>> -	      inev.ie.kind = ICONIFY_EVENT;
>> -	      XSETFRAME (inev.ie.frame_or_window, f);
>> -	    }
>> 	}
>> 
>>       x_handle_property_notify (&event->xproperty);
> 

bug#18722: Correction

[Titus von der Malsburg]

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


On 2014-10-17 Fri 10:48, Jan Djärv wrote:
> 17 okt 2014 kl. 06:02 skrev Titus von der Malsburg <malsburg@posteo.de>:
>
>> 
>> On 2014-10-16 Thu 17:53, Stefan Monnier wrote:
>>> Can you try the patch below (applied to the latest trunk code) to see if
>>> your problem is really triggered by this commit?
>> 
>> Yes, this patch seems to solve the problem.
>
> If it does, your window manager is broken.
> What does the window properties look like when Emacs is unresponsive?

Here is the output of xprop generated while emacs was unresponsive (I
get the exact same output when Emacs is responsive again):

_NET_WM_USER_TIME(CARDINAL) = 91451195
_MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0
XdndAware(ATOM) = BITMAP
_NET_WM_ICON_GEOMETRY(CARDINAL) = 34, 0, 200, 24
WM_STATE(WM_STATE):
		window state: Normal
		icon window: 0x4607484
_WIN_AREA(CARDINAL) = 0, 0
_WIN_WORKSPACE(CARDINAL) = 0
_WIN_LAYER(CARDINAL) = 4
_WIN_STATE(CARDINAL) = 1
_NET_FRAME_EXTENTS(CARDINAL) = 2, 2, 2, 2
_KDE_NET_WM_FRAME_STRUT(CARDINAL) = 2, 2, 2, 2
_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_STICK
_NET_WM_DESKTOP(CARDINAL) = 4294967295
_NET_WM_STATE(ATOM) = _NET_WM_STATE_STICKY
_NET_WM_ICON_VISIBLE_NAME(UTF8_STRING) = "emacs@montana"
_NET_WM_VISIBLE_NAME(UTF8_STRING) = "emacs@montana"
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: True
		Initial state is Normal State.
		bitmap id # to use for icon: 0x42000bd
		bitmap id # of mask for icon: 0x42000c8
		window id # of group leader: 0x4200001
_NET_WM_OPAQUE_REGION(CARDINAL) = 4, 0, 528, 4, 0, 4, 536, 379
_NET_WM_ICON(CARDINAL) = 	Icon (48 x 48):
	                 ░░░▒▒▒▒▒░░                     
	              ░▒▒▒▒▒▒▒▒▒▒▒▒▒▒░                  
	            ░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒                
	          ░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░              
	         ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░            
	        ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░░░▒▒▒░           
	       ▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░         ░▒▒░          
	      ▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░░░░░░     ░▒▒░         
	     ▒▒▒▒▒▒▒▒▒░     ░░░░░░░░░▒▒     ▒▒▒░        
	    ▒▒▒▒▒▒▒▒▒░               ░      ░▒▒▒        
	   ░▒▒▒▒▒▒▒▒▒░                      ░▒▒▒▒       
	   ▒▒▒▒▒▒▒▒▒▒░                      ░▒▒▒▒░      
	  ░▒▒▒▒▒▒▒▒▒▒░                     ░▒▒▒▒▒▒      
	  ▒▒▒▒▒▒▒▒▒▒░░░     ░░░░░░░░░░░░░░░▒▒▒▒▒▒▒░     
	 ░▒▒▒▒▒▒▒▒▒▒░░░░     ░░░░░░░░░░░▒▒▒▒▒▒▒▒▒▒▒░    
	 ▒▒▒▒▒▒▒▒▒▒▒░░░░░     ░░░░░░░░░░▒▒▒▒▒▒▒▒▒▓░▒    
	 ▒▒▒▒▒▒▒▒▒▒▒▒░░░░░     ░░░░░░░░░▒▒▒▒▒▒▒▒▓░▓▒    
	 ▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░     ░░░░░░░▒▒▒▒▒▒▒▒▓▒▒▓▒    
	░▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░     ░░░░░░▒▒▒▒▒▒▒▒▒▒▒▓▒    
	░▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░    ░░░░▒▒▒▒▒▒▒▒▒░▒▓▓▒    
	▒▒▒▒▒▒▒▒▒▒░░                ░▒▒▒▒▒▒▒▒▒░▒▓▓▒▒    
	▒▒▒▒▒▒▒▒░                    ░▒▒▒▒▒▓▒░▒▓▓▒▒▒    
	▒▒▒▒▒▒▒░                      ░▒▒▒▓▒░▒▓▓▒▒▒▒    
	▒▒▒▒▒▒░               ░░░░░░░░░▒▒▒▒░▒▓▓▒▒▒▒▒    
	▒▒▒▒▒▒           ░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░▒▓▓▓▒▒▒▒▒    
	░▒▒▒▒▒         ░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░▒▓▓▓▒▒▒▒▒▒    
	░▒▒▒▒▒░       ░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▒▒▓▓▓▒▒▒▒▒▒▒    
	 ▒▒▒▒▒▒       ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▒▒▓▓▓▒▒▒▒▒▒▒░    
	 ▒▒▒▒▒▒░       ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▒▒▓▓▓▒▒▒▒▒▒▒▒░    
	 ░▒▒▒▒▒▒▒       ░▒▒▒▒░░░▒▒▒▒▓▒▒▓▓▓▒▒▒▒▒▒▒▒▒     
	 ░▒▒▒▒▒▒▒▒        ░░░░░░░░░▒▓▒▓▓▓▒▒▒▒▒▒▒▒▒▒     
	  ▒▒▒▒▒▒▒▒▒░         ░░░░░▒▓▒▓▓▓▓▒▒▒▒▒▒▒▒▒░     
	  ░▒▒▒▒▒▒▒▒▒▒░           ░▓▒▓▓▓▓▒▒▒▒▒▒▒▒▒▒      
	   ▒▒▒▒▒▒▒▒▒▒▒▒░         ▓▓▓▓▓▓▒▒▒▒▒▒▒▒▒▒░      
	   ░▒▒▒▒▒▒▒▒▒▒▒▒░░░     ▒▓▓▓▓▒  ░▒▒▒▒▒▒▒░       
	    ░▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░░▓▓▓▓▒    ░▒▒▒▒▒▒        
	     ▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░▓░▓▓▒      ▒▒▒▒▒         
	      ▒▒▒▒▒▒░░        ▓▓▓▒▒      ░▒▒▒▒░         
	       ▒▒▒▒▒▒▒▒▒▒▒░░░▒▓▓▓▓░░░░▒▒▒▒▒▒▒░          
	        ▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒░           
	         ░▒▒▒▒▒▒▒▒▒▒▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒             
	         ░░▒▒▒▒▒▒▒▒▓▓▓▓▒▒▒▒▒▒▒▒▒▒░░             
	      ░░░░░░▒▒▒▒▒▒▒▓▓▓▒▒▒▒▒▒▒▒▒▒░░░░░           
	      ░░░░░▒▒▒▒▒▒▒▓▓▓▒▒▒▒▒▒▒▒▒▒▒░░░░░░          
	       ░░░░░░▒▒▒▒▒▓▓▒▒▒▒▒▒▒▒▒▒▒░░░░░░           
	          ░░░░░░░▒▒░░░░░░░░░░░░░░░              
	                                                
	                                                


_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 69206193, 69206194
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x42000b0
WM_CLIENT_LEADER(WINDOW): window id # 0x4200001
_NET_WM_PID(CARDINAL) = 17694
WM_LOCALE_NAME(STRING) = "en_US.UTF-8"
WM_CLIENT_MACHINE(STRING) = "montana"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		program specified minimum size: 41 by 79
		program specified resize increment: 9 by 19
		program specified base size: 41 by 79
		window gravity: NorthWest
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_CLASS(STRING) = "emacs", "Emacs"
WM_ICON_NAME(STRING) = "emacs@montana"
_NET_WM_ICON_NAME(UTF8_STRING) = "emacs@montana"
WM_NAME(STRING) = "emacs@montana"
_NET_WM_NAME(UTF8_STRING) = "emacs@montana"

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

bug#18722: Correction

[Jan Djärv]

Hi.
17 okt 2014 kl. 20:14 skrev Titus von der Malsburg <malsburg@posteo.de>:

> 
> On 2014-10-17 Fri 10:48, Jan Djärv wrote:
>> 17 okt 2014 kl. 06:02 skrev Titus von der Malsburg <malsburg@posteo.de>:
>> 
>>> 
>>> On 2014-10-16 Thu 17:53, Stefan Monnier wrote:
>>>> Can you try the patch below (applied to the latest trunk code) to see if
>>>> your problem is really triggered by this commit?
>>> 
>>> Yes, this patch seems to solve the problem.
>> 
>> If it does, your window manager is broken.
>> What does the window properties look like when Emacs is unresponsive?
> 
> Here is the output of xprop generated while emacs was unresponsive (I
> get the exact same output when Emacs is responsive again):

Thanks.  It looks like we might have a bug here.  I will check it.

	Jan D.


> 
> _NET_WM_USER_TIME(CARDINAL) = 91451195
> _MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0
> XdndAware(ATOM) = BITMAP
> _NET_WM_ICON_GEOMETRY(CARDINAL) = 34, 0, 200, 24
> WM_STATE(WM_STATE):
> 		window state: Normal
> 		icon window: 0x4607484
> _WIN_AREA(CARDINAL) = 0, 0
> _WIN_WORKSPACE(CARDINAL) = 0
> _WIN_LAYER(CARDINAL) = 4
> _WIN_STATE(CARDINAL) = 1
> _NET_FRAME_EXTENTS(CARDINAL) = 2, 2, 2, 2
> _KDE_NET_WM_FRAME_STRUT(CARDINAL) = 2, 2, 2, 2
> _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_STICK
> _NET_WM_DESKTOP(CARDINAL) = 4294967295
> _NET_WM_STATE(ATOM) = _NET_WM_STATE_STICKY
> _NET_WM_ICON_VISIBLE_NAME(UTF8_STRING) = "emacs@montana"
> _NET_WM_VISIBLE_NAME(UTF8_STRING) = "emacs@montana"
> WM_HINTS(WM_HINTS):
> 		Client accepts input or input focus: True
> 		Initial state is Normal State.
> 		bitmap id # to use for icon: 0x42000bd
> 		bitmap id # of mask for icon: 0x42000c8
> 		window id # of group leader: 0x4200001
> _NET_WM_OPAQUE_REGION(CARDINAL) = 4, 0, 528, 4, 0, 4, 536, 379
> _NET_WM_ICON(CARDINAL) = 	Icon (48 x 48):
> 	                 ░░░▒▒▒▒▒░░                     
> 	              ░▒▒▒▒▒▒▒▒▒▒▒▒▒▒░                  
> 	            ░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒                
> 	          ░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░              
> 	         ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░            
> 	        ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░░░▒▒▒░           
> 	       ▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░         ░▒▒░          
> 	      ▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░░░░░░     ░▒▒░         
> 	     ▒▒▒▒▒▒▒▒▒░     ░░░░░░░░░▒▒     ▒▒▒░        
> 	    ▒▒▒▒▒▒▒▒▒░               ░      ░▒▒▒        
> 	   ░▒▒▒▒▒▒▒▒▒░                      ░▒▒▒▒       
> 	   ▒▒▒▒▒▒▒▒▒▒░                      ░▒▒▒▒░      
> 	  ░▒▒▒▒▒▒▒▒▒▒░                     ░▒▒▒▒▒▒      
> 	  ▒▒▒▒▒▒▒▒▒▒░░░     ░░░░░░░░░░░░░░░▒▒▒▒▒▒▒░     
> 	 ░▒▒▒▒▒▒▒▒▒▒░░░░     ░░░░░░░░░░░▒▒▒▒▒▒▒▒▒▒▒░    
> 	 ▒▒▒▒▒▒▒▒▒▒▒░░░░░     ░░░░░░░░░░▒▒▒▒▒▒▒▒▒▓░▒    
> 	 ▒▒▒▒▒▒▒▒▒▒▒▒░░░░░     ░░░░░░░░░▒▒▒▒▒▒▒▒▓░▓▒    
> 	 ▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░     ░░░░░░░▒▒▒▒▒▒▒▒▓▒▒▓▒    
> 	░▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░     ░░░░░░▒▒▒▒▒▒▒▒▒▒▒▓▒    
> 	░▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░    ░░░░▒▒▒▒▒▒▒▒▒░▒▓▓▒    
> 	▒▒▒▒▒▒▒▒▒▒░░                ░▒▒▒▒▒▒▒▒▒░▒▓▓▒▒    
> 	▒▒▒▒▒▒▒▒░                    ░▒▒▒▒▒▓▒░▒▓▓▒▒▒    
> 	▒▒▒▒▒▒▒░                      ░▒▒▒▓▒░▒▓▓▒▒▒▒    
> 	▒▒▒▒▒▒░               ░░░░░░░░░▒▒▒▒░▒▓▓▒▒▒▒▒    
> 	▒▒▒▒▒▒           ░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░▒▓▓▓▒▒▒▒▒    
> 	░▒▒▒▒▒         ░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░▒▓▓▓▒▒▒▒▒▒    
> 	░▒▒▒▒▒░       ░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▒▒▓▓▓▒▒▒▒▒▒▒    
> 	 ▒▒▒▒▒▒       ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▒▒▓▓▓▒▒▒▒▒▒▒░    
> 	 ▒▒▒▒▒▒░       ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▒▒▓▓▓▒▒▒▒▒▒▒▒░    
> 	 ░▒▒▒▒▒▒▒       ░▒▒▒▒░░░▒▒▒▒▓▒▒▓▓▓▒▒▒▒▒▒▒▒▒     
> 	 ░▒▒▒▒▒▒▒▒        ░░░░░░░░░▒▓▒▓▓▓▒▒▒▒▒▒▒▒▒▒     
> 	  ▒▒▒▒▒▒▒▒▒░         ░░░░░▒▓▒▓▓▓▓▒▒▒▒▒▒▒▒▒░     
> 	  ░▒▒▒▒▒▒▒▒▒▒░           ░▓▒▓▓▓▓▒▒▒▒▒▒▒▒▒▒      
> 	   ▒▒▒▒▒▒▒▒▒▒▒▒░         ▓▓▓▓▓▓▒▒▒▒▒▒▒▒▒▒░      
> 	   ░▒▒▒▒▒▒▒▒▒▒▒▒░░░     ▒▓▓▓▓▒  ░▒▒▒▒▒▒▒░       
> 	    ░▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░░▓▓▓▓▒    ░▒▒▒▒▒▒        
> 	     ▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░▓░▓▓▒      ▒▒▒▒▒         
> 	      ▒▒▒▒▒▒░░        ▓▓▓▒▒      ░▒▒▒▒░         
> 	       ▒▒▒▒▒▒▒▒▒▒▒░░░▒▓▓▓▓░░░░▒▒▒▒▒▒▒░          
> 	        ▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒░           
> 	         ░▒▒▒▒▒▒▒▒▒▒▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒             
> 	         ░░▒▒▒▒▒▒▒▒▓▓▓▓▒▒▒▒▒▒▒▒▒▒░░             
> 	      ░░░░░░▒▒▒▒▒▒▒▓▓▓▒▒▒▒▒▒▒▒▒▒░░░░░           
> 	      ░░░░░▒▒▒▒▒▒▒▓▓▓▒▒▒▒▒▒▒▒▒▒▒░░░░░░          
> 	       ░░░░░░▒▒▒▒▒▓▓▒▒▒▒▒▒▒▒▒▒▒░░░░░░           
> 	          ░░░░░░░▒▒░░░░░░░░░░░░░░░              
> 	                                                
> 	                                                
> 
> 
> _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
> _NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 69206193, 69206194
> _NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x42000b0
> WM_CLIENT_LEADER(WINDOW): window id # 0x4200001
> _NET_WM_PID(CARDINAL) = 17694
> WM_LOCALE_NAME(STRING) = "en_US.UTF-8"
> WM_CLIENT_MACHINE(STRING) = "montana"
> WM_NORMAL_HINTS(WM_SIZE_HINTS):
> 		program specified minimum size: 41 by 79
> 		program specified resize increment: 9 by 19
> 		program specified base size: 41 by 79
> 		window gravity: NorthWest
> WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
> WM_CLASS(STRING) = "emacs", "Emacs"
> WM_ICON_NAME(STRING) = "emacs@montana"
> _NET_WM_ICON_NAME(UTF8_STRING) = "emacs@montana"
> WM_NAME(STRING) = "emacs@montana"
> _NET_WM_NAME(UTF8_STRING) = "emacs@montana"

bug#18722: Correction

[Jan Djärv]

Hello.

I tried Ubuntu 14.04 and dvwm2 but I could not get the error you see.
However, I have reworked the code a bit. Please try it.

Thanks,

	Jan D.

Den 2014-10-18 14:31, Jan Djärv skrev:
> Hi.
> 17 okt 2014 kl. 20:14 skrev Titus von der Malsburg <malsburg@posteo.de>:
>
>>
>> On 2014-10-17 Fri 10:48, Jan Djärv wrote:
>>> 17 okt 2014 kl. 06:02 skrev Titus von der Malsburg <malsburg@posteo.de>:
>>>
>>>>
>>>> On 2014-10-16 Thu 17:53, Stefan Monnier wrote:
>>>>> Can you try the patch below (applied to the latest trunk code) to see if
>>>>> your problem is really triggered by this commit?
>>>>
>>>> Yes, this patch seems to solve the problem.
>>>
>>> If it does, your window manager is broken.
>>> What does the window properties look like when Emacs is unresponsive?
>>
>> Here is the output of xprop generated while emacs was unresponsive (I
>> get the exact same output when Emacs is responsive again):
>
> Thanks.  It looks like we might have a bug here.  I will check it.
>
> 	Jan D.
>
>
>>
>> _NET_WM_USER_TIME(CARDINAL) = 91451195
>> _MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0
>> XdndAware(ATOM) = BITMAP
>> _NET_WM_ICON_GEOMETRY(CARDINAL) = 34, 0, 200, 24
>> WM_STATE(WM_STATE):
>> 		window state: Normal
>> 		icon window: 0x4607484
>> _WIN_AREA(CARDINAL) = 0, 0
>> _WIN_WORKSPACE(CARDINAL) = 0
>> _WIN_LAYER(CARDINAL) = 4
>> _WIN_STATE(CARDINAL) = 1
>> _NET_FRAME_EXTENTS(CARDINAL) = 2, 2, 2, 2
>> _KDE_NET_WM_FRAME_STRUT(CARDINAL) = 2, 2, 2, 2
>> _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_STICK
>> _NET_WM_DESKTOP(CARDINAL) = 4294967295
>> _NET_WM_STATE(ATOM) = _NET_WM_STATE_STICKY
>> _NET_WM_ICON_VISIBLE_NAME(UTF8_STRING) = "emacs@montana"
>> _NET_WM_VISIBLE_NAME(UTF8_STRING) = "emacs@montana"
>> WM_HINTS(WM_HINTS):
>> 		Client accepts input or input focus: True
>> 		Initial state is Normal State.
>> 		bitmap id # to use for icon: 0x42000bd
>> 		bitmap id # of mask for icon: 0x42000c8
>> 		window id # of group leader: 0x4200001
>> _NET_WM_OPAQUE_REGION(CARDINAL) = 4, 0, 528, 4, 0, 4, 536, 379
>> _NET_WM_ICON(CARDINAL) = 	Icon (48 x 48):
>> 	                 ░░░▒▒▒▒▒░░
>> 	              ░▒▒▒▒▒▒▒▒▒▒▒▒▒▒░
>> 	            ░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
>> 	          ░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░
>> 	         ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░
>> 	        ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░░░▒▒▒░
>> 	       ▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░         ░▒▒░
>> 	      ▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░░░░░░     ░▒▒░
>> 	     ▒▒▒▒▒▒▒▒▒░     ░░░░░░░░░▒▒     ▒▒▒░
>> 	    ▒▒▒▒▒▒▒▒▒░               ░      ░▒▒▒
>> 	   ░▒▒▒▒▒▒▒▒▒░                      ░▒▒▒▒
>> 	   ▒▒▒▒▒▒▒▒▒▒░                      ░▒▒▒▒░
>> 	  ░▒▒▒▒▒▒▒▒▒▒░                     ░▒▒▒▒▒▒
>> 	  ▒▒▒▒▒▒▒▒▒▒░░░     ░░░░░░░░░░░░░░░▒▒▒▒▒▒▒░
>> 	 ░▒▒▒▒▒▒▒▒▒▒░░░░     ░░░░░░░░░░░▒▒▒▒▒▒▒▒▒▒▒░
>> 	 ▒▒▒▒▒▒▒▒▒▒▒░░░░░     ░░░░░░░░░░▒▒▒▒▒▒▒▒▒▓░▒
>> 	 ▒▒▒▒▒▒▒▒▒▒▒▒░░░░░     ░░░░░░░░░▒▒▒▒▒▒▒▒▓░▓▒
>> 	 ▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░     ░░░░░░░▒▒▒▒▒▒▒▒▓▒▒▓▒
>> 	░▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░     ░░░░░░▒▒▒▒▒▒▒▒▒▒▒▓▒
>> 	░▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░    ░░░░▒▒▒▒▒▒▒▒▒░▒▓▓▒
>> 	▒▒▒▒▒▒▒▒▒▒░░                ░▒▒▒▒▒▒▒▒▒░▒▓▓▒▒
>> 	▒▒▒▒▒▒▒▒░                    ░▒▒▒▒▒▓▒░▒▓▓▒▒▒
>> 	▒▒▒▒▒▒▒░                      ░▒▒▒▓▒░▒▓▓▒▒▒▒
>> 	▒▒▒▒▒▒░               ░░░░░░░░░▒▒▒▒░▒▓▓▒▒▒▒▒
>> 	▒▒▒▒▒▒           ░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░▒▓▓▓▒▒▒▒▒
>> 	░▒▒▒▒▒         ░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░▒▓▓▓▒▒▒▒▒▒
>> 	░▒▒▒▒▒░       ░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▒▒▓▓▓▒▒▒▒▒▒▒
>> 	 ▒▒▒▒▒▒       ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▒▒▓▓▓▒▒▒▒▒▒▒░
>> 	 ▒▒▒▒▒▒░       ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▒▒▓▓▓▒▒▒▒▒▒▒▒░
>> 	 ░▒▒▒▒▒▒▒       ░▒▒▒▒░░░▒▒▒▒▓▒▒▓▓▓▒▒▒▒▒▒▒▒▒
>> 	 ░▒▒▒▒▒▒▒▒        ░░░░░░░░░▒▓▒▓▓▓▒▒▒▒▒▒▒▒▒▒
>> 	  ▒▒▒▒▒▒▒▒▒░         ░░░░░▒▓▒▓▓▓▓▒▒▒▒▒▒▒▒▒░
>> 	  ░▒▒▒▒▒▒▒▒▒▒░           ░▓▒▓▓▓▓▒▒▒▒▒▒▒▒▒▒
>> 	   ▒▒▒▒▒▒▒▒▒▒▒▒░         ▓▓▓▓▓▓▒▒▒▒▒▒▒▒▒▒░
>> 	   ░▒▒▒▒▒▒▒▒▒▒▒▒░░░     ▒▓▓▓▓▒  ░▒▒▒▒▒▒▒░
>> 	    ░▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░░▓▓▓▓▒    ░▒▒▒▒▒▒
>> 	     ▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░▓░▓▓▒      ▒▒▒▒▒
>> 	      ▒▒▒▒▒▒░░        ▓▓▓▒▒      ░▒▒▒▒░
>> 	       ▒▒▒▒▒▒▒▒▒▒▒░░░▒▓▓▓▓░░░░▒▒▒▒▒▒▒░
>> 	        ▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒░
>> 	         ░▒▒▒▒▒▒▒▒▒▒▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒
>> 	         ░░▒▒▒▒▒▒▒▒▓▓▓▓▒▒▒▒▒▒▒▒▒▒░░
>> 	      ░░░░░░▒▒▒▒▒▒▒▓▓▓▒▒▒▒▒▒▒▒▒▒░░░░░
>> 	      ░░░░░▒▒▒▒▒▒▒▓▓▓▒▒▒▒▒▒▒▒▒▒▒░░░░░░
>> 	       ░░░░░░▒▒▒▒▒▓▓▒▒▒▒▒▒▒▒▒▒▒░░░░░░
>> 	          ░░░░░░░▒▒░░░░░░░░░░░░░░░
>> 	
>> 	
>>
>>
>> _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
>> _NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 69206193, 69206194
>> _NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x42000b0
>> WM_CLIENT_LEADER(WINDOW): window id # 0x4200001
>> _NET_WM_PID(CARDINAL) = 17694
>> WM_LOCALE_NAME(STRING) = "en_US.UTF-8"
>> WM_CLIENT_MACHINE(STRING) = "montana"
>> WM_NORMAL_HINTS(WM_SIZE_HINTS):
>> 		program specified minimum size: 41 by 79
>> 		program specified resize increment: 9 by 19
>> 		program specified base size: 41 by 79
>> 		window gravity: NorthWest
>> WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
>> WM_CLASS(STRING) = "emacs", "Emacs"
>> WM_ICON_NAME(STRING) = "emacs@montana"
>> _NET_WM_ICON_NAME(UTF8_STRING) = "emacs@montana"
>> WM_NAME(STRING) = "emacs@montana"
>> _NET_WM_NAME(UTF8_STRING) = "emacs@montana"
>
>
>

bug#18722: Correction

[Titus von der Malsburg]

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


On 2014-10-19 Sun 10:09, Jan Djärv wrote:
> Hello.
>
> I tried Ubuntu 14.04 and dvwm2 but I could not get the error you see.
> However, I have reworked the code a bit. Please try it.

In the latest version, I can't reproduce the problem.

Thank you for fixing this.

  Titus

>
> Thanks,
>
> 	Jan D.
>
> Den 2014-10-18 14:31, Jan Djärv skrev:
>> Hi.
>> 17 okt 2014 kl. 20:14 skrev Titus von der Malsburg <malsburg@posteo.de>:
>>
>>>
>>> On 2014-10-17 Fri 10:48, Jan Djärv wrote:
>>>> 17 okt 2014 kl. 06:02 skrev Titus von der Malsburg <malsburg@posteo.de>:
>>>>
>>>>>
>>>>> On 2014-10-16 Thu 17:53, Stefan Monnier wrote:
>>>>>> Can you try the patch below (applied to the latest trunk code) to see if
>>>>>> your problem is really triggered by this commit?
>>>>>
>>>>> Yes, this patch seems to solve the problem.
>>>>
>>>> If it does, your window manager is broken.
>>>> What does the window properties look like when Emacs is unresponsive?
>>>
>>> Here is the output of xprop generated while emacs was unresponsive (I
>>> get the exact same output when Emacs is responsive again):
>>
>> Thanks.  It looks like we might have a bug here.  I will check it.
>>
>> 	Jan D.
>>
>>
>>>
>>> _NET_WM_USER_TIME(CARDINAL) = 91451195
>>> _MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0
>>> XdndAware(ATOM) = BITMAP
>>> _NET_WM_ICON_GEOMETRY(CARDINAL) = 34, 0, 200, 24
>>> WM_STATE(WM_STATE):
>>> 		window state: Normal
>>> 		icon window: 0x4607484
>>> _WIN_AREA(CARDINAL) = 0, 0
>>> _WIN_WORKSPACE(CARDINAL) = 0
>>> _WIN_LAYER(CARDINAL) = 4
>>> _WIN_STATE(CARDINAL) = 1
>>> _NET_FRAME_EXTENTS(CARDINAL) = 2, 2, 2, 2
>>> _KDE_NET_WM_FRAME_STRUT(CARDINAL) = 2, 2, 2, 2
>>> _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_STICK
>>> _NET_WM_DESKTOP(CARDINAL) = 4294967295
>>> _NET_WM_STATE(ATOM) = _NET_WM_STATE_STICKY
>>> _NET_WM_ICON_VISIBLE_NAME(UTF8_STRING) = "emacs@montana"
>>> _NET_WM_VISIBLE_NAME(UTF8_STRING) = "emacs@montana"
>>> WM_HINTS(WM_HINTS):
>>> 		Client accepts input or input focus: True
>>> 		Initial state is Normal State.
>>> 		bitmap id # to use for icon: 0x42000bd
>>> 		bitmap id # of mask for icon: 0x42000c8
>>> 		window id # of group leader: 0x4200001
>>> _NET_WM_OPAQUE_REGION(CARDINAL) = 4, 0, 528, 4, 0, 4, 536, 379
>>> _NET_WM_ICON(CARDINAL) = 	Icon (48 x 48):
>>> 	                 ░░░▒▒▒▒▒░░
>>> 	              ░▒▒▒▒▒▒▒▒▒▒▒▒▒▒░
>>> 	            ░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
>>> 	          ░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░
>>> 	         ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░
>>> 	        ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░░░▒▒▒░
>>> 	       ▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░         ░▒▒░
>>> 	      ▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░░░░░░     ░▒▒░
>>> 	     ▒▒▒▒▒▒▒▒▒░     ░░░░░░░░░▒▒     ▒▒▒░
>>> 	    ▒▒▒▒▒▒▒▒▒░               ░      ░▒▒▒
>>> 	   ░▒▒▒▒▒▒▒▒▒░                      ░▒▒▒▒
>>> 	   ▒▒▒▒▒▒▒▒▒▒░                      ░▒▒▒▒░
>>> 	  ░▒▒▒▒▒▒▒▒▒▒░                     ░▒▒▒▒▒▒
>>> 	  ▒▒▒▒▒▒▒▒▒▒░░░     ░░░░░░░░░░░░░░░▒▒▒▒▒▒▒░
>>> 	 ░▒▒▒▒▒▒▒▒▒▒░░░░     ░░░░░░░░░░░▒▒▒▒▒▒▒▒▒▒▒░
>>> 	 ▒▒▒▒▒▒▒▒▒▒▒░░░░░     ░░░░░░░░░░▒▒▒▒▒▒▒▒▒▓░▒
>>> 	 ▒▒▒▒▒▒▒▒▒▒▒▒░░░░░     ░░░░░░░░░▒▒▒▒▒▒▒▒▓░▓▒
>>> 	 ▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░     ░░░░░░░▒▒▒▒▒▒▒▒▓▒▒▓▒
>>> 	░▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░     ░░░░░░▒▒▒▒▒▒▒▒▒▒▒▓▒
>>> 	░▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░    ░░░░▒▒▒▒▒▒▒▒▒░▒▓▓▒
>>> 	▒▒▒▒▒▒▒▒▒▒░░                ░▒▒▒▒▒▒▒▒▒░▒▓▓▒▒
>>> 	▒▒▒▒▒▒▒▒░                    ░▒▒▒▒▒▓▒░▒▓▓▒▒▒
>>> 	▒▒▒▒▒▒▒░                      ░▒▒▒▓▒░▒▓▓▒▒▒▒
>>> 	▒▒▒▒▒▒░               ░░░░░░░░░▒▒▒▒░▒▓▓▒▒▒▒▒
>>> 	▒▒▒▒▒▒           ░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░▒▓▓▓▒▒▒▒▒
>>> 	░▒▒▒▒▒         ░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░▒▓▓▓▒▒▒▒▒▒
>>> 	░▒▒▒▒▒░       ░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▒▒▓▓▓▒▒▒▒▒▒▒
>>> 	 ▒▒▒▒▒▒       ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▒▒▓▓▓▒▒▒▒▒▒▒░
>>> 	 ▒▒▒▒▒▒░       ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▒▒▓▓▓▒▒▒▒▒▒▒▒░
>>> 	 ░▒▒▒▒▒▒▒       ░▒▒▒▒░░░▒▒▒▒▓▒▒▓▓▓▒▒▒▒▒▒▒▒▒
>>> 	 ░▒▒▒▒▒▒▒▒        ░░░░░░░░░▒▓▒▓▓▓▒▒▒▒▒▒▒▒▒▒
>>> 	  ▒▒▒▒▒▒▒▒▒░         ░░░░░▒▓▒▓▓▓▓▒▒▒▒▒▒▒▒▒░
>>> 	  ░▒▒▒▒▒▒▒▒▒▒░           ░▓▒▓▓▓▓▒▒▒▒▒▒▒▒▒▒
>>> 	   ▒▒▒▒▒▒▒▒▒▒▒▒░         ▓▓▓▓▓▓▒▒▒▒▒▒▒▒▒▒░
>>> 	   ░▒▒▒▒▒▒▒▒▒▒▒▒░░░     ▒▓▓▓▓▒  ░▒▒▒▒▒▒▒░
>>> 	    ░▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░░▓▓▓▓▒    ░▒▒▒▒▒▒
>>> 	     ▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░▓░▓▓▒      ▒▒▒▒▒
>>> 	      ▒▒▒▒▒▒░░        ▓▓▓▒▒      ░▒▒▒▒░
>>> 	       ▒▒▒▒▒▒▒▒▒▒▒░░░▒▓▓▓▓░░░░▒▒▒▒▒▒▒░
>>> 	        ▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒░
>>> 	         ░▒▒▒▒▒▒▒▒▒▒▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒
>>> 	         ░░▒▒▒▒▒▒▒▒▓▓▓▓▒▒▒▒▒▒▒▒▒▒░░
>>> 	      ░░░░░░▒▒▒▒▒▒▒▓▓▓▒▒▒▒▒▒▒▒▒▒░░░░░
>>> 	      ░░░░░▒▒▒▒▒▒▒▓▓▓▒▒▒▒▒▒▒▒▒▒▒░░░░░░
>>> 	       ░░░░░░▒▒▒▒▒▓▓▒▒▒▒▒▒▒▒▒▒▒░░░░░░
>>> 	          ░░░░░░░▒▒░░░░░░░░░░░░░░░
>>> 	
>>> 	
>>>
>>>
>>> _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
>>> _NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 69206193, 69206194
>>> _NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x42000b0
>>> WM_CLIENT_LEADER(WINDOW): window id # 0x4200001
>>> _NET_WM_PID(CARDINAL) = 17694
>>> WM_LOCALE_NAME(STRING) = "en_US.UTF-8"
>>> WM_CLIENT_MACHINE(STRING) = "montana"
>>> WM_NORMAL_HINTS(WM_SIZE_HINTS):
>>> 		program specified minimum size: 41 by 79
>>> 		program specified resize increment: 9 by 19
>>> 		program specified base size: 41 by 79
>>> 		window gravity: NorthWest
>>> WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
>>> WM_CLASS(STRING) = "emacs", "Emacs"
>>> WM_ICON_NAME(STRING) = "emacs@montana"
>>> _NET_WM_ICON_NAME(UTF8_STRING) = "emacs@montana"
>>> WM_NAME(STRING) = "emacs@montana"
>>> _NET_WM_NAME(UTF8_STRING) = "emacs@montana"
>>
>>
>>


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

bug#18722: Correction

[Jan Djärv]

Hi.

> 19 okt 2014 kl. 20:05 skrev Titus von der Malsburg <malsburg@posteo.de>:
> 
> 
> On 2014-10-19 Sun 10:09, Jan Djärv wrote:
>> Hello.
>> 
>> I tried Ubuntu 14.04 and dvwm2 but I could not get the error you see.
>> However, I have reworked the code a bit. Please try it.
> 
> In the latest version, I can't reproduce the problem.

Great, closing.

Thansk for testing.

	Jan D.