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. _______________________________________________ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel