I'm going to have to think about exactly how to do this best. My one concern would be to either handle line-wrap properly, or handle overflow.

Overflow is "easy" if you assume a line is always of a reasonable max length: Just turn off wraparound, and print the whole line.

But if you want to handle super-long lines, you'd at least want a way to "clip" the text you're sending to the terminal to avoid the cost of outputting all of it to the terminal each time you're moving past it.

Depending on how, maybe the minimum width of a glyph is instead what you worry about in cases where you don't wrap.

Let's say the terminal is 80 monospaced characters wide, and you switch on proportional mode.

If you have a long line, you just want to know the maximum number of characters you should output to guarantee that the proportional region is full.

Maybe just an escape to get the terminal to report the maximum number of proportional glyphs that will fit in a given field is enough.

The worst case scenario then is a screen full of I's or 1's or similar, where maybe you spit out twice as much text that the terminal propmptly clips away, but most of the time you'd only output a few more characters than necessary, so I think that's fine.

Not sure how to cleanly extend that to allow wraparound without the app needing to be aware of the font. E.g. a text editor will want to be able to figure out which point in the text should be at the top of the screen as you scroll. Doing that with wraparound without knowing font extent would require some other way to measure. Printing a bit extra might be fine.

For non-interactive applications, none of this would matter - you'd just print everything the same way you do now, and let the terminal sort out the rest.

Maybe adding experimental support for that would be a good starting point. E.g. being able to cat a tab-separated file and get an aligned table with proportional text would be an awesome test case.

I'm now also curious how much would break if I "just" start doing proportional rendering by default when not using the alternate screen.

E.g. anything trying to do layout with spaces would obviously break, but I'm wondering if maybe it'd affect few enough non-interactive programs that making that the default, and just wrap/alias the few things that'd break. My shell already filters output of a number of commands to colorize them, like pstree, so having a small "blacklist" of programs I use that'd need to be switched back to monospaced, or filtered further, wouldn't necessary be a big deal.

Damn you for adding more things to my TODO list :-)

I feel like overflow as an error-handling thing would be reasonable to handle in a variety of ways; however, if you start trying to offer HTML-like word wrap inside tables, you start experiencing difficult optimization problems. I think it's probably better to let applications split paragraphs into lines based on some kind of heuristic, embedding the newlines into the text that the terminal has to handle.

A lot of things would benefit from being able to output tab-separated output. (I feel like https://okmij.org/ftp/papers/DreamOSPaper.html used to have screenshots?) Things like pstree want a "dot leader" approach, where you tag a cell (with an escape sequence?) as being padded out to the column width not with whitespace but with more copies of its contents. In http://canonical.org/~kragen/sw/dev3/alglayout.py I'm doing it with the ~ operator, but that's just nesting stacks of hboxes and vboxes for layout and outputting just fixed-width ASCII, not using full-fledged tables and outputting pixels. (There's an OCaml version of that program if that would be more readable; I haven't written a Ruby version.)