SPC popup not displaying with xmonad

[elvis-sik]

Description

I use Arch. I use xmonad with no desktop environment (I start it with startx). This issue might be related to xmonad.

When I open graphical emacs, and watch it open, it works fine. If, though, I open it, and quickly switch to another xmonad workspace, there is a bug. The SPC popup doesn't show on the screen. I can still command spacemacs with all keybindings, but the graphics do not display Also, the keyboard cursor is glitchy and stops showing up when I move around. The line on the bottom (I don't know its name, I mean that one that asks "do you want to save before quitting?" and says "SPC \ is undefined") doesn't show up (it is blank).

If this is not the place to report this, I'll go elsewhere. Otherwise, I can try to reproduce it on other machines. The reason I chose to report this first here is that other applications I use do not seem to suffer from this. In particular, vanilla graphical emacs (--no-init-file) does display that line on the bottom, so I think it does work correctly.

Reproduction guide 🪲

• Start xmonad
• Start graphical Emacs
• As soon as the Emacs window shows up, switch to another workspace
• Wait for the time it takes for Emacs to load
• Switch back to workspace with Emacs

Observed behaviour: 👀 💔
No SPC popup window, no cursor after moving around a bit.

Expected behaviour: ❤️ 😄
Graphics work okay.

System Info 💻

• OS: gnu/linux
• Emacs: 25.1.1
• Spacemacs: 0.105.22
• Spacemacs branch: pr-7070 (rev. 4c142ac)
• Graphic display: t
• Distribution: spacemacs
• Editing style: vim
• Completion: helm
• Layers:

(csv auto-completion better-defaults emacs-lisp git markdown
     (shell :variables shell-default-height 30 shell-default-position 'bottom shell-default-shell 'multi-term shell-default-term-shell "/bin/zsh" shell-enable-smart-eshell t)
     spell-checking smex syntax-checking version-control cscope gtags semantic xkcd github
     (c-c   :variables c-c  -default-mode-for-headers 'c-mode c-c  -enable-clang-support t)
     extra-langs html javascript shell-scripts sql yaml
     (python :variables python-test-runner 'pytest python-enable-yapf-format-on-save t)
     ipython-notebook
     (haskell :variables haskell-enable-ghc-mod-support t haskell-enable-hindent-style "gibiansky" haskell-enable-shm-support t haskell-completion-backend 'intero)
     evil-commentary
     (evil-snipe :variables evil-snipe-enable-alternate-f-and-t-behaviors t evil-snipe-repeat-scope "visible")
     react idris scheme ranger selectric evil-cleverparens speed-reading asm octave pandoc systemd extra-langs ess)

Edit: somehow I had expected and observed behavior switched.

[e-matteson]

I think I was able to reproduce this behavior, or something similar, using xmonad+MATE on Arch.

It looks to me like a window size problem. The bottom part of the window, including the spaceline and echo area, is cut off. If I move the cursor down below the cutoff point, it disappears. If I open helm-mini, I can only see the top part of the helm buffer. If I press space, I can't see which-key at all.

I have 2 monitors - if I open emacs on one monitor, and then switch to that workspace on the other monitor, the window size problem is fixed and everything is normal.

I couldn't reproduce it with emacs -Q, but that might just be because vanilla emacs loads so quickly that I don't have time to switch workspaces before it's done.

[gilbertw1]

@elvis-sik, I've got this exact same setup running XMonad on Arch Linux which I start manually each session with startx. I frequently start emacs and jump to another workspace while it starts up and have never seen the issue that you've described. Does this happen with a vanilla spacemacs install with a fresh .spacemacs file?

Also, if you can post your xmonad config file I can try and reproduce the issue.

[elvis-sik]

@gilbertw1 I did what you suggested. I tried vanilla Spacemacs. That seems to fix it. I grabbed back my old (bug-inducing) .spacemacs. and copied from it only the following things:

• dotspacemacs-configuration-layers
• dotspacemacs-additional-packages
• the font size
• dotspacemacs/user-config

The odd behavior then comes back.

With an xmonad as simple as

import XMonad
main = xmonad defaultConfig

It still happened.

Now, vanilla spacemacs loads in under 3 seconds, while with my old .spacemacs loading takes about 5 seconds. I tried binding a key in xmonad to spawn emacs in a specific workspace, so that I don't have to switch workspaces in a rush to trigger the behavior. This has led to confusing behavior that I don't think is related to the present issue.

[gilbertw1]

If you have the time, I would try adding your config to the vanilla config in steps to determine when the problem shows up.

1. dotspacemacs-configuration-layers - a package is to blame
2. dotspacemacs-additional-packages - an additional package is to blame
3. dotspacemacs/user-config - a piece of user config code is to blame

This would make it a lot easier to track down where the problem is coming from. Also, I noticed the report was for 0.105.22, have you since updated to the latest version of Spacemacs?

[elvis-sik]

This will take some time, but I promise to investigate this weekend.

[elvis-sik]

I am laughing. It took a while to go through installing a shitload of packages with crappy connection, and the bug wouldn't show up.

However, I can reliably make it come back and go by adjusting the font size 😆

In particular, I like large fonts, and with this configuration

   dotspacemacs-default-font '("Source Code Pro"
                               :size 20
                               :weight normal
                               :width normal
                               :powerline-scale 1.1)

things go wrong.

Spacemacs seems to think the window is larger than it actually is. Why that only happens when it loads without me being on that workspace? That must have something to do with how xmonad handles workspaces, IDK. Why that only happens with large fonts? I guess with small fonts the expected window size kinda matches the actual one.

To explain why I think this has to do with expected window sizes, I'll share two screenshots. I took both of them by using scrot -u (that is, take a screenshot of currently focused window). In both cases, spacemacs was the only thing on the workspace, so it should be expected that it would have the same appearance with either font size.

My understanding is that the cursor fades away because it is on the part of the window which isn't being actually displayed. So I can get it back simply by pressing k repeatedly.

Finally, by simply opening a second window, forcing emacs to resize, everything gets back to normal.

[elvis-sik]

Forgot to mention: yes, I did upgrade spacemacs.

[gilbertw1]

Ha, I wouldn't have guessed it would've been the font! 😃

After making the font size much larger I am able reliably reproduce this issue. I also noticed that if I make the font size smaller that a smaller window within the GUI is rendered for Spacemacs. My guess is that when the workspace is unfocused XMonad let's Spacemacs render at whatever size it wants to (which Spacemacs does based on the font size) and when it's later focused isn't properly getting the signal to resize itself.

Although I'm not entirely sure at this point if fault lies with Emacs, Spacemacs, or XMonad.

[elvis-sik]

I think we should try to fire vanilla Emacs up with a large font size to see if it does reproduce, now that we understand the cause of the problem. I have to prepare for tests for college, otherwise I'd do it right now...

[elvis-sik]

xmonad/xmonad#34
There is a workaround in this link in case anyone ends up here. Seems to be a GTK bug.

Anyway, I cannot fire the bug anymore. Can you, @gilbertw1

[gilbertw1]

Nope, doesn't seem to be an issue for me anymore either. Guess something somewhere got fixed :)