Re: File completion under Cygwin again

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxxxxx