Fwd: Help Request/Bug Report: comparguments causes _arguments to fail in certain cases

[Dan Arad <dan1994@xxxxxxxxx>]

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 <d.s@xxxxxxxxxxxxxxxxxx>
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 <dan1994@xxxxxxxxx>


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 <TAB>» 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 <d.s@xxxxxxxxxxxxxxxxxx>
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 <TAB>» for you
> > (where the ellipsis stands for python's --options).
> >
> > Cheers,
> >
> > Daniel
> >
>
>



-- 
Dan Arad
dan1994@xxxxxxxxx