[Pkg-zsh-devel] debbugs bug number completion += bug subjects

[Daniel Shahaf]

Axel Beckert wrote on Wed, Aug 24, 2016 at 09:25:42 +0200:
> Hi Daniel,
> 
> Daniel Shahaf wrote:
> > zsh master has bug number completion:
> > 
> >     % bts tag 82<TAB>
> >     > bug number
> >      …0510   …0947   …0951
> 
> Interesting. According to Completion/Debian/Type/_debbugs_bugnumber it
> uses the cache directories from the "bts" command to look for bug
> numbers, so it will only complete bug numbers for bug reports you've
> already viewed with the "bts show" command.
> 

Viewed with 'bts show' or downloaded with 'bts cache', yes.  I've been
using the new _debbugs_bugnumber for a while, and now I tend to cache
bugs I submit simply so I'd have completion for them.

That _debbugs_bugnumber logic is relatively new: it hasn't been released yet.

> > I wonder what to do with this patch: on the one hand, I'm not sure the
> > extraction of <title>s into $descs is robust enough to be accepted by
> > upstream; on the other hand, the patch works, and I suspect I'm not the
> > only one who would find it useful.
> 
> It won't help in my case as the only bts subcommand I use and which
> downloads bug reports is "bts --mbox show".
> 

As I say below, bts(1) downloads the html when it downloads the mbox;
does that change your assessment that the functionality won't be useful
for you?

> > +local -a descs; descs=(
> > +  ${(f)"$(<$^cachedirs/*html(N) grep -o '<title>.*</title>' | tr \> \< | cut -d \< -f3 | perl -MHTML::Entities -lnE 'say decode_entities s/^#(\d+) - /\1:/r')"}
> 
> So to support the mbox based caches, similar code, but parsing out the
> first subject line out of each mbox should suffice.
> 

Code for parsing mbox won't be needed, since when bts(1) downloads an
mbox it also downloads the html.  See docs of --cache-mode.

> Then again, don't do that effort for me, it's just a general thought based
> on my usage of "bts":
> 
> * I use "bts --mbox show" (aliased to "btsmutt" :-) usually on my mail
>   server, because that's from where I send mail. And I usually use
>   that command because I want to reply to a bug report I'm not
>   subscribed to (yet).
> 
> * I use "bts tag" and friends (all the commands which modify bug
>   reports) usually on my workstation. There's usually no bts cache at
>   all on my workstation.
> 

On your workstation you should still be able to complete bug numbers
through the 'fake' mechanism, but I don't see an easy way for your
workstation to complete bug subjects to bug numbers.

Note that using the bts cache as the source data narrows down the
universe — the set of potential matches, I mean — so completing 82<TAB>
has only a dozen or so completions, rather than 10000.  Completions
running on your workstation would need to use the entire bugs history as
their universe, I assume?

Thanks for the reply.  I'm still wondering where the patch should live.
I think there are three options: local to me, applied upstream, or
applied to the package as a vendor patch.  For the second option I'd
rather base it on 'bts status' output than on any kind of parsing, which
means an RFE to devscripts to cache 'status' output as well.  For the
third option, I realize the default is to upstream, but in this case one
the obstacles to upstreaming — the HTML output format dependency — might
be less of a hurdle in the context of the package.

Cheers,

Daniel