Annoying extra white space at bottom of terminal windows (while in X)

revivaloflostart · 2021-02-14 07:46:13

I'm on a fresh arch install with the following:
nvidia, nvidia-utils, neovim, rxvt-unicode (via urxvtd/urxvtc), i3

I've had arch on this desktop before and never had this issue in the past so I'm unsure what is actually causing this.
I've tried running bspwm instead of i3 so i'm pretty sure it's not the window manager.

My .Xresources only has a couple of lines for fonts related things so it's unlikely to be a cause as well.
Anyone have any idea?

When the terminal windows are small, like when i float a window. then the extra white space are gone and things appear normal.
When i maximize a term full screen or have it tiled and maxed vertically then the extra white space is very apparent.

Here are some pics:
small floated term window: https://i.imgur.com/gh8EmNm.png
when terms are full-screened or max'ed vertically: https://i.imgur.com/tfpfWE3.png (even the right side shows a bit of the white space as well)

someone said it's something related to size hinting? but how do i actually fix this issue though? and how come i never had this problem before?

seth · 2021-02-14 09:11:49

The terminal geometry is measured in multple of chars - ie. it has a fixed size increment > 1x1 that relates to your font size.
Run "xwininfo -size" and click the terminal for details.

Eg. if the increment is 6x14 and your monitor is 1920x1200, you can get a perfect width (320*6) but only 85*14=1190 px height.
The WM can decide whether it allows the window gemetry to maximize still (and have a gap at the bottom of the window) or restrict the maximized size to a multiple of the increment (and have a gap above/below the window)

The relevant factors are
- the size increment (typically driven by your font geometry for terminals)
- the output geometry (monitor size)
- panels and other strutting elements that restrict the maximization area
- for a tiling WM also how it treats the window geometry in relation to the grid

idk. whether i3wm allows you to configure when to obey to the size increment, so the only mitigation strategies would be the font or padding settings in your terminal to align the size increment w/ your workspace geometry.

respiranto · 2021-02-14 09:26:51

The white border space is formed where urxvt cannot add another full row/column of characters. This is why it does not appear on floating windows, where the window's size most likely is auto-fitted to avoid this issue.

Instead of the bars, there should simply be extended background color. Unfortunately, my Arch machine is not yet setup to use a tiling WM. Cannot reproduce on Debian/XMonad.

Have you tried another terminal emulator? Starting urxvt with default options (except for background)? If this does not help, I'd suggest downgrading urxvt (and deps?) in order to potentially locate a bug.

revivaloflostart · 2021-02-14 09:55:47

respiranto wrote:

The white border space is formed where urxvt cannot add another full row/column of characters. This is why it does not appear on floating windows, where the window's size most likely is auto-fitted to avoid this issue.
Instead of the bars, there should simply be extended background color. Unfortunately, my Arch machine is not yet setup to use a tiling WM. Cannot reproduce on Debian/XMonad.
Have you tried another terminal emulator? Starting urxvt with default options (except for background)? If this does not help, I'd suggest downgrading urxvt (and deps?) in order to potentially locate a bug.

i've tried Alacritty (default with no setup) and got the same extra white row

respiranto · 2021-02-14 12:13:21

revivaloflostart wrote:

i've tried Alacritty (default with no setup) and got the same extra white row

Hm, I expected rxvt or some close dependency to be the culprit.

Anyways, I just installed XMonad (and subsequently i3) on Arch; with neither of them could I reproduce the issue.

Just to be sure: The border appears irrespective of vim running (as seen in the pictures)? Otherwise, it could simply be vim painting the background in a color (grey) different from the background color (white).

revivaloflostart · 2021-02-14 12:27:52

respiranto wrote:

revivaloflostart wrote:
i've tried Alacritty (default with no setup) and got the same extra white row
Hm, I expected rxvt or some close dependency to be the culprit.
Anyways, I just installed XMonad (and subsequently i3) on Arch; with neither of them could I reproduce the issue.
Just to be sure: The border appears irrespective of vim running (as seen in the pictures)? Otherwise, it could simply be vim painting the background in a color (grey) different from the background color (white).

ya. it's not just terminals with vim opened. it's all terminals. i only showed vim because the cmdline area of vim (with colorscheme running) makes it easier to see the extra white space problem.

i also noticed a weird issue with weechat (not sure if it's related or whether it might give us some clue).
Normally (from my past experience), weechat's input bar is just one line. and you type and type... but you're within that one line.

But as it is now, when i type in weechat's input bar. when it reaches the right side of the input bar. the termianl window produced another line underneath and it just keeps going the more i typed. here is a picture to demonstrate:

is this also perhaps due to the same issue? i dont remember this behavior in weechat in the past.

Last edited by revivaloflostart (2021-02-14 12:30:19)

respiranto · 2021-02-14 12:33:52

revivaloflostart wrote:

ya. it's not just terminals with vim opened. it's all terminals. i only showed vim because the cmdline area of vim (with colorscheme running) makes it easier to see the extra white space problem.

So vim does set the background color (grey), and rxvt has a background color of white?

In that case, all is as expected. Vim can only set the background of single characters. The border is not inhabited by characters.

Concerning weechat, that seems unrelated to me.

seth · 2021-02-14 13:55:41

Did anyone bother to read my comment?
What you see is neither weird nor a bug, it's a direct consequence of how terminals work and window managers - might - treat them.

Edit:
For urxvt try playing w/ the internalBorder, eg.

urxvt -internalBorder 12

adds a 12px padding - you can then add that to your xrdb.

You can also control the border colors with an escape code

printf '\033]708;#990000\007'

"#990000" is a nice red, but obviously you can pick any 24 color.
Notice that this doesn't work if you use a pixbuf enabled urxvt and a background image.

Last edited by seth (2021-02-14 14:12:28)

respiranto · 2021-02-14 14:28:40

seth wrote:

Did anyone bother to read my comment?
What you see is neither weird nor a bug, it's a direct consequence of how terminals work and window managers - might - treat them.

I initially misunderstood the stated problem thinking that the background color of urxvt did not match the white at the edges.
Apart from that, I simply did not read your comment before submitting my first one.

Arch Linux

#1 2021-02-14 07:46:13

Annoying extra white space at bottom of terminal windows (while in X)

#2 2021-02-14 09:11:49

Re: Annoying extra white space at bottom of terminal windows (while in X)

#3 2021-02-14 09:26:51

Re: Annoying extra white space at bottom of terminal windows (while in X)

#4 2021-02-14 09:55:47

Re: Annoying extra white space at bottom of terminal windows (while in X)

#5 2021-02-14 12:13:21

Re: Annoying extra white space at bottom of terminal windows (while in X)

#6 2021-02-14 12:27:52

Re: Annoying extra white space at bottom of terminal windows (while in X)

#7 2021-02-14 12:33:52

Re: Annoying extra white space at bottom of terminal windows (while in X)

#8 2021-02-14 13:55:41

Re: Annoying extra white space at bottom of terminal windows (while in X)

#9 2021-02-14 14:28:40

Re: Annoying extra white space at bottom of terminal windows (while in X)

Board footer