Use filter-exact-matches in much more places.

[aartaka]

This makes most of our sources more exact in matching the input. This is important for sources with URLs, medium-to-huge quantities of text, or many-attributes sources.

Please, someone, just look at this change and accept that our sources are more exact and useful now :)

Closes #2792.

Discussion

• Should I add test for that?
• Also note that nyxt/gi-gtk tests fail even on master :P

Checklist:

Everything in this checklist is required for each PR. Please do not approve a PR that does not have all of these items.

• Git hygiene:
  • I have pulled from master before submitting this PR
  • There are no merge conflicts.
• I've added the new dependencies as:
  • ASDF dependencies,
  • Git submodules,

    cd /path/to/nyxt/checkout
    git submodule add https://gitlab.common-lisp.net/nyxt/py-configparser _build/py-configparser

  • and Guix dependencies.
• My code follows the style guidelines for Common Lisp code. See:
  • Norvig & Pitman's Tutorial on Good Lisp Programming Style (PDF)
  • Google Common Lisp Style Guide
• I have performed a self-review of my own code.
• My code has been reviewed by at least one peer. (The peer review to approve a PR counts. The reviewer must download and test the code.)
• Documentation:
  • All my code has docstrings and :documentations written in the aforementioned style. (It's OK to skip the docstring for really trivial parts.)
  • I have updated the existing documentation to match my changes.
  • I have commented my code in hard-to-understand areas.
  • I have updated the changelog.lisp with my changes if it's anything user-facing (new features, important bug fix, compatibility breakage).
  • I have added a migration.lisp entry for all compatibility-breaking changes.
  • (If this changes something about the features showcased on Nyxt website) I have these changes described in the new/existing article at Nyxt website or will notify one of maintainters to do so.
• Compilation and tests:
  • My changes generate no new warnings.
  • I have added tests that prove my fix is effective or that my feature works. (If possible.)
  • I ran the tests locally ((asdf:test-system :nyxt) and (asdf:test-system :nyxt/gi-gtk)) and they pass.

[Ambrevar]

Why for buffers?

[aartaka]

Because buffers have URLs in them, and because buffer-source is used in set-url to match against buffers. In the latter case, it's extremely important to filter aggressively, so that the source disappears the very moment it becomes irrelevant.

[Ambrevar]

But it's not just URLs, it's also titles, so this may be too restrictive.
Same for all history sources.

[aartaka]

But then wait, filter-exact-matches matches against every word separately, so titles are fine too: if there's a word from a title and a word from a URL, the suggestion is still matched, right?

[Ambrevar]

Yup, but fuzzy-matching on titles is desirable.

[aartaka]

I'd still say that most of people search things by space-separated chunks of text, so fuzzy matching that works backwards or matches every single letter is not as useful as matching clearly delineated word-like sequences.

[aadcg]

I'm taking a look at this later today or tomorrow. Thanks!

[aadcg]

I believe @Ambrevar already did a good review.

This seems to address issue #2792, and probably closes it too. I wonder if the default for prompter:filter-preprocessor shouldn't be changed, but I didn't think about it enough.

Feel free to proceed as you find most adequate!

[aartaka]

This seems to address issue #2792, and probably closes it too.

Yes, I just was unable to find the issue xD

I wonder if the default for prompter:filter-preprocessor shouldn't be changed, but I didn't think about it enough.

I lean to that too, because filter-exact-matches is probably the most intuitive matching algo we have. But I'll leave that for @Ambrevar to decide, given that libraries/prompter is to be someday abstracted out, and that will prompt (pun not intended) for all the necessary architectural redesigns.