No text reflow when resizing the terminal

[jleclanche]

When the terminal window is resized and there is text going all the way to the end of the line, the text disappears out of screen instead of being reflown down.

[ljrk0]

which is pretty nasty when using i3 :/

[pvanek]

Jerome, I don't understand you right now. Please explain "there is text going all the way to the end of the line". I'm playing with window resizing regarding #79 but I cannot see anything wrong (of course it can sign lack of my imagination;))

[jleclanche]

printf '@%.0s' {1..1000}

Then resize, making it smaller. The line continues "offscreen"

[worblehat]

@jleclanche I think this issue is an enhancement instead of a bug. Konsole does not have reflowing, too: https://bugs.kde.org/show_bug.cgi?id=196998 Might be more complicated than it looks.

[agaida]

gnome terminal work this way - and it is a great feature

[tsujan]

Coming back to this issue after a long time.

KDE devs haven't implemented wrapping on resize yet (https://bugs.kde.org/show_bug.cgi?id=196998) but gnome-terminal and Terminology (which I'm using right now) have it. In Terminology, it doesn't work as expected.

However, it seems that wrapping on resize works in gnome-terminal. Apparently, gnome devs had a hard time to implement it (https://bugzilla.gnome.org/show_bug.cgi?id=336238).

Therefore:

(1) We can wait for KDE devs to implement it and adapt their method to QTerminal. The problem is that KDE devs don't show any willingnessto do so.

(2) Or we can see how gnome devs have done it and try to do similarly. This may be possible but is beyond my current knowledge because it requires familiarity with the code of gnom-terminal.

(3) We could use a "dirty" hack like the one that has worked for me (https://github.com/tsujan/qtermwidget/commit/18cafd4041b0e0cf20103696ca68865dd27f9229 and https://github.com/tsujan/qterminal/commit/0a643802a614a751c6d6f4e3962442c94fedbbb3).

[felixsanz]

This is easy to reproduce.

Split vertically 2 windows. Above, vim or nano. Below some dummy terminal.

Resize the dummy terminal up and down fast (the height).

You will see that the vim powerline bar appears cut. Or the nano bottom bar.

[agaida]

And this is the expected terminal behaviour without rewrapping on size changes. So not a bug, but not nice.

[tobia]

Some terminals have full reflow capability, meaning that the terminal contents are stored internally as a list of logical lines, much like a text editor like Vim or Emacs would do. They may be longer than the terminal width and are only wrapped when displayed. This allows the terminal to soft-wrap lines when resizing down, but also to unwrap them when resizing up, which is equally important.

Mac OS X's Terminal.app made this feature popular, but some free software terminals such as Konsole have had it forever. VTE, the engine behind Gnome-Terminal and Sakura, added it a few years ago. I could swear Rxvt had it too, but I cannot find the option to enable it right row, or maybe it's disabled in the build I'm using. GNU screen has had it forever as well.

As a user, I consider this feature pretty useful, but not essential. It becomes essential when using a window manager that routinely resizes windows, such as i3. But it's definitely a feature request, not a bug, and I can see how it could require a complete rewrite of the terminal engine.

[tsujan]

some free software terminals such as Konsole have had it forever.

See what Konsole does with a long line after resizing (I don't know about gnome-terminal):

Unfortunately, I removed the "dirty hack" mentioned at https://github.com/lxde/qterminal/issues/76#issuecomment-247773776 inadvertently but it isn't better than the above screenshot.

[tsujan]

The best terminal I know of is Terminology (belonging to Enlightenment) but it also has the same problem.

[agaida]

I see some problems with handling terminal output linewise and than wrap single lines - it is fucking slow if one have some more lines in the buffer - really, the current behaviour can be annoying, but i don't want to think of a the memory usage and speed if i have approx 200-500.000 lines in such a terminal. To be true, i wouldn't argue against an implementation that is fast, reliable and has the abilties to handle that :D

[tsujan]

i wouldn't argue against an implementation that is fast, reliable and has the abilties to handle that :

I either.

QTerminal isn't written from scratch but derived from the old Konsole. When I looked at its code 2 years ago, I found that mastering it required forgetting about other apps ;) I hope an LXQt developer will master it and fix its problems.

[tobia]

@agaida If you have 500.000 lines in a terminal you are using it wrong.

The default value of saveLines for Rxvt (as an example) is 8192

To review anything bigger than that you should be using a logfile and a pager (less)

[yan12125]

Nobody is wrong :) Some terminals even allow infinite scrollback by saving them to files. I like that idea. If you can just use the terminal without thinking more about redirection and temporary files, why bother?

Keeping a very long scrollback and having text reflow are not mutually exclusive. Only the last few lines need reflow when the window is resized. And we can have an index to acess the Nth line fast.

[agaida]

@yan12125 - i like the idea :) @tobia - i don't think that i do it wrong - esp. not if i compile things. i want the output in my terminal and want scroll back when ever i want to. And if i compile some things three or four times in a row, i want the output in my terminal.

[agaida]

@yan12125 - not the last lines - the visible lines :)

[jnunderwood]

I just recently switched from urxvt to qterminal and saw this exact problem. I noticed some movement on this issue recently. Any new thoughts on how it might be implemented?

[KingsWorldProject]

Try not to put the file path in PS1, so that when resize, the width of the terminal is not greater than the length of PS1, the problem will not occur

[yan12125]

Thanks for the tip. It can be useful in many cases, while a complete solution needs re-designing how lines are handled in qtermwidget.

[correabuscar]

xfce4-terminal has this feature and I miss it in qterminal. But the former is using vte and gtk3.

[tsujan]

I'm not sure but, apparently, the link I mentioned above years ago (https://bugs.kde.org/show_bug.cgi?id=196998) says that it's implemented in Konsole at last: https://invent.kde.org/utilities/konsole/-/commit/079a73d735e76dbc9d796ae97314a4272008e50b

[chromer030]

We are going toward 2023 , this issue opened in 2014 and yet this feature is not implemented !

[chromer030]

It's interesting that while using tmux inside qterminal text reflow is OK !!!