[Feat. req.?]: Diacritic-sensitive search (Ctrl+Find)
Hi, It would be great if, as there is a case-sensitive search, there were a diacritic-sensitive option. In fact, I would expect by default that if I search for "esta", Dillo would also find "ésta". Another example would be searching for "accion" that matches both singular "acción" (with accent) and plural "acciones" (without accent). That's Spanish specific, but we may want that for any language, i.e. several diactritical marks: ` ^ ´ ¸ ¨ I don't know how hard it would be to implement, just wanted to mention it as a useful feature. As a good news, I wanted to say that, with the experimental fltk-1.4 flavor, I can use my preferred font (Atkinson Hyperlegible Next) and all absent glyphs are displayed accordingly —a bit off the line I should say, but I knew graphical glitches are to be expected. Best regards!
Hi Juan, On Sun, Apr 05, 2026 at 11:53:03AM -0300, Juan M Sevilla wrote:
Hi,
It would be great if, as there is a case-sensitive search, there were a diacritic-sensitive option. In fact, I would expect by default that if I search for "esta", Dillo would also find "ésta". Another example would be searching for "accion" that matches both singular "acción" (with accent) and plural "acciones" (without accent). That's Spanish specific, but we may want that for any language, i.e. several diactritical marks: ` ^ ´ ¸ ¨
I don't think the matching algorithm would be trivial. For example, should "una" match both "una" and "uña" in Spanish? What about other languages? Firefox for example matches both but I wouldn't see it as the correct behavior (they are two unrelated words in Spanish).
I don't know how hard it would be to implement, just wanted to mention it as a useful feature.
The current search algorithm matches bytes as-is. Trying to do something clever would require us to iterate by glyphs instead, which would be harder to implement and require more computational cost. I would wait until we have strong evidence that this feature is needed and the cost of the implementation is worth it.
As a good news, I wanted to say that, with the experimental fltk-1.4 flavor, I can use my preferred font (Atkinson Hyperlegible Next) and all absent glyphs are displayed accordingly —a bit off the line I should say, but I knew graphical glitches are to be expected.
Thanks for testing! Be sure to use the latest commit of FLTK from their master branch in GitHub, as they contain recent fixes (few weeks ago) for font rendering. Best, Rodrigo.
Hi, 7 Apr 2026 20:30:01 +0200 Rodrigo Arias:
I don't think the matching algorithm would be trivial. For example, should "una" match both "una" and "uña" in Spanish? What about other languages?
That's fair. I would say that's the reason why it would have to be an optional filter, so users could disable it on those cases.
The current search algorithm matches bytes as-is. Trying to do something clever would require us to iterate by glyphs instead, which would be harder to implement and require more computational cost.
I would wait until we have strong evidence that this feature is needed and the cost of the implementation is worth it.
I agree. Thank you for considering it! For now, it's not so difficult to type the variations of words one want to find. Even for misspelled words: I can omit the accentuated character; on some cases, I may look for another related word, etc.
Thanks for testing! Be sure to use the latest commit of FLTK from their master branch in GitHub, as they contain recent fixes (few weeks ago) for font rendering.
I'll certainly check it out! I was using the Debian stable version: FLTK 1.4.3 Kind regards!
participants (2)
-
Juan M Sevilla -
Rodrigo Arias