* bug#18722: 25.0.50; UI partly unresponsive after re-focus of Emacs' window. @ 2014-10-14 20:24 Titus von der Malsburg 2014-10-15 21:41 ` bug#18722: Correction Titus von der Malsburg 0 siblings, 1 reply; 27+ messages in thread From: Titus von der Malsburg @ 2014-10-14 20:24 UTC (permalink / raw) To: 18722 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)) ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#18722: Correction 2014-10-14 20:24 bug#18722: 25.0.50; UI partly unresponsive after re-focus of Emacs' window Titus von der Malsburg @ 2014-10-15 21:41 ` Titus von der Malsburg 2014-10-16 8:52 ` martin rudalics 0 siblings, 1 reply; 27+ messages in thread From: Titus von der Malsburg @ 2014-10-15 21:41 UTC (permalink / raw) To: 18722 [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#18722: Correction 2014-10-15 21:41 ` bug#18722: Correction Titus von der Malsburg @ 2014-10-16 8:52 ` martin rudalics 2014-10-16 10:04 ` Eli Zaretskii 0 siblings, 1 reply; 27+ messages in thread From: martin rudalics @ 2014-10-16 8:52 UTC (permalink / raw) To: Titus von der Malsburg, 18722 > 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#18722: Correction 2014-10-16 8:52 ` martin rudalics @ 2014-10-16 10:04 ` Eli Zaretskii 2014-10-16 11:41 ` martin rudalics 2014-10-16 14:46 ` Titus von der Malsburg 0 siblings, 2 replies; 27+ messages in thread From: Eli Zaretskii @ 2014-10-16 10:04 UTC (permalink / raw) To: martin rudalics; +Cc: malsburg, 18722 > 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? ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#18722: Correction 2014-10-16 10:04 ` Eli Zaretskii @ 2014-10-16 11:41 ` martin rudalics 2014-10-16 12:04 ` Eli Zaretskii 2014-10-16 15:16 ` Titus von der Malsburg 2014-10-16 14:46 ` Titus von der Malsburg 1 sibling, 2 replies; 27+ messages in thread From: martin rudalics @ 2014-10-16 11:41 UTC (permalink / raw) To: Eli Zaretskii; +Cc: malsburg, 18722 >> 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#18722: Correction 2014-10-16 11:41 ` martin rudalics @ 2014-10-16 12:04 ` Eli Zaretskii 2014-10-16 15:16 ` Titus von der Malsburg 1 sibling, 0 replies; 27+ messages in thread From: Eli Zaretskii @ 2014-10-16 12:04 UTC (permalink / raw) To: martin rudalics; +Cc: malsburg, 18722 > 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? ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#18722: Correction 2014-10-16 11:41 ` martin rudalics 2014-10-16 12:04 ` Eli Zaretskii @ 2014-10-16 15:16 ` Titus von der Malsburg 1 sibling, 0 replies; 27+ messages in thread From: Titus von der Malsburg @ 2014-10-16 15:16 UTC (permalink / raw) To: martin rudalics; +Cc: 18722 [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#18722: Correction 2014-10-16 10:04 ` Eli Zaretskii 2014-10-16 11:41 ` martin rudalics @ 2014-10-16 14:46 ` Titus von der Malsburg 2014-10-16 14:54 ` Eli Zaretskii 2014-10-16 16:07 ` Stefan Monnier 1 sibling, 2 replies; 27+ messages in thread From: Titus von der Malsburg @ 2014-10-16 14:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 18722 [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#18722: Correction 2014-10-16 14:46 ` Titus von der Malsburg @ 2014-10-16 14:54 ` Eli Zaretskii 2014-10-16 15:10 ` Titus von der Malsburg 2014-10-16 16:07 ` Stefan Monnier 1 sibling, 1 reply; 27+ messages in thread From: Eli Zaretskii @ 2014-10-16 14:54 UTC (permalink / raw) To: Titus von der Malsburg; +Cc: 18722 > 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#18722: Correction 2014-10-16 14:54 ` Eli Zaretskii @ 2014-10-16 15:10 ` Titus von der Malsburg 2014-10-16 15:34 ` Eli Zaretskii 0 siblings, 1 reply; 27+ messages in thread From: Titus von der Malsburg @ 2014-10-16 15:10 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 18722 [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#18722: Correction 2014-10-16 15:10 ` Titus von der Malsburg @ 2014-10-16 15:34 ` Eli Zaretskii 2014-10-16 15:55 ` Titus von der Malsburg 2014-10-16 21:17 ` Titus von der Malsburg 0 siblings, 2 replies; 27+ messages in thread From: Eli Zaretskii @ 2014-10-16 15:34 UTC (permalink / raw) To: Titus von der Malsburg; +Cc: 18722 > 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#18722: Correction 2014-10-16 15:34 ` Eli Zaretskii @ 2014-10-16 15:55 ` Titus von der Malsburg 2014-10-16 21:17 ` Titus von der Malsburg 1 sibling, 0 replies; 27+ messages in thread From: Titus von der Malsburg @ 2014-10-16 15:55 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 18722 [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#18722: Correction 2014-10-16 15:34 ` Eli Zaretskii 2014-10-16 15:55 ` Titus von der Malsburg @ 2014-10-16 21:17 ` Titus von der Malsburg 2014-10-16 22:31 ` Titus von der Malsburg 1 sibling, 1 reply; 27+ messages in thread From: Titus von der Malsburg @ 2014-10-16 21:17 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 18722 [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#18722: Correction 2014-10-16 21:17 ` Titus von der Malsburg @ 2014-10-16 22:31 ` Titus von der Malsburg 2014-10-17 0:53 ` Stefan Monnier 2014-10-17 9:23 ` martin rudalics 0 siblings, 2 replies; 27+ messages in thread From: Titus von der Malsburg @ 2014-10-16 22:31 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 18722 [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#18722: Correction 2014-10-16 22:31 ` Titus von der Malsburg @ 2014-10-17 0:53 ` Stefan Monnier 2014-10-17 4:02 ` Titus von der Malsburg 2014-10-17 9:23 ` martin rudalics 1 sibling, 1 reply; 27+ messages in thread From: Stefan Monnier @ 2014-10-17 0:53 UTC (permalink / raw) To: Titus von der Malsburg; +Cc: 18722 > 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); ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#18722: Correction 2014-10-17 0:53 ` Stefan Monnier @ 2014-10-17 4:02 ` Titus von der Malsburg 2014-10-17 17:48 ` Jan Djärv 0 siblings, 1 reply; 27+ messages in thread From: Titus von der Malsburg @ 2014-10-17 4:02 UTC (permalink / raw) To: Stefan Monnier; +Cc: 18722 [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#18722: Correction 2014-10-17 4:02 ` Titus von der Malsburg @ 2014-10-17 17:48 ` Jan Djärv 2014-10-17 18:14 ` Titus von der Malsburg 0 siblings, 1 reply; 27+ messages in thread From: Jan Djärv @ 2014-10-17 17:48 UTC (permalink / raw) To: Titus von der Malsburg; +Cc: 18722 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); > ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#18722: Correction 2014-10-17 17:48 ` Jan Djärv @ 2014-10-17 18:14 ` Titus von der Malsburg 2014-10-18 12:31 ` Jan Djärv 0 siblings, 1 reply; 27+ messages in thread From: Titus von der Malsburg @ 2014-10-17 18:14 UTC (permalink / raw) To: Jan Djärv; +Cc: 18722 [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#18722: Correction 2014-10-17 18:14 ` Titus von der Malsburg @ 2014-10-18 12:31 ` Jan Djärv 2014-10-19 17:09 ` Jan Djärv 0 siblings, 1 reply; 27+ messages in thread From: Jan Djärv @ 2014-10-18 12:31 UTC (permalink / raw) To: Titus von der Malsburg; +Cc: 18722 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" ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#18722: Correction 2014-10-18 12:31 ` Jan Djärv @ 2014-10-19 17:09 ` Jan Djärv 2014-10-19 18:05 ` Titus von der Malsburg 0 siblings, 1 reply; 27+ messages in thread From: Jan Djärv @ 2014-10-19 17:09 UTC (permalink / raw) To: Titus von der Malsburg; +Cc: 18722 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" > > > ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#18722: Correction 2014-10-19 17:09 ` Jan Djärv @ 2014-10-19 18:05 ` Titus von der Malsburg 2014-10-19 20:33 ` Jan Djärv 0 siblings, 1 reply; 27+ messages in thread From: Titus von der Malsburg @ 2014-10-19 18:05 UTC (permalink / raw) To: Jan Djärv; +Cc: 18722 [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#18722: Correction 2014-10-19 18:05 ` Titus von der Malsburg @ 2014-10-19 20:33 ` Jan Djärv 0 siblings, 0 replies; 27+ messages in thread From: Jan Djärv @ 2014-10-19 20:33 UTC (permalink / raw) To: Titus von der Malsburg; +Cc: 18722-done 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#18722: Correction 2014-10-16 22:31 ` Titus von der Malsburg 2014-10-17 0:53 ` Stefan Monnier @ 2014-10-17 9:23 ` martin rudalics 2014-10-17 12:55 ` Stefan Monnier 2014-10-17 16:44 ` Titus von der Malsburg 1 sibling, 2 replies; 27+ messages in thread From: martin rudalics @ 2014-10-17 9:23 UTC (permalink / raw) To: Titus von der Malsburg, Eli Zaretskii; +Cc: 18722 >> 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#18722: Correction 2014-10-17 9:23 ` martin rudalics @ 2014-10-17 12:55 ` Stefan Monnier 2014-10-17 16:44 ` Titus von der Malsburg 1 sibling, 0 replies; 27+ messages in thread From: Stefan Monnier @ 2014-10-17 12:55 UTC (permalink / raw) To: martin rudalics; +Cc: Titus von der Malsburg, 18722 > 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#18722: Correction 2014-10-17 9:23 ` martin rudalics 2014-10-17 12:55 ` Stefan Monnier @ 2014-10-17 16:44 ` Titus von der Malsburg 1 sibling, 0 replies; 27+ messages in thread From: Titus von der Malsburg @ 2014-10-17 16:44 UTC (permalink / raw) To: martin rudalics; +Cc: 18722 [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#18722: Correction 2014-10-16 14:46 ` Titus von der Malsburg 2014-10-16 14:54 ` Eli Zaretskii @ 2014-10-16 16:07 ` Stefan Monnier 2014-10-16 19:36 ` Titus von der Malsburg 1 sibling, 1 reply; 27+ messages in thread From: Stefan Monnier @ 2014-10-16 16:07 UTC (permalink / raw) To: Titus von der Malsburg; +Cc: 18722 > 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#18722: Correction 2014-10-16 16:07 ` Stefan Monnier @ 2014-10-16 19:36 ` Titus von der Malsburg 0 siblings, 0 replies; 27+ messages in thread From: Titus von der Malsburg @ 2014-10-16 19:36 UTC (permalink / raw) To: Stefan Monnier; +Cc: 18722 [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2014-10-19 20:33 UTC | newest] Thread overview: 27+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-10-14 20:24 bug#18722: 25.0.50; UI partly unresponsive after re-focus of Emacs' window Titus von der Malsburg 2014-10-15 21:41 ` bug#18722: Correction Titus von der Malsburg 2014-10-16 8:52 ` martin rudalics 2014-10-16 10:04 ` Eli Zaretskii 2014-10-16 11:41 ` martin rudalics 2014-10-16 12:04 ` Eli Zaretskii 2014-10-16 15:16 ` Titus von der Malsburg 2014-10-16 14:46 ` Titus von der Malsburg 2014-10-16 14:54 ` Eli Zaretskii 2014-10-16 15:10 ` Titus von der Malsburg 2014-10-16 15:34 ` Eli Zaretskii 2014-10-16 15:55 ` Titus von der Malsburg 2014-10-16 21:17 ` Titus von der Malsburg 2014-10-16 22:31 ` Titus von der Malsburg 2014-10-17 0:53 ` Stefan Monnier 2014-10-17 4:02 ` Titus von der Malsburg 2014-10-17 17:48 ` Jan Djärv 2014-10-17 18:14 ` Titus von der Malsburg 2014-10-18 12:31 ` Jan Djärv 2014-10-19 17:09 ` Jan Djärv 2014-10-19 18:05 ` Titus von der Malsburg 2014-10-19 20:33 ` Jan Djärv 2014-10-17 9:23 ` martin rudalics 2014-10-17 12:55 ` Stefan Monnier 2014-10-17 16:44 ` Titus von der Malsburg 2014-10-16 16:07 ` Stefan Monnier 2014-10-16 19:36 ` Titus von der Malsburg
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.