More complicated than it sounds

Posted Jan 13, 2026 16:56 UTC (Tue) by jengelh (subscriber, #33263)
In reply to: More complicated than it sounds by iabervon
Parent article: Asciinema: making movies at the command-line

>I want to record a screen session running programs that were started in a different terminal that disagrees with my current one over the number of columns occupied

GNU Screen has you covered (kind of): if any Screen window moves from one to multiple attached viewers, the terminal size of the first one wins. If the second/third/etc. viewer's space is larger than the first, the area will be properly delineated with dashes and all is fine. The problems only start if the second viewer has smaller space than the first. The problem is the same as having an RDP client window being smaller than the desktop it has to portray, but for text mode, there's extra wonky because you cannot scale-and-reproject text like you can with graphics.

>what happens if you put an xterm in that weird mode I've never used intentionally

screen size (or changes thereof) isn't all that weird. Weird mode is activated when you `echo -en '\e(0'`!

to post comments

More complicated than it sounds

Posted Jan 13, 2026 17:33 UTC (Tue) by iabervon (subscriber, #722) [Link] (2 responses)

The case I was thinking of with columns is that xterm and Mac terminals disagree as to whether emoji are one column wide or two, so, if you've got some emoji on a line, they'll disagree as to which character is in which column later on the line.

Changing the number of rows and number of columns is, in fact, not weird at all, aside from the time I maximized an iconified xterm and got something with 1900-character-long lines in a 1x2 font, which may test some limits in recording and playback.

More complicated than it sounds

Posted Jan 13, 2026 18:33 UTC (Tue) by jengelh (subscriber, #33263) [Link] (1 responses)

>xterm and Mac terminals disagree as to whether emoji are one column wide or two

ICU likely has an answer for that, but since xterm isn't using libicu, I would not be surprised if xterm does not have the contemporary picture of how things should be. That said, when I see https://metacpan.org/pod/Unicode::EastAsianWidth referring to U+2010 as "ambiguous-width", I'm losing all hope that there's one true answer for terminal implementations.

Perhaps we should just stop using emojis and anything exceeding cp437 altogether: I don't see the point of why `systemctl status ...` has to emit a U+25CF when U+2022 or an asterisk would have sufficed (because /usr/share/kbd/unimaps/cp437.uni traditionally mapped only that).

More complicated than it sounds

Posted Jan 15, 2026 8:59 UTC (Thu) by taladar (subscriber, #68407) [Link]

Using emojis is a good canary in the coal mine for western developers to notice when they broke support for other languages that need Unicode in their every day text.