XSetWMNormalHints

[Jason Weber]

I recently upgraded from Debian 10 to Debian 11.

My gvim used to always do resize increments by character.  Dragging a window edge would resize the window by snapping to the nearest whole character.  I would even see the window size written on screen, as characters, not pixels.  Now I see sizes by pixels.  My xterm windows still resize by character, as before.

I use fvwm on my host, but I also tried this on a PopOS VM, for whatever the default WM is for that.  The Windows 10 VM does still resize on characters.

For what I have read, this is part of ICCCM, specifically setting PResizeSize with XSetWMNormalHints().  The only thing I saw in the vim source is

#define XSetWMNormalHints XSETWMNORMALHINTS

I'm not sure where that is even used.

I've been digging around for a few hours now and was hoping someone could give me hint where to look next.

[M]

чт, 31 мар. 2022 г. в 21:10, Jason Weber <baboon...@gmail.com>:

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/aeb6fc82-46de-42a7-90af-e5b3484d9c55n%40googlegroups.com.

Hello,

I guess you mean 8.2.2709 (see also Issue #5602 and #8008;  PR #6466 and #8027 on Vim's github page).

Note that the GVim window was and still is resized by pixel, while the text area displays a whole number of chars. The difference is that few "leftover" pixels previously were on the right of the vertical scrollbar, while now they can reside in the text area (and so have "Normal" color). Is there any problem with this?

Regards,

Matvey

[Jason Weber]

I mean where the actual X11 window is constrained to expand/shrink by steps of the font's character width/height.

This has been the case, by my witness, for as long as I recall.  It seems to still be the case on Windows 10.

I don't have a right or bottom scrollbar, just the left.

I asked someone on Arch, and he said the same change happened to him a short while back.

[Bram Moolenaar]

Jason Weber wrote:

> I mean where the actual X11 window is constrained to expand/shrink by steps
> of the font's character width/height.
> This has been the case, by my witness, for as long as I recall. It seems
> to still be the case on Windows 10.
>
> I don't have a right or bottom scrollbar, just the left.
>
> I asked someone on Arch, and he said the same change happened to him a
> short while back.

It might be that this conflicts with filling the whole screen when
maximized. When resizing the GUI window by dragging the edge, you would
want to resize by the character cell size, so that there is no "half
character" gap somewhere. When maximized you do want that gap, to avoid
the Vim window now completely filling the screen. Not sure if we can
have both. Can the window hints be removed when maximized, and added
back when not?

--
Compilation process failed successfully.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Jason Weber]

Yes, the direct evidence is that you get that snap-snap coarse behavior when you drag a window edge.

Additionally, there can be text feedback from the WM, so that if you want to confine yourself to a certain width

and/or height to write in, you can just look at the numbers during resize.  I even have key mappings to adjust a

window width to say "80" or "100", which will be by-character if this all works.  These things work on xterm still,

so that seems like a good reference.

If this wasn't a result of XSetWMNormalHints all along, then I wonder what other mechanism might have been

in play when it previously worked.  I didn't find anything in the WM docs other than ICCCM.

I would expect there to be some code for this in VIM if it works in Win32.

Anyhow, I don't think I've used XSetWMNormalHints, but I would expect to call it after XSetWMProperties

on the newly created window.  To speculate, I'd imagine that a WM might just cache the values when the
window is mapped to screen.

For xterm, doing maximize leaves a gap on the right and bottom.  I'm fine with that, but then, I generally never
use maximize for anything, probably since I've come to expect odd behavior.  Checking the Windows 10 VM, where

I can easily change screen size using the VM window, VIM seems to switch to pixel-incremental mode when full screen,
and then back to char-incremental when unmaximized.

As far as code, I hesitate to suggest adding something new if there was something else already in there

potentially trying to do the same thing.

From a user point of view, a simple opt-in 'set' variable would make me happy.