* bug#44180: 28.0.50; Emacs frames won't redisplay unless resized @ 2020-10-23 18:17 Eric Abrahamsen 2020-10-23 18:25 ` Eli Zaretskii 0 siblings, 1 reply; 28+ messages in thread From: Eric Abrahamsen @ 2020-10-23 18:17 UTC (permalink / raw) To: 44180 Hi all, I rebuilt Emacs on one of my machines yesterday, and am seeing odd behavior (with emacs -Q): I use a tiling window manager, which fullscreens frames by default, and when I open multiple Emacs frames, only one of them redisplays correctly, the others stay "frozen" and do not update the display until I manually resize the frame. I start Emacs, use "C-x 5 2" a couple of times to get my usual three frames. Only the last-created frame has "live" redisplay: I can switch focus between the frames, but the others won't update. If I switch to a frozen frame and do something like `find-file', I see the window title change to "minibuffer", and commands are accepted correctly, but the frame contents aren't updated. If I resize a frame (toggle "floating") then that frame becomes the "live" one, and the others freeze. I use two main computers, both Arch linux. The misbehaving machine uses X11 and i3 as the window manager. The other one uses Wayland and the sway window manager, though Emacs still runs under Xwayland, and on this machine everything works normally. Let me know if I can provide more information... In GNU Emacs 28.0.50 (build 6, x86_64-pc-linux-gnu, GTK+ Version 3.24.23, cairo version 1.17.3) of 2020-10-23 built on clem Repository revision: 46f5d2867cf73a845d582eeb8929ae51b78eae55 Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12009000 System Description: Arch Linux Configured features: XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY INOTIFY ACL GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD JSON PDUMPER LCMS2 Important settings: value of $LC_CTYPE: zh_CN.UTF-8 value of $LANG: en_US.UTF-8 value of $XMODIFIERS: @im=fcitx locale-coding-system: utf-8-unix Major mode: Group Minor modes in effect: gnus-topic-mode: t pyvenv-mode: t recentf-mode: t dired-async-mode: t gnus-undo-mode: t projectile-mode: t ivy-mode: t display-time-mode: t show-paren-mode: t savehist-mode: t shell-dirtrack-mode: t tooltip-mode: t global-eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t buffer-read-only: t line-number-mode: t Features: (shadow sort gnus-cite footnote orgalist mail-extr emacsbug utf-7 nnml nnfolder nnmaildir epa-file gnutls network-stream gnus-topic gnus-delay gnus-draft gnus-agent gnus-srvr gnus-score score-mode nnvirtual nntp gnus-cache nndraft nnmh misearch multi-isearch autorevert filenotify vc-git diff-mode autoinsert org-eldoc org-indent ol-eww eww xdg url-queue mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus ol-docview doc-view jka-compr image-mode exif ol-bibtex bibtex ol-bbdb ol-w3m org-crypt init-modes yasnippet highlight-indentation flymake-proc flymake warnings company-capf merlin-company company help-fns radix-tree elpy elpy-rpc pyvenv eshell esh-cmd esh-ext esh-opt esh-proc esh-io esh-arg esh-module esh-groups esh-util elpy-shell elpy-profile elpy-django s elpy-refactor ido cus-edit cus-start cus-load recentf tree-widget slime-fancy slime-trace-dialog slime-fontifying-fu slime-package-fu slime-references slime-compiler-notes-tree slime-scratch slime-presentations bridge slime-macrostep macrostep slime-mdot-fu slime-enclosing-context slime-fuzzy slime-fancy-trace slime-fancy-inspector slime-c-p-c slime-editing-commands slime-autodoc slime-repl elp slime-parse slime paredit flyspell ispell visible-mark lisp-mnt gud apropos etags fileloop xref project arc-mode archive-mode pp hyperspec dired-async dired-aux ebdb-org ebdb-message sendmail ebdb-gnorb ebdb-snarf ebdb-gnus nnselect gnus-msg ebdb-mua ebdb-com ebdb-format ebdb-i18n-chn ebdb-i18n ebdb-i18n-basic ebdb inline eieio-opt cl-extra speedbar ezimage dframe timezone gnus-icalendar gnorb-registry gnus-registry registry eieio-base gnorb-gnus org-capture org-attach gnus-art mm-uu mml2015 mm-view mml-smime smime dig gnus-sum shr kinsoku svg dom gnus-group gnus-undo nngnorb gnus-start gnus-dbus gnus-cloud nnimap nnmail mail-source utf7 netrc nnoo gnus-spec gnus-int gnus-range message dired dired-loaddefs rfc822 mml mml-sec epa epg epg-config mailabbrev mailheader gnus-win nnir gnus wid-edit mm-decode mm-bodies mm-encode gmm-utils gnorb gnorb-org gnorb-utils pcase nnheader gnus-util rmail rmail-loaddefs mail-utils async-bytecomp async pyim-basedict pyim pyim-probe xr rx pyim-common pyim-pymap popup help-mode notifications dbus org-annotate derived merlin-cap merlin caml-types caml-emacs crm cl vlf-setup init-my my-autoloads init-org ob-sqlite ob-sql ob-gnuplot ob-org ob-ledger ob-plantuml ob-lisp ob-latex ob-shell ob-python python ob-R calc-prog org-caldav icalendar diary-lib diary-loaddefs org-id url-dav url-http url-auth mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr url-gw nsm rmc puny xml calc-units calc-ext calc calc-loaddefs calc-macs org-mobile org-agenda org-refile ox-odt rng-loc rng-uri rng-parse rng-match rng-dt rng-util rng-pttrn nxml-parse nxml-ns nxml-enc xmltok nxml-util ox-latex ox-icalendar ox-html table ox-ascii ox-publish ox org-element avl-tree generator org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro org-footnote org-src ob-comint org-pcomplete org-list org-faces org-entities noutline outline org-version ob-emacs-lisp ob-core ob-eval org-table ol org-keys org-compat advice org-macs org-loaddefs find-func cal-menu calendar cal-loaddefs tramp-cache tramp-sh projectile grep compile text-property-search ibuf-ext ibuffer ibuffer-loaddefs thingatpt ivy flx delsel ivy-faces ivy-overlay colir color eieio-datadebug data-debug time paren savehist tramp tramp-loaddefs trampver tramp-integration files-x tramp-compat shell pcomplete comint ansi-color ring parse-time iso8601 time-date ls-lisp format-spec server prose-mode easy-mmode edmacro kmacro tex-site slime-autoloads w3m-load info package easymenu browse-url url url-proxy url-privacy url-expand url-methods url-history url-cookie url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache json subr-x map url-vars seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib china-util tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote threads dbusbind inotify lcms2 dynamic-setting system-font-setting font-render-setting cairo move-toolbar gtk x-toolkit x multi-tty make-network-process emacs) Memory information: ((conses 16 1668948 132650) (symbols 48 50482 2) (strings 32 762105 17018) (string-bytes 1 35772086) (vectors 16 81412) (vector-slots 8 1447953 84970) (floats 8 494 261) (intervals 56 92788 0) (buffers 992 74)) ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#44180: 28.0.50; Emacs frames won't redisplay unless resized 2020-10-23 18:17 bug#44180: 28.0.50; Emacs frames won't redisplay unless resized Eric Abrahamsen @ 2020-10-23 18:25 ` Eli Zaretskii 2020-10-23 19:07 ` Eric Abrahamsen 0 siblings, 1 reply; 28+ messages in thread From: Eli Zaretskii @ 2020-10-23 18:25 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: 44180 > From: Eric Abrahamsen <eric@ericabrahamsen.net> > Date: Fri, 23 Oct 2020 11:17:16 -0700 > > I rebuilt Emacs on one of my machines yesterday, and am seeing odd > behavior (with emacs -Q): I use a tiling window manager, which > fullscreens frames by default, and when I open multiple Emacs frames, > only one of them redisplays correctly, the others stay "frozen" and do > not update the display until I manually resize the frame. > > I start Emacs, use "C-x 5 2" a couple of times to get my usual three > frames. Only the last-created frame has "live" redisplay: I can switch > focus between the frames, but the others won't update. If I switch to a > frozen frame and do something like `find-file', I see the window title > change to "minibuffer", and commands are accepted correctly, but the > frame contents aren't updated. Sounds like Emacs thinks those other frames are invisible or iconified. Emacs never redisplays such frames, for obvious reasons. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#44180: 28.0.50; Emacs frames won't redisplay unless resized 2020-10-23 18:25 ` Eli Zaretskii @ 2020-10-23 19:07 ` Eric Abrahamsen 2020-10-23 19:38 ` Eli Zaretskii 0 siblings, 1 reply; 28+ messages in thread From: Eric Abrahamsen @ 2020-10-23 19:07 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 44180 On 10/23/20 21:25 PM, Eli Zaretskii wrote: >> From: Eric Abrahamsen <eric@ericabrahamsen.net> >> Date: Fri, 23 Oct 2020 11:17:16 -0700 >> >> I rebuilt Emacs on one of my machines yesterday, and am seeing odd >> behavior (with emacs -Q): I use a tiling window manager, which >> fullscreens frames by default, and when I open multiple Emacs frames, >> only one of them redisplays correctly, the others stay "frozen" and do >> not update the display until I manually resize the frame. >> >> I start Emacs, use "C-x 5 2" a couple of times to get my usual three >> frames. Only the last-created frame has "live" redisplay: I can switch >> focus between the frames, but the others won't update. If I switch to a >> frozen frame and do something like `find-file', I see the window title >> change to "minibuffer", and commands are accepted correctly, but the >> frame contents aren't updated. > > Sounds like Emacs thinks those other frames are invisible or > iconified. Emacs never redisplays such frames, for obvious reasons. Thanks for the clue. I get: (mapcar (lambda (f) (frame-parameter f 'visibility)) (frame-list)) => (icon icon t)df Whichever frame I've forced to be "live" always gets t, and the others become icons. If I split the screen to show two frames side-by-side, they both become visible. I haven't changed anything in my window manager config, and the i3 package hasn't been updated since August. The only recent commit that looks like it could be at all relevant is 2c0cd90083. Hope this points the way further... ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#44180: 28.0.50; Emacs frames won't redisplay unless resized 2020-10-23 19:07 ` Eric Abrahamsen @ 2020-10-23 19:38 ` Eli Zaretskii 2020-10-23 21:07 ` Eric Abrahamsen 0 siblings, 1 reply; 28+ messages in thread From: Eli Zaretskii @ 2020-10-23 19:38 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: 44180 > From: Eric Abrahamsen <eric@ericabrahamsen.net> > Cc: 44180@debbugs.gnu.org > Date: Fri, 23 Oct 2020 12:07:33 -0700 > > > Sounds like Emacs thinks those other frames are invisible or > > iconified. Emacs never redisplays such frames, for obvious reasons. > > Thanks for the clue. I get: > > (mapcar (lambda (f) (frame-parameter f 'visibility)) (frame-list)) > => (icon icon t)df > > Whichever frame I've forced to be "live" always gets t, and the others > become icons. What do you mean by "become icons"? Are they visible or aren't they? > I haven't changed anything in my window manager config, and the i3 > package hasn't been updated since August. The only recent commit that > looks like it could be at all relevant is 2c0cd90083. And if you revert that change, does the problem go away? ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#44180: 28.0.50; Emacs frames won't redisplay unless resized 2020-10-23 19:38 ` Eli Zaretskii @ 2020-10-23 21:07 ` Eric Abrahamsen 2020-10-24 6:55 ` martin rudalics 2020-10-24 8:03 ` Eli Zaretskii 0 siblings, 2 replies; 28+ messages in thread From: Eric Abrahamsen @ 2020-10-23 21:07 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 44180 On 10/23/20 22:38 PM, Eli Zaretskii wrote: >> From: Eric Abrahamsen <eric@ericabrahamsen.net> >> Cc: 44180@debbugs.gnu.org >> Date: Fri, 23 Oct 2020 12:07:33 -0700 >> >> > Sounds like Emacs thinks those other frames are invisible or >> > iconified. Emacs never redisplays such frames, for obvious reasons. >> >> Thanks for the clue. I get: >> >> (mapcar (lambda (f) (frame-parameter f 'visibility)) (frame-list)) >> => (icon icon t)df >> >> Whichever frame I've forced to be "live" always gets t, and the others >> become icons. > > What do you mean by "become icons"? Are they visible or aren't they? I just meant that their 'visibility frame-parameter became 'icon. Their "real" visibility is the same as always -- the two non-focused frames are visible only as stacked title bars above the currently focused frame. >> I haven't changed anything in my window manager config, and the i3 >> package hasn't been updated since August. The only recent commit that >> looks like it could be at all relevant is 2c0cd90083. > > And if you revert that change, does the problem go away? Yes it does! ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#44180: 28.0.50; Emacs frames won't redisplay unless resized 2020-10-23 21:07 ` Eric Abrahamsen @ 2020-10-24 6:55 ` martin rudalics 2020-10-24 8:36 ` Eli Zaretskii 2020-10-24 20:19 ` Eric Abrahamsen 2020-10-24 8:03 ` Eli Zaretskii 1 sibling, 2 replies; 28+ messages in thread From: martin rudalics @ 2020-10-24 6:55 UTC (permalink / raw) To: Eric Abrahamsen, Eli Zaretskii; +Cc: 44180 I just meant that their 'visibility frame-parameter became 'icon. Their > "real" visibility is the same as always -- the two non-focused frames > are visible only as stacked title bars above the currently focused frame. Can you please describe this in more detail. As I understand it, your initial frame looks as usual until you do C-x 5 2. At that moment, the initial frame becomes non-focused and appears as a stacked title bar while the new frame becomes focused and appears as expected. Is that right? Then how does the "fullscreen frames by default" fit into this picture and how does a tiling manager use stacking? >>> I haven't changed anything in my window manager config, and the i3 >>> package hasn't been updated since August. The only recent commit that >>> looks like it could be at all relevant is 2c0cd90083. >> >> And if you revert that change, does the problem go away? > > Yes it does! Maybe we need an option for 2c0cd90083. Maybe we also should just wait. I'd expect a few more of such reports to drop in. martin ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#44180: 28.0.50; Emacs frames won't redisplay unless resized 2020-10-24 6:55 ` martin rudalics @ 2020-10-24 8:36 ` Eli Zaretskii 2020-10-24 20:19 ` Eric Abrahamsen 1 sibling, 0 replies; 28+ messages in thread From: Eli Zaretskii @ 2020-10-24 8:36 UTC (permalink / raw) To: martin rudalics, J. Scott Berg; +Cc: eric, 44180 > Cc: 44180@debbugs.gnu.org > From: martin rudalics <rudalics@gmx.at> > Date: Sat, 24 Oct 2020 08:55:48 +0200 > > >> And if you revert that change, does the problem go away? > > > > Yes it does! > > Maybe we need an option for 2c0cd90083. Maybe we also should just > wait. I'd expect a few more of such reports to drop in. (Adding J. Scott to the addressees.) What about ignoring these events only if the size is 1x1, which is definitely bogus? Would that work in the VcXsrv case? ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#44180: 28.0.50; Emacs frames won't redisplay unless resized 2020-10-24 6:55 ` martin rudalics 2020-10-24 8:36 ` Eli Zaretskii @ 2020-10-24 20:19 ` Eric Abrahamsen 2020-10-25 15:08 ` Eli Zaretskii 1 sibling, 1 reply; 28+ messages in thread From: Eric Abrahamsen @ 2020-10-24 20:19 UTC (permalink / raw) To: martin rudalics; +Cc: 44180 [-- Attachment #1: Type: text/plain, Size: 1885 bytes --] On 10/24/20 08:55 AM, martin rudalics wrote: > I just meant that their 'visibility frame-parameter became 'icon. Their >> "real" visibility is the same as always -- the two non-focused frames >> are visible only as stacked title bars above the currently focused frame. > > Can you please describe this in more detail. As I understand it, your > initial frame looks as usual until you do C-x 5 2. At that moment, the > initial frame becomes non-focused and appears as a stacked title bar > while the new frame becomes focused and appears as expected. Is that > right? Then how does the "fullscreen frames by default" fit into this > picture and how does a tiling manager use stacking? Sorry if this wasn't clear. The window manager can display multiple windows (our frames) tiled into some sort of grid, in which case everything behaves correctly, or it can allow one of the windows to take up the full workspace, and other windows are only visible as a sort of window title bar, either tabbed along the top, or stacked along the top. I'm attaching a screenshot, that's stacked. My understanding is that this is *not* equivalent to X11's iconification or minification, where the window disappears and shows up as a icon in some notification area. i3 does have a notification bar, but I wouldn't know how to send a window there. In the screenshotted situation, i3 provides keybindings for switching focus between the stacked windows, but I believe in X11 terms, all three windows are meant to be visible, you're just switching which one is "foremost". I've got i3 set up to use stacking by default, meaning that as new windows are created they are added to the stack and displayed on top. You can also have them tabbed or split by default. I hope that makes sense. I'd be happy to try to contact an i3 person and ask them exactly what's happening, in X11 terms. Thanks, Eric [-- Attachment #2: 20201024_13h14m00s_grim.png --] [-- Type: image/png, Size: 196474 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#44180: 28.0.50; Emacs frames won't redisplay unless resized 2020-10-24 20:19 ` Eric Abrahamsen @ 2020-10-25 15:08 ` Eli Zaretskii 2020-10-25 16:01 ` Eric Abrahamsen 2020-10-25 16:26 ` Sascha Sadeghian 0 siblings, 2 replies; 28+ messages in thread From: Eli Zaretskii @ 2020-10-25 15:08 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: 44180 > From: Eric Abrahamsen <eric@ericabrahamsen.net> > Cc: Eli Zaretskii <eliz@gnu.org>, 44180@debbugs.gnu.org > Date: Sat, 24 Oct 2020 13:19:45 -0700 > > Sorry if this wasn't clear. The window manager can display multiple > windows (our frames) tiled into some sort of grid, in which case > everything behaves correctly, or it can allow one of the windows to take > up the full workspace, and other windows are only visible as a sort of > window title bar, either tabbed along the top, or stacked along the top. > I'm attaching a screenshot, that's stacked. Since the other frames are not really visible, treating them as iconified makes some sense. But then I don't understand your original report: you said these frames are not updated, but since they are obscured, what does "updated" mean for them? IOW, I'm now confused regarding the original report of the problem you have. I guess we need to start from the beginning now, so I'm asking you to describe in more detail what doesn't work in this situation. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#44180: 28.0.50; Emacs frames won't redisplay unless resized 2020-10-25 15:08 ` Eli Zaretskii @ 2020-10-25 16:01 ` Eric Abrahamsen 2020-10-25 16:16 ` Eli Zaretskii 2020-10-26 18:24 ` martin rudalics 2020-10-25 16:26 ` Sascha Sadeghian 1 sibling, 2 replies; 28+ messages in thread From: Eric Abrahamsen @ 2020-10-25 16:01 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 44180 On 10/25/20 17:08 PM, Eli Zaretskii wrote: >> From: Eric Abrahamsen <eric@ericabrahamsen.net> >> Cc: Eli Zaretskii <eliz@gnu.org>, 44180@debbugs.gnu.org >> Date: Sat, 24 Oct 2020 13:19:45 -0700 >> >> Sorry if this wasn't clear. The window manager can display multiple >> windows (our frames) tiled into some sort of grid, in which case >> everything behaves correctly, or it can allow one of the windows to take >> up the full workspace, and other windows are only visible as a sort of >> window title bar, either tabbed along the top, or stacked along the top. >> I'm attaching a screenshot, that's stacked. > > Since the other frames are not really visible, treating them as > iconified makes some sense. But then I don't understand your original > report: you said these frames are not updated, but since they are > obscured, what does "updated" mean for them? > > IOW, I'm now confused regarding the original report of the problem you > have. I guess we need to start from the beginning now, so I'm asking > you to describe in more detail what doesn't work in this situation. The problem is that switching focus between windows (frames) does not update which window is "live". The most-recently created, or most-recently resized, window is always the live one. If I switch focus to one of the other frames, it doesn't update, and I need to move it around somehow in order to make it live. Then the other frames go dead. Before the breakage, it's possible that the non-visible frames were not updated while they remained invisible, and I simply never knew because I couldn't see them. Now they stay un-updated until I manipulate the size of the window somehow. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#44180: 28.0.50; Emacs frames won't redisplay unless resized 2020-10-25 16:01 ` Eric Abrahamsen @ 2020-10-25 16:16 ` Eli Zaretskii 2020-10-25 16:28 ` Eric Abrahamsen 2020-10-26 18:24 ` martin rudalics 1 sibling, 1 reply; 28+ messages in thread From: Eli Zaretskii @ 2020-10-25 16:16 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: 44180 > From: Eric Abrahamsen <eric@ericabrahamsen.net> > Cc: rudalics@gmx.at, 44180@debbugs.gnu.org > Date: Sun, 25 Oct 2020 09:01:20 -0700 > > The problem is that switching focus between windows (frames) does not > update which window is "live". The most-recently created, or > most-recently resized, window is always the live one. If I switch focus > to one of the other frames, it doesn't update, and I need to move it > around somehow in order to make it live. Then the other frames go dead. > > Before the breakage, it's possible that the non-visible frames were not > updated while they remained invisible, and I simply never knew because > I couldn't see them. Now they stay un-updated until I manipulate the > size of the window somehow. That seems to suggest that we don't trigger expose_frame calls anymore for the frames that become un-fontified? ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#44180: 28.0.50; Emacs frames won't redisplay unless resized 2020-10-25 16:16 ` Eli Zaretskii @ 2020-10-25 16:28 ` Eric Abrahamsen 2020-10-25 16:55 ` Eli Zaretskii 0 siblings, 1 reply; 28+ messages in thread From: Eric Abrahamsen @ 2020-10-25 16:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 44180 Eli Zaretskii <eliz@gnu.org> writes: >> From: Eric Abrahamsen <eric@ericabrahamsen.net> >> Cc: rudalics@gmx.at, 44180@debbugs.gnu.org >> Date: Sun, 25 Oct 2020 09:01:20 -0700 >> >> The problem is that switching focus between windows (frames) does not >> update which window is "live". The most-recently created, or >> most-recently resized, window is always the live one. If I switch focus >> to one of the other frames, it doesn't update, and I need to move it >> around somehow in order to make it live. Then the other frames go dead. >> >> Before the breakage, it's possible that the non-visible frames were not >> updated while they remained invisible, and I simply never knew because >> I couldn't see them. Now they stay un-updated until I manipulate the >> size of the window somehow. > > That seems to suggest that we don't trigger expose_frame calls anymore > for the frames that become un-fontified? I wouldn't know, but that certainly sounds likely. I'd be happy to try contacting someone at i3, if that would be helpful, or to try fiddling with the display code. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#44180: 28.0.50; Emacs frames won't redisplay unless resized 2020-10-25 16:28 ` Eric Abrahamsen @ 2020-10-25 16:55 ` Eli Zaretskii 2020-10-25 18:26 ` Eric Abrahamsen 0 siblings, 1 reply; 28+ messages in thread From: Eli Zaretskii @ 2020-10-25 16:55 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: 44180 > From: Eric Abrahamsen <eric@ericabrahamsen.net> > Cc: 44180@debbugs.gnu.org > Date: Sun, 25 Oct 2020 09:28:09 -0700 > > >> Before the breakage, it's possible that the non-visible frames were not > >> updated while they remained invisible, and I simply never knew because > >> I couldn't see them. Now they stay un-updated until I manipulate the > >> size of the window somehow. > > > > That seems to suggest that we don't trigger expose_frame calls anymore > > for the frames that become un-fontified? > > I wouldn't know, but that certainly sounds likely. I'd be happy to try > contacting someone at i3, if that would be helpful, or to try fiddling > with the display code. What would help is if you put a breakpoint at expose_frame, and see how it is called when the changes made by the offending commit are reverted. Please show which X event triggers that and with what parameters. Then do the same with the offending changes in place, and try to figure out why the expose event doesn't get triggered. Armed with that info, we could try finding a way of having the cake and eating it, too. TIA ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#44180: 28.0.50; Emacs frames won't redisplay unless resized 2020-10-25 16:55 ` Eli Zaretskii @ 2020-10-25 18:26 ` Eric Abrahamsen 0 siblings, 0 replies; 28+ messages in thread From: Eric Abrahamsen @ 2020-10-25 18:26 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 44180 Eli Zaretskii <eliz@gnu.org> writes: >> From: Eric Abrahamsen <eric@ericabrahamsen.net> >> Cc: 44180@debbugs.gnu.org >> Date: Sun, 25 Oct 2020 09:28:09 -0700 >> >> >> Before the breakage, it's possible that the non-visible frames were not >> >> updated while they remained invisible, and I simply never knew because >> >> I couldn't see them. Now they stay un-updated until I manipulate the >> >> size of the window somehow. >> > >> > That seems to suggest that we don't trigger expose_frame calls anymore >> > for the frames that become un-fontified? >> >> I wouldn't know, but that certainly sounds likely. I'd be happy to try >> contacting someone at i3, if that would be helpful, or to try fiddling >> with the display code. > > What would help is if you put a breakpoint at expose_frame, and see > how it is called when the changes made by the offending commit are > reverted. Please show which X event triggers that and with what > parameters. Then do the same with the offending changes in place, and > try to figure out why the expose event doesn't get triggered. > > Armed with that info, we could try finding a way of having the cake > and eating it, too. Okay, got it. I won't have access to the misbehaving machine until tomorrow, but will do this then. Maybe Sascha will beat me to it. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#44180: 28.0.50; Emacs frames won't redisplay unless resized 2020-10-25 16:01 ` Eric Abrahamsen 2020-10-25 16:16 ` Eli Zaretskii @ 2020-10-26 18:24 ` martin rudalics 2020-10-26 19:51 ` Eric Abrahamsen 1 sibling, 1 reply; 28+ messages in thread From: martin rudalics @ 2020-10-26 18:24 UTC (permalink / raw) To: Eric Abrahamsen, Eli Zaretskii; +Cc: 44180 > The problem is that switching focus between windows (frames) does not > update which window is "live". The most-recently created, or > most-recently resized, window is always the live one. If I switch focus > to one of the other frames, it doesn't update, and I need to move it > around somehow in order to make it live. Then the other frames go dead. > > Before the breakage, it's possible that the non-visible frames were not > updated while they remained invisible, and I simply never knew because > I couldn't see them. Now they stay un-updated until I manipulate the > size of the window somehow. Do you get the corresponding focus events (whatever they are now) when you make another frame the fullscreen one? If so, we should probably redraw the frame in that case. martin ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#44180: 28.0.50; Emacs frames won't redisplay unless resized 2020-10-26 18:24 ` martin rudalics @ 2020-10-26 19:51 ` Eric Abrahamsen 2020-10-27 9:08 ` martin rudalics 0 siblings, 1 reply; 28+ messages in thread From: Eric Abrahamsen @ 2020-10-26 19:51 UTC (permalink / raw) To: martin rudalics; +Cc: 44180 martin rudalics <rudalics@gmx.at> writes: >> The problem is that switching focus between windows (frames) does not >> update which window is "live". The most-recently created, or >> most-recently resized, window is always the live one. If I switch focus >> to one of the other frames, it doesn't update, and I need to move it >> around somehow in order to make it live. Then the other frames go dead. >> >> Before the breakage, it's possible that the non-visible frames were not >> updated while they remained invisible, and I simply never knew because >> I couldn't see them. Now they stay un-updated until I manipulate the >> size of the window somehow. > > Do you get the corresponding focus events (whatever they are now) when > you make another frame the fullscreen one? If so, we should probably > redraw the frame in that case. I'm still not at the offending computer, but I think there's a high likelihood of confusing myself with conflicting terminology here so, just to be clear: this isn't proper fullscreening in the X11 sense. i3 also does that, but I hardly ever use it since the stacked layout is close enough to full screen. In X11 terms I think all that's happening is switching of focus between windows, it's just that i3's layout means that the unfocused windows are always completely obscured. For some reason Emacs now thinks that a window being obscured means that it's now an icon. Switching focus back to that window does not un-iconify it. Anyway, more later in the day... ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#44180: 28.0.50; Emacs frames won't redisplay unless resized 2020-10-26 19:51 ` Eric Abrahamsen @ 2020-10-27 9:08 ` martin rudalics 2020-10-27 18:11 ` Eric Abrahamsen 0 siblings, 1 reply; 28+ messages in thread From: martin rudalics @ 2020-10-27 9:08 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: 44180 >> Do you get the corresponding focus events (whatever they are now) when >> you make another frame the fullscreen one? If so, we should probably >> redraw the frame in that case. > > I'm still not at the offending computer, but I think there's a high > likelihood of confusing myself with conflicting terminology here so, > just to be clear: this isn't proper fullscreening in the X11 sense. I didn't expect it to be but thanks for confirming. > i3 > also does that, but I hardly ever use it since the stacked layout is > close enough to full screen. In X11 terms I think all that's happening > is switching of focus between windows, it's just that i3's layout means > that the unfocused windows are always completely obscured. For some > reason Emacs now thinks that a window being obscured means that it's now > an icon. Switching focus back to that window does not un-iconify it. Always keep in mind that Emacs has no idea about whether and how a window has been iconified or focused. It just waits for the corresponding information from the window manager, believes what the latter tells and acts (redrawing a frame, for example) accordingly. > Anyway, more later in the day... martin ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#44180: 28.0.50; Emacs frames won't redisplay unless resized 2020-10-27 9:08 ` martin rudalics @ 2020-10-27 18:11 ` Eric Abrahamsen 2020-10-27 18:45 ` Eli Zaretskii 0 siblings, 1 reply; 28+ messages in thread From: Eric Abrahamsen @ 2020-10-27 18:11 UTC (permalink / raw) To: martin rudalics; +Cc: 44180 [-- Attachment #1: Type: text/plain, Size: 1976 bytes --] On 10/27/20 10:08 AM, martin rudalics wrote: >>> Do you get the corresponding focus events (whatever they are now) when >>> you make another frame the fullscreen one? If so, we should probably >>> redraw the frame in that case. >> >> I'm still not at the offending computer, but I think there's a high >> likelihood of confusing myself with conflicting terminology here so, >> just to be clear: this isn't proper fullscreening in the X11 sense. > > I didn't expect it to be but thanks for confirming. > >> i3 >> also does that, but I hardly ever use it since the stacked layout is >> close enough to full screen. In X11 terms I think all that's happening >> is switching of focus between windows, it's just that i3's layout means >> that the unfocused windows are always completely obscured. For some >> reason Emacs now thinks that a window being obscured means that it's now >> an icon. Switching focus back to that window does not un-iconify it. > > Always keep in mind that Emacs has no idea about whether and how a > window has been iconified or focused. It just waits for the > corresponding information from the window manager, believes what the > latter tells and acts (redrawing a frame, for example) accordingly. Okay, thanks. I think I'm going to need more help here, though. I have built master with optimizations off, I start GDB in a controlling emacs, set a breakpoint at xdisp.c:34381 at the beginning of expose_frame, and then "run -Q". That pops up a new frame, and we hit the breakpoint. I run "bt" and have attached the resulting backtrace. Something tells me you need more information than this, though. I went up a frame, to handle_one_xevent, where there are a bunch of local values I can print, but the values of dpyinfo and event are enormous structures. What variables exactly would you need to see? Again, this is on misbehaving master. Once I know exactly what you need I'll do the same for a build with the commit reverted. Thanks, Eric [-- Attachment #2: master.txt --] [-- Type: text/plain, Size: 3618 bytes --] #0 expose_frame (f=0x555556313f00, x=1900, y=1030, w=16, h=34) at xdisp.c:34381 #1 0x00005555556f2711 in handle_one_xevent (dpyinfo=0x55555604c400, event=0x7fffffffcd90, finish=0x555555e1f6fc <current_finish>, hold_quit=0x7fffffffd0a0) at xterm.c:8243 #2 0x00005555556f13dd in event_handler_gdk (gxev=0x7fffffffcd90, ev=0x555555fe8ca0, data=0x0) at xterm.c:7768 #3 0x00007ffff75c654f in () at /usr/lib/libgdk-3.so.0 #4 0x00007ffff75ca10b in () at /usr/lib/libgdk-3.so.0 #5 0x00007ffff756e15b in gdk_display_get_event () at /usr/lib/libgdk-3.so.0 #6 0x00007ffff75c9e44 in () at /usr/lib/libgdk-3.so.0 #7 0x00007ffff6f8d914 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0 #8 0x00007ffff6fe17d1 in () at /usr/lib/libglib-2.0.so.0 #9 0x00007ffff6f8c121 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0 #10 0x00007ffff781d597 in gtk_main_iteration () at /usr/lib/libgtk-3.so.0 #11 0x00005555556f5491 in XTread_socket (terminal=0x555555f94dd8, hold_quit=0x7fffffffd0a0) at xterm.c:9395 #12 0x000055555574f92d in gobble_input () at keyboard.c:6890 #13 0x000055555574ff5b in handle_async_input () at keyboard.c:7127 #14 0x000055555574ff7a in process_pending_signals () at keyboard.c:7141 #15 0x000055555581e182 in maybe_quit () at eval.c:1549 #16 0x0000555555829f94 in list_length (list=XIL(0x555555f2dc63)) at fns.c:98 #17 0x000055555582a106 in Flength (sequence=XIL(0x555556832353)) at fns.c:126 #18 0x000055555582baf9 in concat (nargs=1, args=0x7fffffffd318, target_type=Lisp_Cons, last_special=false) at fns.c:666 #19 0x000055555582b8d6 in Fcopy_sequence (arg=XIL(0x555556832353)) at fns.c:598 #20 0x00005555557492b0 in timer_check () at keyboard.c:4398 #21 0x0000555555746f69 in readable_events (flags=1) at keyboard.c:3405 #22 0x000055555574f743 in get_input_pending (flags=1) at keyboard.c:6805 #23 0x00005555557591e4 in detect_input_pending_run_timers (do_display=true) at keyboard.c:10366 #24 0x0000555555891fa5 in wait_reading_process_output (time_limit=0, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=XIL(0), wait_proc=0x0, just_wait_proc=0) at process.c:5702 #25 0x0000555555747f1b in kbd_buffer_get_event (kbp=0x7fffffffd920, used_mouse_menu=0x7fffffffdf2d, end_time=0x0) at keyboard.c:3874 #26 0x0000555555742678 in read_event_from_main_queue (end_time=0x0, local_getcjmp=0x7fffffffdd30, used_mouse_menu=0x7fffffffdf2d) at keyboard.c:2160 #27 0x0000555555742a88 in read_decoded_event_from_main_queue (end_time=0x0, local_getcjmp=0x7fffffffdd30, prev_event=XIL(0), used_mouse_menu=0x7fffffffdf2d) at keyboard.c:2224 #28 0x0000555555744cd2 in read_char (commandflag=1, map=XIL(0x5555568323b3), prev_event=XIL(0), used_mouse_menu=0x7fffffffdf2d, end_time=0x0) at keyboard.c:2834 #29 0x0000555555757125 in read_key_sequence (keybuf=0x7fffffffe110, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9552 #30 0x000055555573fd76 in command_loop_1 () at keyboard.c:1354 #31 0x000055555581db25 in internal_condition_case (bfun=0x55555573f8dc <command_loop_1>, handlers=XIL(0x90), hfun=0x55555573eed0 <cmd_error>) at eval.c:1359 #32 0x000055555573f4c5 in command_loop_2 (ignore=XIL(0)) at keyboard.c:1095 #33 0x000055555581cf79 in internal_catch (tag=XIL(0xd710), func=0x55555573f498 <command_loop_2>, arg=XIL(0)) at eval.c:1120 #34 0x000055555573f464 in command_loop () at keyboard.c:1074 #35 0x000055555573e9b9 in recursive_edit_1 () at keyboard.c:718 #36 0x000055555573ebb0 in Frecursive_edit () at keyboard.c:790 #37 0x000055555573a984 in main (argc=2, argv=0x7fffffffe598) at emacs.c:2047 ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#44180: 28.0.50; Emacs frames won't redisplay unless resized 2020-10-27 18:11 ` Eric Abrahamsen @ 2020-10-27 18:45 ` Eli Zaretskii 2020-10-27 19:48 ` Eric Abrahamsen 0 siblings, 1 reply; 28+ messages in thread From: Eli Zaretskii @ 2020-10-27 18:45 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: 44180 > From: Eric Abrahamsen <eric@ericabrahamsen.net> > Cc: Eli Zaretskii <eliz@gnu.org>, 44180@debbugs.gnu.org > Date: Tue, 27 Oct 2020 11:11:26 -0700 > > I think I'm going to need more help here, though. I have built master > with optimizations off, I start GDB in a controlling emacs, set a > breakpoint at xdisp.c:34381 at the beginning of expose_frame, and then > "run -Q". > > That pops up a new frame, and we hit the breakpoint. That's the initial frame, isn't it? If so, this is not the frame we want, we want a frame that was obscured and then gets the focus. To save yourself from a lot of unwanted breakpoint hits, I suggest this paradigm: $ gdb ./emacs (gdb) break Frecenter (gdb) r -Q Inside Emacs: M-x blink-cursor-mode RET M-x global-eldoc-mode RET Now create one or more other frames and make them obscured ("iconified"). Now type C-l -- this will hit the breakpoint in Frecenter, and GDB will kick in. Then set a breakpoint in expose_frame and type "continue". Finally, switch to a frame that was obscured: does the breakpoint in expose_frame break, and if so, is Emacs told to expose the correct frame, the one that was obscured and is going to become visible? If it's the correct frame, show the backtrace. Then do all this again, but after reverting the change which causes the problem. By comparing the backtraces and the behavior, we might begin to understand how this change causes the problem in your case. Thanks. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#44180: 28.0.50; Emacs frames won't redisplay unless resized 2020-10-27 18:45 ` Eli Zaretskii @ 2020-10-27 19:48 ` Eric Abrahamsen 2020-10-31 8:28 ` Eli Zaretskii 0 siblings, 1 reply; 28+ messages in thread From: Eric Abrahamsen @ 2020-10-27 19:48 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 44180 [-- Attachment #1: Type: text/plain, Size: 2486 bytes --] Eli Zaretskii <eliz@gnu.org> writes: >> From: Eric Abrahamsen <eric@ericabrahamsen.net> >> Cc: Eli Zaretskii <eliz@gnu.org>, 44180@debbugs.gnu.org >> Date: Tue, 27 Oct 2020 11:11:26 -0700 >> >> I think I'm going to need more help here, though. I have built master >> with optimizations off, I start GDB in a controlling emacs, set a >> breakpoint at xdisp.c:34381 at the beginning of expose_frame, and then >> "run -Q". >> >> That pops up a new frame, and we hit the breakpoint. > > That's the initial frame, isn't it? If so, this is not the frame we > want, we want a frame that was obscured and then gets the focus. > > To save yourself from a lot of unwanted breakpoint hits, I suggest > this paradigm: > > $ gdb ./emacs > (gdb) break Frecenter > (gdb) r -Q > > Inside Emacs: > > M-x blink-cursor-mode RET > M-x global-eldoc-mode RET > > Now create one or more other frames and make them obscured > ("iconified"). Now type C-l -- this will hit the breakpoint in > Frecenter, and GDB will kick in. Then set a breakpoint in > expose_frame and type "continue". Finally, switch to a frame that was > obscured: does the breakpoint in expose_frame break, and if so, is > Emacs told to expose the correct frame, the one that was obscured and > is going to become visible? If it's the correct frame, show the > backtrace. > > Then do all this again, but after reverting the change which causes > the problem. By comparing the backtraces and the behavior, we might > begin to understand how this change causes the problem in your case. Okay, hope this is helpful. I start in a workspace with only the terminal, do the gdb dance, and when I run "r -Q" the first frame appears, in stacked mode, taking up the whole screen. I create a second frame: now i3 has a vertical stack of three windows: terminal, emacs1 and emacs2 -- emacs2 is focused. I shut off blink cursor and global eldoc, note the frame addresses, then move focus "wrap-around" style down and back around to the terminal, so the emacs1 window (which is the "stuck" one in master) never receives focus (that might not be important). Back in the terminal I pause execution, set the expose_frame breakpoint, turn on logging, and continue. Then move focus down to emacs1, back up to the terminal, see the breakpoint has triggered, get a backtrace, and confirm that the frame in question is indeed emacs1. I did that exact routine in both master and a "revert" branch, with the commit reverted. Fingers crossed! [-- Attachment #2: master.txt --] [-- Type: text/plain, Size: 5048 bytes --] #0 expose_frame (f=0x555556317630, x=0, y=1042, w=1900, h=10) at xdisp.c:34381 #1 0x00005555556f2711 in handle_one_xevent (dpyinfo=0x5555560a2fe0, event=0x7fffffffd420, finish=0x555555e1f6fc <current_finish>, hold_quit=0x7fffffffd730) at xterm.c:8243 #2 0x00005555556f13dd in event_handler_gdk (gxev=0x7fffffffd420, ev=0x555555fecde0, data=0x0) at xterm.c:7768 #3 0x00007ffff75c654f in () at /usr/lib/libgdk-3.so.0 #4 0x00007ffff75ca10b in () at /usr/lib/libgdk-3.so.0 #5 0x00007ffff756e15b in gdk_display_get_event () at /usr/lib/libgdk-3.so.0 #6 0x00007ffff75c9e44 in () at /usr/lib/libgdk-3.so.0 #7 0x00007ffff6f8d914 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0 #8 0x00007ffff6fe17d1 in () at /usr/lib/libglib-2.0.so.0 #9 0x00007ffff6f8c121 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0 #10 0x00007ffff781d597 in gtk_main_iteration () at /usr/lib/libgtk-3.so.0 #11 0x00005555556f5491 in XTread_socket (terminal=0x555555f94d38, hold_quit=0x7fffffffd730) at xterm.c:9395 #12 0x000055555574f92d in gobble_input () at keyboard.c:6890 #13 0x000055555574ff5b in handle_async_input () at keyboard.c:7127 #14 0x000055555574ff7a in process_pending_signals () at keyboard.c:7141 #15 0x0000555555890bab in wait_reading_process_output (time_limit=30, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=XIL(0), wait_proc=0x0, just_wait_proc=0) at process.c:5248 #16 0x00005555555a857f in sit_for (timeout=make_fixnum(30), reading=true, display_option=1) at dispnew.c:6056 #17 0x0000555555744631 in read_char (commandflag=1, map=XIL(0x555555f8dbb3), prev_event=XIL(0), used_mouse_menu=0x7fffffffdf5d, end_time=0x0) at keyboard.c:2742 #18 0x0000555555757125 in read_key_sequence (keybuf=0x7fffffffe140, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9552 #19 0x000055555573fd76 in command_loop_1 () at keyboard.c:1354 #20 0x000055555581db25 in internal_condition_case (bfun=0x55555573f8dc <command_loop_1>, handlers=XIL(0x90), hfun=0x55555573eed0 <cmd_error>) at eval.c:1359 #21 0x000055555573f4c5 in command_loop_2 (ignore=XIL(0)) at keyboard.c:1095 #22 0x000055555581cf79 in internal_catch (tag=XIL(0xd710), func=0x55555573f498 <command_loop_2>, arg=XIL(0)) at eval.c:1120 #23 0x000055555573f464 in command_loop () at keyboard.c:1074 #24 0x000055555573e9b9 in recursive_edit_1 () at keyboard.c:718 #25 0x000055555573ebb0 in Frecursive_edit () at keyboard.c:790 #26 0x000055555573a984 in main (argc=2, argv=0x7fffffffe5c8) at emacs.c:2047 Continuing. Thread 1 "emacs" hit Breakpoint 3, expose_frame (f=0x555556317630, x=0, y=1052, w=1916, h=12) at xdisp.c:34381 34381 { Continuing. Thread 1 "emacs" received signal SIGTSTP, Stopped (user). 0x00007ffff5af2c96 in pselect () from /usr/lib/libc.so.6 #0 0x00007ffff5af2c96 in pselect () at /usr/lib/libc.so.6 #1 0x00005555558d3322 in really_call_select (arg=0x7fffffffd170) at thread.c:592 #2 0x00005555557e1ff5 in flush_stack_call_func1 (func=0x5555558d325b <really_call_select>, arg=0x7fffffffd170) at alloc.c:5066 #3 0x00005555558d2620 in flush_stack_call_func (func=0x5555558d325b <really_call_select>, arg=0x7fffffffd170) at lisp.h:3791 #4 0x00005555558d341f in thread_select (func=0x7ffff5af2bd0 <pselect>, max_fds=7, rfds=0x7fffffffd280, wfds=0x7fffffffd300, efds=0x0, timeout=0x7fffffffd8d0, sigmask=0x0) at thread.c:624 #5 0x0000555555909f8a in xg_select (fds_lim=7, rfds=0x7fffffffd940, wfds=0x7fffffffd9c0, efds=0x0, timeout=0x7fffffffd8d0, sigmask=0x0) at xgselect.c:131 #6 0x0000555555891bdc in wait_reading_process_output (time_limit=30, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=XIL(0), wait_proc=0x0, just_wait_proc=0) at process.c:5604 #7 0x00005555555a857f in sit_for (timeout=make_fixnum(30), reading=true, display_option=1) at dispnew.c:6056 #8 0x0000555555744631 in read_char (commandflag=1, map=XIL(0x555555f8dbb3), prev_event=XIL(0), used_mouse_menu=0x7fffffffdf5d, end_time=0x0) at keyboard.c:2742 #9 0x0000555555757125 in read_key_sequence (keybuf=0x7fffffffe140, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9552 #10 0x000055555573fd76 in command_loop_1 () at keyboard.c:1354 #11 0x000055555581db25 in internal_condition_case (bfun=0x55555573f8dc <command_loop_1>, handlers=XIL(0x90), hfun=0x55555573eed0 <cmd_error>) at eval.c:1359 #12 0x000055555573f4c5 in command_loop_2 (ignore=XIL(0)) at keyboard.c:1095 #13 0x000055555581cf79 in internal_catch (tag=XIL(0xd710), func=0x55555573f498 <command_loop_2>, arg=XIL(0)) at eval.c:1120 #14 0x000055555573f464 in command_loop () at keyboard.c:1074 #15 0x000055555573e9b9 in recursive_edit_1 () at keyboard.c:718 #16 0x000055555573ebb0 in Frecursive_edit () at keyboard.c:790 #17 0x000055555573a984 in main (argc=2, argv=0x7fffffffe5c8) at emacs.c:2047 Continuing. [Thread 0x7ffff1132640 (LWP 49694) exited] [Thread 0x7ffff2cf3fc0 (LWP 49690) exited] [Inferior 1 (process 49690) exited normally] [-- Attachment #3: revert.txt --] [-- Type: text/plain, Size: 5520 bytes --] #0 0x00007ffff5af2c96 in pselect () at /usr/lib/libc.so.6 #1 0x000055555576b78c in really_call_select (arg=0x7fffffffcf70) at thread.c:592 #2 0x000055555576c56f in flush_stack_call_func (arg=0x7fffffffcf70, func=0x55555576b720 <really_call_select>) at lisp.h:3791 #3 thread_select (func=<optimized out>, max_fds=max_fds@entry=7, rfds=rfds@entry=0x7fffffffd070, wfds=wfds@entry=0x7fffffffd0f0, efds=efds@entry=0x0, timeout=timeout@entry=0x7fffffffd6a0, sigmask=0x0) at thread.c:624 #4 0x0000555555788ffb in xg_select (fds_lim=7, rfds=rfds@entry=0x7fffffffd7b0, wfds=wfds@entry=0x7fffffffd830, efds=efds@entry=0x0, timeout=timeout@entry=0x7fffffffd6a0, sigmask=sigmask@entry=0x0) at xgselect.c:131 #5 0x0000555555749dcd in wait_reading_process_output (time_limit=time_limit@entry=30, nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=-1, do_display=do_display@entry=true, wait_for_cell=wait_for_cell@entry=XIL(0), wait_proc=wait_proc@entry=0x0, just_wait_proc=0) at process.c:5604 #6 0x00005555555ab1ff in sit_for (timeout=timeout@entry=make_fixnum(30), reading=reading@entry=true, display_option=display_option@entry=1) at lisp.h:1007 #7 0x000055555569431f in read_char (commandflag=1, map=XIL(0x55555613fad3), prev_event=XIL(0), used_mouse_menu=0x7fffffffe04b, end_time=0x0) at lisp.h:1122 #8 0x0000555555694d44 in read_key_sequence (keybuf=<optimized out>, prompt=XIL(0), dont_downcase_last=<optimized out>, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=<optimized out>) at keyboard.c:9552 #9 0x00005555556966cc in command_loop_1 () at lisp.h:1007 #10 0x0000555555703167 in internal_condition_case (bfun=bfun@entry=0x5555556964e0 <command_loop_1>, handlers=handlers@entry=XIL(0x90), hfun=hfun@entry=0x55555568cc10 <cmd_error>) at eval.c:1359 #11 0x0000555555687194 in command_loop_2 (ignore=ignore@entry=XIL(0)) at lisp.h:1007 #12 0x00005555557030c1 in internal_catch (tag=tag@entry=XIL(0xd710), func=func@entry=0x555555687170 <command_loop_2>, arg=arg@entry=XIL(0)) at eval.c:1120 #13 0x000055555568713b in command_loop () at lisp.h:1007 #14 0x000055555568c826 in recursive_edit_1 () at keyboard.c:718 #15 0x000055555568cb52 in Frecursive_edit () at keyboard.c:790 #16 0x00005555555a0fcc in main (argc=2, argv=<optimized out>) at emacs.c:2047 Continuing. Thread 1 "emacs" hit Breakpoint 3, expose_frame (f=0x55555604ae20, x=0, y=1042, w=1916, h=22) at xdisp.c:34381 34381 { #0 expose_frame (f=0x55555604ae20, x=0, y=1042, w=1916, h=22) at xdisp.c:34381 #1 0x0000555555661b40 in handle_one_xevent (dpyinfo=<optimized out>, event=0x7fffffffd270, finish=0x555555b68ab0 <current_finish>, hold_quit=<optimized out>) at xterm.c:8243 #2 0x0000555555663078 in event_handler_gdk (gxev=0x7fffffffd270, ev=<optimized out>, data=<optimized out>) at xterm.c:7767 #3 0x00007ffff75c654f in () at /usr/lib/libgdk-3.so.0 #4 0x00007ffff75ca10b in () at /usr/lib/libgdk-3.so.0 #5 0x00007ffff756e15b in gdk_display_get_event () at /usr/lib/libgdk-3.so.0 #6 0x00007ffff75c9e44 in () at /usr/lib/libgdk-3.so.0 #7 0x00007ffff6f8d914 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0 #8 0x00007ffff6fe17d1 in () at /usr/lib/libglib-2.0.so.0 #9 0x00007ffff6f8c121 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0 #10 0x00007ffff781d597 in gtk_main_iteration () at /usr/lib/libgtk-3.so.0 #11 0x0000555555655df3 in XTread_socket (terminal=<optimized out>, hold_quit=0x7fffffffd530) at xterm.c:9394 #12 0x000055555568e552 in gobble_input () at keyboard.c:6890 #13 0x000055555568eb35 in handle_async_input () at keyboard.c:7127 #14 process_pending_signals () at keyboard.c:7141 #15 0x0000555555749e1d in wait_reading_process_output (time_limit=time_limit@entry=30, nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=-1, do_display=do_display@entry=true, wait_for_cell=wait_for_cell@entry=XIL(0), wait_proc=wait_proc@entry=0x0, just_wait_proc=0) at process.c:5248 #16 0x00005555555ab1ff in sit_for (timeout=timeout@entry=make_fixnum(30), reading=reading@entry=true, display_option=display_option@entry=1) at lisp.h:1007 #17 0x000055555569431f in read_char (commandflag=1, map=XIL(0x555555c60ed3), prev_event=XIL(0), used_mouse_menu=0x7fffffffe04b, end_time=0x0) at lisp.h:1122 #18 0x0000555555694d44 in read_key_sequence (keybuf=<optimized out>, prompt=XIL(0), dont_downcase_last=<optimized out>, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=<optimized out>) at keyboard.c:9552 #19 0x00005555556966cc in command_loop_1 () at lisp.h:1007 #20 0x0000555555703167 in internal_condition_case (bfun=bfun@entry=0x5555556964e0 <command_loop_1>, handlers=handlers@entry=XIL(0x90), hfun=hfun@entry=0x55555568cc10 <cmd_error>) at eval.c:1359 #21 0x0000555555687194 in command_loop_2 (ignore=ignore@entry=XIL(0)) at lisp.h:1007 #22 0x00005555557030c1 in internal_catch (tag=tag@entry=XIL(0xd710), func=func@entry=0x555555687170 <command_loop_2>, arg=arg@entry=XIL(0)) at eval.c:1120 #23 0x000055555568713b in command_loop () at lisp.h:1007 #24 0x000055555568c826 in recursive_edit_1 () at keyboard.c:718 #25 0x000055555568cb52 in Frecursive_edit () at keyboard.c:790 #26 0x00005555555a0fcc in main (argc=2, argv=<optimized out>) at emacs.c:2047 Currently logging to "gdb.txt". Logs will be appended to the log file. Output will be logged and displayed. Debug output will be logged and displayed. Continuing. [Thread 0x7ffff1133640 (LWP 49752) exited] [Thread 0x7ffff2cf3fc0 (LWP 49748) exited] [Inferior 1 (process 49748) exited normally] ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#44180: 28.0.50; Emacs frames won't redisplay unless resized 2020-10-27 19:48 ` Eric Abrahamsen @ 2020-10-31 8:28 ` Eli Zaretskii 2020-11-06 1:52 ` Eric Abrahamsen 0 siblings, 1 reply; 28+ messages in thread From: Eli Zaretskii @ 2020-10-31 8:28 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: 44180 > From: Eric Abrahamsen <eric@ericabrahamsen.net> > Cc: 44180@debbugs.gnu.org > Date: Tue, 27 Oct 2020 12:48:52 -0700 > > Okay, hope this is helpful. I start in a workspace with only the > terminal, do the gdb dance, and when I run "r -Q" the first frame > appears, in stacked mode, taking up the whole screen. I create a second > frame: now i3 has a vertical stack of three windows: terminal, emacs1 > and emacs2 -- emacs2 is focused. > > I shut off blink cursor and global eldoc, note the frame addresses, then > move focus "wrap-around" style down and back around to the terminal, so > the emacs1 window (which is the "stuck" one in master) never receives > focus (that might not be important). > > Back in the terminal I pause execution, set the expose_frame breakpoint, > turn on logging, and continue. Then move focus down to emacs1, back up > to the terminal, see the breakpoint has triggered, get a backtrace, and > confirm that the frame in question is indeed emacs1. > > I did that exact routine in both master and a "revert" branch, with the > commit reverted. The backtraces look identical. So does this mean expose_frame returns immediately in the "master" case without doing anything, but in the "revert" case it doesn't return? If so, is the reason the fact that the problematic frame is marked as "garbaged" in the "master" case, but not in the "revert" case? ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#44180: 28.0.50; Emacs frames won't redisplay unless resized 2020-10-31 8:28 ` Eli Zaretskii @ 2020-11-06 1:52 ` Eric Abrahamsen 2022-04-24 14:08 ` Lars Ingebrigtsen 0 siblings, 1 reply; 28+ messages in thread From: Eric Abrahamsen @ 2020-11-06 1:52 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 44180 Eli Zaretskii <eliz@gnu.org> writes: >> From: Eric Abrahamsen <eric@ericabrahamsen.net> >> Cc: 44180@debbugs.gnu.org >> Date: Tue, 27 Oct 2020 12:48:52 -0700 >> >> Okay, hope this is helpful. I start in a workspace with only the >> terminal, do the gdb dance, and when I run "r -Q" the first frame >> appears, in stacked mode, taking up the whole screen. I create a second >> frame: now i3 has a vertical stack of three windows: terminal, emacs1 >> and emacs2 -- emacs2 is focused. >> >> I shut off blink cursor and global eldoc, note the frame addresses, then >> move focus "wrap-around" style down and back around to the terminal, so >> the emacs1 window (which is the "stuck" one in master) never receives >> focus (that might not be important). >> >> Back in the terminal I pause execution, set the expose_frame breakpoint, >> turn on logging, and continue. Then move focus down to emacs1, back up >> to the terminal, see the breakpoint has triggered, get a backtrace, and >> confirm that the frame in question is indeed emacs1. >> >> I did that exact routine in both master and a "revert" branch, with the >> commit reverted. > > The backtraces look identical. So does this mean expose_frame returns > immediately in the "master" case without doing anything, but in the > "revert" case it doesn't return? If so, is the reason the fact that > the problematic frame is marked as "garbaged" in the "master" case, > but not in the "revert" case? (I haven't had time to tackle this, and now will be away from the X11 machine for a week. Will report back in a couple weeks.) ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#44180: 28.0.50; Emacs frames won't redisplay unless resized 2020-11-06 1:52 ` Eric Abrahamsen @ 2022-04-24 14:08 ` Lars Ingebrigtsen 2022-04-24 15:26 ` Eric Abrahamsen 0 siblings, 1 reply; 28+ messages in thread From: Lars Ingebrigtsen @ 2022-04-24 14:08 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: 44180 Eric Abrahamsen <eric@ericabrahamsen.net> writes: >> The backtraces look identical. So does this mean expose_frame returns >> immediately in the "master" case without doing anything, but in the >> "revert" case it doesn't return? If so, is the reason the fact that >> the problematic frame is marked as "garbaged" in the "master" case, >> but not in the "revert" case? > > (I haven't had time to tackle this, and now will be away from the X11 > machine for a week. Will report back in a couple weeks.) This was a year ago -- are you still seeing this problem on the trunk? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#44180: 28.0.50; Emacs frames won't redisplay unless resized 2022-04-24 14:08 ` Lars Ingebrigtsen @ 2022-04-24 15:26 ` Eric Abrahamsen 2022-04-24 15:27 ` Lars Ingebrigtsen 0 siblings, 1 reply; 28+ messages in thread From: Eric Abrahamsen @ 2022-04-24 15:26 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 44180 On 04/24/22 16:08 PM, Lars Ingebrigtsen wrote: > Eric Abrahamsen <eric@ericabrahamsen.net> writes: > >>> The backtraces look identical. So does this mean expose_frame returns >>> immediately in the "master" case without doing anything, but in the >>> "revert" case it doesn't return? If so, is the reason the fact that >>> the problematic frame is marked as "garbaged" in the "master" case, >>> but not in the "revert" case? >> >> (I haven't had time to tackle this, and now will be away from the X11 >> machine for a week. Will report back in a couple weeks.) > > This was a year ago -- are you still seeing this problem on the trunk? Nope! Guess it fixed itself in the meantime. Please go ahead and close. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#44180: 28.0.50; Emacs frames won't redisplay unless resized 2022-04-24 15:26 ` Eric Abrahamsen @ 2022-04-24 15:27 ` Lars Ingebrigtsen 0 siblings, 0 replies; 28+ messages in thread From: Lars Ingebrigtsen @ 2022-04-24 15:27 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: 44180 Eric Abrahamsen <eric@ericabrahamsen.net> writes: > Nope! Guess it fixed itself in the meantime. Please go ahead and close. OK; done. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#44180: 28.0.50; Emacs frames won't redisplay unless resized 2020-10-25 15:08 ` Eli Zaretskii 2020-10-25 16:01 ` Eric Abrahamsen @ 2020-10-25 16:26 ` Sascha Sadeghian 2020-10-25 16:57 ` Eli Zaretskii 1 sibling, 1 reply; 28+ messages in thread From: Sascha Sadeghian @ 2020-10-25 16:26 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Eric Abrahamsen, 44180 Eli Zaretskii <eliz@gnu.org> wrote: > Since the other frames are not really visible, treating them as > iconified makes some sense. But then I don't understand your original > report: you said these frames are not updated, but since they are > obscured, what does "updated" mean for them? I am seeing similar behaviour with the i3 window manager. Let’s say we start with an Emacs GTK window and an xterm window side by side, so that each has 50% of the total screen width ("split" mode in i3). If I switch to "tabbed" mode now and select the Emacs tab, the Emacs frame is unresponsive, and its contents are not redrawn any more. This didn’t happen before 2c0cd90083. Here is a quick demo with emacs -Q: https://webterm.io/bug-gnu-emacs/44180-working.webm https://webterm.io/bug-gnu-emacs/44180-broken.webm The bug can be reproduced with a single frame. The confusing part is probably that for this frozen frame, keyboard input is still working, so buffers can be edited, while the edits are only visible in other, non-frozen frames (for example, a second emacsclient frame showing the same buffers). The GTK menu and toolbar are also not affected. Hope this helps! ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#44180: 28.0.50; Emacs frames won't redisplay unless resized 2020-10-25 16:26 ` Sascha Sadeghian @ 2020-10-25 16:57 ` Eli Zaretskii 0 siblings, 0 replies; 28+ messages in thread From: Eli Zaretskii @ 2020-10-25 16:57 UTC (permalink / raw) To: Sascha Sadeghian; +Cc: eric, 44180 > Date: Sun, 25 Oct 2020 17:26:18 +0100 > From: Sascha Sadeghian <sadeghian@acm.org> > Cc: Eric Abrahamsen <eric@ericabrahamsen.net>, 44180@debbugs.gnu.org > > Let’s say we start with an Emacs GTK window and an xterm window side by > side, so that each has 50% of the total screen width ("split" mode in > i3). If I switch to "tabbed" mode now and select the Emacs tab, the > Emacs frame is unresponsive, and its contents are not redrawn any more. > > This didn’t happen before 2c0cd90083. > > Here is a quick demo with emacs -Q: > > https://webterm.io/bug-gnu-emacs/44180-working.webm > https://webterm.io/bug-gnu-emacs/44180-broken.webm > > The bug can be reproduced with a single frame. > > The confusing part is probably that for this frozen frame, keyboard > input is still working, so buffers can be edited, while the edits are > only visible in other, non-frozen frames (for example, a second > emacsclient frame showing the same buffers). The GTK menu and toolbar > are also not affected. This is actually not confusing at all, it is entirely expected. > Hope this helps! I've just explained to Eric which information would be helpful to make some progress here. If you can help collecting that information, it will be really appreciated. Thanks. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#44180: 28.0.50; Emacs frames won't redisplay unless resized 2020-10-23 21:07 ` Eric Abrahamsen 2020-10-24 6:55 ` martin rudalics @ 2020-10-24 8:03 ` Eli Zaretskii 1 sibling, 0 replies; 28+ messages in thread From: Eli Zaretskii @ 2020-10-24 8:03 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: 44180 > From: Eric Abrahamsen <eric@ericabrahamsen.net> > Cc: 44180@debbugs.gnu.org > Date: Fri, 23 Oct 2020 14:07:00 -0700 > > >> (mapcar (lambda (f) (frame-parameter f 'visibility)) (frame-list)) > >> => (icon icon t)df > >> > >> Whichever frame I've forced to be "live" always gets t, and the others > >> become icons. > > > > What do you mean by "become icons"? Are they visible or aren't they? > > I just meant that their 'visibility frame-parameter became 'icon. Their > "real" visibility is the same as always -- the two non-focused frames > are visible only as stacked title bars above the currently focused frame. Isn't that a bug that needs to be fixed, regardless? Emacs will not handle iconified frames as it does visible frames, so sooner or later problems will appear due to that. > >> I haven't changed anything in my window manager config, and the i3 > >> package hasn't been updated since August. The only recent commit that > >> looks like it could be at all relevant is 2c0cd90083. > > > > And if you revert that change, does the problem go away? > > Yes it does! Then I guess we will have to revert at least part of that change. ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2022-04-24 15:27 UTC | newest] Thread overview: 28+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-10-23 18:17 bug#44180: 28.0.50; Emacs frames won't redisplay unless resized Eric Abrahamsen 2020-10-23 18:25 ` Eli Zaretskii 2020-10-23 19:07 ` Eric Abrahamsen 2020-10-23 19:38 ` Eli Zaretskii 2020-10-23 21:07 ` Eric Abrahamsen 2020-10-24 6:55 ` martin rudalics 2020-10-24 8:36 ` Eli Zaretskii 2020-10-24 20:19 ` Eric Abrahamsen 2020-10-25 15:08 ` Eli Zaretskii 2020-10-25 16:01 ` Eric Abrahamsen 2020-10-25 16:16 ` Eli Zaretskii 2020-10-25 16:28 ` Eric Abrahamsen 2020-10-25 16:55 ` Eli Zaretskii 2020-10-25 18:26 ` Eric Abrahamsen 2020-10-26 18:24 ` martin rudalics 2020-10-26 19:51 ` Eric Abrahamsen 2020-10-27 9:08 ` martin rudalics 2020-10-27 18:11 ` Eric Abrahamsen 2020-10-27 18:45 ` Eli Zaretskii 2020-10-27 19:48 ` Eric Abrahamsen 2020-10-31 8:28 ` Eli Zaretskii 2020-11-06 1:52 ` Eric Abrahamsen 2022-04-24 14:08 ` Lars Ingebrigtsen 2022-04-24 15:26 ` Eric Abrahamsen 2022-04-24 15:27 ` Lars Ingebrigtsen 2020-10-25 16:26 ` Sascha Sadeghian 2020-10-25 16:57 ` Eli Zaretskii 2020-10-24 8:03 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).