zsh-workers
 help / color / mirror / code / Atom feed
From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: PATCH: Re: _find or _users broken?
Date: Tue, 2 May 2000 10:53:47 +0200 (MET DST)	[thread overview]
Message-ID: <200005020853.KAA30718@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: "Bart Schaefer"'s message of Sat, 29 Apr 2000 17:39:06 +0000


Bart Schaefer wrote:

> On Apr 29,  1:58pm, Adam Spiers wrote:
> } Subject: _find or _users broken?
> }
> } $ find -user <TAB>
> } ---- user
> } ---- directory
> } <list of directories and users together>
> } $ find ! -user <TAB>
> } ---- directory
> } <list of directories>
> } 
> } Why is it completing directories at all?  And when it completes users
> } and directories, why are the users listed under the directory group?
> 
> That part must have something to do with your settings.  The final clause
> of the _arguments call in _find is to complete directories when nothing
> else matches.

Right. Maybe a not-fully up-to-date version? We had some changes to
_arguments lately. And they were also causing this:

> There is something going wrong, though:
> 
> zagzig[103] find -user <TAB>
> Completing user
> (list of users only)
> zagzig[103] find /tmp -user <TAB>
> (feep, no completions)
> 
> This (and your case with `!') appears to happen because comparguments
> believes the list of options to have been finished when /tmp was put
> on the line, i.e., it doesn't deal well with commands whose options
> follow a list of non-option arguments.

That was just a bug in the function that collects the actions to
report. It incorrectly tested the argument numbers even for arguments
of options.

And it should always complete options and their arguments after all
normal arguments, right? It always did (or should have done) that.

And of course, for `find' there is no `last' argument because we
complete any number of directories.

Bye
 Sven

Index: Src/Zle/computil.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/computil.c,v
retrieving revision 1.10
diff -u -r1.10 computil.c
--- Src/Zle/computil.c	2000/04/28 11:16:52	1.10
+++ Src/Zle/computil.c	2000/05/02 08:52:11
@@ -1396,9 +1396,9 @@
 
     addopt = (opt ? 0 : ca_laststate.oopt);
 
-    for (; arg && (arg->num < 0 ||
-		   (arg->min <= ca_laststate.nth + addopt &&
-		    arg->num >= ca_laststate.nth));) {
+    for (; arg && (opt || (arg->num < 0 ||
+			   (arg->min <= ca_laststate.nth + addopt &&
+			    arg->num >= ca_laststate.nth)));) {
 	lopt = (arg->type == CAA_OPT);
 	if (!opt && !lopt && oopt > 0)
 	    oopt = 0;

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


                 reply	other threads:[~2000-05-02  8:54 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=200005020853.KAA30718@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).