Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix identifying full matches in some cases. #149

Merged
merged 1 commit into from
Jul 25, 2023

Conversation

okamsn
Copy link
Contributor

@okamsn okamsn commented Jul 9, 2023

Fixes #147. Builds upon #148.

  • Change how regexps from filter methods added to candidates.
  • Fix filter method prefix so that it doesn't match more than intended. Other methods might also need to be changed.

@raxod502
Copy link
Member

Since this changes some behavior, I went ahead and finally added a unit test framework for prescient.el (#150) and added some tests covering your changes (5a194bb). Does that look good to you?

@okamsn okamsn force-pushed the full-match branch 11 times, most recently from 2d94917 to b43e334 Compare July 15, 2023 18:42
@okamsn
Copy link
Contributor Author

okamsn commented Jul 15, 2023

Thank you for adding the test framework. Writing the tests helped me find another bug in prefix.

@raxod502
Copy link
Member

Do you want to merge that one, then this one, or do you just want to merge this one? If the latter, do you want this one to be made into a single commit?

Any way is fine with me. Feel free to merge them yourself, or I can do it.

Do you care whether the properties attached to the candidates for sorting are keyword symbols or normal symbols?

You can do it either way; I have no opinion.

@okamsn okamsn force-pushed the full-match branch 5 times, most recently from e2edb8b to bbca50f Compare July 21, 2023 00:02
- Let `prescient-filter-regexps` return flat list of regexps.

  We need to be able to test the individual regexps produced by the
  filter methods to see if they fully match. If we use the `or`-ed
  combined regexps, which we use for filtering, then it's possible for
  Emacs to only find a matching substring using a partially matching
  sub-regexp before testing the fully matching sub-regexp, depending
  on the order in which the sub-regexps are `or`-ed together.

- Change the property list to use normal keys.

- Change `prescient-regexps` to `:prescient-match-regexps`.

- Add `:prescient-all-regexps`, which we need for proper sorting.

- Test the each regexp produced by a filter method separately.  Do not
  just re-use the regexps that were used for filtering. Do not assume
  that all of the tested regexps will match the candidates.

- Fix `prefix` with `:with-group` when the first character of the
  query is a word character.  Make sure to not accidentally match the
  middle of a word.

- Tweak the `prefix` filter method to better work with
  `prescient-sort-full-matches-first` and avoid conflicts when trying
  to use an initialism.  Don't use greedy matching when there are no
  non-word characters.

  1. "re" only matches "re" at the start of the word "repeat", not the
     entire word.  Otherwise, we run into conflicts when we want "re"
     to be an initialism for a longer command name, such as
     "restart-emacs".

  2. ".g" fully matches ".git".

  3. "s-r" fully matches "string-rectangle", not just "string-r".
     This can't conflict with `initialism`, so there is no harm in
     assuming that the "r" is meant to match an entire word, just like
     the "s" does.
@okamsn okamsn merged commit e0cca29 into radian-software:main Jul 25, 2023
4 checks passed
@okamsn okamsn deleted the full-match branch July 25, 2023 23:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

Improve prescient-sort-full-matches-first with multiple filter methods
2 participants