Line rebreaking on terminal resize

[GoogleCodeExporter]

It would be rather nifty if long lines could be rebroken after the number
of terminal columns changes, much like you see with flowing text in a web
browser. Apple's Terminal.app does this.

This would also solve the problem of window contents disappearing when
increasing the font size in a window that can't be enlarged.

(Fullscreen apps such as editors usually already do this via the SIGWINCH
signal, so this primarily concerns plain command line output and the
scrollback.)

Original issue reported on code.google.com by andy.koppe on 4 Apr 2009 at 7:24

[GoogleCodeExporter]

Original comment by andy.koppe on 7 Jun 2009 at 7:51

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Lots of restructuring of the screen buffer data would be needed for this. Not 
sure it's 
worthwhile.

Original comment by andy.koppe on 30 Jan 2010 at 10:49

• Added labels: Priority-None
• Removed labels: Priority-Low

[GoogleCodeExporter]

Oh, it's definitely worthwhile (especially if you do the work and I benefit)! I 
bet it would be one of the best recognized new features of Mintty. You would 
put others to shame. (How many years has Apple had this feature without 
competition on any platform?) --Ken Nellis

Original comment by nelli...@gmail.com on 14 Sep 2010 at 4:49

[GoogleCodeExporter]

Issue 219 has been merged into this issue.

Original comment by andy.koppe on 14 Sep 2010 at 8:29

[GoogleCodeExporter]

Nice speech, and I agree that automatic re-wrapping is something that terminals 
ought to do. I think you're overestimating the significance of this feature 
though, and the fact that most terminals don't have it either suggests that 
their authors agree. (Rxvt-unicode does have it actually, to little acclaim.)

Many programs are either designed for a terminal width of 80 characters or 
adapt to the actual width of the terminal, inserting their own line breaks as 
appropriate. Automatic re-wrapping would make no difference with such programs. 
That even includes plain 'ls'.

For others, it's worth stressing that no output is being lost since lines are 
wrapped at the screen edge. Re-wrapping after widening the terminal can make 
output easier to read, but usually that can be achieved by simply re-running 
the command.

In the rarer cases where the command can't easily be re-run, it's probably a 
good idea anyway to 'tee' its output into a file and/or pipe it straight into 
'less'. And if you forget that, there's still the possibility to 'Select All' 
and paste the scrollback into a text editor.

Therefore I think automatic re-wrapping is purely a matter of convenience, 
affecting relatively few cases. Bumping this back up to "Low" though, since I 
would try to implement it if I had the time.

Original comment by andy.koppe on 18 Sep 2010 at 6:49

• Added labels: Priority-Low
• Removed labels: Priority-None

[GoogleCodeExporter]

Just FYI: I'm currently implementing this feature in VTE (gnome-terminal and 
friends). I'd be glad if anyone interested in this feature could give it a try 
with their favorite applications, so that we can all benefit from our shared 
experiences (e.g. I'd be curious to hear about applications that this feature 
breaks, if any). See the patch at 
https://bugzilla.gnome.org/show_bug.cgi?id=336238

Half of the patch is the rewrapping code. I didn't touch the scrollback's 
internals, what I'm doing is I'm building up a brand new scrollback buffer with 
the new width and then throw away the old one (compare with Andy's comment #2). 
This is far from ideal: it uses double memory during its operation, and is also 
a bit slow as it individually copies all the cells (although <1s wall clock 
time on an average laptop for an insanely large scrollback buffer of 100'000 
lines is okay I think). One day the internals of the scrollback buffer can be 
re-written so that it's more convenient and faster to rewrap (no copying of 
cells, just adjusting pointers to lines, or something like this). The only 
essential pre-requisite I'm building on is that for each terminal row, VTE 
already keeps the information whether it was terminated with a soft wrap 
(overflow to next line) or hard wrap (explicit newline).

The other, boring but important half of my patch is to figure out the desired 
offsets (scroll position and such) after the resize.

I hope my work gives you new inspiration on implementing this great feature in 
mintty, too :)

Original comment by egm...@gmail.com on 11 Sep 2013 at 4:29

[GoogleCodeExporter]

Some comments to the "nice speech" and "relatively few cases" parts :)

Yes it's surely a "convenience" feature, but (at least for me) this feature 
makes my life way more convenient. I tend to move and resize all my windows 
crazily, both when a new window appears or old ones disappear, and when the 
output of a terminal application makes it worthwile to widen the terminal. Many 
commands, such as "make" are inconvenient to re-run, partially because they 
might not execute the same underlying commands again, and partially because 
they might take lot of time. All the workarounds you suggest (tee, less, 
copy-paste to an editor) are terribly inconvenient. Another drawback is that 
resizing the terminal does not only cut off text or leaves whitespace, but also 
makes the text not selectable by mouse (especially double click).

You say that rxvt-unicode has this feature, but to little acclaim. Rxvt seems 
to be the "love or hate" terminal to me, and I personally... well... don't love 
it :P Rewrapping doesn't work there in the first screenful of text, I wonder 
why. But anyways, people don't tend to praise what they love, they kind of take 
it for granted and rather complain about what they'd like to have. If you look 
around, you'll find this feature being requested for pretty much all terminals 
out there. I think this matters more.

So I have a feeling that I personally find this feature probably much more 
useful than you Andy do :) I just wanted to share my point of view.

(To be fair, let me mention that I don't have Windows and don't use Mintty, I 
just keep an eye on all terminals out there.)

Original comment by egm...@gmail.com on 11 Sep 2013 at 4:48