Package: zsh Version: 4.2.5-22 Severity: wishlist Tags: patch make completion currently doesn't use -C arguments passed on the current command line to decide the completion of -[CfoW] as well as to choose the Makefile to use for getting the targets. This patch incorporates this behaviour.
--- _make.orig 2005-11-20 00:40:19.000000000 +0530 +++ _make 2005-11-20 01:01:10.000000000 +0530 @@ -92,6 +92,28 @@ done } +findBasedir () { + local file index basedir + basedir=$PWD + for ((index=0; index<$#@; index++)); do + if [[ [EMAIL PROTECTED] = -C ]]; then + [EMAIL PROTECTED]; + if [[ -z $file ]]; then + # make returns with an error if an empty arg is given + # even if the concatenated path is a valid directory + return + elif [[ $file = /* ]]; then + # Absolute path, replace base directory + basedir=$file + else + # Relative, concatenate path + basedir=$basedir/$file + fi + fi + done + print -- $basedir +} + _pick_variant -r is_gnu gnu=GNU unix -v -f if [[ $is_gnu = gnu ]]; then @@ -100,21 +122,27 @@ incl=.include fi if [[ "$prev" = -[CI] ]]; then - _files -/ + _files -W ${(q)$(findBasedir ${words[1,CURRENT-1]})} -/ elif [[ "$prev" = -[foW] ]]; then - _files + _files -W ${(q)$(findBasedir $words)} else file="$words[(I)-f]" if (( file )); then - file="$words[file+1]" - elif [[ -e Makefile ]]; then - file=Makefile - elif [[ -e makefile ]]; then - file=makefile - elif [[ $is_gnu = gnu && -e GNUmakefile ]]; then - file=GNUmakefile + file=${~words[file+1]} + [[ $file = [^/]* ]] && file=${(q)$(findBasedir $words)}/$file + [[ -r $file ]] || file= else - file='' + local basedir + basedir=${(q)$(findBasedir $words)} + if [[ $is_gnu = gnu && -r $basedir/GNUmakefile ]]; then + file=$basedir/GNUmakefile + elif [[ -r $basedir/makefile ]]; then + file=$basedir/makefile + elif [[ -r $basedir/Makefile ]]; then + file=$basedir/Makefile + else + file='' + fi fi if [[ -n "$file" ]] && _tags targets; then
Since I am new to zsh scripting, I am unsure of the completion policy while dealing with the values of arguments passed when deciding the completion. Currently I only use the ${~word} to evaluate the argument to -C. Is it considered safe to expand constructs like .. -C $(ls) ... ? I thought I could atleast expand constructs like .. -C ~/* .. by using files=(${~word}), followed by using file=$file[1], but I end up with an error for $() constructs (numeric argument expected). It would be good if someone could indicate the cause of this error, and whether it is conventional to expand globs to use it for further completion. Regards, Ramkumar. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (101, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.14-archck1 Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8) Versions of packages zsh depends on: ii debconf [debconf-2.0] 1.4.58 Debian configuration management sy ii libc6 2.3.5-6 GNU C Library: Shared libraries an ii libncurses5 5.4-9 Shared libraries for terminal hand Versions of packages zsh recommends: ii libcap1 1:1.10-14 support for getting/setting POSIX. ii libpcre3 6.4-1.0.1 Perl 5 Compatible Regular Expressi -- no debconf information -- WARN_(accel)("msg null; should hang here to be win compatible\n"); -- WINE source code