Jonas Bernoulli writes:
> Nice to run into you.
You too :)
> Do you contribute to *all* the killer apps? ;D
Heh. I think notmuch is great, but I haven't made any real
contributions. Just a happy user and a lurker on the mailing list.
> Kyle Meyer writes:
>> From there, you can easily
Hello,
On Wed 15 Apr 2020 at 01:41PM -07, Sean Whitton wrote:
> Debian/Ubuntu/etc. you can `apt-get install mailscripts`
Oh, and `apt-get install elpa-mailscripts` to get `M-x
notmuch-slurp-this-debbug` and `M-x notmuch-slurp-debbug`.
--
Sean Whitton
Hello,
On Wed 15 Apr 2020 at 04:28PM -03, David Bremner wrote:
> Jonas Bernoulli writes:
>
>>
>> One related use case for "notmuch insert" that I had in mind is the
>> import of debbugs threads. It someone is aware of an existing solution
>> then please let me know. Kyle, have you considered
Jonas Bernoulli writes:
>
> One related use case for "notmuch insert" that I had in mind is the
> import of debbugs threads. It someone is aware of an existing solution
> then please let me know. Kyle, have you considered mirroring
> emacs-devel and the Emacs debbugs as well?
Sean Whitton (in
Nice to run into you.
Do you contribute to *all* the killer apps? ;D
Kyle Meyer writes:
> [ in case it's useful in the future ]
> I've recently set up a public-inbox archive of notmuch
Absolutely! In fact I already had a bookmark about that somewhere.
> From there, you can easily download an
Jonas Bernoulli writes:
> (I cannot actually reply to "easy (?) elisp project for notmuch"
> because I wasn't subscribed yet when that was send.)
[ in case it's useful in the future ]
I've recently set up a public-inbox archive of notmuch here:
https://yhetil.org/notmuch/
>From there,
Jonas Bernoulli writes:
> I have already done this (and then some) a while ago. I want to have
> another look before I submit it, but will try to get that done today.
>
> (I cannot actually reply to "easy (?) elisp project for notmuch"
> because I wasn't subscribed yet when that was send.)
>
> As of Emacs 27, Emacs will start issuing deprecation warnings for
> packages that load cl.el. I _think_ it's just a matter of replacing
> functions and macros from cl.el with cl- prefixed ones, but I
> haven't really investigated.
> If someone is looking for an easy way to contribute, this
