From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: Re: _files does not list files after foo/
Date: Mon, 2 Aug 1999 15:40:04 +0200 (MET DST) [thread overview]
Message-ID: <199908021340.PAA13466@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: Peter Stephenson's message of Tue, 27 Jul 1999 16:07:13 +0200
Peter Stephenson wrote:
> Tanaka Akira wrote:
> > Z(2):akr@is27e1u11% zsh -f
> > is27e1u11% autoload -U compinit; compinit -D
> > is27e1u11% gunzip ./<TAB>
> >
> > After above operation, zsh does not list files in current directory.
> >
> > OK, I know that the behaviour is intentional as:
> >
> > But it is confusing in this case.
> > I suppose that there should be the way to disable the hack.
>
> Yes, in fact in the case of something like `_files *(*)' it's preventing
> the second call of _path_files from trying to look for directories when
> there aren't any other matches, which is quite a serious problem (note that
> it only arises right after the /, but with menu completion that's where I
> mostly use completion nowadays). This turns it off unless the path_keepdir
> configuration key is set. Maybe Sven can think of something more subtle to
> do.
This isn't subtle at all, but I wouldn't like to have to decide
whether I want `gunzip' to work correctly or if I want to avoid this
correction-of-correct-directory-names.
So the patch below does the correction-avoidance-thingy only if
`_path_files' didn't get any of the pattern options (`-g' and `-/').
It also removes the `path_keepdir' key again -- I'm not too sure
about this. Should I put it back again? Or should we replace it by a
configuration key with the reverse meaning (and name)?
Bye
Sven
diff -u oc/Core/_path_files Completion/Core/_path_files
--- oc/Core/_path_files Mon Aug 2 11:45:15 1999
+++ Completion/Core/_path_files Mon Aug 2 15:35:30 1999
@@ -25,7 +25,7 @@
local linepath realpath donepath prepath testpath exppath
local tmp1 tmp2 tmp3 tmp4 i orig pre suf tpre tsuf
-local pats ignore group expl addpfx addsfx remsfx
+local pats haspats=no ignore group expl addpfx addsfx remsfx
local nm=$compstate[nmatches] menu
typeset -U prepaths exppaths
@@ -82,9 +82,11 @@
;;
/) sopt="${sopt}/"
pats=("$pats[@]" '*(-/)')
+ haspats=yes
;;
g) gopt='-g'
pats=("$pats[@]" ${=OPTARG})
+ haspats=yes
;;
esac
done
@@ -259,14 +261,11 @@
# an attempt to correct a valid directory name. So we just add the
# original string in such a case so that the command line doesn't
# change but other completers still think there are matches.
+ # We do this only if we weren't given a `-g' or `-/' option because
+ # otherwise this would keep `_files' from completing all filenames
+ # if none of the patterns match.
- # Problem: this seems to stop _files from finding directory
- # completions if there were no file completions, for
- # example `_files *(*)' no longer completes subdirectories after
- # a /. For now, make this a configuration option, but
- # probably it needs to be done better.
-
- if [[ -n "$compconfig[path_keepdir]" && -z "$tpre$tsuf" &&
+ if [[ "$haspats" = no && -z "$tpre$tsuf" &&
"$pre" = */ && -z "$suf" ]]; then
compadd -nQS '' - "$linepath$donepath$orig"
tmp4=-
diff -u od/Zsh/compsys.yo Doc/Zsh/compsys.yo
--- od/Zsh/compsys.yo Mon Aug 2 11:45:23 1999
+++ Doc/Zsh/compsys.yo Mon Aug 2 15:34:30 1999
@@ -738,7 +738,7 @@
`tt(-S)', `tt(-q)', `tt(-r)', and `tt(-R)' options from the
tt(compadd) builtin.
-Finally, the tt(_path_files) function supports three configuration keys.
+Finally, the tt(_path_files) function supports two configuration keys.
startitem()
item(tt(path_expand))(
If this is set to any non-empty string, the partially
@@ -749,14 +749,6 @@
If this is set to a non-empty string, the cursor will be left
after the first ambiguous pathname component even when menucompletion
is used.
-)
-item(tt(path_keepdir))(
-If this is set to a non-empty string, then if completion immediately after
-a slash fails, treat the original string as a successful completion. This
-prevents a valid directory being treated as a candidate for correction.
-However, it has the side effect that a pattern completion, such as
-`tt(files -g *(*))', will no longer try to complete directories in this
-position if there are no file matches.
)
enditem()
)
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
next reply other threads:[~1999-08-02 13:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-08-02 13:40 Sven Wischnowsky [this message]
-- strict thread matches above, loose matches on Subject: below --
1999-07-24 16:29 Tanaka Akira
1999-07-27 14:07 ` Peter Stephenson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199908021340.PAA13466@beta.informatik.hu-berlin.de \
--to=wischnow@informatik.hu-berlin.de \
--cc=zsh-workers@sunsite.auc.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).