GNOME Bugzilla – Bug 423237
Find dialog doesnt normalize search history
Last modified: 2020-11-24 09:59:10 UTC
Search history is not normalized when used for autocompletion. It should be. For example: I succesfully search for "école" with U+00E9 LATIN SMALL LETTER E WITH ACUTE in a document so it is in the search history. If I change keyboard layouts and use one with combining diacritics, typing the beginning of "école" with <U+0065 LATIN SMALL LETTER E + U+0301 COMBINING ACUTE ACCENT> doesn't autocomplete to what's equivalent and already in the search history.
I can not reproduce this bug. It was maybe fixed some time ago. Feel free to reopen this bug if the problem still occurs with a more recent gedit version.
Created attachment 251913 [details] test file with same string in NFD and NFC first line is NFD second line is NFC
I'v attached a test file with the same string "école" in NFD (where e-acute is decomposed in e and combining acute) and "école" in NFC (where e-acute is a single character). Steps to reproduce: 1. Ctrl+H or Search>Replace 2. Search for the NFC "école" (copy the string from the second line to be sure) 3. Start inputing the NFC word with "é" and the search history autocompletes with "cole". 3. Start input the NFD word with "é" (copy if from the first line to be sure) and nothing happens as if the string was never searched. The expected behaviour is autocompletion with "cole". The NFC and NFD strings are equivalent, and actually return the same search results, they should therefore be treated as the same search string in the history for autocompletion.
OK thank you for the details. Now I can reproduce the problem.
Mass-closing of all gedit bugzilla tickets. Special "code" to find again all those gedit bugzilla tickets that were open before the mass-closing: 2bfe1b0590a78457e1f1a6a90fb975f5878cb60064ccfe1d7db76ca0da52f0f3 By searching the above sha256sum in bugzilla, the gedit contributors can find again the tickets. We may be interested to do so when we work on a specific area of the code, to at least know the known problems and possible enhancements. We do this mass-closing because bugzilla.gnome.org is being replaced by gitlab.gnome.org.