https://bugs.kde.org/show_bug.cgi?id=525602
cwo <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #1 from cwo <[email protected]> --- We use committed text for all our search fields (i.e. text that was accepted in the input method). It's possible to get the pre-edit text (i.e. what is currently shown in the field, but was not accepted by the input method). But I'm not sure if this is the right thing to do, as pre-edit text often has little relation to the text that was entered, or the text that is the final output. For example, if I try to search for 日本語 the sequence of pre-edit text would be ｎ> に > にｈ> にほ > にほｎ> にほんｇ> にほんご> 日本語 (and if it wasn't the first suggestion for the final kanji. it would have other sequences before the final step) You'd likely get wildly jumping results and quite possibly a lot of "No matches" placeholders for the various in-between states; these are just not good things to search for. In general, if you set a particular keyboard layout or input method, it seems to make sense that you want results matching that input method/keyboard layout. But I can see how this is cumbersome if your input method uses latin characters that you actually want to search for as its pre-edit text. I'm not sure there's a good way to fix this with how things work currently. -- You are receiving this mail because: You are watching all bug changes.
