GNU bug report logs - #44180
28.0.50; Emacs frames won't redisplay unless resized

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 44180 in the body.
You can then email your comments to 44180 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; Emacs frames won't redisplay unless resized
Date: Fri, 23 Oct 2020 11:17:16 -0700

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))

Message #8 received at 44180 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 44180 <at> debbugs.gnu.org
Subject: Re: bug#44180: 28.0.50; Emacs frames won't redisplay unless resized
Date: Fri, 23 Oct 2020 21:25:32 +0300

> From: Eric Abrahamsen <eric <at> 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.

Message #11 received at 44180 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44180 <at> debbugs.gnu.org
Subject: Re: bug#44180: 28.0.50; Emacs frames won't redisplay unless resized
Date: Fri, 23 Oct 2020 12:07:33 -0700

On 10/23/20 21:25 PM, Eli Zaretskii wrote:
>> From: Eric Abrahamsen <eric <at> 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...

Message #14 received at 44180 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 44180 <at> debbugs.gnu.org
Subject: Re: bug#44180: 28.0.50; Emacs frames won't redisplay unless resized
Date: Fri, 23 Oct 2020 22:38:43 +0300

> From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
> Cc: 44180 <at> 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?

Message #17 received at 44180 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44180 <at> debbugs.gnu.org
Subject: Re: bug#44180: 28.0.50; Emacs frames won't redisplay unless resized
Date: Fri, 23 Oct 2020 14:07:00 -0700

On 10/23/20 22:38 PM, Eli Zaretskii wrote:
>> From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
>> Cc: 44180 <at> 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!

Message #20 received at 44180 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 44180 <at> debbugs.gnu.org
Subject: Re: bug#44180: 28.0.50; Emacs frames won't redisplay unless resized
Date: Sat, 24 Oct 2020 08:55:48 +0200

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

Message #23 received at 44180 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 44180 <at> debbugs.gnu.org
Subject: Re: bug#44180: 28.0.50; Emacs frames won't redisplay unless resized
Date: Sat, 24 Oct 2020 11:03:26 +0300

> From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
> Cc: 44180 <at> 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.

Message #26 received at 44180 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>, "J. Scott Berg" <jsberg-bnl <at> outlook.com>
Cc: eric <at> ericabrahamsen.net, 44180 <at> debbugs.gnu.org
Subject: Re: bug#44180: 28.0.50; Emacs frames won't redisplay unless resized
Date: Sat, 24 Oct 2020 11:36:58 +0300

> Cc: 44180 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> 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?

Message #29 received at 44180 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 44180 <at> debbugs.gnu.org
Subject: Re: bug#44180: 28.0.50; Emacs frames won't redisplay unless resized
Date: Sat, 24 Oct 2020 13:19:45 -0700

[Message part 1 (text/plain, inline)]

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

[20201024_13h14m00s_grim.png (image/png, attachment)]

Message #32 received at 44180 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: rudalics <at> gmx.at, 44180 <at> debbugs.gnu.org
Subject: Re: bug#44180: 28.0.50; Emacs frames won't redisplay unless resized
Date: Sun, 25 Oct 2020 17:08:38 +0200

> From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  44180 <at> 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.

Message #35 received at 44180 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 44180 <at> debbugs.gnu.org
Subject: Re: bug#44180: 28.0.50; Emacs frames won't redisplay unless resized
Date: Sun, 25 Oct 2020 09:01:20 -0700

On 10/25/20 17:08 PM, Eli Zaretskii wrote:
>> From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,  44180 <at> 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.

Message #38 received at 44180 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: rudalics <at> gmx.at, 44180 <at> debbugs.gnu.org
Subject: Re: bug#44180: 28.0.50; Emacs frames won't redisplay unless resized
Date: Sun, 25 Oct 2020 18:16:07 +0200

> From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
> Cc: rudalics <at> gmx.at,  44180 <at> 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?

Message #41 received at 44180 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44180 <at> debbugs.gnu.org
Subject: Re: bug#44180: 28.0.50; Emacs frames won't redisplay unless resized
Date: Sun, 25 Oct 2020 09:28:09 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
>> Cc: rudalics <at> gmx.at,  44180 <at> 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.

Message #44 received at 44180 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 44180 <at> debbugs.gnu.org
Subject: Re: bug#44180: 28.0.50; Emacs frames won't redisplay unless resized
Date: Sun, 25 Oct 2020 18:55:14 +0200

> From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
> Cc: 44180 <at> 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

Message #47 received at 44180 <at> debbugs.gnu.org (full text, mbox):

From: Sascha Sadeghian <sadeghian <at> acm.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Eric Abrahamsen <eric <at> ericabrahamsen.net>, 44180 <at> debbugs.gnu.org
Subject: bug#44180: 28.0.50; Emacs frames won't redisplay unless resized
Date: Sun, 25 Oct 2020 17:26:18 +0100

Eli Zaretskii <eliz <at> 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!

Message #50 received at 44180 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sascha Sadeghian <sadeghian <at> acm.org>
Cc: eric <at> ericabrahamsen.net, 44180 <at> debbugs.gnu.org
Subject: Re: bug#44180: 28.0.50; Emacs frames won't redisplay unless resized
Date: Sun, 25 Oct 2020 18:57:38 +0200

> Date: Sun, 25 Oct 2020 17:26:18 +0100
> From: Sascha Sadeghian <sadeghian <at> acm.org>
> Cc: Eric Abrahamsen <eric <at> ericabrahamsen.net>, 44180 <at> 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.

Message #53 received at 44180 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44180 <at> debbugs.gnu.org
Subject: Re: bug#44180: 28.0.50; Emacs frames won't redisplay unless resized
Date: Sun, 25 Oct 2020 11:26:23 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
>> Cc: 44180 <at> 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.

Message #56 received at 44180 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 44180 <at> debbugs.gnu.org
Subject: Re: bug#44180: 28.0.50; Emacs frames won't redisplay unless resized
Date: Mon, 26 Oct 2020 19:24:21 +0100

> 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

Message #59 received at 44180 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 44180 <at> debbugs.gnu.org
Subject: Re: bug#44180: 28.0.50; Emacs frames won't redisplay unless resized
Date: Mon, 26 Oct 2020 12:51:37 -0700

martin rudalics <rudalics <at> 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...

Message #62 received at 44180 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 44180 <at> debbugs.gnu.org
Subject: Re: bug#44180: 28.0.50; Emacs frames won't redisplay unless resized
Date: Tue, 27 Oct 2020 10:08:18 +0100

>> 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

Message #65 received at 44180 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 44180 <at> debbugs.gnu.org
Subject: Re: bug#44180: 28.0.50; Emacs frames won't redisplay unless resized
Date: Tue, 27 Oct 2020 11:11:26 -0700

[Message part 1 (text/plain, inline)]

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

[master.txt (text/plain, attachment)]

Message #68 received at 44180 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: rudalics <at> gmx.at, 44180 <at> debbugs.gnu.org
Subject: Re: bug#44180: 28.0.50; Emacs frames won't redisplay unless resized
Date: Tue, 27 Oct 2020 20:45:58 +0200

> From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  44180 <at> 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.

Message #71 received at 44180 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44180 <at> debbugs.gnu.org
Subject: Re: bug#44180: 28.0.50; Emacs frames won't redisplay unless resized
Date: Tue, 27 Oct 2020 12:48:52 -0700

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,  44180 <at> 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!

[master.txt (text/plain, attachment)]

[revert.txt (text/plain, attachment)]

Message #74 received at 44180 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 44180 <at> debbugs.gnu.org
Subject: Re: bug#44180: 28.0.50; Emacs frames won't redisplay unless resized
Date: Sat, 31 Oct 2020 10:28:03 +0200

> From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
> Cc: 44180 <at> 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?

Message #77 received at 44180 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44180 <at> debbugs.gnu.org
Subject: Re: bug#44180: 28.0.50; Emacs frames won't redisplay unless resized
Date: Thu, 05 Nov 2020 17:52:59 -0800

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
>> Cc: 44180 <at> 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.)

Message #80 received at 44180 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 44180 <at> debbugs.gnu.org
Subject: Re: bug#44180: 28.0.50; Emacs frames won't redisplay unless resized
Date: Sun, 24 Apr 2022 16:08:30 +0200

Eric Abrahamsen <eric <at> 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

Message #85 received at 44180 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 44180 <at> debbugs.gnu.org
Subject: Re: bug#44180: 28.0.50; Emacs frames won't redisplay unless resized
Date: Sun, 24 Apr 2022 08:26:43 -0700

On 04/24/22 16:08 PM, Lars Ingebrigtsen wrote:
> Eric Abrahamsen <eric <at> 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.

Message #88 received at 44180 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 44180 <at> debbugs.gnu.org
Subject: Re: bug#44180: 28.0.50; Emacs frames won't redisplay unless resized
Date: Sun, 24 Apr 2022 17:27:47 +0200

Eric Abrahamsen <eric <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.