SUMMARY Underscores are currently treated as letters instead of symbols, making it impossible to use "ctrl+right/left" to navigate text which uses underscores as separator characters. STEPS TO REPRODUCE 1. write "this_is_a_text_using_underscores_as_separators" and "this-time-we-are-using-hyphens"; 2. use "ctrl+right/left" to navigate through the words; 3. see how the first text is treated as a whole word, instead of multiple words using underscores as separator characters, while the second one is correctly identified as being made of multiple used with hyphens used as separators. OBSERVED RESULT Underscores are treated like letters, so long sequences of characters using underscores as separators are treated as if they were a single word. This is especially frustrating if one has to select a portion of text inside a string which uses underscores as separators. EXPECTED RESULT Underscores are treated the same as all other symbols such as hyphens, commas, dots and so on, so that one can navigate text using "ctrl+right/left". As far as I have been able to asses GNOME follows this convention, which appears more intuitive and practical. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE neon KDE Plasma Version: 5.17.4 KDE Frameworks Version: 5.65.0 Qt Version: 5.13.4
Implementation hint: In kateviewinternal.cpp, there is a CalculatingCursor, see: https://github.com/KDE/ktexteditor/blob/master/src/view/kateviewinternal.cpp#L887 This CalculatingCursor supports basic text navigation. From this class, other classes are derived, e.g. the BoundedCursor, or the WrappingCursor. To fix this, one could either derive a new Cursor with the desired behavior, or add a switch to the other existing cursor classes.
It's unclear to me if that component also controls file open/save windows, but that is where this behavior tends to bother me the most. I know KDE is not at all responsible for GNOME apps, but since GTK-based dialogs treat the underscore as a separation character, different apps on one system have inconsistent behavior. It would be great if this could be configured somehow.
(In reply to jat255 from comment #2) > It's unclear to me if that component also controls file open/save windows, > but that is where this behavior tends to bother me the most. I know KDE is > not at all responsible for GNOME apps, but since GTK-based dialogs treat the > underscore as a separation character, different apps on one system have > inconsistent behavior. It would be great if this could be configured somehow. It is unclear to me as well and the use case you mention is what actually brought me to open this bug report. But I agree wholeheartedly, this is an issue that needs fixing as it is neither logical nor consistent.
Fixed with the introduction of Camel case movement. Please enable "Editing -> Text Navigation -> Enable camel cursor movement"
(In reply to Waqar Ahmed from comment #4) > Fixed with the introduction of Camel case movement. Please enable "Editing > -> Text Navigation -> Enable camel cursor movement" Thanks. Would this apply elsewhere in Plasma (e.g. in Dolphin)? If that's not the case, what component should this bug be reopened against?
> Thanks. Would this apply elsewhere in Plasma (e.g. in Dolphin)? If that's not the case, what component should this bug be reopened against? It only applies to Ktexteditor and childern (KDevelop / Kate / KWrite ... ). For any other apps, everyone will need to implement that for whatever editor they have. Even in Kate for instance, this will only work in the text area and not for example in a search line edit.