Re: PATCH: Re: pws-10 RE: zsh-3.1.5-pws-9: _path_files and symbolic links

Re: PATCH: Re: pws-10 RE: zsh-3.1.5-pws-9: _path_files and symbolic links

[Sven Wischnowsky]

Peter Stephenson wrote:

> (Phew, I hope I don't have to rewrite all my completions again...
> Just have to wait and see if Bart excoriates `compgen'.)

(So you have some as yet unrevealed completion functions?)

Phew, I hope I don't have to change all the completion functions again ;-)

> > Ah, tricky. The patch below makes path components be left unchanged
> > only if the rest of the string would produce a match below that
> > directory.
> 
> Was that all that needed doing?  I knew about this, but didn't complain
> about this because I thought it was a feature which would need a lot of
> work to alter.

My big patch also contained some other fixes in _path_files. Without
them it would indeed be more complicated.

Bye
 Sven

diff -u oc/Commands/_most_recent_file Completion/Commands/_most_recent_file
--- oc/Commands/_most_recent_file	Mon Mar  1 16:42:45 1999
+++ Completion/Commands/_most_recent_file	Mon Mar  1 16:44:50 1999
@@ -1,5 +1,5 @@
 #defkeycomp complete-word \C-xm
-local file tilde exptilde
+local file tilde etilde
 if [[ $PREFIX = \~*/ ]]; then
   tilde=${PREFIX%%/*}
   etilde=${~tilde}

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

RE: PATCH: Re: pws-10 RE: zsh-3.1.5-pws-9: _path_files and symbolic links

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> > The question is what one can find under `/u/'. If there is anything
> > matching `l/l/T' the behavior might be correct (since it can't expand
> > `u' to `usr' then).
> 
> Nope. It is the problem of exact match. ``/u'' is matched _exactly_ and
> hence ``/usr'' is never even tried.

Ah, tricky. The patch below makes path components be left unchanged
only if the rest of the string would produce a match below that
directory.

Bye
 Sven

diff -u oc/Core/_path_files Completion/Core/_path_files
--- oc/Core/_path_files	Mon Mar  1 14:32:16 1999
+++ Completion/Core/_path_files	Mon Mar  1 15:45:51 1999
@@ -170,23 +170,26 @@
   fi
 fi
 
-# First we skip over all pathname components in `str' which really exist in
-# the file-system, so that `/usr/lib/l<TAB>' doesn't offer you `lib' and
-# `lib5'. Pathname components skipped this way are taken from `str' and added
-# to `donepath'.
-
-while [[ "$str" = */* ]] do
-  [[ -e "$realpath$donepath${str%%/*}" ]] || break
-  donepath="$donepath${str%%/*}/"
-  str="${str#*/}"
-done
-
+# Save the original string.
 orig="${str:s/*//}"
 
 # Now build the glob pattern by calling `_match_pattern'.
 patstr="$str"
 matchflags=""
 _match_pattern _path_files patstr matchflags
+
+# First we skip over all pathname components in `str' which really exist in
+# the file-system, so that `/usr/lib/l<TAB>' doesn't offer you `lib' and
+# `lib5'. Pathname components skipped this way are taken from `orig' and added
+# to `donepath'.
+
+while [[ "$orig" = */* ]] do
+  tmp1=($realpath$donepath${orig%%/*}/${~patstr#*/})
+  [[ $#tmp1 -gt 0 && -e "$realpath$donepath${orig%%/*}" ]] || break
+  donepath="$donepath${orig%%/*}/"
+  orig="${orig#*/}"
+  patstr="${patstr#*/}"
+done
 
 # We almost expect the pattern to have changed `..' into `*.*.', `/.' into
 # `/*.', and probably to contain two or more consecutive `*'s. Since these

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

RE: PATCH: Re: pws-10 RE: zsh-3.1.5-pws-9: _path_files and symbolic links

[Sven Wischnowsky]

I'm a bit slow today...

I wrote:

>  the only other place where `-W' is currently used is `_mh'

This uses `compgen' (i.e. the former `complist'), not `_files'. Was
the reason for this that `_path_files' didn't handle ignored prefixes
correctly? My big patch made `_path_files' give `IPREFIX' to `compadd' 
so this should work now.

Bye
 Sven


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

Re: PATCH: Re: pws-10 RE: zsh-3.1.5-pws-9: _path_files and symbolic links

[Peter Stephenson]

(Phew, I hope I don't have to rewrite all my completions again...
Just have to wait and see if Bart excoriates `compgen'.)

Sven Wischnowsky wrote:
> This uses `compgen' (i.e. the former `complist'), not `_files'. Was
> the reason for this that `_path_files' didn't handle ignored prefixes
> correctly? My big patch made `_path_files' give `IPREFIX' to `compadd' 
> so this should work now.

Not sure if that was part of the problem, but there was an earlier problem,
also now fixed, where _path_files was less than happy about producing only
directories.  Since there's no point in having files other than
directories, I've made it just call _path_files rather than _files.  There
was also a bit of over-compensation in _mh: the perl code to generate
options using the -help output now uses $words instead of backreferences,
which is a little baroque.  Also, there was a bit missing from _zftp.
Finally, while I'm here, I've upgraded _most_recent_file to handle ~'s
properly (that ${.../#.../...} feature is neater than I realised it was
going to be).

Also

> Ah, tricky. The patch below makes path components be left unchanged
> only if the rest of the string would produce a match below that
> directory.

Was that all that needed doing?  I knew about this, but didn't complain
about this because I thought it was a feature which would need a lot of
work to alter.

--- Completion/Builtins/_zftp.bak	Mon Mar  1 13:50:33 1999
+++ Completion/Builtins/_zftp	Mon Mar  1 15:26:08 1999
@@ -15,8 +15,10 @@
       putat get getat append appendat ls dir local remote mkdir rmdir
     return
   fi
+  subcom=$words[2]
+else
+  subcom=$words[1]
 fi
-subcom=$words[2]
 
 case $subcom in
   *(cd|ls|dir))
--- Completion/Commands/_most_recent_file.bak	Mon Mar  1 13:50:34 1999
+++ Completion/Commands/_most_recent_file	Mon Mar  1 15:45:41 1999
@@ -1,4 +1,11 @@
 #defkeycomp complete-word \C-xm
-local file
-compgen -g '*(om[1])'
-(( $#file )) && compadd -f $file
+local file tilde exptilde
+if [[ $PREFIX = \~*/ ]]; then
+  tilde=${PREFIX%%/*}
+  etilde=${~tilde}
+  file=($~PREFIX*$~SUFFIX(om[1]N))
+  file=(${file/#$etilde/$tilde})
+else
+  file=($~PREFIX*$~SUFFIX(om[1]N))
+fi
+(( $#file )) && compadd -f -Q $file
--- Completion/User/_mh.bak	Mon Mar  1 13:50:35 1999
+++ Completion/User/_mh	Mon Mar  1 15:40:59 1999
@@ -1,4 +1,4 @@
-#defcomp folder comp inc mark refile repl scan show next prev rmm pick whom mhn mhpath mhpatch
+#defcomp folder folders comp inc mark refile repl scan show next prev rmm pick whom mhn mhpath
 
 # Completion for all possible MH commands.
 # Alter the following two to your own mh directory and the directory
@@ -17,9 +17,9 @@
   # awk is just too icky to use for this, sorry.  send me one if
   # you come up with it.
   compadd - $($words[1] -help | perl -ne 'if (/^\s*-\(?(\S+)/) {
-    $n = $words[2];
+    $n = $1;
     $n =~ s/\)//g;
-    print $n =~ s/^\[([a-z]+)\]// ? "$n\n${words[2]}$n\n" : "$n\n";
+    print $n =~ s/^\[([a-z]+)\]// ? "$n\n$1$n\n" : "$n\n";
   }')
   return
 elif [[ -iprefix '+' || -iprefix '@' || "$prev" = -draftfolder ]]; then
@@ -33,7 +33,7 @@
   fi
 
   # painless, or what?
-  compgen -W mhpath -/
+  _path_files -W mhpath -/
 elif [[ "$prev" = -(editor|(whatnow|rmm|show|more)proc) ]]; then
   compgen -c
 elif [[ "$prev" = -file ]]; then
@@ -50,7 +50,7 @@
 elif [[ "$prev" = -(no|)cc ]]; then
   compadd all to cc me
 elif [[ "$prev" = -[rw]cache ]]; then
-  compadd  public private never ask
+  compadd public private never ask
 else
   # Generate sequences.
   local foldnam folddir f
@@ -66,7 +66,7 @@
     # leaving foldnam empty works here
   fi
 
-  compgen -s '$(mark $foldnam | awk -F: '\''{ print $1 }'\'')'
-  compadd  reply next cur prev first last all unseen
+  compgen -s '$(mark $foldnam 2>/dev/null | awk -F: '\''{ print $1 }'\'')'
+  compadd reply next cur prev first last all unseen
   compgen -W folddir -g '<->'
 fi

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

RE: PATCH: Re: pws-10 RE: zsh-3.1.5-pws-9: _path_files and symbolic links

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> Should it not be tested in _path_files? What if I want to use other array
> rather than cdpath in other function? It is really hard to always remember
> to test it before using.

I thought about it, too, but decided against it because:

- cdpath is special: if empty or unset, `.' is used
- in other cases you will have no tests, if the array containing the
  dirs is empty you probably won't want the files in `.'; I use `-W'
  only for `cd', so I'm not sure what people would like to have here
  (producing no matches due to an empty `-W'-array looked like a good
  hint that something went wrong); I could be convinced otherwise,
  though (the only other place where `-W' is currently used is `_mh'
  which I don't use (since I don't use `mh'), so I have to ask: would
  the automatic-use-current-dir behavior be correct there?)

> And, BTW, is it not a typo in _path_files:
> 
>   liniepath=''
> 
> I'd expect it to be linepath (not that it helps much).

Yes, thanks.

Bye
 Sven

diff -u oc/Core/_path_files Completion/Core/_path_files
--- oc/Core/_path_files	Mon Mar  1 13:13:16 1999
+++ Completion/Core/_path_files	Mon Mar  1 14:31:07 1999
@@ -150,7 +150,7 @@
   # If the string does not start with a `~' we don't remove a prefix from the
   # string.
 
-  liniepath=''
+  linepath=''
   realpath=''
 
   if [[ "$str[1]" = / ]]; then

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

PATCH: Re: pws-10 RE: zsh-3.1.5-pws-9: _path_files and symbolic links

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> Just tried on vanilla pws-10. Copied Core, Base, Builtins, sourced compinit.
> The result is the same. What I have is:
> 
> itsrm1% ls -F /
> SAM/         config/      lib@         shlib@       tools@       var@
> X11/         dev/         lost+found/  stand/       u/
> bck/         dgn/         mnt/         svr4@        unix*
> bin@         etc/         opt@         tftpboot/    unix.old*
> boot/        export/      proc/        tmp@         usr@
> cdrom/       home@        sbin/        tmp_mnt/     utmp/
> 
> itsrm1% ls -l /usr
> lrwxrwxrwx   1 root     root           7 Feb 22 17:50 /usr -> SAM/usr
> 
> itsrm1% ls -ldF /usr/lib/locale/TZ
> drwxr-xr-x   9 bin      bin         2048 Feb 23 13:50 /usr/lib/locale/TZ/
> 
> itsrm1% cd /S/u/l/l/T =>  is correctly completed to
> itsrm1% cd /SAM/usr/lib/locale/T
> 
> but
> 
> itsrm1% cd /u/l/l/T
> results in beep.

The question is what one can find under `/u/'. If there is anything
matching `l/l/T' the behavior might be correct (since it can't expand
`u' to `usr' then).
I tried it with my `/var' which is a link to `/usr/val' and it works
nicely.

> Oh, just found:
> 
> drwxr-xr-x   9 bin      bin         2048 Feb 23 13:50 /usr/lib/locale/TZ/
> drwxr-xr-x   3 root     other       1024 Feb 22 18:19
> /usr/lib/locale/Transparent/

What's wrong with that? The string you showed above correctly stops
at the `T'.

>From 5569:

> And even more funny ...
> 
> itsrm1% cat ~/.zshrc
> #!/tools/bin/zsh
> fpath=("$fpath[@]" ~/.zsh.d/comp.d/*)
> [[ -f ~/.zsh.d/comp.d/Core/compinit ]] && source
> ~/.zsh.d/comp.d/Core/compinit
> 
> itsrm1% ls src
> bzip2-0.9.0c      make-3.77         zsh-3.1.5-pws-10
> gzip-1.2.4        sudo.v1.5.8       zsh-3.1.5-pws-9
> 
> itsrm1% cd s/z/C/C>TAB> => B-E-E-P
> itsrm1% cd ./s/z/C/C<TAB> =>
> itsrm1% cd ./src/zsh-3.1.5-pws-10/Completion/Co

That's the result of not testing ig `cdpath' is set.

Bye
 Sven

diff -u oc/Builtins/_cd Completion/Builtins/_cd
--- oc/Builtins/_cd	Mon Mar  1 13:12:40 1999
+++ Completion/Builtins/_cd	Mon Mar  1 13:54:51 1999
@@ -1,3 +1,7 @@
 #defcomp cd
 
-_files -W cdpath -g '*(-/)'
+if (( $#cdpath )); then
+  _files -W cdpath -/
+else
+  _files -/
+fi

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

RE: PATCH: Re: pws-10 RE: zsh-3.1.5-pws-9: _path_files and symbolic links

[Andrej Borsenkow]

Should it not be tested in _path_files? What if I want to use other array
rather than cdpath in other function? It is really hard to always remember
to test it before using.

And, BTW, is it not a typo in _path_files:

  liniepath=''

I'd expect it to be linepath (not that it helps much).

/andrej

> That's the result of not testing ig `cdpath' is set.
>
> Bye
>  Sven
>
> diff -u oc/Builtins/_cd Completion/Builtins/_cd
> --- oc/Builtins/_cd	Mon Mar  1 13:12:40 1999
> +++ Completion/Builtins/_cd	Mon Mar  1 13:54:51 1999
> @@ -1,3 +1,7 @@
>  #defcomp cd
>
> -_files -W cdpath -g '*(-/)'
> +if (( $#cdpath )); then
> +  _files -W cdpath -/
> +else
> +  _files -/
> +fi
>
> --
> Sven Wischnowsky                         wischnow@informatik.hu-berlin.de
>
>

RE: PATCH: Re: pws-10 RE: zsh-3.1.5-pws-9: _path_files and symbolic links

[Andrej Borsenkow]

>
> The question is what one can find under `/u/'. If there is anything
> matching `l/l/T' the behavior might be correct (since it can't expand
> `u' to `usr' then).

Nope. It is the problem of exact match. ``/u'' is matched _exactly_ and
hence ``/usr'' is never even tried. I have no ``/SAM/u'', that's why
``/SAM/usr'' is matched. It does not matter, what follows:

itsrm1% ls -F /u
pub/  sni/

Now I ask myself if it's desirable. As my example shows, it could be at
least unexpected  :-) And note, that ``cd /u<TAB>'' correctly lists ``/usr''
as possible match.

/andrej