Re: zathura conpletion for zsh broken

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

Oliver Freyermuth wrote on Tue, 25 Sep 2018 23:22 +0200:
> Am 25.09.18 um 22:36 schrieb Daniel Shahaf:
> > Oliver Freyermuth wrote on Tue, 25 Sep 2018 22:02 +0200:
> >> Am 25.09.18 um 21:21 schrieb Daniel Shahaf:
> >>> Oliver Freyermuth wrote on Tue, Sep 25, 2018 at 17:14:04 +0200:
> >>>> +++ b/Completion/X/Command/_zathura
> >>>> @@ -25,7 +25,7 @@ _zathura_files(){
> >>>> -      supported_filetypes+="${${pf%.so}#${plugins_dir}/lib}"
> >>>> +      supported_filetypes+="${${pf%.so}#${plugins_dir}/}"
> >>>
> >>> Isn't this equivalent to «supported_filetypes+=${pf:t:r}»?
> >>
> >> Indeed, it is, and that would be much easier. 
> > 
> > Pushed.  I changed the log message to avoid mentioning implementation
> > terms (the variable's name) in ChangeLog, which is user-facing.
> 
> Thanks! Didn't know this is copied as-is, I'll take better care in the
> future. Hopefully the commit message of the attached patch is better.

Yes, it is, thank you.

Not all developers copy the message as-is.  I happen to use git-am(1)
to apply patches so it's easier for me to consume patches produced
by git-send-email(1) or git-format-patch(1), like yours.  Other developers
use other tools and don't care so much about the format so long as it
can be piped to patch(1) or git-apply(1).

[ Actually, I use a wrapper around git-am(1) that also automatically
adds the mailing list message number to the log message and creates
a ChangeLog entry.  You might find it an interesting read:
https://github.com/danielshahaf/zsh-dev/ ]

> >>> The 'break' on line 12 looks odd.  Does zathura really ignore
> >>> /usr/lib/zathura/foo.so if /usr/local/lib/zathura/bar.so exists and
> >>> /usr/local/lib/zathura/foo.so does not?
> >>
> >> You are correct in spotting this, if I read the zathura code correctly
> >> (not a girara expert...), it "does the right thing" and searches the
> >> full list of paths.
> >>
> >> I'll try to cook up a patch fixing both those issues. Might take a
> >> while though, since I'm just starting with this (basically I started
> >> to investigate after "zathura <tab>" stopped doing anything after a
> >> zsh upgrade, makinɡ usage rather cumbersome).
> > 
> > Thanks for the patch and looking into the additional issue.
> 
> The attached patch fixes the second issue, I tested with a dummy .so
> in /usr/local/lib/zathura. Plugin file formats are now also made
> unique. Let me know if this can be simplified, or if it is in any case
> unneeded since the "uniqueness" is implicit in the matching code later
> on - I'm still learning more and more about the wonders of zsh
> expansion, and every bit I learn leaves me wondering how I could ever
> survive without that knowledge up to now.
>

I've changed:
.
    +    plugins_files+=( $plugins_dir/*.so )
.
to:
.
    +    plugins_files+=( $plugins_dir/*.so(N) )
.
to avoid an error if one of the directories exists and contains no *.so
files.  This was a preëxisting bug in the function (it means the '((
$#plugin_files ))' check was redundant).

Regarding uniqueness, another way to achieve uniqueness is to pass -U to
the 'typedef -a' command that declares the variable.

Also, it's not idiomatic to use [[ -z $array ]], though it will function correctly.

> Cheers,
> Oliver
> 
> > P.S. Our of curiosity, what's that U+0261 LATIN SMALL LETTER SCRIPT G doing there?
> Spotted very well, my font and mail client hid that from me. I did
> accidentally hit the keybinding for SCIM (Smart Common Input
> Method) while typing, and it started to interfere. That created
> some funny characters, and apparently I missed to remove the "g"
> once I noticed it.

OK :)

Cheers,

Daniel