Allow more customizations of formatResult() #893

Activity

1. tkirda commented on Sep 29, 2026

   

   tkirda

   on Sep 29, 2026

   Last edited by tkirda

   Owner

   More actions

   Thanks for the suggestions! Taking them one at a time:

   1. <mark> instead of <strong>. Changing the default would break existing styling (the README's CSS and many sites target .autocomplete-suggestions strong), so the default stays. But you don't need to rewrite the formatter: the built-in one is available as $.Autocomplete.defaults.formatResult, and it escapes everything except its own <strong> tags, so swapping the tag is safe:

   formatResult: (suggestion, currentValue) =>
       $.Autocomplete.defaults
           .formatResult(suggestion, currentValue)
           .replace(/<(\/?)strong>/g, '<$1mark>'),

   2. Accent-insensitive matching. Small correction on the mechanism: case-insensitive "CAFÉ" vs "café" already works today (the highlight regex uses the i flag, which handles É/é). The regex u flag doesn't fold accents, though — /cafe/iu still won't match "Café".

   For local lookups, accent-insensitive filtering is a one-line custom lookupFilter:

   const fold = (text) => text.normalize('NFD').replace(/\p{M}/gu, '').toLowerCase();
   
   lookupFilter: (suggestion, query) => fold(suggestion.value).includes(fold(query)),

   With that, cafe finds Café; the default formatter just won't highlight the accent-folded match. I prototyped a built-in option that also handled highlighting, but decided the extra API surface wasn't worth it, so both snippets are going into the README instead (#899). If highlighting of accent-folded matches turns out to matter to more people, I'm happy to revisit.
2. tkirda

   added a commit that references this issue on Sep 29, 2026

   docs: add recipes for accent-insensitive filtering and <mark> highlig…

   ...

   3150c22
3. tkirda

   closed this as completedin #899on Sep 29, 2026