If count of matched by eix packages is large, then eix output $EIX_LIMIT entries and then continue performing a file IO operations for calculate exact count of packages matched packages. File IO operations on a 'cold' run may be appreciably slow. In my point, information, what matched more then $EIX_LIMIT packages, enough for make decision about doing more specifical request or enlarging display limit. I don’t know use cases where user need exact count of matched packages and has relatively small display limit (therefore not need in list all matched packages). Reproducible: Always Steps to Reproduce: 1. eix '*' 2. 3. Actual Results: First $EIX_LIMIT entries, wait, wait… exact count of matched packages. Expected Results: Only first $EIX_LIMIT entries and count of matched packages in form like: * n (where n <= $EIX_LIMIT); * ${EIX_LIMIT}+ (where n > $EIX_LIMIT).
The purpose of EIX_LIMIT is to save you from a huge scrolling when a query gives an unexpected long list (e.g. by a typo). The information whether only one or two packages are not shown or whether this is a huge number is rather important in such a case. Waiting for some seconds after such a typo is not so bad, especially since the time is only lost if a lot of packages would be output, i.e. only if it was really a typo. If you have to wait often for this you are doing something wrong. The alternative would be the previous hack which could not only output a completely wrong number but even output the EIX_LIMIT message if the limit is not reached. This was wrong behaviour and needed to be fixed.
Sounds reasonably. If long list is result of typo, then I can type Ctrl+C and repeat with fixed request. If that not typo, then count of matched packages is likely to important. Thanks for describe you view of these cases.
