mirror of
https://github.com/fish-shell/fish-shell.git
synced 2025-02-27 08:07:24 +08:00
b88b257726
Commit 09685c36826c5d5d41565e00ed2d92e67997ac6a tried making the apt completions faster by doing two things: 1. Introduce a limiting "head" 2. Re-replace our "string" usage with tr Unfortunately, in doing so it introduced a few issues: 1. The "tr" had a dangling "+" so it cut apart package descriptions that contained a "+". This caused e.g. "a C++ library" to generate another completion candidate, "library". 2. In reusing "tr" it probably reintroduced #8575, as tr is not 8-bit-clean. 3. It filtered too early, on the raw apt-cache output, which caused it to fill up with long descriptions. So e.g. for "texlive" it would only generate 10 completions, where it should have matched 54 packages. Because most of the speedup is in the "head" stopping early, we instead go back to the old string way, but introduce a limiting "head" after the "sed" (which will have removed everything but the package name line and the first line of the description) In my tests this is about ~10% slower than doing head early and using tr, but it's more correct. Admittedly I haven't been able to reproduce the 35s scenario that 09685 talks about, but the most likely cause of that is *apt-cache* being slow - I don't see how string can be that much slower on another system - and so it will most likely also be fixed by doing head here. Future possibilities here include: 1. Using "apt-cache search --names-only", which gives a much nicer format (but only for non-installed packages - the search strings are apparently ANDed?) 2. Switching to `string split`, possibly using NUL and using `string split0`? 3. Introducing a `string --null-in` switch so we can get by with one `string` 4. (multi-threaded execution so the `string`s run in parallel)