--- Begin Message ---
Subject: |
27.0.50; Make `debbugs-gnu-search' work with `repeat-complex-command' |
Date: |
Mon, 23 Sep 2019 08:26:08 +0200 |
Hi,
when I want to repeat searching bugs with `debbugs-gnu-search' and a
similar query, I currently have to specify everything again.
`repeat-complex-command' is no help since the command currently has no
arguments. Could we please make it work with `repeat-complex-command'?
The argument list of `debbugs-gnu-search' (currently empty) needs to
contain all information gathered, that seems to be the value of
`debbugs-gnu-current-query' and all arguments of the `debbugs-gnu' call.
Then most of the current function body should be moved into the
interactive form. In the body only `debbugs-gnu-current-query' should
be let-bound to the first part of the function arguments, and
`debbugs-gnu' should be called with the rest.
TIA,
Michael.
--- End Message ---
--- Begin Message ---
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 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
Michael Heerdegen <address@hidden> 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.
--- End Message ---