Dmitry Gutov <dmitry@gutov.dev> writes:

> On 18/08/2025 21:53, Spencer Baugh wrote:
>> Properly fix bug#38458, which is fundamentally an issue with
>> completion-ignore-case, by checking if the completions are
>> unique ignoring case.  When the completions are unique, the
>> normal code to delete a wildcard naturally causes point to be
>> moved to the end of the minibuffer, which is the correct
>> behavior.
>> Now that the bug is fixed properly, remove a hack which
>> previously was used to "fix" it, which made point behave
>> inconsistently if it was in the middle of the minibuffer versus
>> at the end of the minibuffer.
>
> Thanks, the description makes sense and the tests are great to have.
>
> I wonder if Stefan will want to comment though.
>
> Just one thing:
>
>> +                                      ;; They're all the same string, ignoring case.
>> +                                      (seq-every-p
>> +                                       (lambda (elem) (string-equal-ignore-case elem prefix))
>> +                                       comps)))))
>
> Is this performance-sensitive? Using a less abstracted function like
> cl-every of even a (cl-loop for ... always ...) could be faster.
>
> There is a (dolist) above it which iterates across segments of the
> pattern, so whatever overhead is added could be multiplied; OT2H I
> haven't tested it myself yet, maybe all bottlenecks are somewhere
> else.

Hm, good point.  After thinking about it more, I realized that the
second try-completion call above somewhat duplicates the check I added,
and that I could refactor in general to improve performance here.

So I reworked the change a bit to combine my check with the second
try-completion call.  This should have better performance even though we
aren't using the C implementation of try-completion anymore, since we're
now doing much less work than try-completion does.

(I also refactored to use a cond instead of (or (and ...) (and ...)),
which I think makes this logic a fair bit clearer)