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

[João Távora]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> `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

I agree with this general idea.  I think we have to be careful to write
tests in terms of user experience as much as possible.  For example, in
the very latest version of the code I pushed, I still have one of
Dario's original tests failing (down to only two now).

   completion-substring-test-4

Actually, only 1 of 3 of its assertions is failing (and this is an
argument for splitting it up further).  This is that assertion:

 (should (equal
           (completion--pcm-first-difference-pos
            (car (completion-substring-all-completions
                  "jab" '("dabjabstabby" "many") nil 1)))
           6))

The number returned by the current code is 4, and not 6.  Maybe this is
wrong, but I don't know if it makes a difference.  If I evaluate

  (let ((completion-styles '(substring)))
     (completing-read "hey? " '("dabjabstabby" "dabjabfooey" "many")))

... and then type "jab", backtrack two characters, and type TAB.  I see
the 's' of stabby and the 'f' of fooey being highlighted as the "next
character to type".  I also see "jab" correctly highlighted.  Exactly as
expected.  Likewise if I evaluate this:

  (let ((completion-styles '(partial-completion)))
     (completing-read "hey? " '("few" "many" "foo")))

which is similar to the other failing test.

Anyway, what I mean is that we need to see tests that tell us when
things are failing at this level.  It's not always easy to write such
tests: we should pick "public" interfaces carefully (regardless of these
problems Dario did a great job with the new tests, which are certainly
better than the pure nothing we had there.)

João