zsh-workers
 help / color / mirror / code / Atom feed
From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: Re: file completion bug
Date: Wed, 14 Jul 1999 15:32:56 +0200 (MET DST)	[thread overview]
Message-ID: <199907141332.PAA11754@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: Peter Stephenson's message of Wed, 14 Jul 1999 14:08:13 +0200


Peter Stephenson wrote:

> Something weird is going on, presumably after some recent change to
> _path_files.
> 
> With zsh -f, completion loaded, and compconfig[completer] set to
> _complete:_correct ,
> 
> % echo ~/tmp/d1/<TAB>
> 
> goes to
> 
> % echo ~/tmp/RCS//
> 
> and offers corrections in tmp.  But tmp/d1 exists; I don't want to alter
> the directory I'm completing in just because it's empty.

It's been there for quite some time and it was intentional. The
important bit is the trailing slash: with that _path_files wants to
complete in that directory, of course -- and can't add any matches
because there aren't any. Then _correct takes over.

However, this already irritated me too, I just forgot to have a look
at it. The patch below is somewhat radical: it looks if we have such a 
slash-terminated string on the line and if there are no matches in
that directory, it adds the original string as a `match', thus keeping 
other completers from adding more matches or whatever.

Bye
 Sven

diff -u oc/Core/_path_files Completion/Core/_path_files
--- oc/Core/_path_files	Wed Jul 14 14:47:03 1999
+++ Completion/Core/_path_files	Wed Jul 14 15:32:43 1999
@@ -252,6 +252,18 @@
         continue 2
       fi
     elif (( ! $#tmp1 )); then
+      # A little extra hack: if we were completing `foo/<TAB>' and `foo'
+      # contains no files, this will normally produce no matches and other
+      # completers might think that's it's their time now. But if the next
+      # completer is _correct or something like that, this will result in
+      # 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.
+
+      if [[ -z "$tpre$tsuf" && "$pre" = */ && -z "$suf" ]]; then
+        compadd -nQS '' - "$linepath$donepath$orig"
+        tmp4=-
+      fi
       continue 2
     fi
 

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


             reply	other threads:[~1999-07-14 13:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-07-14 13:32 Sven Wischnowsky [this message]
1999-07-14 13:11 ` Peter Stephenson
  -- strict thread matches above, loose matches on Subject: below --
1999-07-14 14:07 Sven Wischnowsky
1999-07-14 12:08 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=199907141332.PAA11754@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).