Re: [ELPA] New package: gnus-search-mu

[Eric Abrahamsen <eric@ericabrahamsen.net>]

On 03/28/22 09:43 AM, Jai Flack wrote:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Jai Flack <jflack@disroot.org> writes:
>>
>>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>>
>>>> Jai Flack <jflack@disroot.org> writes:
>>>>
>>>>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>>>>> Hi! Thanks very much for working on this. Wouldn't it make more sense to
>>>>>> include this in Emacs proper? Gnus-search is new enough that it doesn't
>>>>>> seem useful to let users of prior Emacs versions to install
>>>>>> gnus-search-mu from the repos... What do you think?
>>>>>
>>>>> I'm happy for it to be included in Emacs proper; though possibly as both
>>>>> a la modus-themes as it's missed the release window for Emacs 28 (if I
>>>>> understand the release cycle correctly).
>>>>>
>>>>> Shall I convert this to a patch for gnus-search.el?
>>>>
>>>> Sure! Thanks.
>>>>
>>>> Otherwise, please make sure that the first line of docstrings are a
>>>> complete sentence, and there's no need for a blank line between the
>>>> first sentence and whatever comes after.
>>>
>>> Right.
>
> Were there any docstrings in particular you noticed that didn't make up
> a complete sentence? I've updated them to be (roughly) the same as the
> notmuch and namazu backends but the first lines already matched.

Sorry, that was poorly phrased. I meant the first sentence of the docstring
should all fit on a single line. Like this:

(defcustom gnus-search-mu-raw-queries-p nil
  "If t, all mu engines will only accept raw search query
strings.
  
This can also be set per-server."
  :type 'boolean
  :group 'gnus-search)

The first sentence should be munged until it doesn't wrap, then the
second blank line doesn't need to be there. A la the "Tips for
Documentation Strings" section of the Elisp manual.

(If gnus-search.el itself doesn't fully adhere to these conventions,
well... I'll get there eventually.)

>>>> Out of curiosity, what is `ansi-color-filter-apply' doing there?
>>>
>>> I think I had trouble with mu giving ANSI escape codes to Emacs, it
>>> might no longer be a problem or maybe there is a better solution.
>>
>> Okay, sounds good! ansi-color is built in so there's no harm in that.
>
> I've changed this to use the --nocolor option for mu.

Even better.

>> I'm assuming you have done copyright assignment. Do you have push
>> permissions for ELPA and/or Emacs proper?
>
> Done copyright assignment. Don't have any push permissions.

Are you expecting to ask for permission? (I'm not able to grant it.) If
not, I can push these things for you.

> For the ELPA package is there a good way to signal to users that the
> built-in version should be used on a recent-enough Emacs version?

I think your current Package-Requires header is the best we can do. I
haven't actually tested if it will refuse to install on Emacs < 28.1,
but I think due diligence is done.

Eric