From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 21430 invoked from network); 15 May 2020 14:40:43 -0000 Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with ESMTPUTF8; 15 May 2020 14:40:43 -0000 Received: (qmail 13810 invoked by alias); 15 May 2020 14:40:30 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: List-Unsubscribe: X-Seq: 24838 Received: (qmail 16980 invoked by uid 1010); 15 May 2020 14:40:30 -0000 X-Qmail-Scanner-Diagnostics: from mail-io1-f54.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.3/25812. spamassassin: 3.4.4. Clear:RC:0(209.85.166.54):SA:0(-1.7/5.0):. Processed in 1.655756 secs); 15 May 2020 14:40:30 -0000 X-Envelope-From: dan1994@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.166.54 as permitted sender) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uSRmSJssTCaxOTrmQl8Ox/C+SdgDtX4X3r4OY4IBIxA=; b=f7MsX7faYcTCZkuETxHtaC+wKKgca7hdvBF7/xW5AKHnH9G6tnqp1igvsuQS3V/AQO g3UhGGg84KKOAMLxg8kHRsuCFEoUzEaqiKF8+b+AbZwyM0TebQrt4I+BPjX3TVuA16bC CXsxjSLlxEMRcRz58d57zEpHGjDPW70QAfqg4F881GYcZeSrEcvj8CIE2S/iEQCqaYA5 Ad1I3daM5J8zmA1M7oFQ/ZTriJXT4y2cSeEUJFAKHa+2GThXa/pfakW/7d3F/DMB76YV ULb8RXlwbaxhnlU3Cd4k/Yw7FsmLScm1x/Jzal7q3Mx8VZAd0kDqQHA4Inf4WsmDD5td Ucrg== X-Gm-Message-State: AOAM530hGUPkBIS+0fHq/dT2VYyUAYQqC0WyVga663059BBxm69JaaXB 77Qgg/ojaa3izHpNPaj3e/ceMfIgKesz+U38LF0= X-Google-Smtp-Source: ABdhPJz8eg273H6O0HSdztklGrS7xSz7O59iAkT4bFB+yZ+c2qRdsRlKypRVKA5v3BpBK406T5opJlLLVjKtdbnQthE= X-Received: by 2002:a5e:a80e:: with SMTP id c14mr2089037ioa.3.1589553595167; Fri, 15 May 2020 07:39:55 -0700 (PDT) MIME-Version: 1.0 References: <20200503165802.6540ad48@tarpaulin.shahaf.local2> <20200504131830.3572e317@tarpaulin.shahaf.local2> <20200505164934.3f6b7f42@tarpaulin.shahaf.local2> <20200507204007.7487332d@tarpaulin.shahaf.local2> In-Reply-To: <20200507204007.7487332d@tarpaulin.shahaf.local2> From: Dan Arad Date: Fri, 15 May 2020 17:39:39 +0300 Message-ID: Subject: Re: Help Request/Bug Report: comparguments causes _arguments to fail in certain cases To: Daniel Shahaf Cc: zsh-users@zsh.org Content-Type: multipart/alternative; boundary="0000000000006439a005a5b0c98e" --0000000000006439a005a5b0c98e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I got it working using the hook method: I added another script with `#compdef -first-` that saves the words array. The thing is, that now I'm faced with a different problem: When the command line is `./ps.py`, completions are generated correctly. When the command line is `python ps.py`, the actual completions are joined by the list of files in the current directory. This appears to be a byproduct of going through the `_python` auto-completion script. I was wondering if there is a way to remove existing completion matches before adding my own to make sure I provide only correct matches. Also, might this be a bug in the `_python` completion script? Thanks for all the help, Dan On Thu, May 7, 2020 at 11:40 PM Daniel Shahaf wrote: > > > > > After _python returned, my script was invoked again and printed > > > > > `BUFFER=3Dpython ps.py` and `words=3Dpython*3* ps.py` (note the 3= ). > > > > > > I'm not sure offhand where this comes from. $context, $funcstack, et > al > > > may have clues. > > > > > > I may have neglected to say that I aliased `python` to `python3`, so it > > makes sense since you said that words is the result of alias expansion. > > Yes, that'd be it. > > > > You might try looking up the place that originally populates $words a= nd > > > making it stash a copy of $words in another, read-only array; then > you'll > > > be able to use =C2=ABcompset -P=C2=BB and access that array. (Compar= e vcs_info's > > > use of *_orig keys in ${hook_com}.) > > > > > > I tried looking at things related to `vcs_info`, and I saw they were > > outside of the Completion directory. > > I was able to find the place where the `*_orig` keys are set, but > couldn't > > find where they are used. > > It would be nice to get some context (or reference) about how this part > of > > zsh connects to compsys, and how variables like `hook_com` become > available > > to completion functions. > > vcs_info has nothing to do with compsys. Sorry for the unclarity. > > *_orig variables would be used by hooks in people's dotfiles. There > are examples of hooks in Misc/vcs_info-examples, though they don't > access the *_orig keys. > > I was trying to explain by way of analogy: just like vcs_info sets > ${hook_com[revision_orig]}, in order that if two hooks are installed > the later one be able to access the original value even if the > earlier one had modified ${hook_com[revision]}, so I imagined > a ${words_orig} array, to let your completion function access the > value of $words before the _arguments call in _python shifted some > elements off it. > > > > Something along these lines, I think: > > > > > > local -a words2=3D( ${(z):-"$PREBUFFER${LBUFFER}x"} ) > > > words2[-1]=3D${words2[-1]%x} > > > words2[1,${words2[(I)(;|&&|=E2=80=A6)]}]=3D() > > > > > > A lot for me to unpack here and in the paragraphs that follow. > > I'll try to understand as much as I can, but will probably ask about it > > later. > > Sure, feel free. > > =C2=AB${foo[(I)bar]}=C2=BB expands to an index into the array $foo; which= index is > determined by the pattern =C2=ABbar=C2=BB. (You can get quick help by ta= b > completing after the opening round parenthesis; the full description of > ${[(I)]} is in the manual.) > > Do consider the other two alternatives, though. Just because it's > _possible_ to reimplement the $BUFFER-to-$words transformation doesn't > imply that's the best way forward. > > Cheers, > > Daniel > > > Thanks! > > Dan > > > > On Tue, May 5, 2020 at 7:49 PM Daniel Shahaf > wrote: > > > > > > > > Well, for starters, if you =C2=ABshift words=C2=BB, you should = decrement > > > CURRENT > > > > > > as well. > > > > > > > > > > > > However, _python uses the =C2=AB*::=E2=80=A6=C2=BB form of an _= arguments optspec, > > > > > > which should take care of $words/$NUMERIC for you. I assume > the > > > reason > > > > > > it didn't is that you used =C2=ABcompdef -p=C2=BB. Try -P inst= ead? If > I'm not > > > > > > mistaken, that would also handle =C2=ABpython =E2=80=A6 script.= py =C2=BB for > you > > > > > > (where the ellipsis stands for python's --options). > > > > > > > > > > > > > > > I tested the 4 possible options, and found that switching -p with > -P > > > > > doesn't change anything, but shifting words and decrementing > CURRENT > > > > > works! But... I feel like it's a hack I'm not supposed to do > > > > > (correct me if I'm wrong). > > > > > > Those parameters are documented, and manipulated by a number of > > > functions (including _python, as it happens), so you _are_ using the > API. > > > See also the 'compset' builtin. > > > > > > However, as mentioned, I suspect that hardcoding a skip/decrement of > one > > > element won't DTRT if python is invoked with options (e.g., =C2=ABpyt= hon > > > --foo script.py =C2=BB) =E2=80=94 not unless you reimplement _py= thon's parsing > > > of those options and any arguments to them. > > > > > > > > I now tried using the BUFFER variable instead of words (since it > > > remains > > > > > unchanged), but found that it also has caveats: The BUFFER variab= le > > > > > contains the raw value of the line, whereas the words array > contains > > > the > > > > > words after expansions (I think that's the right term). > > > > > > Partly. $words has undergone alias expansion, but not further > > > expansions. In particular, the words are still quoted. > > > > > > > > To demonstrate this I tried running again completion for `python > ps,py` > > > > > with `#compdef -P *`, and printing out BUFFER and words. The > debug > > > log > > > > > (and my terminal) showed the following: > > > > > First of all _python was called and dispatched my script which > printed > > > > > `BUFFER=3Dpython ps.py` and `words=3Dps.py`. > > > > > > That's what I'd expect. > > > > > > > > After _python returned, my script was invoked again and printed > > > > > `BUFFER=3Dpython ps.py` and `words=3Dpython*3* ps.py` (note the 3= ). > > > > > > I'm not sure offhand where this comes from. $context, $funcstack, et > al > > > may have clues. > > > > > > > > I do think the right solution is to be dispatched by _python with > > > > > `#compdef -P *.py`, but to be able to run I need the words array = as > > > > > seen by _python > > > > > > Once an element is shifted off $words, it's lost forever (free() is > > > called on it), so there'll be no way to access a "previous" value of > $words > > > unless a copy had been made somewhere. > > > > > > Moreover, consider that python may be itself wrapped by some > precommand: > > > for example, =C2=ABenv X=3DY python=C2=BB, =C2=ABsudo -u foo python= =C2=BB, or =C2=ABssh foo > python=C2=BB. > > > > > > You might try looking up the place that originally populates $words a= nd > > > making it stash a copy of $words in another, read-only array; then > you'll > > > be able to use =C2=ABcompset -P=C2=BB and access that array. (Compar= e vcs_info's > > > use of *_orig keys in ${hook_com}.) > > > > > > > > or a to understand how BUFFER can be expanded/converted to its > > > correct > > > > > form. If you have any input on this, I would very much appreciat= e > > > > > it. > > > > > > Something along these lines, I think: > > > > > > local -a words2=3D( ${(z):-"$PREBUFFER${LBUFFER}x"} ) > > > words2[-1]=3D${words2[-1]%x} > > > words2[1,${words2[(I)(;|&&|=E2=80=A6)]}]=3D() > > > > > > To understand the second line, see addx() in Src/Zle/zle_tricky.c. > With > > > that out of the way, the first line's a textbook use of the ${(z)} > > > tokenizer. The third line just throws out everything until the start > of > > > the current _simple command_ (see zshmisc(1)) =E2=80=94 or, at least,= it will > > > once the ellipsis is filled out. > > > > > > Caveats: that snippet doesn't do alias expansion, doesn't try to deal > > > with ${RBUFFER}, doesn't try to deal with SHORT_LOOPS, doesn't try to > > > deal with precommands and precommand assignments, should be changed t= o > > > use zZ+c+ if the INTERACTIVE_COMMENTS option is set=E2=80=A6 > > > > > > Although it's a plugin that I worked on myself, I should probably > > > mention that zsh-syntax-highlighting has faced the same problem and y= ou > > > and implemented a solution to it, which handles a number of the above > > > caveats. > > > > > > > > > > > > > There's also a third approach: instead of trying to run the binary, > make > > > it stash the output in a well-known location. For example, > /usr/bin/foo > > > could store the output in /usr/share/argcomplete/foo. (I've always > > > wanted to standardize _some_ solution to this problem; I'm tired of > > > writing completion functions by hand=E2=80=A6) > > > > > > Cheers, > > > > > > Daniel > > > > > > > > > --=20 Dan Arad dan1994@gmail.com --0000000000006439a005a5b0c98e--