possible bug in completion style for repeated pattern

[gtusr]

possible bug in completion style for repeated pattern

[oantolin]

That is the expected behavior. Orderless splits the input into components, compiles each to a regexp, and a string is considered to match if each component's regexp matches somewhere in the string. In particular it follows that repeating components makes no difference to whether a string matches or not.

For the particular example of matching something like fi fi to find-file, I'd suggest using the orderless-prefixes matching style and phrasing the input as fi-fi instead. Or you could use the orderless-regexp style and type fi.*fi.

[minad]

I wonder if it makes sense to add a special rule which compiles repeated patterns to literals separated by .*.

Alternatively one could combine all the styles but I don't think the quadratic, cubic behavior, etc would be a great idea.

[oantolin]

Even if we added that special rule, I'd still use fi-fi with orderless-prefixes for this example, because it matches fewer things as it means \<fi.*-fi. I think I'm happy with being precise about whether I mean \<fi.*-fi or just fi.*fi specially since I get to pick the syntax for those things. I've never found much use for fi.*fi so I don't mind typing two characters (. and *) to get that meaning, and I do have orderless-prefixes setup for components with dashes or a few other separators in them.

[oantolin]

We don't need that special rule since it is easy to do in your own configuration:

(defun respect-repeats (string)
  (mapcar
   (lambda (group) (string-join (cdr group) ".*"))
   (seq-group-by #'identity (split-string string))))

(setq orderless-component-separator #'respect-repeats)

[oantolin]

I'm closing this since I think this should be handled in configuration like in the above example code.

[minad]

Makes sense. It is just that users seem to often stumble over this issue. What about compiling repeated patterns to prefix syntax then? I think typing `fi-fi` vs `fi fi` still adds a little bit of mental overhead, since Orderless is relying so much on SPC. It would be an optional feature, which probably wouldn't add much complexity and wouldn't lead to a muddying of the overall character of Orderless. If you would be willing to add this one should check that other issues related to repeated patterns would be fixed. Iirc there was also a proposal that repeated patterns should somehow affect the ordering, which is obviously not a possibility.

[minad]

On 1/11/23 07:56, Omar Antolín Camarena wrote: We don't need that special rule since it is easy to do in your own configuration: (defun respect-repeats (string) (mapcar (lambda (group) (string-join (cdr group) ".*")) (seq-group-by #'identity (split-string string)))) (setq orderless-component-separator #'respect-repeats)

Oh, I see. That's very nice. So the only thing left then could be that we add this special separator to Orderless then. That's even less intrusive than I had expected. But keeping this in a user configuration or the wiki is fine too.

[gtusr]

Thanks for the explanation and a proposed solution by treating the repeated pattern as a special case that needs to use .* in order to concatenate the two terms.

But I think the problem is more general than this. Some users may naturally think in terms of the matches to the sequence of pattern components separated by spaces as being 'consumed' by the matching algorithm in some order, so that in the case of the OP, the first 'fi' in find-file would match, and then remove from further consideration, the fi in 'find', leaving just 'nd-file' for the second 'fi' to match.

Viewed from this perspective, the issue is no longer just about repeated pattern components.

Is there an easy way to configure orderless so that the matches to the individual pattern components cannot overlap in a successful candidate?

[oantolin]

Well, programs in the "machine language" that orderless compiles to are just list of regexps and the semantics are that a string matches the list if every regexp matches. Which is why orderless's semantics is chosen to be similar: input matches if each component matches according to the chosen styles.

But I think it's not too hard to do an alternative component separator where something like ab bc ef compiles to the list ("ab.*bc\|bc.*ab" "ef"). I'll try my hand at it when I get the chance.