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

Previous Next

Package: emacs;

Reported by: Wanrong Lin <wrglin <at> gmail.com>

Date: Fri, 7 Feb 2020 15:46:02 UTC

Severity: normal

Found in version 26.3

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Wanrong Lin <wrglin <at> gmail.com>
To: Andreas Schwab <schwab <at> linux-m68k.org>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 39484 <at> debbugs.gnu.org
Subject: bug#39484: 26.3; try-completion bug
Date: Wed, 28 Oct 2020 08:59:24 -0400
This is not implementation detail. This is the interface of this 
function. User/caller should know exactly what are the rules for the 
return value.

So in summary, my two points:

1. Return value is not ideal. You can argue it is still not wrong, but I 
think we can improve.
2. Even if we don't change anything here, we need to make this 
less-than-ideal behavior clear in the documentation (doc string).

I hope I convinced at least some of you.

Wanrong

On 10/28/2020 7:44 AM, Andreas Schwab wrote:
> On Okt 28 2020, Lars Ingebrigtsen wrote:
>
>> Andreas Schwab <schwab <at> linux-m68k.org> writes:
>>
>>> The case always matches one of the candidates.
>> Yes.  An arbitrary candidate (well, the first one, but it's not
>> documented, which means that it's arbitrary).
> It is not nessesary to document each and every implementation detail.
> That makes it difficult to change the implementation later, and it also
> unduly restricts the way a collection function can handle that
> situation.
>
> Andreas.
>





This bug report was last modified 3 years and 110 days ago.

Previous Next


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