I've just realized that termios's struct winsize has, in addition to the two fields storing the number of cells, another two fields for the size in pixels. It is filled out by some terminal emulators. We could join them.

It's unclear to me what the intent and the exact semantics (see below) of this field. There's hardly any info I could find on the net.

One might argue that a client app running inside the terminal emulator should not be able to query this information, it's none of its business. However, we already break that by answering to the "\e[14t" sequence with the window size in pixels, plus we break these kinds of principles at other places too (e.g. focus in/out reporting).

This piece of information might become handy if we ever implement some kind of image rendering support. Being able to synchronously query these values is a huge aid for apps intending to leverage this feature, rather than having to expect an asychronous response to an escape sequence which is a real PITA.

Also, this gives us a convenient method of notifying apps about font size change: simply a SIGWINCH is sent to them. I've checked that the Linux kernel indeed sends this signal even if only the pixel size changes, and ssh also forwards this event.

---

To quickly query the values (e.g. to see if an emulator supports these), use either a "strace stty size", or this python snippet:

import array, fcntl, termios
buf = array.array('H', [0, 0, 0, 0])
fcntl.ioctl(1, termios.TIOCGWINSZ, buf)
print(buf)

Beware of the stupid output order: y x x y.

---

These variables are forwarded by ssh and screen, but are not forwarded to mc's subshell (I can fix it if it becomes important) or in tmux. Any other important software along these lines to test? [Actually screen and tmux probably won't be important... at least not until they also implement a VTE-compatible image support.]

xterm forgets to update these variables on font size change. (I'm lazy at the moment to figure out how to change the font size runtime in the other emulators.)

---

Here's a support matrix of some emulators.

"base" means that the reported numbers are the number of cells multiplied by each cell's size, "extended" means it also includes the standard padding (border), the extra padding in case the window size is not grid-aligned (e.g. maximized), and the scrollbar.

                \e[14t       ws_[xy]pixel
xterm            base(*)      extended
urxvt            extended     base
pterm (putty)    extended     base
st (suckless)    -            base
VTE              base         -
konsole          -            -
terminology      -            -

(*) Ctrl + right click -> Allow Window Ops

I especially "love" how xterm and urxvt are the exact opposite of each other :-)

On one hand, I don't see the point in reporting the "extended" size, _that_ (i.e. UI chrome) is really not the business of the client app. What if these emulators supported multiple tabs, would they also include the tab bar's size? What if they had CSD? ... Also, it's not helpful at all if we're about to use this feature for drawing pixel graphics.

On the other hand, what's the goal of this feature? If the goal would be to know the cell size, why not store that in the first place?

Probably noone knows, it's a legacy leftover that we might try to hijack for a certain purpose...