Oh, it's a vte bug.

Hi Egmont,

your comment does make some sense, but I really don't see a sane way to 
distinguish the case in which the user really wants those empty lines (think 
of a code snippet where the empy line makes it more readable or anything similar).

And I believe that the behaviour of copying exactly what was on the screen makes
more sense given a choice.

I'd say this is NOTABUG.

what do you think?

Hi Michele,

You're right, mouse selection should copy exactly what is on the screen.
If I see empty lines, I want empty lines to be copied to the buffer, but that
is always how vte worked and works now, no problem with this. The problem was,
in older versions of vte, is plenty of extra unnecessary _space_ characters
added to the buffer if an empty line was selected.

This is gone now, as of vte 0.11.13, but there's another bug: if I copy a
region that contains only space characters (one or more spaces) then the
clipboard is cleared, these spaces are not put there.

What does xterm do in this case? It's been said over and over that we should
emulate xterm behaviour as closely as possible...

Xterm copies the spaces, as one would expect.

In fact, xterm even allows you to select the spaces at the end of a line if they
were explicitly printed.  For example:
1. Run this command in xterm/g-t:  echo "hello"; echo "hello   "
2. Select both output lines and paste them in gedit.

Result: when done in xterm, the 3 extra spaces on the second line are preserved.
 When done in g-t, no spaces are copied at all.

And there's another related bug in g-t, which xterm gets right:
1. Run this command in xterm/g-t (assuming terminal width=80, and a UTF-8 locale):
  perl -e 'use open ":locale"; print "x" x 79, "\x{3042}\n"'
2. Select the whole output and paste into gedit.

Result: Both xterm and g-t insert a space after the 79 x's so that the entire
U+3042 (double-width Hiragana A) appears on the next line.  However, when you
select the output in g-t, the extra space is copied, whereas in xterm it is not
copied.

Created attachment 51087 [details] [review]
Proposed patch

This patch makes vte keep track of whether each cell is empty or not, and
changes the selection algorithm to use this information instead of looking for
spaces at ends of lines.  It fixes all the above-mentioned problems.

Nice work, works perfectly for me, thanks!!! Someone please commit it :-)
I'll keep on using vte with this patch and will report immediately if I find
something wrong.

Well, the patch (or other relevant parts of vte) is not perfect.

This bug is easily reproducible:

If a line contains some spaces at its end, then highlighting with a single
mouse click works okay, however, highlighting with double click (actually
one-and-a-half: click, raise, click and hold) is not okay, visually one more
space character is highlighted at the end of the line. For example, a typical
command typed using the TAB completion ends in one space, but if highlighted
with double click, two spaces are highlighted. (But only one is actually copied
to the clipboard.)

This one is hard to reproduce:

For lines ending with a space, rarely the double click selection method skips
the option to include that space but not the newline. E.g. skips the option
that is visually incorrectly displayed as described above. First only the text
part is highlighted and copied to the clipboard, but if I move the mouse to the
right, suddenly the whole line gets highlighted and the space and newline are
both put into the clipboard. The middle option (only the space, but not the
newline) is skipped.

This one is hard to reproduce too, it only happened to me 2 times:

Sometimes (rarely) the newline is missing from the clipboard. No, I don't mean
overlong lines that wrap to the next physical row, I'm just typing bash
commands of 40-50 characters in my 80 wide terminal. Still, very rarely, such
a line cannot be selected by a triple-click on its own, it gets highlighted
altogether with the next line just as if they were one long logical line, but
they aren't, as proven by a single-click selection which, after the text part
is highlighted, suddenly jumps to highlight the whole first line up to its end
instead of walking on the spaces one by one. No matter if this line is
selected by single, double or three clicks, the newline character is missing
from the clipboard.

I cannot systematically reproduce the two "rare" cases but I'll keep trying to.
One common thing in them is if one line misbehaves then that particular line
will still be misbehaving throughout the whole vte session, no matter how I
scroll or resize the window. If the terminal's content scrolls then the
location of this bug scrolls to, so it stays at the same text.

2006-07-10  Behdad Esfahbod  <behdad@gnome.org>

        Bug 121904 – copy-paste of empty line
        Bug 25290 – Small UI tweak to select-by-word (only select only letter
        at a time for non-word characters)
        Bug 339986 – Patch to select localized strings exactly

        * src/vte-private.h:
        * src/vte.c (_vte_terminal_set_default_attributes),
        (_vte_terminal_insert_char), (vte_terminal_is_word_char),
        (vte_same_class), (vte_terminal_get_text_range_maybe_wrapped),
        (vte_terminal_extend_selection):
        * src/vteseq.c (vte_sequence_handler_screen_alignment_test):
        Fix a bunch of selection-related issues.  We now recognize explicitly
        put space at the end of lines, and copy/paste it.  The other change is
        that non-wordchar characters are not grouped together.  Also fixes the
        fallback on Unicode properties that I added two commits ago.

I committed a drastically improved version of the patch.  It shouldn't have any of the issues you are reporting.