unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Basil L. Contovounesios" <contovob@tcd.ie>
To: martin rudalics <rudalics@gmx.at>
Cc: Ramon Diaz-Uriarte <rdiaz02@gmail.com>, 48268@debbugs.gnu.org
Subject: bug#48268: 28.0.50; Blank screen when switching virtual desktops or when starting exwm (regression from 483c5e9)
Date: Fri, 14 May 2021 10:38:32 +0100	[thread overview]
Message-ID: <8735upejtz.fsf@tcd.ie> (raw)
In-Reply-To: <9406e305-897b-4561-e988-d6f12a2c03be@gmx.at> (martin rudalics's message of "Fri, 14 May 2021 09:09:26 +0200")

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

martin rudalics <rudalics@gmx.at> writes:

>> The problem is still present (using 43701a8) with XMonad: switching to a
>> different virtual desktop leads to a blank screen. It still responds to (at
>> least) some keyboard shortcuts (I can close with C-x C-x) and if the menu
>
> Is that C-x C-c or is C-x C-x special for you?
>
>> bar or the toolbar are active they also respond to some mouse clicks.
>>
>> Interestingly, the problem does not show up if I launch Emacs in an XMonad
>> session inside XMonad using xephyr.
>
> I'm a bit too dense to understand what you are doing and what does not
> work for you.  Is the behavior of Xmonad showing an Emacs frame OK as
> long as you do not switch to a different virtual desktop?  Are tool and
> menu bar shown in the blank screen case?  Does a blank screen blank out
> other things besides Emacs.  Does it work when Emacs is not supposed to
> be shown on that "different virtual desktop"?
>
> In either case please try to identify the commit that broke this - I
> have my slight doubts that it is 483c5e9.  Could it be already a190b4c?

Bisected the following behaviour on Xmonad to 483c5e9.  In the
screenshots below a red or black border indicates which frame Xmonad
thinks is selected or unselected, respectively.  Similarly a filled or
hollow box cursor shows which frame Emacs thinks is selected or
unselected, respectively.

0. emacs -Q


[-- Attachment #2: 0.png --]
[-- Type: image/png, Size: 13880 bytes --]

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


1. C-x 5 2
   [Ignore the missing scroll bar for now.]

2. (visible-frame-list) C-j C-m

3. (mapcar #'frame-visible-p (frame-list)) C-j C-m


[-- Attachment #4: 3.png --]
[-- Type: image/png, Size: 28052 bytes --]

[-- Attachment #5: Type: text/plain, Size: 413 bytes --]


4. Switch to another workspace.  At this point Emacs thinks neither
   frame is visible (I'm guessing they're all iconified).  I know this
   because in my customised compilation-finish-functions I do a
   notifications-notify for long-running compilations, but only if the
   compilation BUF does not satisfy (get-buffer-window BUF 'visible).

5. Switch back to the workspace with Emacs.

6. Repeat steps 2-3.


[-- Attachment #6: 6.png --]
[-- Type: image/png, Size: 18502 bytes --]

[-- Attachment #7: Type: text/plain, Size: 295 bytes --]


Note that the unselected frame is still iconified and lacks a toolbar.
Switching to that frame using Xmonad bindings would deiconify it.

7. C-x 5 o
   [Nothing changes.]

8. (select-frame (next-frame)) C-x C-e C-m
   [Nothing changes.]

9. (select-frame-set-input-focus (next-frame)) C-x C-e


[-- Attachment #8: 9.png --]
[-- Type: image/png, Size: 27986 bytes --]

[-- Attachment #9: Type: text/plain, Size: 184 bytes --]


This deiconifies the frame on the right, which now receives input, but
Xmonad still thinks the frame on the left is selected.

10. C-s focus RET C-e C-x C-e
    [AKA repeat step 9.]


[-- Attachment #10: 10.png --]
[-- Type: image/png, Size: 22696 bytes --]

[-- Attachment #11: Type: text/plain, Size: 96 bytes --]


Back to where we started, with both frames deiconified.

11. C-x C-e
    [AKA repeat step 9.]


[-- Attachment #12: 11.png --]
[-- Type: image/png, Size: 22899 bytes --]

[-- Attachment #13: Type: text/plain, Size: 1899 bytes --]


So to me it looks like some state/hint either on Xmonad's or Emacs' side
isn't refreshed or heeded when switching workspace.

I actually kind of like that Emacs frames on workspaces other than the
current one are considered invisible now, because of course they're not
visible :).

But switching back to that workspace should ideally make all frames
visible again.  I'm certain that there are both Xmonad and Emacs hooks
that allow the user to program this, but previously this wasn't needed.

BTW, I forgot to include in the recipe above that

  (mapc #'make-frame-visible (frame-list))

also changes nothing.  It seems that the only thing that deiconifies
frames is giving them input focus.

[ P.S. Let me know if fullscreen inline screenshots are annoying, and
  what to do instead.  I passed the images through pngquant so that at
  least their size is small. ]

> As soon as you have done that, I would like to give you a few
> instructions to make the code that broke this a NOOP and, in the worst
> case, make its execution optional on tiling WMs.

Thanks,

-- 
Basil

In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw3d scroll bars)
 of 2021-05-13 built on tia
Repository revision: 43701a84367b76ccc93ad46f89110486988eec10
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux bullseye/sid

Configured using:
 'configure 'CC=ccache gcc' 'CFLAGS=-O2 -march=native' --config-cache
 --prefix=/home/blc/.local --enable-checking=structs
 --with-x-toolkit=lucid --with-file-notification=yes --with-x'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
X11 XAW3D XDBE XIM XPM LUCID ZLIB

  reply	other threads:[~2021-05-14  9:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-06 22:43 bug#48268: 28.0.50; Blank screen when switching virtual desktops or when starting exwm (regression from 483c5e9) Mauricio Collares
2021-05-07  7:09 ` martin rudalics
2021-05-12  8:45 ` martin rudalics
2021-05-13 21:59 ` Ramon Diaz-Uriarte
2021-05-14  7:09   ` martin rudalics
2021-05-14  9:38     ` Basil L. Contovounesios [this message]
2021-05-14 10:02       ` Basil L. Contovounesios
2021-05-16  8:31   ` martin rudalics
2021-05-16 23:09     ` Ramon Diaz-Uriarte
2021-05-16  8:30 ` martin rudalics
2021-05-19 12:49   ` Mauricio Collares
2022-07-01 12:19     ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8735upejtz.fsf@tcd.ie \
    --to=contovob@tcd.ie \
    --cc=48268@debbugs.gnu.org \
    --cc=rdiaz02@gmail.com \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).