bug#42149: Substring and flex completion ignore implicit trailing ‘any’

[Stefan Monnier <monnier@iro.umontreal.ca>]

>>> The latter is fixed by explicitly moving
>>> the position of ‘completions-first-difference’ in case an overlap with
>>> ‘completions-common-part’ is detected.
>>
>> Did you (by any chance) figure out how/why the two end up overlapping?
>> The fix you're using looks pretty "hackish" and introduces a non-trivial
>> data flow for `pos`.  Before using such an ad-hoc solution it'd be best
>> to understand where the problem comes from (it might still be the
>> better answer in the end, but it's hard to judge).
>
> `completions-first-difference' is put at the first position after point
> in the query string.

Oh, yes, I remember the problem is in the name: it is not really used to
highlight the first difference, but rather something like the "next
character to type" (which happens to be the first difference in the
simplest case of prefix completion).

In the example you show, I think overlapping *is* as good a behavior as
any other (and the code is careful to to replace one face with the other
but to actually put both faces there, so you get a bold-blue instead of
either bold or blue).  Moving the highlighting to the next character
like you've done seems actually worse in this case (e.g. if you're
completing ("f" . 0) against ("foo" "barfoo"), it's rather odd to
highlight the "b" of "barfoo" and the first "o" of "foo").

[ BTW, I notice that we have a bug currently in the highlighting:
  M-x for-s C-a ?
  correctly puts "for" and "s" in blue in the completion list, whereas
  M-x for C-a ?
  somehow fails to put "for" in blue :-(

>> This is good (consecutive `any` can introduce serious performance bugs
>> because of our backtracing regexp matcher).
>> Other than improving performance, have you found other effects?
>
> Yes, the presence of multiple consecutive wildcards invalidates the
> aforementioned assumption of completion-pcm--hilit-commonality that the
> match is of the form
>
>     <hole><match><hole><match>...<hole>

Makes sense, thank you.


        Stefan