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.
A vector doesn't decay to pointer, so we can iterate over it with range-for
in Profile and ProfileReader/Writer without using pointers to array
elements, and a while loop that checks for the special element at the end
of the array to stop the loop. Also remove that dud element at the end of
DefaultPropertyNames.
std::array is a viable option, but the downside is we'd have to specify the
number of elements in it (as that's part of its type), and keeping that
number in sync when adding new properties could be problematic.
RegExpFilter::process() was going through all the screen lines for every
match. Instead, the second and next matches can start from the line
were the last match was found.
The query and fragment components can include question marks in them. As
an example, LDAP URIs have queries of the form:
["?" [attributes] ["?" [scope] ["?" [filter] ["?" extensions]]]]]]
so the following:
ldap://[2001:db8::7]/c=GB?objectClass?one
does a one-level deep query to the LDAP server at IPv6 address
2001:db8::7 for the children of object c=GB and returns their
objectClass attribute.
This allows recognizing URIs like the following:
http://[2a00:1450:4001:829::200e]/http://[2a00:1450:4001:829::200e]:80/
Our regexp is not as strict as the syntax in RFC 3986, we just allow any
combination of hex-digits, colons and dots.
Besides, we don't go to the effort of forbidding IP-literals in www. URI
suffixes, so the following invalid suffix is recognized by our regexp:
www.[dead::beef]
but that was already recognized by the old regexp before 3b7e73f5.
We recognize URIs that start with an scheme and a possibly empty
authority, and URI suffixes that start with "www."
In the case of URIs starting with an scheme, they are of the form:
scheme://[ userinfo "@" ] host ...
while "www." URI suffixes are of the form:
www. <rest of host> ...
where host is actually in reg-name form (not in IPv4address or
IP-literal form).
This commit allows more strict parsing of e.g.
www.example.com:foo@bar.com
as <URI>:<email> instead of as a long <URI>.
Apply the same fix at a6b2bd53 to demo_konsolepart:
Basically to use QWidget::windowHandle() to get a QWindow*, we need
to first set the Qt::WA_NativeWindow attribute on the QWidget. See:
https://phabricator.kde.org/D23108
It turns out that trailing spaces _are_ significant, e.g. when the
current rendition is set to underline. Gaps where appearing in
underlined text with spaces. To test, launch konsole with -p
BidiRenderingEnabled=false, and run:
printf '\e[4mtest under line foo ññññ ááá ééé '
which should show no gaps in underlining, and exercises both instances
of the "group non-wide characters with following spaces" code.
This got broken in 3b58e4a9ac when
multiple shortcut sequences were added to a single QKeySequence object,
rather than having a list with multiple QKeySequences in it. As a
result, the single QKeySequence object discarded all sequences after
the first, so the Ctrl+PageUp/PageDown shortcuts got discarded.
QT_MAJOR_VERSION is defined automatically by QtVersionOption (since ECM
5.82) which is included by KDEInstallDirs. For older ECM, if
QT_MAJOR_VERSION isn't already set, default to 5.
There is similar to what's used in polkit-qt-1 (which doesn't depend/use
ECM at all).
Otherwise the build would fail:
/usr/lib64/gcc/x86_64-suse-linux/11/../../../../x86_64-suse-linux/bin/ld: ../lib/libkonsoleprivate_core.a(ShellCommand.cpp.o): warning: relocation against `_ZN7QString6_emptyE@@Qt_6' in read-only section `.text'
/usr/lib64/gcc/x86_64-suse-linux/11/../../../../x86_64-suse-linux/bin/ld: ../lib/libkonsoleprivate_core.a(ShellCommand.cpp.o): relocation R_X86_64_PC32 against symbol `_ZN10QByteArray6_emptyE@@Qt_6' can not be used when making a shared object; recompile with -fPIC
/usr/lib64/gcc/x86_64-suse-linux/11/../../../../x86_64-suse-linux/bin/ld: final link failed: bad value
This seems to affect both STATIC and OBJECT CMake library types.
- Port QStringRef to QStringView (using Q5StringRef::toInt() because
Q5StringView::toInt() uses toString() internally to get a QString
which defeats the point of using a view)
- Fix creating a QKeySequence from OR'ing Qt::Key and Qt::Modifiers by
explicitly constructing a QKeySequence; IIUC, this is due to the two
values coming from two different enums:
"cannot convert ‘QIncompatibleFlag’ to ‘const QKeySequence&’"
- Implicit cast from int to QChar is gone in Qt6
- Implicit cast of QString to QFileInfo is gone in Qt6
- Create a QByteArray to make QStringBuilder work
- QHash::const_iterator can't be used in place of a
QMultiHash::const_iterator
There is no reason for a tab title to change if there is no QT event.
So, instead of snapshoting session regularly, we do it only if there is
some QT events. To catch all QT events an event handler is installed on the
QCoreApplication instance.
Four characters in DEC Special Graphics (Line Drawing)[⁽¹⁾] charset were translated by Konsole into codepoints in private use area.
This patch uses the same code points that xterm uses.
| Index | Previously | Should be |
| ------ | ---------- | ----------|
| `0x6F` | `U+F800` | `U+23BA` |
| `0x70` | `U+F801` | `U+23BB` |
| `0x72` | `U+F803` | `U+23BC` |
| `0x73` | `U+F804` | `U+23BD` |
The old behavior used the same mapping used by Linux consoles, as stated
in `unicode.txt`[⁽²⁾] in Linux's documents. This has been changed long ago
when Unicode 3.2.0 introduced the codepoints `U+23BA`, `U+23BB`, `U+23BC`,
`U+23BD`, as the following excerpt of `unicode.txt` says:
```
In addition, the following characters not present in Unicode 1.1.4
have been defined; these are used by the DEC VT graphics map. [v1.2]
THIS USE IS OBSOLETE AND SHOULD NO LONGER BE USED; PLEASE SEE BELOW.
====== ======================================
U+F800 DEC VT GRAPHICS HORIZONTAL LINE SCAN 1
U+F801 DEC VT GRAPHICS HORIZONTAL LINE SCAN 3
U+F803 DEC VT GRAPHICS HORIZONTAL LINE SCAN 7
U+F804 DEC VT GRAPHICS HORIZONTAL LINE SCAN 9
====== ======================================
[...]
[v1.3]: These characters have been officially added to Unicode 3.2.0;
they are added at U+23BA, U+23BB, U+23BC, U+23BD. Linux now uses the
new values.
```
[⁽¹⁾]: https://vt100.net/docs/vt220-rm/chapter2.html#T2-4
[⁽²⁾]: https://raw.githubusercontent.com/torvalds/linux/5bfc75d92efd494db37f5c4c173d3639d4772966/Documentation/admin-guide/unicode.rst
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
Matan Ziv-Av
Ahmad Samir
Luis Javier Merino Morán
Heiko Becker
Nate Graham
l10n daemon script
Benoît DÉCHAMPS
André Kugland
Kurt Hindenburg
Martin Hostettler
Vlad Zahorodnii