GNU bug report logs -
#43222
28.0.50; fido-mode selects wrong buffer to kill when no input
Previous Next
Reported by: Sean Whitton <spwhitton <at> spwhitton.name>
Date: Sat, 5 Sep 2020 15:40:01 UTC
Severity: normal
Tags: confirmed
Found in version 28.0.50
Done: João Távora <joaotavora <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 43222 in the body.
You can then email your comments to 43222 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
larsi <at> gnus.org, joaotavora <at> gmail.com, bug-gnu-emacs <at> gnu.org
:
bug#43222
; Package
emacs
.
(Sat, 05 Sep 2020 15:40:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Sean Whitton <spwhitton <at> spwhitton.name>
:
New bug report received and forwarded. Copy sent to
larsi <at> gnus.org, joaotavora <at> gmail.com, bug-gnu-emacs <at> gnu.org
.
(Sat, 05 Sep 2020 15:40:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
This is orthogonal to #43120 so far as I can tell.
1. emacs -q
2. M-x fido-mode RET
3. C-x C-f ~/src/emacs/lisp/icomplete.el RET
4. M-: (find-file (locate-library "icomplete.el.gz")) RET
5. C-x b icomplete.el RET
6. C-x k [wait for completions] RET|M-j
This should kill the buffer visiting icomplete.el (right?) but in fact
it kills the buffer visiting icomplete.el.gz. The first completion
offered by fido-mode is different from the default value shown in the
minibuffer prompt.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#43222
; Package
emacs
.
(Sat, 05 Sep 2020 22:49:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 43222 <at> debbugs.gnu.org (full text, mbox):
Sean Whitton <spwhitton <at> spwhitton.name> writes:
> This is orthogonal to #43120 so far as I can tell.
>
> 1. emacs -q
> 2. M-x fido-mode RET
> 3. C-x C-f ~/src/emacs/lisp/icomplete.el RET
> 4. M-: (find-file (locate-library "icomplete.el.gz")) RET
> 5. C-x b icomplete.el RET
> 6. C-x k [wait for completions] RET|M-j
>
> This should kill the buffer visiting icomplete.el (right?) but in fact
> it kills the buffer visiting icomplete.el.gz. The first completion
> offered by fido-mode is different from the default value shown in the
> minibuffer prompt.
Yup. This bug is present in Emacs 27, too...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) confirmed.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sat, 05 Sep 2020 22:49:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#43222
; Package
emacs
.
(Sun, 06 Sep 2020 07:05:01 GMT)
Full text and
rfc822 format available.
Message #13 received at 43222 <at> debbugs.gnu.org (full text, mbox):
Sean Whitton <spwhitton <at> spwhitton.name> writes:
> This is orthogonal to #43120 so far as I can tell.
>
> 1. emacs -q
> 2. M-x fido-mode RET
> 3. C-x C-f ~/src/emacs/lisp/icomplete.el RET
> 4. M-: (find-file (locate-library "icomplete.el.gz")) RET
> 5. C-x b icomplete.el RET
> 6. C-x k [wait for completions] RET|M-j
Followed your report and confirmed it. Notice that the problem only
happens because the file names share a common prefix: "icomplete.el"
Maybe the title (and the severity) of this bug should be changed to
reflect that. Do you know how to do that, Lars?
> The first completion offered by fido-mode is different from the
> default value shown in the minibuffer prompt.
This sentence indeed describes it. There code is fido-mode to "bubble"
up the default to the first result, but it isn't working for some
reason. I'd say the problem lies somewhere in
icomplete--sorted-completions.
João
Reply sent
to
João Távora <joaotavora <at> gmail.com>
:
You have taken responsibility.
(Sun, 06 Sep 2020 07:40:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Sean Whitton <spwhitton <at> spwhitton.name>
:
bug acknowledged by developer.
(Sun, 06 Sep 2020 07:40:01 GMT)
Full text and
rfc822 format available.
Message #18 received at 43222-done <at> debbugs.gnu.org (full text, mbox):
João Távora <joaotavora <at> gmail.com> writes:
> Sean Whitton <spwhitton <at> spwhitton.name> writes:
>
>> This is orthogonal to #43120 so far as I can tell.
>>
>> 1. emacs -q
>> 2. M-x fido-mode RET
>> 3. C-x C-f ~/src/emacs/lisp/icomplete.el RET
>> 4. M-: (find-file (locate-library "icomplete.el.gz")) RET
>> 5. C-x b icomplete.el RET
>> 6. C-x k [wait for completions] RET|M-j
>
> Followed your report and confirmed it. Notice that the problem only
> happens because the file names share a common prefix: "icomplete.el"
>
> Maybe the title (and the severity) of this bug should be changed to
> reflect that. Do you know how to do that, Lars?
>
>> The first completion offered by fido-mode is different from the
>> default value shown in the minibuffer prompt.
>
> This sentence indeed describes it. There code is fido-mode to "bubble"
> up the default to the first result, but it isn't working for some
> reason. I'd say the problem lies somewhere in
> icomplete--sorted-completions.
I've fixed this in 6fc502c1ef327ab357c971b9bffbbd7cb6a436f1.
Author: João Távora <joaotavora <at> gmail.com>
Date: Sun Sep 6 08:35:53 2020 +0100
Don't resort Icomplete candidates when default already on top
Fixes: bug#43222
Icomplete mode re-sorts candidates, bubbling the default to top if
it's found somewhere down the list. This is done according to two
criteria: exact match and prefix match. Before this fix, it didn't
take into account the possibility that the exact match for the default
would already be on top, and would incorrectly bubble a prefixing
completion down the list to the top. This commit fixes that.
* lisp/icomplete.el (icomplete--sorted-completions):
Rework. Recomment.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#43222
; Package
emacs
.
(Sun, 06 Sep 2020 18:28:02 GMT)
Full text and
rfc822 format available.
Message #21 received at 43222 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Sun 06 Sep 2020 at 08:39AM +01, João Távora wrote:
> I've fixed this in 6fc502c1ef327ab357c971b9bffbbd7cb6a436f1.
Thank you for this fix!
--
Sean Whitton
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 05 Oct 2020 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 316 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.