[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] bash_completion: propose file names for few commands

From: Fabien COELHO <fabien_at_coelho.net>
Date: 2007-06-03 11:06:56 CEST

Hello,

On Sat, 2 Jun 2007, Hyrum K. Wright wrote:

> This patch has been out there for a while, but hasn't had any comments.
> If there are none in the next few days, I'll open an issue.

As I'm the one who re-wrote most of the bash completion stuff a while
back, I feel responsible for it, so here are a few comments.

(0) I like the idea, but it raises issues...

(1) I'm unsure about external command calls from within the completion.
      ISTM that the current status is that there is not a single fork
      from the completion function (apart for bash internals).

      Breaking this should at least be discussed carefully.
      If okay, then :

>> + local FILESrevert
(2) calling 'svn status' on some repositories is a nightmare.

      fabien@briare DEV> time svn status
      ... lots of stuff, recursion, external repositories...
      real 0m54.989s

      Yes, 55 seconds. No one wants a 55s lag when typing <TAB>.

      At the minimum, the --non-recursive option should always be added.
      Moreover, it should also depend on the current completed word,
      so that only the relevant directories are listed?

(3) I do not like to have "awk" for such very simple stuff.
      use cut instead? Or emulate grep/awk in shell (one loop) ?

(4) minor style issue: lines should be within the 80 column limit.

(5) If costly things are performed on completion, there should
      be a way to disable it (say with an environment variable for
      instance).

-- 
Fabien.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jun 3 11:07:29 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.