[Bash-completion-devel] [Bash-completion-commits] [SCM] bash-completion branch, master, updated. 7d45595493e1f830a3ddbdff845f05ce5a0bc696

[Ville Skyttä]

On Saturday 06 November 2010, Guillaume Rousse wrote:
> Le 26/10/2010 20:16, Ville Skyttä a écrit :
> > On Tuesday 26 October 2010, Ville Skyttä wrote:
> >> On Tuesday 26 October 2010, Guillaume Rousse wrote:
> >>> I'm still interested in merging remaining similar patches (for rpm
> >>> database completion,
> >> 
> >> I don't personally find rpmdb completion too slow to warrant it being
> >> off by default.
> > 
> > Forgot to include some representative numbers about this; on a box with
> > Athlon
> 
> > 64 3200+, 3GB memory, and rpmdb on an SSD disk:
> 'SSD' and 'representative' together :) ?

Well, if that's the way you want to put it, shrug.  The numbers are 
representative in my experience.

> Sure, on any modern desktop or laptop, everything is fine. But just try
> on some 4/5 years-old outworked server, for instance... Everytime you
> hit <TAB>, just because you are used too on your own workstation, you
> are entitled to 2/3 second timeout.

Here are some numbers from such a server box (BIOS from 2004, box probably 
even older than that), P4 2.8GHz, 1.5GB memory, slow PATA disk, running CentOS 
5.5 i386.  The first time one of these commands are executed takes a bit of 
time (even a bit more than the 3 seconds you mentioned), but after that the 
numbers look like:

$ time rpm -qa --nodigest --nosignature --qf="%{NAME} " >/dev/null

real    0m0.119s
user    0m0.072s
sys     0m0.047s

$ time rpm -qa --nodigest --nosignature --qf="%{NAME} " "x*" >/dev/null

real    0m0.113s
user    0m0.069s
sys     0m0.045s

> Hence my point to make them at least
> configurable, and eventually disabled by default.

Configurable ok if people insist, disabled by default -1.

> Also, I'm not very happy with the name you used for the new avahi
> switch, as it's not very consistent with other variables names sofar:
> COMP_IWLIST_SCAN,

That's not documented in doc/bash_completion.txt BTW.

> COMP_CONFIGURE_HINTS, COMP_TAR_INTERNAL_PATHS all use
> a <command>_<verb> or <command>_<object> pattern, whereas
> COMP_KNOWN_HOSTS_WITH_AVAHI use <objects>_with_<command> pattern. I'd
> rather use something as COMP_AVAHI_HOSTS or COMP_AVAHI_KNOWN_HOSTS, for
> instance.

That would be inconsistent with all the other variables (except 
COMP_IWLIST_SCAN which IMO would be better named COMP_IWCONFIG_IWLIST_SCAN) 
because it places "avahi" at the beginning and this variable does not control 
avahi completions, it controls known hosts completions.  All the things that 
control something should have a common prefix ("COMP_" alone does not count) 
so they group naturally in sorted listings making them easier to look up (e.g. 
docs, env | sort), and all the existing variables (except COMP_IWLIST_SCAN) 
follow that naming.  And we already had COMP_KNOWN_HOSTS_WITH_HOSTFILE.  The 
WITH in COMP_KNOWN_HOSTS_* might be noise, but... meh.