I know Google just donated to Trump’s inauguration, and also does all the stupid surveillance capitalism crap that Google does, but I just compared prices, and Google Workspace is a few dollars per month cheaper per user than Proton is, for my needs (family, custom domain names, etc)

We’ve been on Proton for a few years, and it’s fine, but we do also have Pixel Android phones, and not using Google services constantly feels like swimming upstream, plus all family members also still end up having to use Google services for work, anyway

It’s just not practical for me to de-Google, which is a shame, so I think I’ll be switching in a few months, unless pricing changes significantly :S

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