This action should not be performance critical, so scrolling one line n times seems reasonable.
A solution with better performance requires more changes in addHistLine().
This should solve https://bugs.kde.org/show_bug.cgi?id=449233 .
Regression introduced by 5919c1fd. The selection range is inclusive in
both ends.
Thanks to Chiitoo for reporting and to Yerrey Dev for proposing a
solution.
BUG: 448144
Commit d37d3ac1 "CompactHistoryScroll: Remove _maxLineCount + 5 lines at
a time" caused a regression: addHistLine queried the number of lines in
history before and after adding a line, and if it had not incremented it
assumed one line entered history and another was dropped at the other
end. Now, lines are dropped from history in batches, so take care of
that.
TerminalPainter already takes care of calculating blended colors when
"Always invert the colors of selected text" is off. Move there also the
swapping of fg/bg colors for the inverted colors kind of selections.
This removes one reference to TerminalDisplay from Screen. There is
still another one to support reflow for some zsh configurations.
Every time the selection is changed, the selection text is retrieved to
check whether to enable or disable the copy actions. Besides that, the
selection text is also used for the web search context menu entries.
Better just check if the selection is empty and make a note that the
selection changed, so the next time the context menu is invoked it can
retrieve the current selection text, which should happen much less often
than selection changes.
If the "Trim leading spaces" option is set, we can pass a pointer to the
first non-space character to decodeLine(), no need to first move memory
around.
- Hoist _columns access out of loop.
- Make copyFromScreen more similar to copyFromHistory.
- Use std::copy and std::fill instead of explicit loops.
Prompted by suggestions by Waqar Ahmed.
The profile was checked for every selected character to learn whether it
should be rendered with inverted foreground and background colors, or
with blended colors.
From esctest:
ANSIRCTests.test_SaveRestoreCursor_ResetsOriginMode
DECRCTests.test_SaveRestoreCursor_ResetsOriginMode
DECSETTiteInhibitTests.test_SaveRestoreCursor_ResetsOriginMode
RIS (ESC c) - Hard Reset should move the cursor to (1,1) and clear tab
stops.
From esctest:
RISTests.test_RIS_CursorToOrigin
RISTests.test_RIS_ResetTabs
This change tries to improve the performance when you are outputting a
lot of text to the screen. Result with a 40M text file for me before was
6 seconds which is now down to about 3.5 seconds with this change.
It can still be improved a lot more.
BUG: 443885
Commit 8de0e6c7 mistakenly removed code to cancel the pending wrap flag
(which in konsole is implemented as having the cursor one past the width
of the screen) before the cursor controls CUU, CUD, CUB and BS.
While the behavior may seem counter-intuitive (specially BS and CUB,
where `printf "A\bB"` at the last column results in `BA`), this is the
behavior of VT100, xterm (without reverse-wraparound mode), and, most
importantly, is expected by ncurses.
CCBUG: 399615
clearImage() just clears until _columns. To prevent characters from
beyond _columns from reappearing, e.g. due to DCH (Delete CHaracters)
requests, make clearImage() resize lines when clearing to the end of
line.
BUG: 432669
The recent change of blending the background/foreground colours for text
selection doesn't work everywhere, users with vision impairment or
colour-blindness would probably find it hard to distinguish text selection
colours; and the current code can't possibly cover all variations of colour
schemes out there. The same goes with certain displays and viewing angles,
some display types are notoriously awful when viewed at an angle.
BUG: 435309
FIXED-IN: 21.08
- Add a type alias for QPointer<Session>
- Use TerminalDisplay::setSessionController() as early as possible
- Use Screen::setCurrentTerminalDisplay() in TerminalDisplay::mousePressEvent(),
this matches what's being done in keyPressEvent()
- Add convenience function TerminalDisplay::currentSession()
- More const
Commits 9ffe33a27a and
4352df00d9 introduce and use a
getScreenLineColumns(line) method to provide support for DECDWL
(Double-Width) lines.
It turns out that under some conditions on resize Screen::_cuY (the
current cursor Y position) and ScreenWindow::endWindowLine() can have
different ideas of how many lines the terminal has.
A test that asserts:
- while [ true ]; do echo -e "\e[?1047h"; done
- Resize the window, making it smaller
BUG: 436327
Restore Y coordinate before X coordinate, so we make sure Y is in bounds
before trying to access _lineProperties depending on Y.
To test:
- Go to the last line
- tput sc
- Shrink the terminal
- tput rc
It is removing the vector of lines storage. Now it is using a similar
idea used in history file.
All chars are stored in a linear way, only the line indexes are
changed when reflowing.
No speed problem found when removing lines.
Double height lines are actually two lines, the first with the top part
of the characters, the second with the bottom part. Reflowing could lead
to situations where we render a top part, a double height line with its
top and bottom parts, and a bottom part, which looks weird.
There is a difference with xterm behavior: when the screen width is an
odd number of columns, xterm allows selecting up to columns/2+1, we just
allow selecting up to columns/2.
While DECDHL/DECDWL lines are not wrapped at the correct column, now at
least reflowing doesn't clear line rendition attributes, so resizing
Konsole and going back to the original size always recovers the original
content, including double-height/double-width status of each line.
Reflowing double-height lines doesn't make much sense, since a
double-height line actually consists of a top (T) and a bottom (B)
line. Shrinking them could lead to TTBB lines, which look weird. At
least now going back to the original size brings back the original
content in all its glory.
While DECHDL sequences should be used in pairs on adjacent lines, the
first line drawing the top half, and the second line drawing the bottom
half, apparently real VTxxx (or at least the VT220) terminals did draw
only the top or bottom of characters when confronted with an isolated
DECDHL line (https://retrocomputing.stackexchange.com/questions/18023/).
xterm has that same behavior. So behave likewise.
EL (Erase Line) should not reset the line rendition attribute to
single-width. ED (Erase Display) should only reset it for completely
cleared lines. ECH (Erase CHaracters) should obviously not reset it.
DECSED and DECSEL (Selective Erase, not supported by Konsole) should not
reset it.
This fixes a vttest test where a line is set to double-height-top and
then EL before writing its text and the double-height-bottom line below.
Can also be tested with:
echo -e "\e[2J\e[4;1HNormal\n\e#6DOUBLE\n\e#6DOUBLE\nNormal" &&
sleep 2; echo -e "\e[5;3H\e[1J\e[8;1H"
Some control functions special case the last column. When a line has
been set to double-width via DECDWL or DECDHL (double-height and
double-width), the correcr last column for that line should be used.
Control functions which special case the last column include TAB, CUF,
ICH and DECRC.
Can be tested with:
perl -E '$r=join "", map{$_%10}1..80; say "\e<\e[?40h\e[?3l\e[?7l$r";
$s="L"."\tx"x4 ."\t\tR"; say "\e#3$s\n\e#4$s"'
The above tests that tabs don't travel beyond the last column in
double-width lines. The last column (below columns 79 and 80 of
the previous line) should have an "R".
perl -E '$r=join "", map{$_%10}1..80; say "\e<\e[?40h\e[?3l\e[?7h$r";
$s="L"."X"x36 ."\e[6C"."R"; say "\e#3$s\n\e#4$s"'
The above tests that CUF (Cursor Forward) doesn't travel beyond the last
column in double-width lines. The last column (below columns 79 and 80
of the previous line) should have an "R".
perl -E '$r=join "", map{$_%10}1..80; say "\e<\e[?40h\e[?3l\e[?7h$r";
$s="L"."X"x22 ."R"."x"x8 ."r"."\e[17D\e[16@";
say "\e#3$s\n\e#4$s"'
The above tests that ICH (Insert CHaracters; VT200+) doesn't write past
the last column, visible on repaints (switch to another window and
back).
perl -E '$r=join "", map{$_%10}1..80; say "\e<\e[?40h\e[?3l\e[?7h$r";
$s="L"."X"x38 ."r\e7\e[H\e8R"; say "\e#3$s\n\e#4$s"'
The above tests that DECRC (Restore Cursor) doesn't restore the cursor
to a position beyond the last column on double-width lines. The last
column should have an "R", "r" should not be visible.
perl -E '$r=join "", map{$_%10}1..80; say "\e<\e[?40h\e[?3l\e[?7l$r";
$s="L"."X"x38 ."R"; print "\e#6$s"'; sleep 5; echo
The above tests that the cursor stays at the rightmost column. The
cursor should stay over the "R" for 5 seconds.
Since double-width/double-height lines have room for just half the
characters, take that into account.
Can be tested with:
perl -E '$r=join "", map{$_%10}1..80; say "\e<\e[?40h\e[?3l\e[?7h$r";
$s="L"."X"x38 ."RL"; say "\e#6$s"'
The above tests that appending characters to double-width lines in
DECAWM (Auto Wrap Mode) wraps at the correct last column. There should
appear a second line (single-width) with a single "L".
perl -E '$r=join "", map{$_%10}1..80; say "\e<\e[?40h\e[?3l\e[?7l$r";
$s="L"."X"x42 ." TEST FAILED OUTOFBOUNDS R"; say "\e#6$s"'
The above tests that appending characters to double-width lines in
non-DECAWM (Auto Wrap Mode) doesn't write past the last column (visible
on repaints - switch to another window and back). The last column (below
columns 79 and 80 of prev line) should have an "R".
