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

[Jai Flack]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Jai Flack <jflack@disroot.org> writes:
>
>> 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.
>
> Worked for me! Ha.
>
>>>> 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.
>
> Oh... I actually don't know how that's supposed to work -- if there's
> some automatic machinery in place to prefer the built-in version when
> it's newer than the package. We'd have to ask the experts.
>
> Packaging experts? Is there anything special that has to be done?

I think the package is ready for GNU ELPA, I made a couple little
cleanup changes and requested a NonGNU Savannah repo for it.

I'll start writing the extra documentation for the patch then submit it
to bug-gnu-emacs.

-- 
Thanks,
Jai