prescient-filter-method values are not documented completely and partly wrong

[tsdh]

The anchored prescient-filter-method is not documented in the docstring and a bit testing seems to reveal that the current description of prefix actually matches the behavior of anchored whereas the actual behavior of prefix is just "prefix matching with no magic", i.e., no partial matching of candidate word beginnings.

So the behavior and naming seems right but the documentation needs an update.

[okamsn]

The prefix matching turns queries like fi-fi--p into \<fi[[:word:]]*-fi[[:word:]]*-[[:word:]]*-p and a.b.c into \<a[[:word:]]*\.b[[:word:]]*\.c.

The description of the transformation is

Value prefix means the words (substrings of only word characters) match the beginning of words found in the candidate, in order, separated by the same non-word characters that separate words in the query.

What part of the description is misleading/insufficient, and how do you think it could be improved?

[tsdh]

I think the description you quoted mostly matches the (undocumented) anchored filter method but certainly not the prefix filter method as I can observer with the current MELPA version.

Take this example. After typing "f b" only two of the 4 candidates are left, namely foo-bar and bar-foo where the f and b are underlined and bold indicating that they match the input. With an input of "f-b" only foo-bar matches.

(progn
  (setq prescient-filter-method '(anchored))
  (selectrum-completing-read "=> " '(foo-bar foo-quux bar-baz bar-foo)))

When doing the same with just the prefix filter method, I actually don't really understand the behavior (and even less how this method should be useful).

(progn
  (setq prescient-filter-method '(prefix))
  (selectrum-completing-read "=> " '(foo-bar foo-quux bar-baz bar-foo)))

If I have the input "foo", I would think that the prefix foo of foo-bar and foo-quux should be highlighted, but no, nothing is highlighted and all four candidates are still available. Even if I type "test test test" as input, all four candidates stay available. Only after typing "foo-" (including the hyphen), that prefix is highlighted in foo-bar and foo-quux, and at this point the candidates are restricted to those two.

So my claim is that

• the anchored filter method is undocumented (but its behaviour matches the description of the prefix method except for the "in order" part as demonstrated with my example where "f b" also matched bar-foo.)
• the prefix filter method does not what the documentation states (and I think it behaves very strange which might mean it is broken)

[okamsn]

When I wrote the prefix filter method, I assumed that people would only want to use it when there were non-word characters in the query, and it currently only activates on that condition. I apologize for the confusion caused by this oversight, and will remove that restriction in a pull request.

You are correct that the anchored method is similar to the prefix method. The description in question (as I understand it) is correct for both, but the anchored method is more flexible in that it can use "FiFiAP" and "fi-fi-a-p" to match "find-file-at-point" (described here: #70), while prefix can only use the latter.

One important difference I noticed is that with anchored "FP" will match "fill-individual-paragraphs", but prefix would currently need to use "f--p", not "f-p".

In a way, then, I think one can look at the prefix filter as a stricter and less featured version of the anchored filter. With that in mind, do you think that prefix filter should be changed to be more different? For example, the prefix filter returns a regexp that starts by matching the beginning of a word, but do you think it might be better if it matched the beginning of the candidate instead?

[tsdh]

@okamsn I think prefix will be useful after removing that "input must contain non-word character" restriction and then I'll have to check if I prefer prefix over anchored or the other way round.

What I'd definitely would like to have was a strict, no-magic "prefix" filter method similar to literal but only allowing candidates which start with the given input string rather than containing it at some arbitrary position.

And of course, anchored should be documented.

[tsdh]

@okamsn @raxod502 Yes, looks fine, thanks!

I've also got some time to implement the "strict, no-magic prefix" filter method in PR #79 I've mentioned in my comment above.

What I'd definitely would like to have was a strict, no-magic "prefix" filter method similar to literal but only allowing candidates which start with the given input string rather than containing it at some arbitrary position.