GNOME Bugzilla – Bug 93711
[Ctrl]+[Left] and [Ctrl]+[Right] ignore non-alphanumeric strings.
Last modified: 2011-02-04 16:11:59 UTC
Description of Problem: [Ctrl]+[Left] and [Ctrl]+[Right] ignore non-alphanumeric strings. Steps to reproduce the problem: 1. Start gedit2. 2. Type in the following text (do not type the line numbers): 1 . 2 |-- 1 3 | |-- A 4 | |-- B 5 | `-- C 6 `-- 2 7 |-- D 8 |-- E 9 `-- F 3. Position the text cursor behind the letter "D". 4. Press [Ctrl]+[Left]. 5. Press [Ctrl]+[Left]. Actual Results: The text cursor is now in front of the number "2". Expected Results: I would expect the text cursor to be in front of the "|--" string on line 7. 6. Press [Ctrl]+[Right]. 7. Press [Ctrl]+[Right]. Actual Results: The text cursor is now behind the letter "D". Expected Results: I would expect the text cursor to be behind the "|--" string on line 7. How often does this happen? Always. Additional Information: I understand that this is "smart" behaviour, but sometimes one would want the application to act "stupidly". Therefore, I think it might be useful to make this "smart" feature configurable (ON/OFF). Version Details: gtk+-2.0.6.tar.bz2 gedit-2.0.5.tar.bz2
Configurable by who in what context? A user option for all text widgets, or a user option in programming editors and such?
It appears that both the GtkTextView and GtkEntry widgets have this behaviour. I think that this "smart" behaviour makes more sense in GtkTextView than it does in GtkEntry. I investigated how the NEdit text editor handles these things. There, it's turned on in the GtkTextView equivalent and turned off in the GtkEntry equivalent. My advice would therefore be to keep this "smart" behaviour in GtkTextView (not configurable) and to always turn it off in GtkEntry.
Hmm, tricky one, I'd agree that the current GtkTextView behaviour doesn't feel right though. There might even be a case for allowing the developer to specify what constitutes a word boundary (which would also apply when double-clicking to select a word etc.) for any given text field, if they can't already-- e.g. in a field for entering URLs you'd definitely want "/" to be a separator, but you may not in other circumstances (e.g. maybe a C++ source code editor where you'd want Ctrl+arrow to treat "//" as a single word... okay so you'd probably want that in a URL entry field as well but you get my drift!)
Duplicate status is a bit backwards here, but 111503 already has the right milestone and title. *** This bug has been marked as a duplicate of 111503 ***