After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 323886 - Selecting a line should also select the line ending
Selecting a line should also select the line ending
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkTextView
3.22.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
: 451863 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-12-12 15:34 UTC by Joachim Noreiko
Modified: 2018-05-02 14:14 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Joachim Noreiko 2005-12-12 15:34:13 UTC 
Distribution/Version: Ubuntu 5.10

A whole line of text in gedit can be selected with a triple mouse click.
However, this doesn't include the newline character in the selection.

Consequence: using cut & paste or drag & drop to move the line glues it to the
following line at the destination, and messes up indentation.
Comment 1 Paolo Borelli 2005-12-15 11:24:03 UTC 
GtkTextView issue. No idea if there is a rationale or if it's "just a bug"
Comment 2 Matthias Clasen 2005-12-18 04:02:56 UTC 
If it is a bug, it is shared e.g. by firefox
Comment 3 Shaun McCance 2006-06-17 17:49:23 UTC 
It occurs to me that a potential problem with selecting the newline is that, if you then paste the text to a GtkEntry (or any other one-line text area widget), you'll get an annoying box thing representing the newline.  Perhaps we could make GtkTextView select the newline, but then have GtkEntry (and other one-line text area widgets) strip *trailing* newlines from pasted data.

Selecting the newline means that triple-click+delete will really kill the line, which seems more natural to me for line-oriented editors.

I do firmly believe that each application should decide the double-click and triple-click select behavior that works best for its users.  I also firmly believe that applications want to be anthropomorphized.
Comment 4 Joachim Noreiko 2006-10-07 17:58:26 UTC 
Interesting reverse inconsistency: nautilus *does* take a newline when you copy a file and paste in a text context, but it shouldn't (Bug 360441).
Comment 5 Yevgen Muntyan 2007-09-04 16:08:57 UTC 
What browsers do in their html views is irrelevant. Browsers are very different from editors because they are not *editors*. Besides, try to triple-click a line in an text box in mozilla, it will select line end (you can try it right here, in the comment box). Plain GtkTextView bug. Same as "Ctrl-Left will not jump to the left because there is no word on the left". Just happened so. Impossible to fix since "it's good" too.
Comment 6 Owen Taylor 2007-10-18 11:59:24 UTC 
*** Bug 451863 has been marked as a duplicate of this bug. ***
Comment 7 GNOME Infrastructure Team 2018-05-02 14:14:45 UTC 
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/253.