View Single Post
Old 06-25-2024, 06:08 PM   #5
KevinH
Sigil Developer
KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.
 
Posts: 8,848
Karma: 6120478
Join Date: Nov 2009
Device: many
One way to handle this might be to provide a Sigil Tool command to convert all text to either NFD or NFC format, by choice of the user. That way if the User uses this command before running Find and Replace, it would allow Find and Replace to stand some chance of working perfectly without forcing one Normalization Form or the Other.

Alternatively I could instead force convert each file to NFC form and force Find and Replace contents to NFC form so that search and replace actually works and actual file position of cursor in the file makes sense.

Nothing I know will work when the file has the identical string one in NFD form and one in NFC form which is what I was trying to see how often that might happen. It seems some keyboard input methods form chars/text as NFC while other form chars as NFD while others form chars in the order typed. And from my testing it seems copying and pasting can easily end up with mixed forms.

Last edited by KevinH; 06-25-2024 at 06:11 PM.
KevinH is offline   Reply With Quote