GNU bug report logs - #37489
27.0.50; Make `debbugs-gnu-search' work with `repeat-complex-command'

Previous Next

Full log

Message #20 received at 37489-done <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 37489-done <at> debbugs.gnu.org
Subject: Re: bug#37489: 27.0.50; Make `debbugs-gnu-search' work with
 `repeat-complex-command'
Date: Tue, 24 Sep 2019 08:51:58 +0200

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

Hi Michael,

>> The appended patch shall do the job, you might test.
>
> Seems to work fine, yes, thanks.

Thanks for testing. There was still an error in the patch; it didn't
distinguish between queries and filters. I have fixed this.

>> However, I fear we will open a Pandora's box. We must set both
>> debbugs-gnu-current-query and debbugs-gnu-current-filter, it depends
>> on whether PHRASE is a string, or not. And even the allowed arguments
>> in both cases are different. So it is very easy to make it wrong when
>> editing the argument list. Even *I* would need to consult the
>> implementation, in order to know what's allowed, and what's
>> not.
>
> I don't find it this problematic.  It's ok when not all combinations of
> arguments are allowed.  But instead of consulting the implementation, it
> would of course be better to describe limitations in the docstring.  If
> it gets too complicated, maybe the list of arguments could be changed to
> reflect the implementation even more.

It's even more complex. There is the difference whether an argument is
appropriate or not, depending on QUERY being a string or nil. But there
is also the difference whether an argument is sent to the server, or
whether the argument's discrimination is done client-side. The latter is
much less performant.

> Anyway, the patch is all that I wanted.  If the command barks the last
> resort is to go through the queries again, which I have to do now
> anyway.
>
>> I would add some further sanity checks for QUERY, before callings
>> debbugs-gnu.
>
> That might be appropriate, but adding some details to the docstring in
> addition along the way might not be wrong, too.  You don't even need to
> explain each argument in detail (maybe you could even point to other
> functions' docstring for that?), just enough to let me know what would
> not work.  FWIW, I never called the command with an empty phrase, since
> I didn't know that this is allowed and even then I would rather expect
> that the server would blacklist me :-)

See the manual, it tells you :-)

`debugs-gnu search' is designed to handle all of this interactively. Now,
that we have arguments, and this command can be called like a function,
I've added a reference to the docstring, pointing to the manual. Plus
the promised sanity checks.

I've pushed the changes to GNU ELPA. I've also released debbugs 0.20,
because the solution for bug#36903, which was blocking the release, is
expected to be applied in gnus.

> Regards,
>
> Michael.

Best regards, Michael.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.