bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#49888: 28.0.50; fido-mode not sorting by recency


From: João Távora
Subject: bug#49888: 28.0.50; fido-mode not sorting by recency
Date: Sun, 15 Aug 2021 13:38:58 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

João Távora <joaotavora@gmail.com> writes:

> João Távora <joaotavora@gmail.com> writes:
>
>> Manuel Uberti <manuel.uberti@inventati.org> writes:
>>
>>> In 'emacs -Q', this is what I did:
>>>
>>> - M-x savehist-mode RET
>>> - M-x fido-mode RET
>>> - M-x icomplete-vertical-mode RET
>>> - M-x emacs-init-time
>>> - C-x p p, pick a Git-versioned directory RET
>>> - f, pick the fourth candidate, C-x k RET
>>> - M-x now shows pr-ps-file-preview on top
>>> - C-x p p, pick the only available project
>>> - C-x p f does not offer the previously selected candidate
>>>
>>> Is it possible to make fido-mode sort the candidates by recency?
>>
>> I've now taken a look at this.  Yes, it is certainly possible and
>> desirable _if_ there aren't any other overriding criteria.  This has to
>> do with the 'flex' completion style.  In that style, if anything has
>> been input that leads to "flexy" filtering, the default and correct
>> behaviour is to sort by completion score.
>>
>> But if nothing has been input and there are basically no scores, it
>> makes sense to fall back to a sensible strategy like the one you
>> suggest.
>>
>> Try this patch.  It will fix the M-x case, bugt not the C-x p f or C-x f
>> cases unfortunately.  Those will be harder to fix.
>
> Actually, I correct that.  C-x f will be harder to fix, but C-x p f and
> C-x p p RET f work just fine!

I've just commited this fix:

    commit ab23fa4eb22f6557414724769958a63f1c59b49a (HEAD -> master, 
origin/master, origin/HEAD)
    Author: João Távora <joaotavora@gmail.com>
    Date:   Sun Aug 15 13:19:59 2021 +0100
     
        Sort by recency in flex completion style when no flexy stuff happening

There is still the C-x f bug, but that wasn't in your report.  You seem
to be concerned with M-x and C-x p f (as am I, by the way)

That other problem isn't even very well understood by me.  C-x f looks
for files in a single directory, but minibuffer history has whole
paths...  I think it deserves a new bug report if anyone really cares.

For now I think particular bug report can be closed.  If anyone
disagrees, let me know.

João





reply via email to

[Prev in Thread] Current Thread [Next in Thread]