swm-gaps crashes with _NET_FRAME_EXTENTS negative value

[podiki]

I think I'm at fault for this with how I fixed #178 and #75, as I'm suddenly getting a crash with the last value of _NET_FRAME_EXTENTS negative (end of maximize-window)

stumpwm-contrib/util/swm-gaps/swm-gaps.lisp

Line 97 in 6514148

(xlib:change-property (window-xwin win) :_NET_FRAME_EXTENTS

(I'm not sure why this is cropping up now, somehow changing a font in emacs...???)

The offending line causing this looks to be what I introduced to not do gap subtraction unless needed, for the height

stumpwm-contrib/util/swm-gaps/swm-gaps.lisp

Line 67 in 6514148

(>= height (- (frame-height frame) oh)))

Removing that fixes it for the one crash I'm getting, but not sure why this started happening. I don't quite understand the different offsets and sizes to know what went wrong and what the proper fix is here, any ideas?

[jakecoble]

Are you using the mode-line and getting the additive inverse of your mode-line height? (e.g. My mode line is 20 pixels high, so I was getting -20.) The frame height doesn't include the mode line, so I was getting crashes until I changed it to (stumpwm::frame-display-height (window-group win) frame) instead. Not sure why it's less consistent for you, but that might fix it.

[cspark-development]

I'd like to make a follow up, the fix listed by @jakecoble DOES WORK. However, (I'm not sure if this is related with changing a font in emacs, that may also cause it despite the supposed fix), when launching Emacs specifically, it will still crash. It seems Emacs for me is managing its size in some way, and emacs used to do this on other distributions and window managers, leaving blank space even if fullscreen in the bottom and right corners. I added a message to debug the output of the height variable once its subtracted the modeline height. As seen here:

The output of ANY WINDOW that is not Emacs is shown consistently as follows:

However, Emacs :

Once it is opened and not fully loaded, it gives the correct height.

Fully opened and the height changes by 5 pixels for some reason.

This change is I believe why Emacs is returning a negative height value.

I'm no lisp hacker, so I'm not sure how to deal with this without a hacky approach to check specifically for Emacs or something. I still have yet to check it with other windows that may change its geometry on itself. I'm curious if there are any mitigations against this, perhaps atleast putting a request on the main stumpwm repo to atleast get "(set-window-geometry win :x wx :y wy :width width :height height :border-width 0)" to exit gracefully if receives a negative value if not done already. Window Managers like AwesomeWM and such which i've tried has handled this, despite retaining the broken geometry. I'd like to repeat again that this was not a one time Emacs error with my system, I have had this issue persist across various linux distributions, and emacs distributions ranging from doom emacs, spacemacs and my own handrolled configuration.

If anyone has this problem, I hope this at least serves as useful.

[haoxiangliew]

The fix by @jakecoble works and tested in my fork of stumpwm-contrib.

As for @Spacur 's problem, I have encountered this bug in Emacs where setting certain font sizes in Emacs can cause crashes. Setting (setq frame-resize-pixelwise t) fixes all problems (including the border that appears with Emacs's window) for me, as well as trying out fractional font sizes, as I think Emacs and StumpWM is calculating font sizes incorrectly (ex. 10 -> 10.5).

[podiki]

Sorry I didn't follow up here (haven't used Stump in a while). I also had I think the same problem with Emacs (crashing with some fonts or font sizes). Perhaps I should come back to Stump, but unfortunately stumpwm/stumpwm#763 was a blocker (I rarely need multiple monitors, but certainly don't want it crashing when I do).

[heiwiper]

why did no one submit a PR to fix this issue ?

[podiki]

Happy to help debug/test, just came back to StumpWM. I haven't experienced this crash again though, but I'll be on the look out. Do we have a current reproducer?

[heiwiper]

I don't really recall what was the issue in the first place, but I remember that this is how I fixed it.

Here's the diff from the link:

-                 (>= height (- (frame-height frame) oh)))
+		  (>= height (- (stumpwm::frame-display-height (window-group win) frame) oh)))