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

[Jai Flack]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

>> 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.

Ah right.

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

I also noticed some of the defcustom :types don't match (like
`gnus-search-*-remove-prefix). Probably wouldn't save you any time
writing a patch for these.

>>>>> 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.

I wasn't planning on asking for permission. Not sure about the process
but I assume a bit more trust is required than a potential patch and a
couple potential ELPA packages.

>> 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.

Not sure if you misunderstood me, I meant a warning for Emacs > 28 when
the mu backend will (hopefully) be a part of Emacs.

Though it will possibly not like the current pretest 28.0.92 < 28.1.

-- 
Thanks,
Jai