GNU bug report logs - #39484
26.3; try-completion bug

Previous Next

Full log

View this message in rfc822 format

From: Wanrong Lin <wrglin <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Andreas Schwab <schwab <at> linux-m68k.org>, 39484 <at> debbugs.gnu.org
Subject: bug#39484: 26.3; try-completion bug
Date: Wed, 28 Oct 2020 11:47:34 -0400

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
>

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.