https://bugs.kde.org/show_bug.cgi?id=522492
Bug ID: 522492
Summary: Various odd behaviors from long filter command output
Classification: Applications
Product: kate
Version First 26.04.1
Reported In:
Platform: Neon
OS: Linux
Status: REPORTED
Keywords: accessibility, usability
Severity: minor
Priority: NOR
Component: application
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
DESCRIPTION
There needs to be better handling of the output to stderr from Tools|Filter
Through Command after the command fails with nonzero exit status. Very long
lines in the output seem only to be handled by stretching the window to fit,
which can cause crashes and other weird behavior.
STEPS TO REPRODUCE
1. Open Kate.
2. Create or open a text document.
3. Split the editor view vertically.
4. Click File|New Window.
5. In the new window, type some text.
6. Select that text.
7. Click Tools|Filter Through Command.
8. Enter
w=65535; printf '!!%-*s!!\n' "$w" '' >&2 && false
as the command and press Enter or OK.
OBSERVED RESULT
Depending on the phase of the moon and width of the string:
- Shorter length: A message pane might appear at the top of the window with the
error output in it, stretching the window to fit the entire line without
wrapping, and stretching vertical splits so proportions are maintained. (As the
user, this may look like one of the split panes closing suddenly and without
warning, but it's just shifted several screens' worth of pixels to the right.)
- Medium string: Depending, I suspect, upon available VRAM and texture geometry
limits, you may see the older window resize itself wide enough that its client
area and frame are entirely black, and manual resizing of the window to correct
this is intractable. (It's easiest to use window rules to force the width back
to something reasonable..) Restoring the width restores the client area's
visibility, as will maximizing the window, but the text in the titlebar may
remain unusually small or narrow compared to the other titlebars afterwards.
(From accumulated error after repeated transforms, maybe?)
- Longer string: The process might crash or abort, I assume as a result of
running out of VRAM or matching texture formats.
In my tests, effects from the failed command generally appear in the oldest
open window, whether or not that's the one the command was ostensibly executed
from/for. If Kate is restarted and the user recovers their data, the text from
stderr may even appear in the buffer, as if typed by the user.
EXPECTED RESULT
The window should ideally maintain its sizing and stay within screen bounds
unless the user explicitly suggests otherwise. In this specific case, a long
error output can best be handled by offering a scrollbar or word-wrapping the
text. Both are useful; e.g., Gawk's error output might print a large number of
spaces to indicate the location of a syntax error in a long script argument,
and if word wrap is applied, it's not immediately clear what those spaces point
to, especially if a monospace font isn't used. However, if more reasonable
error messages are used, then word wrap is probably preferable. For extremely
long output, truncation is acceptable as long as it's made obvious somehow that
it's happened.
The process shouldn't crash/abort, either, of course, and interactions between
the command and Kate should be reflected entirely in the correct window and
buffer.
SOFTWARE/OS VERSIONS
Operating System: GNU/Linux
KDE Plasma Version: 6.6.5
KDE Frameworks Version: 6.26.0
Qt Version: 6.11.1
ADDITIONAL INFORMATION
Graphics Platform: Wayland
Display Driver: Nouveau
--
You are receiving this mail because:
You are watching all bug changes.
