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 100487 - Request of UI change select-by-word
Request of UI change select-by-word
Status: RESOLVED FIXED
Product: vte
Classification: Core
Component: general
unspecified
Other opensolaris
: Normal enhancement
: ---
Assigned To: VTE Maintainers
VTE Maintainers
Depends on:
Blocks:
 
 
Reported: 2002-12-06 01:08 UTC by Hidetoshi Tajima
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement



Description Hidetoshi Tajima 2002-12-06 01:08:15 UTC
The issue was originally filed against libzvt under bug 
100155 where word-selection on gnome-terminal does not 
work when non-ASCII characters are given in text entry 
of "select-by-word characters".

To fix, libZvt has code change to use PangoLogAttr, instead of using this
settings, so that g-t's 
word selection should be consistent to how other gtk+
apps do.

I think VTE should implement a similar way by using 
Pango to handle word selection, then the "select-by-word characters" UI
option will be revisited.
Comment 1 Havoc Pennington 2002-12-06 01:49:04 UTC
The problem with using LogAttr is that an URL or a filename 
won't be considered a word, and those are the main reason 
people use select-by-word. And obviously of course you can't 
use LogAttr while still keeping any kind of preference for 
what defines a word.

non-ascii should certainly be allowed in the "word chars", 
though of course that doesn't help for selecting natural-language words.

We might need some hack like using LogAttr and then have a list of 
"chars that should not cause a word break" such as '/' 
and allow customizing that list.
Comment 2 Nalin Dahyabhai 2002-12-10 00:15:20 UTC
VTE should be handling non-ASCII characters correctly in the word
break configuration setting -- the UTF-8 word_chars string is
converted to gunichars and ranges are evaluated using those values.
Comment 3 Nalin Dahyabhai 2003-02-21 03:30:23 UTC
The current behavior seems to work, so marking FIXED (though
works-for-me would be more correct).  Please reopen if this needs
revisiting.