[ELPA] New package: gnus-search-mu

[ELPA] New package: gnus-search-mu

[Jai Flack]

Greetings,

I would like to propose my package: gnus-search-mu [1] for inclusion in
GNU ELPA. It provides a gnus-search backend leveraging mu (similar to
the existing gnus-search-notmuch).

I have just brought it up to feature-completeness (it handles all of the
gnus-search query keys) so I think this is the perfect time for
addition.

[1] https://git.disroot.org/jflack/gnus-search-mu

-- 
Thanks,
Jai

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

[Eric Abrahamsen]

Jai Flack <jflack@disroot.org> writes:

> Greetings,
>
> I would like to propose my package: gnus-search-mu [1] for inclusion in
> GNU ELPA. It provides a gnus-search backend leveraging mu (similar to
> the existing gnus-search-notmuch).
>
> I have just brought it up to feature-completeness (it handles all of the
> gnus-search query keys) so I think this is the perfect time for
> addition.
>
> [1] https://git.disroot.org/jflack/gnus-search-mu

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?

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

[Jai Flack]

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?

-- 
Thanks,
Jai

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

[Eric Abrahamsen]

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.

Please note that engine custom options like -remove-prefix and
-config-directory have been moved away from `getenv' to something like:

(expand-file-name "foo" "~")

and it would be nice to stick to that convention.

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.

Out of curiosity, what is `ansi-color-filter-apply' doing there?

Yours,
Eric

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:
>>> 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.
>
> Please note that engine custom options like -remove-prefix and
> -config-directory have been moved away from `getenv' to something like:
>
> (expand-file-name "foo" "~")
>
> and it would be nice to stick to that convention.

Sure.

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

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

-- 
Thanks,
Jai

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

[Eric Abrahamsen]

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.
>>
>> Please note that engine custom options like -remove-prefix and
>> -config-directory have been moved away from `getenv' to something like:
>>
>> (expand-file-name "foo" "~")
>>
>> and it would be nice to stick to that convention.
>
> Sure.
>
>> 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.
>
>> 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'm assuming you have done copyright assignment. Do you have push
permissions for ELPA and/or Emacs proper?

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

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

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

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?

-- 
Thanks,
Jai

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

[Eric Abrahamsen]

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

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

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

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