From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6202 invoked from network); 16 Jun 2000 14:55:08 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 16 Jun 2000 14:55:08 -0000 Received: (qmail 9824 invoked by alias); 16 Jun 2000 14:55:01 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 11948 Received: (qmail 9806 invoked from network); 16 Jun 2000 14:55:01 -0000 Date: Fri, 16 Jun 2000 16:54:58 +0200 (MET DST) Message-Id: <200006161454.QAA07423@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Peter Stephenson's message of Fri, 16 Jun 2000 14:47:07 +0100 Subject: Re: Cygwin path completion Peter Stephenson wrote: > Andrej wrote: > > Even if > > we cannot find out all drives (is it possible?) _path_files still has to > > treat /cygdrive/?/ specially, and not try to glob it. It can also always > > offer ``cygdrive'' for the first component (of course, if it matches > > current prefix/suffix). > > Sven will have to answer for the feasibility of all of this, but... > > One thing that might fit our needs here and elsewhere (e.g. speedups of > path completion when you know you don't want initial path components > re-jigged) is a style along the lines of fix-path-prefix, only maybe with a > better name. A number would fix that many components (`2', here), while > something else e.g. `all' would turn off completion of earlier bits of the > path altogether. A more generic `fix-prefix' might possibly be useful in > certain other completions. [Btw. I forgot to remove the optimation in the C-code again that makes initial existing directories be accepted immediately. We can't do that, because, if you have `foo/x' and `foobar/y' and try `./foo/y' it won't complete to `foobar/y'. (It will work with `foo/y' for another reason...) ] Is the number really enough? But only if statting the thing shows that there is such a file, right? I think I'd still prefer patterns -- they are more flexible and can still made to match a certain number of components. Maybe we'll just have to try. Andrej Borsenkow answered: > While this may be useful, I meant something different. I'd prefer if > /c/d/t would still complete to /cygdrive/d/temp. I meant, that > _path_files (BTW I agree that it already deserves to be converted to > shell code. It may even give old compctl the ability to complete paths) I guess you mean C. And we started already. And _path_files (with some more optimisations I sent this morning) isn't really that slow anymore. I, at least, will *not* do anything to help compctl. Never again. > should simply stuff cygdrive as first component. In the above case the > possible completions would consist of > > /c*/d*/t* AND > /cygdrive/d/t* That's of course a completely different thing from the accept-thingy. I know nothing about cygwin, but maybe a style for _path_files that gives pairs of patterns and (sets of) strings. If the word on the line matches a pattern, the strings will be taken to be possible completions. So you could do: zstyle '...:paths' fake-paths '/[^/]#:cygdrive' '/cygdrive/:a b c d' Maybe even with ways to say `only that' and `this plus whatever you find yourself'. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de