select by word crosses some whitespace

[Michael P. Soulier]

I've come across some very annoying behaviour in gnome-terminal. When I
double-click and drag to select-by-word, it will cross some newline boundaries,
which IMHO it should never do until the mouse is dragged across the newline.

Example:

[msoulier@sme61build msoulier]$ ls devrpms/RPMS/*/ppp-modules-2.4.2-9es2*
devrpms/RPMS/athlon/ppp-modules-2.4.2-9es2.athlon.rpm
devrpms/RPMS/i686/ppp-modules-2.4.2-9es2.i686.rpm

The above appears in my terminal like this...

[msoulier@sme61build msoulier]$ ls devrpms/RPMS/*/ppp-modules-2.4.2-9es2*
devrpms/RPMS/athlon/ppp-modules-2.4.2-9es2.athlon.rpm
devrpms/RPMS/i686/ppp-modules-2.4.2-9es2.i686.rpm

...but notice that when I pasted it in the first case, without modification,
that the first newline was not present. This also causes the select-by-word on
the second pasted line to select all of the way back to the * on the first line.
I'll delimit the selection that appears with curly braces below, when I
double-click on the second line.

[msoulier@sme61build msoulier]$ ls devrpms/RPMS/*/ppp-modules-2.4.2-9es2{*
devrpms/RPMS/athlon/ppp-modules-2.4.2-9es2.athlon.rpm}
devrpms/RPMS/i686/ppp-modules-2.4.2-9es2.i686.rpm

This is totally wrong, and works fine in xterm. It will select like so:

[msoulier@sme61build msoulier]$ ls devrpms/RPMS/*/ppp-modules-2.4.2-9es2*
{devrpms/RPMS/athlon/ppp-modules-2.4.2-9es2.athlon.rpm}
devrpms/RPMS/i686/ppp-modules-2.4.2-9es2.i686.rpm

This makes select-by-word pretty much useless in a lot of cases, and it makes
the paste of the region wrong, as the first newline is not respected.

If I run script before executing the ls command, the output is interesting...

Script started on Mon Jan 3 10:24:49 2005
[msoulier@sme61build msoulier]$ ls devrpms/RPMS/*/ppp-modules-2.4.2-9es2*
ESC[00mESC[01;31mdevrpms/RPMS/athlon/ppp-modules-2.4.2-9es2.athlon.rpmESC[00m
ESC[01;31mdevrpms/RPMS/i686/ppp-modules-2.4.2-9es2.i686.rpmESC[00m
ESC[m[msoulier@sme61build msoulier]$ exit
ESC[HESC[2Jexit

Script done on Mon Jan 3 10:25:02 2005

I'm not entirely sure how to interpret those control characters, but it did
capture the newline correctly.

[Matt Zimmerman (mdz)]

I can't reproduce this bug. Can you provide a recipe for testing it which
doesn't rely on your local environment?

[Michael P. Soulier (msoulier)]

(In reply to comment #1)
> I can't reproduce this bug. Can you provide a recipe for testing it which
> doesn't rely on your local environment?

Hmm. It would seem that it doesn't happen locally. It only happens when I ssh
into our RedHat 7.3 based build server. It must have something to do with the
terminal settings at one/each end. I'm not sure where to start though.

Locally:

[msoulier@latte msoulier]$ stty -a
speed 38400 baud; rows 24; columns 80; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = M-^?; eol2 = M-^?;
start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V;
flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc ixany imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke

Remotely:

[msoulier@sme60build msoulier]$ stty -a
speed 38400 baud; rows 24; columns 80; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = M-^?; eol2 = M-^?;
start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V;
flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc ixany imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke

[Matt Zimmerman (mdz)]

Check the value of the TERM environment variable on the remote side. Are you
running inside screen(1) or anything similar?

We won't be able to do much about this bug until we have a way to reproduce it
on Ubuntu.

[Matt Zimmerman (mdz)]

I just ran into a situation where gnome-terminal is doing the wrong thing as
well, running a local shell on my desktop. There does seem to be a bug
somewhere in the vicinity of gnome-terminal. If I see it again, I will try to
work up a test case

[Michael P. Soulier (msoulier)]

(In reply to comment #3)
> Check the value of the TERM environment variable on the remote side. Are you
> running inside screen(1) or anything similar?

I am using either xterm or screen on the remote side for TERM, when running
outside of screen or inside, respectively.

This happened outside of screen, although I've had oddities inside of screen too.

[Dennis Kaarsemaker (dennis)]

I have not seen any oddities on breezy, can someone please confirm this bug on
breezy

[Daniel Holbach (dholbach)]

Marking bug fixed. If this is still an issue in Breezy or Dapper, please speak up.