Re: Recommendation for CAPF setup when you don't know completion string in advance

[Daniel Mendler <mail@daniel-mendler.de>]

On 5/11/21 5:57 PM, Stefan Monnier wrote:
>> ;; XXX There is a small bug here, depending on interpretation. When
>> ;; completing "~/emacs/master/li|/calc" where "|" is the cursor,
>> ;; then the returned candidate only includes the prefix
>> ;; "~/emacs/master/lisp/", but not the suffix "/calc". Default
>> ;; completion has the same problem when selecting in the
>> ;; *Completions* buffer.
>>
>> Is it non-intentional that the suffix is thrown away?
> 
> I think the answer depends on the completion-style.  IIRC some
> completion styles do that on purpose (in order to preserve/reproduce
> the behavior of earlier completion code), whereas I seem to remember
> a few cases where we may do something like that not on purpose (rather
> because of a bug, or out of laziness).

I see. There is some code in `choose-completion-string` which checks if
the length of the resulting string equals the car of the
`completion-boundaries`. When choosing a directory, the minibuffer is
not automatically exited. But the suffix string after the directory is
still thrown away. I don't see where the completion style is involved here.

The problem is probably that when appending the suffix the resulting
choice is not necessarily a valid candidate. This is at least how I
thought about it when replicating the behavior in Vertico/Corfu.

We could adjust the `choose-completion` behavior such that the suffix is
never thrown away and completion is never automatically exited when a
suffix exists. Would that make sense or did I miss something? Is this
worth a bug report/patch?

Daniel