When a line is reflowed then the vertical position of all
graphics placements above or below it (as appropriate) are
adjusted, so they remain in the same place relative to the
text lines.
When selecting past the last character, extend the selection to the last
column. This allows the user to know when the selection has extended
past the last character on a line, even in the presence of trailing
spaces, and will get a newline added to the last line.
This is the behavior of xterm, VTE and rxvt. mlterm doesn't allow
selections to extend past the last non-space character on a line.
BUG: 413426
CCBUG: 158726
Commit c3b3ef19 introduced a regression when invoking the
clear-history-and-reset action. While RIS (Reset to Initial State) is
specified in DEC STD-070 as homing the cursor, konsole has grown some
hacks in the name of usability to preserve the command prompt line.
For a long time, it has sent two SIGWINCH with changed sizes after clear
and reset actions to force the shell to redraw the prompt (see d346a2cc,
temporarily disabled on 5d61b69e and re-added on 82778e87), which works
for bash, zsh, ksh, ...
tcsh doesn't redraw its prompt on SIGWINCH, but commit b8e96bcd modified
Screen::refresh() so instead of clearing the entire screen and homing
the cursor, it scrolled up everything but the last (usually the prompt)
line.
So, keep that last hack when called from clear-history-and-reset, and
behave as specified on DEC STD-070 otherwise.
Note that other ways of clearing the screen don't need hacks, e.g.
Ctrl-L, if handled at all, is handled by the shell, which then redraws
its prompt. Calling "clear" or invoking "printf '\ec'" will result in
the shell redrawing its prompt in the usual way.
BUG: 453568
Moving all cursor and scroll handling to addPlacement.
This requires the moveCursor parameter to have three possible values,
since Sixel cursor movement is not the same as Kitty/iterm2. This also
unnecessitates addPlacement return value.
BUG: 452476
(cherry picked from commit 9ae57f4e1de920d1a30b8f64448fd6c186a36730)
DECSTR is a level 2 control (VT2xx and up), and is to be used instead of
RIS (Reset to Initial State), which can initiate a self-test and drop
the connection on some hardware terminals.
BUG: 134892
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
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.
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.
Was already taken care of by Screen::Screen(lines, columns) calling
Screen::reset(), which calls Screen::saveCursor() after resetting
_currentModes[MODE_Origin].
From esctest:
ANSIRCTests.test_SaveRestoreCursor_ResetsOriginMode
DECRCTests.test_SaveRestoreCursor_ResetsOriginMode
DECSETTiteInhibitTests.test_SaveRestoreCursor_ResetsOriginMode
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
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"
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".
Those Classes are not QObject, so most of it's pointers could be changed
to smart pointers with no problems.
Problem found when using QList<std::unique_ptr>: it wasn't possible to
use it. I'm using std containers instead.
Unfortunately the code is still fragile and I froze konsole
a few times in a few minutes. This is something that konsole
really needs, but we need more time to squish all the bugs
we find.
Some improvements in calculations and safeguards when changing
cursor position, using defined value in Vt102Emulation.cpp to
protect the integers.
Added cursor position tests to ScreenTest.
Vt102Emulation MAX_ARGUMENT calculation wasn't correct, it was
sending an argument bigger than max argument.
This path adds a new feature for konsole, in the form of URL Escaped
Sequences. It allows programs to embbed URL's on texts much like
the anchor tag in html does
There's a allowed list of possible schemas for links, by default
it only accepts http://, https:// and file:// but the user can
add more if he wants.
The maximum amount of URL's accepted is 200, to prevent OOM
History is taken into account while scrooling
- It implements Cursor Next Line (CNL) sequence.
- It implments Cursor Previous Line (CPL) sequence.
- Ex: echo -e "Hello\e[3EWorld" or echo -e "Hello\e[3FWorld"
BUG: 418519
FIXED-IN: 20.08
https://invent.kde.org/utilities/konsole/-/merge_requests/116
New unit test, triggers faulty code in `Screen::copyLineToStream`
which goes outside `Character` array boundaries, overwriting
memory of other objects.
Compiling the code with address-sanitizer makes the fault
visible when running those new UTs.
'Konsole::Screen` defined an array of 1024 elements, where user
may resize the konsole to have more columns than this array can handle.
Selecting a row in such case, is going to cause a buffer-overflow.
Bug: 330066
Before we opened a link via mousePress but if we want to make a
selection that will open a file and drag.
Now we check if there is a selection before trying to open something.
So if you click and drag a url, it will not open. If you directly
click and release without dragging, it will open.
FIXED-IN: 20.08
https://invent.kde.org/utilities/konsole/-/merge_requests/9
Summary:
Currently Unicode uses 0x10FFFF code points. It is possible to represent
all of them with up to two 16 bit values (UTF-16), but this makes it
harder to e.g. check for their width.
Some test cases were changed. Originally they were added with an
assumption that the code point will be truncated to 16 bit value and
as a result changed to another code point.
Test Plan:
* All code points <= 0xFFFF should work as before
* Start the same tmux session in two Konsoles
* Change background to fully transparent in one of them and put it in
front of the other one, so that all text will overlap
* Generate characters with (you can pipe it to `fold -s | less -r`):
```
perl -XCSDL -e 'print map{chr($_), " "} 1..0xffff'
```
* Compare output visually.
* Code points > 0xFFFF should not be truncated to 16 bits
* "𝐀" and "퐀" should be different characters
* Some code points > 0xFFFF should have single width
* Vertical lines below should align:
```
|𝐀 |
|𠀋|
```
Reviewers: #konsole, hindenburg
Reviewed By: #konsole, hindenburg
Subscribers: konsole-devel, hindenburg, #konsole
Tags: #konsole
Differential Revision: https://phabricator.kde.org/D12236
Summary:
Move the Q_DECLARE_OPERATORS_FOR_FLAGS macro declaration for the
DecodingOption enum to the Konsole namespace. This should fix a bug that
happens when KeyboardTranslator.h is included in Screen.h (either
directly or indirectly), where the compiler doesn't find the |() operator
of the QFlags class.
I haven't pinpointed where the conflicting |() operator is coming from
exactly, but moving the macro declaration to the Konsole namespace
matches how other QFlags are used through out the code (and matches
upstream doc examples).
Test Plan:
- Add this include to Screen.h and try to compile:
#include "KeyboardTranslator.h"
- The compilation fails in SessionController.cpp:
error: invalid conversion from 'int' to 'Konsole::Screen::DecodingOption'
The line it fails on is 1200:
QString selectedText = _view->screenWindow()->selectedText(Screen::PreserveLineBreaks | Screen::TrimLeadingWhitespace | Screen::TrimTrailingWhitespace);
- Apply the diff and build again, the build should complete
I tested the options from the DecodingOption enum from the Screen class and they still work as before
Reviewers: #konsole, hindenburg
Reviewed By: #konsole, hindenburg
Subscribers: hindenburg, konsole-devel
Tags: #konsole
Differential Revision: https://phabricator.kde.org/D12797
Matan Ziv-Av
Luis Javier Merino Morán
Martin T. H. Sandsmark
Waqar Ahmed
Ahmad Samir
Tomaz Canabrava
Carlos Alves
Kurt Hindenburg
Gustavo Carneiro
Luis Alves
Lukasz Kotula
Mariusz Glebocki