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

Previous Next

Full log

Message #62 received at 39484 <at> debbugs.gnu.org (full text, mbox):

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

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