bug#39484: 26.3; try-completion bug

[Wanrong Lin]

The examples I gave are real life situations. I discovered this issue 
from an unexpected behavior with ido. The "bug" has real negative 
consequences, at least for me.

As for this:

"It does it by refraining from mix-and-match:
either the whole result comes from the user input or the whole result
comes from *one* of the candidates."

It still sounds quite arbitrary to me, as I failed to understand why it 
is bad if the whole result comes from *all* of the candidates if that 
happens to be possible.

I will try to give a version which I think is better (up to debate, of 
course)

For the user input x, return a string y (or nil if impossible) so that 
it satisfies all three conditions below:

1. x is a prefix of y, ignoring case.

2. y is the maximum common prefix, ignoring case, among all candidates

3. y is the *exact* (including case) prefix of at least one of the 
candidates

Wanrong

On 10/28/2020 10:45 AM, Stefan Monnier wrote:
> > 1. Return value is not ideal. You can argue it is still not wrong, but
> >     I think we can improve.
> Indeed, it can be improved, but we should not try to be too clever about
> it, because some choices might seem obvious in some circumstances but
> would result in rather poor answers in other cases.
>
> So rather than hypothetical cases like what we've seen here, I'm much
> more interested in real life situations.
>
> The current design is trying to be conservative, in the sense that it
> tries to avoid returning a poor result, at the cost of sometimes failing
> to return a better result.  It does it by refraining from mix-and-match:
> either the whole result comes from the user input or the whole result
> comes from *one* of the candidates.
>
> There are cases where `completion-try-completion` (as opposed to
> `try-completion`) doesn't actually follow this rule correctly, and it's
> been a source of suboptimal results.
>
>
>          Stefan