GNOME Bugzilla – Bug 421736
filechooser should normalize strings
Last modified: 2018-04-15 00:29:21 UTC
If I have a file named "école" with <U+00E9 LATIN SMALL LETTER E WITH ACUTE>, when I start typing "école" with <U+0065 LATIN SMALL LETTER E + U+0301 COMBINING ACUTE ACCENT> the file should come up in the autocompletion and vice versa.
Sorry, I must have got mixed in my test. Autocomplete does work properly. Thus renaming the bug and restating it: If there is a file with one characters sequence in the name and the user types another character sequence but that is canonically equivalent to the other. The right file should be opened. This should be done carefully. Some people could have an input method or a keyboard layout that only give some characters, so this equivalence is needed. But some people might have two files in the same directory, so equivalence should be discarded in that case.
*** This bug has been marked as a duplicate of 423242 ***
reopening as this is more than just saving normalized filenames. The entry autocompletion/suggestion is faulty. For example we have two files - "écolier" with composed form <U+00E9 LATIN SMALL LETTER E WITH ACUTE> - "écolière" with decomposed form <U+0065 LATIN SMALL LETTER E + U+0301 COMBINING ACUTE ACCENT> Here’s what the autocompletion doing: typing: e autocompletion: (nothing, good as there are more than one possibility) suggestion: écolier écolière typing: é <U+0065 LATIN SMALL LETTER E + U+0301 COMBINING ACUTE ACCENT> autocompletion: écolière (bad as there are more than one possibility) suggestion: écolier écolière typing: é <U+00E9 LATIN SMALL LETTER E WITH ACUTE> autocompletion: écolier (bad as there are more than one possibility) suggestion: écolier écolière The suggestions are correct as they are normalized before comparison. The autocompletion is incorrect.
There are other faults in the current behaviour. Suggestion only works properly when both files are there. So if I only have the file "écolier" with the composed <U+00E9 LATIN SMALL LETTER E WITH ACUTE> typing: e autocompletion: (nothing, bad as there is one possibility) suggestion: (nothing, ditto) typing: é <U+0065 LATIN SMALL LETTER E + U+0301 COMBINING ACUTE ACCENT> autocompletion: (nothing, bad as there is only one possibility) suggestion: (nothing, ditto) Autocompletion is confusing because when both files are there (or only the decomposed one) typing just e suggest the accented names, but not when only the composed one is present. When only the file "écolière" with decomposed form <U+0065 LATIN SMALL LETTER E + U+0301 COMBINING ACUTE ACCENT> is present typing: e autocompletion: écolière (this is good, right?) suggestion: (nothing, good there's only one choice) typing: é <U+00E9 LATIN SMALL LETTER E WITH ACUTE> autocompletion: (nothing, bad as there is only one possibility) suggestion: (nothing) I'm not sure whether completion starting with combining marks are a good thing, at least in Latin script. It's a bit awkward to type e and have an accent completed when a decomposed name is an option but not only composed names are.
*** Bug 423257 has been marked as a duplicate of this bug. ***
*** Bug 423244 has been marked as a duplicate of this bug. ***
*** Bug 423247 has been marked as a duplicate of this bug. ***
*** Bug 423242 has been marked as a duplicate of this bug. ***
*** Bug 423282 has been marked as a duplicate of this bug. ***
*** Bug 423265 has been marked as a duplicate of this bug. ***
*** Bug 423264 has been marked as a duplicate of this bug. ***
*** Bug 423261 has been marked as a duplicate of this bug. ***
See gtk+/gtk/gtkfilechooserentry.c:find_common_prefix(). It should be easy to play with several possibilities there.
Created attachment 176764 [details] [review] patch to gtkfilechooserentry.c to normalize strings before comparison Thank Federico. This patch normalizes the string display_name to NFD before comparison. This way whichever way the user start inputting a name all canonically equivalent names will match. For example, the files "école.txt" with <U+0065 U+0301> and "école.txt" with U+00E9 will both be suggested when the user start typing é <U+0065 U+0301> or é U+00E9. Whether both files should not exist at the same time in the same directory is a matter of when they are created (moved or renamed) there.
Sorry the patch does what it shouldn't. Autocompletion can end up with an NFC form of a NFD filename, with that form not existing. And typing a NFD form does not autocomplete. I guess the prefix should be normalized too and the text up to cursor should be replaced when there's a unique canonically equivalent match.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new