Thanks for sharing! <3

Okay, let’s go with xterm running bash, where the user ran ls, so xterm -> bash -> ls …

• ls never talks to xterm directly, it’s stdout/stderr are provided by bash
• bash effectively outputs a grid of characters to xterm, xterm doesn’t know about prompts or words or line feeds, just the grid
• every time ls outputs a line, bash adds a row of output to the grid that it sends to xterm
• if there’s not enough space for a new row, bash discards the top-most row, moves all other rows up by one row, and then inserts the row for the ls output

Now imagine a hypothetical fork of bash or some other new shell …

• the only thing different is the direction that the rows move off the edge of the screen when running out of space, that’s all

Thus, this is entirely a shell problem, with a shell solution

However, what I’ve neglected to mention so far is that terminal emulators and shells are almost certainly optimised for rows dropping off the top edge and new rows being added to the bottom edge

So, the role of a terminal emulator in this scenario could be to provide ANSI control characters or other protocol for operating just as quickly in the opposite direction, sure

Seems like a shell feature, and not a feature that a terminal emulator would implement