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

[Ville Skyttä]

On Sunday 07 November 2010, Guillaume Rousse wrote:
 
> However, there was a second completion in my list: remote path
> completion through scp. Here, whatever your hardware, you also depends
> on remote hardware, and on network congestion. Morevoer, there is no
> speedup at second attempt.

True.

> All this concurs to make it a 'potentially
> slow' completion, hence my suggestion to make it disabled by default.

I see your point, but personally I still disagree with disabling it by 
default, my earlier reply in this thread had some reasons for it:
http://lists.alioth.debian.org/pipermail/bash-completion-devel/2010-
October/003114.html

Also, if we don't do remote path completion, I'd be surprised if finding out 
the remote path one wants to use by other means (probably separately ssh'ing 
to the box and listing dirs) wouldn't take more time and typing than just 
waiting for the completion to happen.  Is the slowness _really_ a problem that 
should be addressed by disabling this feature by default?  I honestly don't 
see it being a problem - if it is, just don't hit the tab (but then what do 
you actually do at that point if there are no remote file completions?).

> Morevoer, this would be consistent with a switch we already have for CVS
> (COMP_CVS_REMOTE).

True.  But I think there's a difference in behavior: with CVS_COMP_REMOTE off, 
one gets local file completions that are quite useful - often one knows what 
files are to be committed anyway (well at least I do ;)) and local completions 
work fine for that.  With remote scp filename completion off, there are no 
completions at all for remote files, and remote files are pretty much the only 
ones that make sense in the cases where the completion would be invoked.  So 
COMP_CVS_REMOTE off doesn't actually prevent anything or get in the way, 
whereas remote file completion off for scp would.

> Unfortunatly, I also realized than as long as we don't have a
> standardized configuration process, we can't do it easily. Unless we use
> an ugly mix of 'enable-if-defined' and 'disable-if-defined' environment
> variables :/

I'm afraid we'll end up needing something like that eventually.

> What about the following naming scheme then ?
> COMP_IWCONFIG_WITH_IWLIST
> COMP_KNOWN_HOSTS_WITH_HOSTFILE
> COMP_KNOWN_HOSTS_WITH_AVAHI

No objections, and COMP_KNOWN_HOSTS_* are IIRC already that way.  But I'd hold 
changing names of these variables until we have decided whether we want to 
rename them all some way as part of the namespace item on the roadmap for 2.0 
(which is currently for functions only, but I think variables should be 
considered at the same time) to annoy end users less.