[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#48841: fido-mode is slower than ido-mode with similar settings
From: |
João Távora |
Subject: |
bug#48841: fido-mode is slower than ido-mode with similar settings |
Date: |
Thu, 17 Jun 2021 22:29:22 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Dmitry Gutov <dgutov@yandex.ru> writes:
> On 14.06.2021 03:16, João Távora wrote:
>>> Perhaps predicate it on the value of icomplete-hide-common-prefix instead?
>>>
>>> fido-mode sets it to nil, and this way we retain a better level of
>>> abstraction, and better backward compatibility for vanilla
>>> icomplete-mode users.
>> This is a good idea, the level of abstraction. But what is this
>> "common prefix" anyway? Is it the the same as the "determ"
>> thing, or the "[mplete...] dance" as I called it earlier. Shouldn't
>> fido-mode then_hide_ it?
>> I'm confused, but if you're not, go ahead and make that more
>> abstract change instead of relying on fido-mode.
>
> So... it's a bit more complex than that.
Yes, my batch broke the things you mentioned.
> It seems there are two ways to proceed from here:
>
> - Just alter the printing logic in the "single match" case to print
> the match text in full is it's not equal to the input string. I
> haven't puzzled out the logic doing that yet.
>
> - Try to keep the current behavior while avoiding the duplicate work.
Both sound absolutely fine to me.
> About the latter option: the result of that most-try stuff is only
> useful when there is only one match, right?
No idea, but may be.
> Unless I'm missing something and the value does see some use in the
> multiple-matches situations, the patch below both keeps the current
> behavior and gives the same performance improvement:
That'd be fantastic, but I doubt you'd be keeping the exact same
behaviour. I never understood it -- that's the thing here -- but I
think that completion-try-completion is doing more stuff when multiple
candidates matched by a pattern happen to share the same prefix or
suffix or something like that. I might be completely wrong, tho.
But really if you make this patch conditional to fido-mode or that other
var that you think is more abstract, I think it's fine and it's a very
clear win. I really doubt that the tiny number of fido-mode users care
about that behaviour anyway, but I'm sure they'll appreciate the
considerable speedup.
João
- bug#48841: fido-mode is slower than ido-mode with similar settings, (continued)
- bug#48841: fido-mode is slower than ido-mode with similar settings, João Távora, 2021/06/11
- bug#48841: fido-mode is slower than ido-mode with similar settings, Dmitry Gutov, 2021/06/11
- bug#48841: fido-mode is slower than ido-mode with similar settings, João Távora, 2021/06/13
- bug#48841: fido-mode is slower than ido-mode with similar settings, Dmitry Gutov, 2021/06/13
- bug#48841: fido-mode is slower than ido-mode with similar settings, João Távora, 2021/06/13
- bug#48841: fido-mode is slower than ido-mode with similar settings, Dmitry Gutov, 2021/06/16
- bug#48841: fido-mode is slower than ido-mode with similar settings,
João Távora <=
- bug#48841: fido-mode is slower than ido-mode with similar settings, Stefan Monnier, 2021/06/05
- bug#48841: fido-mode is slower than ido-mode with similar settings, João Távora, 2021/06/06
- bug#48841: fido-mode is slower than ido-mode with similar settings, Dmitry Gutov, 2021/06/06
- bug#48841: fido-mode is slower than ido-mode with similar settings, João Távora, 2021/06/06
- bug#48841: fido-mode is slower than ido-mode with similar settings, Dmitry Gutov, 2021/06/06
- bug#48841: fido-mode is slower than ido-mode with similar settings, João Távora, 2021/06/06
- bug#48841: fido-mode is slower than ido-mode with similar settings, Stefan Monnier, 2021/06/06
- bug#48841: fido-mode is slower than ido-mode with similar settings, João Távora, 2021/06/06