Is it appropriate to add a non-formal algorithm?

[yomguithereal]

Is it appropriate to add a non-formal algorithm?

[Yomguithereal]

I think it makes sense to have it in a separate lib. What's more you will have better control of it and won't need me to validate your choices and publish the lib when you need to I think.

[Yomguithereal]

Hello @anonimitoraf. It looks a lot like a heuristic-based mix of multiple typical methods such as absolute bigram Dice coeff + first letters boosts etc. I guess the real question is: is this method particularly known and used, as is, by many people? So my first answer would be no because it's not very definite and a lot of alternative to this particular approach exist in the wild (such as sublime text's fuzzy matching heuristics) and tailored to this kind of use cases (mostly dev tool focused), while this lib is more about elementary building blocks. This said, a second way to answer the question would be: would it be useful to you that this is included to the library? In which case I would say why not?

[anonimitoraf]

Hi @Yomguithereal

I see. Yes, it seems like this algorithm is used by Emacs' ido (and maybe the others like ivy) for autocompletion (https://github.com/lewang/flx).

Based on that^ repo, Sublime Text uses a similar (if, not, the same) approach.

while this lib is more about elementary building blocks

Understood

would it be useful to you that this is included to the library? In which case I would say why not?

Actually, the bigger context to my initial question is: clojure-lsp uses this library for filtering particular search results (e.g. symbols within a project). It currently uses Dice coeff.
I personally find the results quite unintuitive so I suggested (to the clojure-lsp maintainer) to use https://github.com/lewang/flx instead.
TLDR: I can just make a separate lib and make a PR to clojure-lsp to use that lib, if it makes more sense to do so.

[anonimitoraf]

Thanks. I'll do that, then.