Commit 09685c3682 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)
b88b257726