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 399829 - Unexpected behavior when double clicking words to highlight them
Unexpected behavior when double clicking words to highlight them
Status: RESOLVED DUPLICATE of bug 97545
Product: pango
Classification: Platform
Component: general
1.15.x
Other All
: Normal minor
: ---
Assigned To: pango-maint
pango-maint
Depends on:
Blocks:
 
 
Reported: 2007-01-23 16:11 UTC by Matthew Nuzum
Modified: 2009-11-27 03:46 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16



Description Matthew Nuzum 2007-01-23 16:11:55 UTC
When double clicking a word that has punctuation or numbers in it, only the portion of the word that is clicked on is highlighted. For example, if you have the word Frank's and double click the word somewhere around the a, you'd highlight "Frank" and not the entire word. Likewise, if you have a word with numbers in it you don't get the whole word higlighted. It would be nice to have the word-boundry be some kind of space. Likewise, it would probably be acceptable to have the word boundary include a hyphen.

Additionally, if you have a line of text, it can be difficult to add the last word in a line to a selection. In a new gedit window, put the line "The word Temp1 is a word containing numbers" (without quotes). Then, double click the word Temp1 and on the second click, hold the mouse down. Drag to the right to add additional words to the selection. As you drag to "numbers" it will momentarily become higlighted, but if you continue to drag past the end of the word it will un-highlight.

Other information:
Comment 1 Steve Frécinaux 2007-01-23 17:08:04 UTC
This is an issue wrt how pango defines a word. It looks like it's too smart for your use case...
Comment 2 DougMcNutt 2009-11-27 00:37:17 UTC
This one really bugs me. Terminal app gets it closer to reality but is perhaps too shell oriented for "normal" users.

What I got used to was Apple's MPW which worked with an environment variable WORDSEP which contained the ASCII characters that would be included in a word. It could be different for each file that you worked with because it could be stored in a resource fork.

It would likely be adequate to place it in a *.lang file though.

And what to do about unicode escapes me.
Comment 3 Behdad Esfahbod 2009-11-27 03:46:09 UTC
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.

*** This bug has been marked as a duplicate of bug 97545 ***