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
