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

[Eric Abrahamsen]

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?

Eric