[Konsole-devel] [Bug 188528] konsole's history adds spaces to end of lines when copying text

[tomasb at kapsa.cz]

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

--- Comment #138 from tomasb at kapsa.cz ---
I feel responsible, because I have proposed the idea on which current behavior
is based. So I'll try to explain it in more detail.

Running applications are issuing commands to konsole using VT102 protocol. In
the most simplest mode of operation it is a stream of characters to be written
on the screen and that's the way commands such as cat /some/file operates.
However applications like mcedit makes greater use of VT102 - they issue
commands to move cursor around the screen or erase portions of screen. If you
look into Vt102Emulation::processToken function you will see many possibilities
to clear a portion of screen - application can request clearToEndOfLine,
clearToBeginOfLine, clearEntireLine etc. So mcview and similar application
doesn't clear screen by directly writing space char on it, but rather using
VT102 clearing commands.

All these clear operations are mapped in konsole source code to
Screen::clearImage(int loca, int loce, char c) with space character in c
variable (in my screenshot replaced by another character to visualize) used to
overwrite previous contents in a screen buffer. Konsole's screen buffer is
basically a 2d array of characters visible on terminal window and each
character have some additional properties such as color. There is no such thing
as an "empty character" or "unexisting character" so ordinary space is used
instead.

Even konsole in KDE 4.1.x worked fine (meaning not adding unnecessary spaces
when copying in mcedit). I'm guessing that konsole simply deleted all the
spaces at the end of lines while copying to clipboard. However around 4.2
release there was some change triggering this solution to be non-working. For
example in PlainTextDecoder::decodeLine there was code to remove spaces from
the end of lines, but when used for copying to clipboard this funcionality is
disabled thanks to _includeTrailingWhitespace = true (see my comment #107).
There were some attemps to restore space-on-end-of-line filtering, but mostly
done in wrong way or on a wrong place (see attachment "mc screenshot with the
patch attached").

However I believe that simply deleting all the spaces at the end of line is not
an ideal solution. What if that space actually should be there because it is
written in the file? See attachment "A file that can be used to test
correctness of terminal windows" not paying attention to tab issue (yet). So
I've proposed possible solution in comment #94 for testing(!) which
distinguishes between spaces written by application and spaces written by
clearImage not copying the latter into the clipboard and Jekyll Wu submitted
cleanly written patch based on that idea into git. Actually I've expected more
feedback before actually submitting this idea, but well...

Latter it occured, that this approach is still not sufficient in some more
subtle situations. To me its not completly clear what these situautions are. I
have noticed problems when connected over ssh to a server with very old version
of mc, but locally on current mc problem was nonexistent. I have studied stream
of commands coming from that old mcedit and it occured that the old mc actually
prints some nonexisting trailing whitespace! Please see my comment 118.

Opinions may vary and we need more feedback. It can be viewed as a bug in my
idea arguing that mcview/mcedit bahavior is correct saving bandwidth and only
rewriting parts of screen which needs to be visually different without
considering what is actually in screen buffer and what would be eventually
copied into the clipboard. And that it's a konsole resposibility to blindly
delete all trailing spaces whetever they are real or not. Or it can be viewed
as mcedit/mcview bug that it should print real and exact contents of viewed or
edited files with exact indentation (spaces vs. tabs) instead of simply moving
cursor and considering only as things appear on screen without considering for
example what indentation will be copied into clipboard.

I'm still thinking that it would be better if mc developers change it's
behavior (or it is a behavior of ncurses or slang?). Consider a source code
file with tab-based indentation. Now when you open such a file in mcedit and
copy contents into clipboard (both in konsole and in xterm) all the indentation
will be changed into spaces instead of tabs. That's another result of mc
behavior of only moving cursor instead of printing indentation.

It would be a great help to investigate, who is responsible for this behavior.
Mc? Slang? Ncurses? Could they be fixed? Is there other applications beside
mcedit which have similar problems too? But please note, that its not allways
easy to make a conclusion. See comment 125. I belive, that this problem that
disapeared on subsequent run is caused by some invisible garbage left on the
screen by previous application. Good way to visualize whats going on is to
change c into something visible in src/Screen.cpp on line 842.

Please note I'm not a konsole developer. I'm just long time user who tried to
understand a problem and proposed some solution instead of blaming developers.
Richlv, if you want checkbox in configuration to delete all trailing spaces,
then fine, write a patch.

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