this happens only in this one terminal window

and only the shell is affected, i can’t even type # without it appearing as £

opening this file in vim is fine though!

TIL: there is an escape sequence that makes a line wide (\e#6), which Konsole apparently understands

   

Terminals are weird.
I'm having so much fun with this lmao
@nilsding why is this possible xD
@dancrescentwolf I have no idea, but my shell prompt is now    
@nilsding my Mastodon client interestingly gives each letter a grey background, making it almost look like the letters have been cut out from a newspaper heading. Also, that 'i' is chonky!
@dancrescentwolf
@FiXato @dancrescentwolf the emojis have that background :3

@FiXato @nilsding

I think these letters are basically emotes, tho ?

@nilsding @dancrescentwolf It's a feature of DEC terminals since the VT100 and is there for compatibility with them.

Not finding the hard evidence, but I wonder if this was originally a DECwriter feature they carried over to their video terminals.

@dancrescentwolf @nilsding

ESC # 3 DEC double-height line, top half (DECDHL)
ESC # 4 DEC double-height line, bottom half (DECDHL)
ESC # 5 DEC single-width line (DECSWL)
ESC # 6 DEC double-width line (DECDWL)
ESC # 8 DEC Screen Alignment Test (DECALN)
from the xterm docs

Xterm Control Sequences

@nilsding there exist escape sequences for resizing and moving the terminal window. Iirc one can config xterm to accept them, no idea about console.
@nilsding Behaves weird in my Konsole. It renders half the letter until I alt-tab, then it rerenders it properly.
@nilsding Okay so as far as I understand from Wikipedia, \e#3 is supposed to be the top half of the letters, and \e#4 is supposed to be the bottom half (which is why it behaves so weird in your earlier example). I guess Konsole just tries its best to render full letters.
If you repeat the line twice (in a single command, separated with line break), once with \e#3 and once with \e#4, it renders properly.
If you input different lines for the \e#3 and the \e#4 parts, Konsole starts freaking out.

@nilsding

I was compelled to make this happen directly inside of bash.

https://gist.github.com/infinityb/d7a09d1b0c0ee0c234e26bb48845525e

README.md

GitHub Gist: instantly share code, notes, and snippets.

Gist
@nilsding yes, hello @dnkl I'd like to report a critical missing feature of foot(1)
@nilsding oh yeah, these are holdovers from actual VT-100 series serial terminals. note that technically #4 is the bottom-half of a double-height text block, so you need to specify #3 on actual hardware for the top half, and are responsible for displaying the same text twice.

@dragonminded omfg this is so cool, i'm on a proper terminal! :3

but that explains why the text is split in half like that!

@nilsding basically, under the hood, this was an 80x24 (or 132x24) text mode only display (hey, there's where peoples' dogmatic insistence on 80 character lines comes from!!!) and those escape sequences caused it to change the "sprite mapping" for a character at a specific spot. they handled the double wide case because i guess that just means advancing the cursor, but given the terminal supports intelligent scrolling within a window, i guess it was too difficult to handle it properly for double tall. so it's the programmer's responsibility to echo the text twice. you can skip that, at which point the hardware will actually display only the top or bottom half, as expected.

also i was gonna get a picture of these posts on the terminal but for some reason my vt-100 mastodon client is actin' up rn.

@nilsding oh jk it started working again idgi lmao here u can be on a proper terminal again :3

side note: thanks for alt texting, it makes using this interface possible!

@nilsding I found it necessary to try this in Windows Terminal and... yay!
@nilsding I'm curious where these are defined... where did you discover them?

@whimsy I just noticed that I've never replied to this -- sorry for the delay ^^

basically I discovered them while investigating the alternative charset thingy from the opening post where my # includes were replaced with £. eventually it lead me to discover vttest, a tool for testing terminal (emulator)s from the xterm maintainer. while running it I noticed that some tests displayed wide and large text -- something I've never seen before in a terminal window!

thankfully the source code of vttest is relatively easy to grep through, which finally led me to these escape sequences

VTTEST – VT100/VT220/XTerm test utility

vttest tests the functionality of a VT100/VT220/VT420 terminal (or emulator, in particular xterm) with menus and demo screens

@nilsding Neat. I did some research on my own at the time and discovered the double-width/double-size codes originated on the VT-100, which makes sense, but surprising that I'd never heard of them before.
@nilsding Please stop. This is probably illegal. 😆
@remaster if I understand it correctly \e#4 should've only printed the bottom half of the large text
@nilsding Yeah, perhaps the implementation is so that \e#3 prints an empty line and \e#4 prints the actual text in the available space. 🤔
Terminals have a lot of complex features. I have a VT420 that I’ve found some fun stuff on.
@nilsding oh yeah you're supposed to do a first line for the top half, and a second line (slightly different escape sequence) for the bottom half!
@nilsding its a very cool feature that I use sometimes. there is also an ansi escape code for blinking text and for two-line text, so you can display all sorts of large text

@aks

gcc main.c || printf "\e#6This code is ass. Compilation terminated.\n"
@nilsding looks like double-width
@nilsding This is weird – pterm (PuTTY terminal for *nix) understands \e#6), but PuTTY itself doesn't…
@nilsding …and funnily enough, \e#8 works on both.
@nilsding Correction, I was testing inside screen. Works fine in PuTTY otherwise.
@nilsding xterm too (debian 12)
@nilsding This makes me think of the double-wide sprites in old Atari 2600 VCS games like Air Sea Battle. Or was it Combat?
@nilsding Windows Terminal on both CMD and PowerShell also understands it. Just checked
@nilsding: same tbh, but rude to point it out.
@jnkrtech

@nilsding ah! something probably dumped out binary garbage that included an ANSI escape code to switch your terminal's codepage

vim runs in the secondary buffer that has separate state

@lambda terminals were a mistake

@lambda but yes, that was it.

to reproduce:

printf '\e(A'