* [ELPA] New package: gnus-search-mu
@ 2022-03-24 14:17 Jai Flack
2022-03-24 15:18 ` Eric Abrahamsen
0 siblings, 1 reply; 11+ messages in thread
From: Jai Flack @ 2022-03-24 14:17 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ELPA] New package: gnus-search-mu
2022-03-24 14:17 [ELPA] New package: gnus-search-mu Jai Flack
@ 2022-03-24 15:18 ` Eric Abrahamsen
2022-03-25 0:35 ` Jai Flack
0 siblings, 1 reply; 11+ messages in thread
From: Eric Abrahamsen @ 2022-03-24 15:18 UTC (permalink / raw)
Cc: emacs-devel
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?
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ELPA] New package: gnus-search-mu
2022-03-24 15:18 ` Eric Abrahamsen
@ 2022-03-25 0:35 ` Jai Flack
2022-03-25 22:46 ` Eric Abrahamsen
0 siblings, 1 reply; 11+ messages in thread
From: Jai Flack @ 2022-03-25 0:35 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ELPA] New package: gnus-search-mu
2022-03-25 0:35 ` Jai Flack
@ 2022-03-25 22:46 ` Eric Abrahamsen
2022-03-27 4:12 ` Jai Flack
0 siblings, 1 reply; 11+ messages in thread
From: Eric Abrahamsen @ 2022-03-25 22:46 UTC (permalink / raw)
To: Jai Flack; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ELPA] New package: gnus-search-mu
2022-03-25 22:46 ` Eric Abrahamsen
@ 2022-03-27 4:12 ` Jai Flack
2022-03-27 20:26 ` Eric Abrahamsen
0 siblings, 1 reply; 11+ messages in thread
From: Jai Flack @ 2022-03-27 4:12 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ELPA] New package: gnus-search-mu
2022-03-27 4:12 ` Jai Flack
@ 2022-03-27 20:26 ` Eric Abrahamsen
2022-03-27 23:43 ` Jai Flack
0 siblings, 1 reply; 11+ messages in thread
From: Eric Abrahamsen @ 2022-03-27 20:26 UTC (permalink / raw)
To: Jai Flack; +Cc: emacs-devel
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?
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ELPA] New package: gnus-search-mu
2022-03-27 20:26 ` Eric Abrahamsen
@ 2022-03-27 23:43 ` Jai Flack
2022-03-28 3:57 ` Eric Abrahamsen
0 siblings, 1 reply; 11+ messages in thread
From: Jai Flack @ 2022-03-27 23:43 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ELPA] New package: gnus-search-mu
2022-03-27 23:43 ` Jai Flack
@ 2022-03-28 3:57 ` Eric Abrahamsen
2022-03-28 8:22 ` Jai Flack
0 siblings, 1 reply; 11+ messages in thread
From: Eric Abrahamsen @ 2022-03-28 3:57 UTC (permalink / raw)
To: Jai Flack; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ELPA] New package: gnus-search-mu
2022-03-28 3:57 ` Eric Abrahamsen
@ 2022-03-28 8:22 ` Jai Flack
2022-03-29 20:28 ` Eric Abrahamsen
0 siblings, 1 reply; 11+ messages in thread
From: Jai Flack @ 2022-03-28 8:22 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ELPA] New package: gnus-search-mu
2022-03-28 8:22 ` Jai Flack
@ 2022-03-29 20:28 ` Eric Abrahamsen
2022-03-30 4:42 ` Jai Flack
0 siblings, 1 reply; 11+ messages in thread
From: Eric Abrahamsen @ 2022-03-29 20:28 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ELPA] New package: gnus-search-mu
2022-03-29 20:28 ` Eric Abrahamsen
@ 2022-03-30 4:42 ` Jai Flack
0 siblings, 0 replies; 11+ messages in thread
From: Jai Flack @ 2022-03-30 4:42 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2022-03-30 4:42 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-03-24 14:17 [ELPA] New package: gnus-search-mu Jai Flack
2022-03-24 15:18 ` Eric Abrahamsen
2022-03-25 0:35 ` Jai Flack
2022-03-25 22:46 ` Eric Abrahamsen
2022-03-27 4:12 ` Jai Flack
2022-03-27 20:26 ` Eric Abrahamsen
2022-03-27 23:43 ` Jai Flack
2022-03-28 3:57 ` Eric Abrahamsen
2022-03-28 8:22 ` Jai Flack
2022-03-29 20:28 ` Eric Abrahamsen
2022-03-30 4:42 ` Jai Flack
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.