Re: File completion under Cygwin again

Re: File completion under Cygwin again

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> It seems, that there is some demand for Zsh under Cygwin (and I got private
> mail asking for binary distribution). For this reason I list problems/wishes I
> am aware about now; it would really be nice if some of these were fixed in
> 4.0.
> 
> 1. drive:/path completion.
> 
> This is an absolute path on under Cygwin. Currently, Zsh treats it as relative
> to current directory.

Use the fake-files style to offer `a:/' etc. Then use an
implementation of _first that makes compset -P '?:/' and calls _files
with -W. Does that work?

> 2. UNC path completion - //server/share/path - here actually subtopics
>  a) server name completion
>  b) share name completion
>  c) path completion
> 
> a) is unlikely and I am currently unaware of any easy way to implement b), but
> c) is quite possible. Current problem is, globbing on the first two levels
> fails and Zsh finds no match.

I'm not exactly sure what this does, but maybe it could be done with
some more fiddling with _first (I mean: completing the server names)?

> 3. (related to 2) currently we can either squeeze all slashes or nothing.
> Under Cygwin initial `//' is significant and must not be squeezed
> irrespectively of squeeze-slashes settings.

That's just an additional value for squeeze-slashes and a bit of extra 
code in _path_files:298. I think.

> 4. Windows is using case-insensitive file system, so some way to make file
> name completion case-insensitive is needed. It is _not_ the same as simply set
> global matcher - it is applied to _every_ completion, and this is not always
> appropriate.

Use the matcher style? (Not matcher-list.)

> 5. (related to 4) things are complicated by the fact, that you can mount
> case-sensitive file system (e.g. off SAMBA server), so, if we could say "names
> with this prefix are case sensitive and with this not" ...

The matcher style with `zstyle -e'?

> 6. drive:path completion (x:path)
> 
> This is *not* the same as 1. It is relative path that is interpreted as
> "relative to current directory of drive x). Unfortunately, this seems to be
> broken in current cygwin, but for the record ...

But the solution may be similar to that for 1, i.e. a bit of checking
in _first, and fake only `a:' etc, not `a:/'.

> 7. Backslash handling. So, that I do not forget it myself :-)

I once said that this may be hard. But maybe it can be made simple:
just convert all backslashes to slashes before completing >:->


Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

RE: File completion under Cygwin again

[Andrej Borsenkow]

> >
> > 1. drive:/path completion.
>
> Use the fake-files style to offer `a:/' etc. Then use an
> implementation of _first that makes compset -P '?:/' and calls _files
> with -W. Does that work?
>

Mmm ... yes and no. It is simply too early. It will try to modify any word
that looks like x:/foo; and it needs to be done for "real" file names only.
I.e. in _path_files.

Anyway, adding (conditional) checking for ?:/ prefix is trivial (for anybody
who spent two years on _path_files at least :-). The question is - may it be
used for something else?

Is root-name style good enough? With implied usage

zstyle 'completion:*:paths' root-name '/ ?:/'

and implementation that basically sets donepath to root-name and strips it
off.

> > 2. UNC path completion - //server/share/path - here actually subtopics
> >  a) server name completion
> >  b) share name completion
> >  c) path completion
>
> I'm not exactly sure what this does, but maybe it could be done with
> some more fiddling with _first (I mean: completing the server names)?
>

The same as above. And could be implemented by

zstyle 'completion:*:paths' root-name '//server1/(share1|share2)/
//server2/share3/ ...'

And server/share names itself could already be completed with fake-files.

>
> > 4. Windows is using case-insensitive file system,
>
> Use the matcher style? (Not matcher-list.)
>
> > 5. (related to 4) things are complicated by the fact, that you can mount
> > case-sensitive file system (e.g. off SAMBA server),
>
> The matcher style with `zstyle -e'?
>

This is currently the best approximation. The only comment - this has to be
set for every tag that represents file names; users (and completion function
authors) are free to invent there own tags; and there is no ultimate tag list
currently (and cannot be).

I.e. again - it is property of file names, not particular completion context,
and logically should be implemented in _path_files. paths tag? Like for
squeeze-slashes?

>
> > 7. Backslash handling. So, that I do not forget it myself :-)
>
> I once said that this may be hard. But maybe it can be made simple:
> just convert all backslashes to slashes before completing >:->
>

Yes. For this reason I mentioned cygpath (that takes care of mount points as
well).

-andrej

File completion under Cygwin again

[Andrej Borsenkow]

It seems, that there is some demand for Zsh under Cygwin (and I got private
mail asking for binary distribution). For this reason I list problems/wishes I
am aware about now; it would really be nice if some of these were fixed in
4.0.

1. drive:/path completion.

This is an absolute path on under Cygwin. Currently, Zsh treats it as relative
to current directory.

2. UNC path completion - //server/share/path - here actually subtopics
 a) server name completion
 b) share name completion
 c) path completion

a) is unlikely and I am currently unaware of any easy way to implement b), but
c) is quite possible. Current problem is, globbing on the first two levels
fails and Zsh finds no match.

3. (related to 2) currently we can either squeeze all slashes or nothing.
Under Cygwin initial `//' is significant and must not be squeezed
irrespectively of squeeze-slashes settings.

4. Windows is using case-insensitive file system, so some way to make file
name completion case-insensitive is needed. It is _not_ the same as simply set
global matcher - it is applied to _every_ completion, and this is not always
appropriate.

5. (related to 4) things are complicated by the fact, that you can mount
case-sensitive file system (e.g. off SAMBA server), so, if we could say "names
with this prefix are case sensitive and with this not" ...

6. drive:path completion (x:path)

This is *not* the same as 1. It is relative path that is interpreted as
"relative to current directory of drive x). Unfortunately, this seems to be
broken in current cygwin, but for the record ...

7. Backslash handling. So, that I do not forget it myself :-)

Of these, 1, 2c and 3 are needed to allow easy use under Cygwin. 2a and 2b can
already be emulated by fake-path style (assuming, that initial double slashes
are not lost). Evrything else is nice to have and can wait if somebody else
request it. Even if only 1-3 are implemnted, Zsh will be far ahead of bash as
interactive shell.

Just to mention - Cygwin provides utility (and API) to convert file names
between Unix and Windows. May be, it can be used here (at least, it solves
problem of backslashes, because Unix names always have slashes).

-andrej

Have a nice DOS!
B >>

File completion under Cygwin again

[Andrej Borsenkow]

It seems, that there is some demand for 

-andrej

Have a nice DOS!
B >>