[Konsole-devel] [konsole] [Bug 196998] Konsole should reflow the text when resizing

[Egmont Koblinger]

https://bugs.kde.org/show_bug.cgi?id=196998

--- Comment #19 from Egmont Koblinger <egmont at gmail.com> ---
Text reflow itself is the easiest part, all the chrome around it are the real
hard bits.

E.g. you make the terminal taller or shorter (you haven't changed the width
yet, no need for reflow), should it add/drop lines at the top or at the bottom?
It's really not trivial. With bash-4.3 (that doesn't redraw its prompt on
resize) type a long command that wraps to the next line and move the cursor
back to its first line, then resize the terminal vertically - notice that
terminology cuts the 2nd line of the command and misplaces the cursor, whereas
g-t and konsole are correct. How much more complicated will it get if you can
even change the width?

Terminology allows up to 128k lines of scrollback. My favorite test case file
contains about half of that. After cat'ing that, gnome-terminal rewraps/resizes
almost immediately, you can see a very small delay, like maybe 0.1 seconds.
Terminology starts to print "Big problem. Can't allocate backscroll compress
buffer" endlessly to its stderr, even if I'm redirecting it to /dev/null it's
still spinning my CPU at 100% after about a minute and it's unusable. Let's go
10-fold in g-t, 1.28M lines of scrollback fully filled up; rewraps for me in
about a sec.

Terminology doesn't draw a vertical scrollbar. I could have significantly
further improved g-t's rewrap performance if we hadn't needed a scrollbar,
using delayed ondemand rewrapping. It was the scrollbar that made us need to
rewrap everything immediately, to know the scrollbar's new position.

Terminology wraps CJK incorrectly: it's totally fine with displaying the left
half and cropping the right part. I can't read any CJK scripts, but I bet even
those who can would have serious troubles reading these half characters.

I easily managed to get Terminology into a state when the cursor (shell prompt)
was consistently one line below its actual viewport. I don't know how I did it
and whether I could reproduce it, but I got there in just a few minutes,
whereas I've been stressing g-t's rewrap for about a year without any problems.
By the way, let me mention that it's been in g-t for a year and the only
bugreport I got was that I forgot to maintain the mouse selection. No reports
about any crash, lockup or malfunction, even though it probably has a much
larger user base than Terminology.

I don't think any TextView widget is prepared to handle content backed up by a
file (let alone compressed and encrypted file as gnome-terminal will have very
soon), and to handle content of tens of megabytes or even much more. Just a
very simple question: how would you do the memory management (without long term
memory fragmentation) of a let's say 10,000 or 100,000 line scrollback buffer,
continuously appending at the end and purging data from its tail?

Of course, life was so much simpler if we were limited to 500 scrollback lines,
then it would all be soooooo easy. But alas, terminals are much harder than
simple TextView widgets ;)

-- 
You are receiving this mail because:
You are the assignee for the bug.