Hi there, I'm forwarding a conversation I started by mistake on the wrong mailing list (Sorry, I'm new to the concept). Any help on the topic would be greatly appreciated! Cheers, Dan ---------- Forwarded message --------- From: Daniel Shahaf Date: Mon, May 4, 2020 at 4:18 PM Subject: Re: Help Request/Bug Report: comparguments causes _arguments to fail in certain cases To: Dan Arad Good morning Dan, Would you re-send that to the mailing list, please? You sent it only to me. Thanks for tracking down the rich text issue — it's much easier to talk this way. ☺ Cheers, Daniel Dan Arad wrote on Mon, 04 May 2020 09:46 +0300: > First of all, thank you for your swift response! > > For future reference, you should have addressed your question to > > zsh-users@, as the answer to it doesn't involve a change to zsh itself. > > > Noted! I searched online for the zsh bug tracker, and stumbled into this > mail address. > > Furthermore, it would be helpful to configure your email client to > > generate a text/plain part that doesn't surround every line by asterisks > > and add spurious blank lines in code blocks. > > > > I was trying to copy paste the stack overflow entry through Word, so it > won't keep the web formatting, and that's probably why this happened... > > Well, for starters, if you «shift words», you should decrement CURRENT > > as well. > > > > However, _python uses the «*::…» 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 «compdef -p». Try -P instead? If I'm not > > mistaken, that would also handle «python … script.py » 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). > > Your second paragraph made me look back at a previous solution (that > doesn't work). I would be glad to discuss it if you have the time. > > I was using `#compdef -p *.py` before, and what I saw was that _python was > being called before my script, and that my script didn't work well. What > was actually happening was that _python was shifting words before I was > being called, and that interfered with the logic of my script. > > In order to generate completions I rely on running what is currently > present in the command line, and so this may cause my script to generate no > completions (i.e. `python ps.py` becomes `ps.py` which can't be run, and > `python ./ps.py` becomes `./ps.py` which may or may not be run depending on > file permissions). > > I now tried using the BUFFER variable instead of words (since it remains > unchanged), but found that it also has caveats: The BUFFER variable > contains the raw value of the line, whereas the words array contains the > words after expansions (I think that's the right term). > 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=python ps.py` and `words=ps.py`. > After _python returned, my script was invoked again and printed > `BUFFER=python ps.py` and `words=python*3* ps.py` (note the 3). > > 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 > 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 appreciate it. > > Best Regards, > Dan > > > On Sun, May 3, 2020 at 7:58 PM Daniel Shahaf wrote: > > > Dan Arad wrote on Sun, 03 May 2020 10:40 +0300: > > > Hi there, > > > > > > From what I understand, bug reports should be mailed here. If I'm wrong > > I'd > > > be happy to be redirected to the correct medium. > > > > For future reference, you should have addressed your question to > > zsh-users@, as the answer to it doesn't involve a change to zsh itself. > > Furthermore, it would be helpful to configure your email client to > > generate a text/plain part that doesn't surround every line by asterisks > > and add spurious blank lines in code blocks. > > > > > What I want to report is probably not a bug, and stems from my > > > misunderstanding of compsys. Any help will be greatly appreciated. > > > The following is a copy paste of the a this question > > > < > > https://stackoverflow.com/questions/61560687/comparguments-causes-arguments-to-fail-in-certain-cases > > > > > > I asked on stack overflow: > > > > > > > Thanks for the cross-reference. > > > > > *1. The script is invoked directly (e.g. ~/script.py)* > > > > > > *2. The script is invoked through python (e.g. python script.py)* > > > > > > *3. The script is invoked as a python module (e.g. python -m script)* > > > > > > > > > *I have so far managed to successfully handle the first case, but the > > > second case fails to retrieve any completions. Using zsh completion debug > > > log I was able to see where things went wrong:* > > ⋮ > > > *EDIT:* > > > > > > *In order to temporarily bypass the problem I tried adding a shift words > > > before calling _arguments. This caused comparguments to succeed (!), but > > > still causes _arguments to fail with a no arguments message later on.* > > > > > > *I added the log for this case to the gist linked above.* > > > > Well, for starters, if you «shift words», you should decrement CURRENT > > as well. > > > > However, _python uses the «*::…» 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 «compdef -p». Try -P instead? If I'm not > > mistaken, that would also handle «python … script.py » for you > > (where the ellipsis stands for python's --options). > > > > Cheers, > > > > Daniel > > > > -- Dan Arad dan1994@gmail.com