+ (subject (plist-get headers :Subject))
> + (to (plist-get headers :To))
> + (cc (plist-get headers :Cc)))
> +
> +(eval directive)))
This code is not compatible with lexical binding in emacs >= 24, which I
assume notmuch will eventually want to adopt. What’s so bad about
.
Maybe you could use a combination of ‘make-obsolete’ (for byte-compiler
warnings) and ‘display-warning’ (for runtime)? I understand the desire
to phase the function out eventually rather than have an eternal stub,
but intentionally breaking .emacs is a really drastic ste
prevent peoples emacs startup
> from failing.
Guess who wrote a reply before catching up on all the list mail. :P
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
for a different purpose.
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
also fix one typo
---
test/README | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/test/README b/test/README
index 81c232d..d12cff2 100644
--- a/test/README
+++ b/test/README
@@ -178,11 +178,18 @@ library for your script to use.
test_expect_equal_file
Presently, the code which finds the parent of a message as it is being
added to the database assumes that the first Message-ID-like substring
of the In-Reply-To header is the parent Message ID. Some mail clients,
however, put stuff other than the Message-ID of the parent in the
In-Reply-To
-replies
new file mode 100755
index 000..a902691
--- /dev/null
+++ b/test/thread-replies
@@ -0,0 +1,144 @@
+#!/usr/bin/env bash
+#
+# Copyright (c) 2013 Aaron Ecay
+#
+
+test_description='test of proper handling of in-reply-to and references headers
+
+This test makes sure that the thread structure
-replies
new file mode 100755
index 000..a902691
--- /dev/null
+++ b/test/thread-replies
@@ -0,0 +1,144 @@
+#!/usr/bin/env bash
+#
+# Copyright (c) 2013 Aaron Ecay
+#
+
+test_description='test of proper handling of in-reply-to and references headers
+
+This test makes sure that the thread structure
Presently, the code which finds the parent of a message as it is being
added to the database assumes that the first Message-ID-like substring
of the In-Reply-To header is the parent Message ID. Some mail clients,
however, put stuff other than the Message-ID of the parent in the
In-Reply-To
- next part ------
--
Aaron Ecay
essage would be best.
Here?s a message from the notmuch list that has passed through gmane,
which inserts References but not In-Reply-To headers:
id:877h0sa207.fsf at fester.com . Here?s a link to one with a borked
In-Reply-To header:
http://article.gmane.org/gmane.emacs.orgmode/66616/raw
--
Aaron Ecay
Presently, the code which finds the parent of a message as it is being
added to the database assumes that the first Message-ID-like substring
of the In-Reply-To header is the parent Message ID. Some mail clients,
however, put stuff other than the Message-ID of the parent in the
In-Reply-To
Presently, the code which finds the parent of a message as it is being
added to the database assumes that the first Message-ID-like substring
of the In-Reply-To header is the parent Message ID. Some mail clients,
however, put stuff other than the Message-ID of the parent in the
In-Reply-To
ve #' on lambdas (that is, there are 0
instances of #'(lambda ...) in the code base). IMO that?s correct:
the unnecessary #' is just line-noise-ish.
--
Aaron Ecay
(that is, there are 0
instances of #'(lambda ...) in the code base). IMO that’s correct:
the unnecessary #' is just line-noise-ish.
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
t-buffer (find-file-noselect file))
(setq result (buffer-substring (point-min) (point-max)))
(set-buffer-modified-p nil)
(kill-buffer (current-buffer))
- cut here -----
--
Aaron Ecay
(find-file-noselect file))
(setq result (buffer-substring (point-min) (point-max)))
(set-buffer-modified-p nil)
(kill-buffer (current-buffer))
- cut here -
--
Aaron Ecay
___
notmuch mailing list
notmuch
Emacs message-mode uses certain text strings to indicate how to attach
files to outgoing mail. If these are present in the text of an email,
and a user is tricked into replying to the message, the user?s files
could be exposed.
---
NEWS | 18 ++
The test is broken at this time; the next commit will introduce a fix.
---
Thanks for the reminder, Austin. Things got hectic, and it took a
little bludgeoning to get the test suite to behave. I *think* I got
it, although I am by no means confident. Specifically, I am seeing
some unrelated(?)
Emacs message-mode uses certain text strings to indicate how to attach
files to outgoing mail. If these are present in the text of an email,
and a user is tricked into replying to the message, the user’s files
could be exposed.
---
NEWS | 18 ++
files to email very often, but I?ll let you know
how it works out.
Thanks a lot,
--
Aaron Ecay
On Thu, 19 Jan 2012 21:46:46 -0700, Adam Wolfe Gordon <awg+notmuch at xvx.ca>
wrote:
> On Thu, Jan 19, 2012 at 11:45, Aaron Ecay wrote:
> > Shouldn?t this just use message-insert-formatted-citation-line?
>
> Yes, good idea. I just tried this and it almost wor
files to email very often, but I’ll let you know
how it works out.
Thanks a lot,
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
that case is a security hole, then the hole is in the user?s brain
and not in notmuch. :)
--
Aaron Ecay
sn?t
mean that we should break that usage.
>
> >
> > (defun notmuch-mua-forward-message ()
> >(message-forward)
>
> Speaking of future-proofing, it would be good to have a test.
It would. ;) I?ll work on one.
--
Aaron Ecay
ding the reply will produce the original
single-quoted tag again.
--
Aaron Ecay
show
buffer that says:
- 6 messages hidden -
instead of the 6 (or however many) individual messages.
--
Aaron Ecay
So
to mitigate this, whatever reply mechanism winds up being used should
call mml-quote-region on the reply text (as message-cite-original does).
I just sent a patch to the list to do this in the current version of
notmuch, which should show up in
id:"1326998589-37187-1-git-send-email-aaronecay at gmail.com" .
--
Aaron Ecay
> to inline.
>
> This fixes the display of attached image/jpeg parts, for example.
I had suggested the same approach in a message that only Dmitry got
(accursed new reply bindings!) LGTM.
--
Aaron Ecay
Emacs message-mode uses certain text strings to indicate how to attach
files to outgoing mail. If these are present in the text of an email,
and a user is tricked into replying to the message, the user’s files
could be exposed.
---
To demonstrate this, open a reply to this message then remove
show up in
id:1326998589-37187-1-git-send-email-aarone...@gmail.com .
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
messages hidden -
instead of the 6 (or however many) individual messages.
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
.
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
, but that doesn’t
mean that we should break that usage.
(defun notmuch-mua-forward-message ()
(message-forward)
Speaking of future-proofing, it would be good to have a test.
It would. ;) I’ll work on one.
--
Aaron Ecay
___
notmuch mailing
.
If that case is a security hole, then the hole is in the user’s brain
and not in notmuch. :)
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
On Thu, 19 Jan 2012 21:46:46 -0700, Adam Wolfe Gordon awg+notm...@xvx.ca
wrote:
On Thu, Jan 19, 2012 at 11:45, Aaron Ecay e...@sas.upenn.edu wrote:
Shouldn’t this just use message-insert-formatted-citation-line?
Yes, good idea. I just tried this and it almost works. The only
issue
for allowing runtime use.)
Aaron
Footnotes:
[1] He specifically objects to the way that the cl package uses keyword
arguments, calling it un-Elisp-like. He has resisted past efforts
to merge cl functions into Elisp core, although they are slowly
diffusing across the barrier.
--
Aaron Ecay
- the comments were very useful in
improving things - thanks!
You’re welcome! The patch LGTM.
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
runtime use.)
Aaron
Footnotes:
[1] He specifically objects to the way that the cl package uses keyword
arguments, calling it un-Elisp-like. He has resisted past efforts
to merge cl functions into Elisp core, although they are slowly
diffusing across the barrier.
--
Aaron Ecay
r
id part-number #'notmuch-show-part-button-whatever-worker))
It would be the latter function that the key would be bound to. If a
macro is used, the split between the worker and glue fns can be
abandoned, and only one function is needed:
(defun notmuch-show-part-button-whatever ()
(notmuch-with-temp-part-buffer
;; do stuff...
))
A further advantage is if interactive arguments (e.g. C-u prefix) are
needed for the function, there is no need to thread them through as
arguments of notmuch-with-temp-part-buffer.
--
Aaron Ecay
+1
--
Aaron Ecay
\"unarchived\" (ie. the \"inbox\" tag will be added instead of
> +removed)."
> + (interactive)
If this function uses the prefix arg, its interactive call should be
?(interactive "P")?. This applies equally to the -thread variant in
patch 2/6, but I made the comment here because that diff doesn?t show
the function contiguously.
--
Aaron Ecay
tags will be removed instead of added.
This should be a docstring instead of a comment. (This applies equally
to the old version)
--
Aaron Ecay
+1 on this series from me. (Minor comments on a couple of the patches
to follow.)
--
Aaron Ecay
if it seems like this is the case.)
If you do:
M-x set-variable RET debug-on-quit RET t RET
then trigger the loop and press C-g, you should get a buffer showing a
backtrace of the lisp stack. What does that say?
Thanks,
--
Aaron Ecay
if it seems like this is the case.)
If you do:
M-x set-variable RET debug-on-quit RET t RET
then trigger the loop and press C-g, you should get a buffer showing a
backtrace of the lisp stack. What does that say?
Thanks,
--
Aaron Ecay
___
notmuch mailing
+1 on this series from me. (Minor comments on a couple of the patches
to follow.)
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
equally
to the old version)
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
+1
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
) are
needed for the function, there is no need to thread them through as
arguments of notmuch-with-temp-part-buffer.
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
a comment instead of a documentation string,
| but that is no longer the case--documentation strings now take up
| very little space in a running Emacs.
`
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman
On Mon, 16 Jan 2012 08:39:30 +, David Edmondson wrote:
> On Mon, 16 Jan 2012 02:38:38 -0500, Aaron Ecay wrote:
> > - Greater flexibility in the construction of address lists. For example,
> > there are some email lists where I want replies to list mail to go only
&g
`visual-line-mode' were that it wrapped long lines
> in received messages. With `notmuch-wash-wrap-long-lines' now default
> behaviour, this is no longer required.
+1
--
Aaron Ecay
ikely to be a
very frequent problem with email messages that are not on this listserv
:), it would be nice to fix it. Maybe you could change the regex that
matches id:?s to require a little more structure ? an at-sign, perhaps.
Or even requiring more than (say) 5 non-space characters after the
message id would
> ((looking-at "[Tt]o:")
> @@ -760,6 +806,8 @@ current buffer, if possible."
>(overlay-put headers-overlay 'priority 10))
> (overlay-put (make-overlay body-start body-end) 'invisible
> message-invis-spec)
>
> +(plist-put msg :depth depth)
> +
> ;; Save the properties for this message. Currently this saves the
> ;; entire message (augmented it with other stuff), which seems
> ;; like overkill. We might save a reduced subset (for example, not
> @@ -,6 +1159,9 @@ Some useful entries are:
> (defun notmuch-show-get-to ()
>(notmuch-show-get-header :To))
>
> +(defun notmuch-show-get-depth ()
> + (notmuch-show-get-prop :depth))
> +
> (defun notmuch-show-set-tags (tags)
>"Set the tags of the current message."
>(notmuch-show-set-prop :tags tags)
> --
> 1.7.7.3
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
--
Aaron Ecay
and are the right color.
I haven?t reloaded the notmuch *.el files since this change landed, but
I agree with Pieter that the overlays were nice.
--
Aaron Ecay
macs).
So, a +1 from me on this idea, from a different perspective.
--
Aaron Ecay
that are not on this listserv
:), it would be nice to fix it. Maybe you could change the regex that
matches id:’s to require a little more structure – an at-sign, perhaps.
Or even requiring more than (say) 5 non-space characters after the
message id would cut down sharply on the false positive rate.
--
Aaron
-mode' were that it wrapped long lines
in received messages. With `notmuch-wash-wrap-long-lines' now default
behaviour, this is no longer required.
+1
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman
On Mon, 16 Jan 2012 08:39:30 +, David Edmondson d...@dme.org wrote:
On Mon, 16 Jan 2012 02:38:38 -0500, Aaron Ecay aarone...@gmail.com wrote:
- Greater flexibility in the construction of address lists. For example,
there are some email lists where I want replies to list mail to go only
on this idea, from a different perspective.
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
list query-string
What about using ?format?:
(let (...
(args (format "reply --reply-to=%s %s %s"
(if reply-all "all" "sender")
(if notmuch-show-process-crypto "--decrypt" "")
query-string)))
...)
It?s still not beautiful, but maybe it is better?
--
Aaron Ecay
the clear to bikeshed about its calling convention. :) It?s your
patch, though, so it?s your call if you feel that the goes best
in a new change.
--
Aaron Ecay
think
I’m in the clear to bikeshed about its calling convention. :) It’s your
patch, though, so it’s your call if you feel that the optional goes best
in a new change.
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org
On Sun, 08 Jan 2012 18:49:56 -0800, Jameson Graef Rollins wrote:
> Thanks so much for the review, Aaron.
>
> On Sun, 08 Jan 2012 20:08:59 -0500, Aaron Ecay wrote:
> > A couple of comments on the arguments:
> > - It would be good to make show-next This will enable code
ible
values 'text, 'html, and 'both. This requires the emacs reply
functionality to distinguish between html parts that are part of a
multipart/alternative and those which are not, which (AFAICT) the
current code doesn?t do.
I haven?t tested the patch yet, but it looks very promising. Thanks!
--
Aaron Ecay
; notmuch-mua-hidden-headers))
>
> +(defun w3m-region (start end)) ;; From `w3m.el'.
What is the purpose of the above line? If it is to make the compiler
aware of the function, you should use ?declare-function? instead. Defun
will erase the original definition of the w3m-region function.
--
Aaron Ecay
line)
> (set 'notmuch-search-continuation continuation)
> +(when (and notmuch-search-exclude-deleted
> +(not (string-match "tag:deleted[ )]*" query)))
?is:? is a synonym for ?tag:? in searches ? so this section of the code
should look for it too.
--
Aaron Ecay
> + (kill-this-buffer)
> + (switch-to-buffer parent-buffer)
> + (forward-line 1))
> + (goto-char (point-max))
>
> (defun notmuch-show-previous-open-message ()
>"Show the previous message."
> --
> 1.7.7.3
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
--
Aaron Ecay
r notmuch-show-parent-buffer))
> + (notmuch-kill-this-buffer)
> + (if parent-buffer
> + (progn
> + (switch-to-buffer parent-buffer)
> + (forward-line)
> + (if show-next
> + (notmuch-search-show-thread)))
--
Aaron Ecay
ple think it would be useful, I can work on a patch to
implement this approach.
Footnotes:
[1] Or having its tags changed generally.
--
Aaron Ecay
think it would be useful, I can work on a patch to
implement this approach.
Footnotes:
[1] Or having its tags changed generally.
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
+ (notmuch-search-show-thread)))
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
-char (point-max))
(defun notmuch-show-previous-open-message ()
Show the previous message.
--
1.7.7.3
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
--
Aaron Ecay
:” in searches – so this section of the code
should look for it too.
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
of the above line? If it is to make the compiler
aware of the function, you should use ‘declare-function’ instead. Defun
will erase the original definition of the w3m-region function.
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
http
. This requires the emacs reply
functionality to distinguish between html parts that are part of a
multipart/alternative and those which are not, which (AFAICT) the
current code doesn’t do.
I haven’t tested the patch yet, but it looks very promising. Thanks!
--
Aaron Ecay
On Sun, 08 Jan 2012 18:49:56 -0800, Jameson Graef Rollins
jroll...@finestructure.net wrote:
Thanks so much for the review, Aaron.
On Sun, 08 Jan 2012 20:08:59 -0500, Aaron Ecay aarone...@gmail.com wrote:
A couple of comments on the arguments:
- It would be good to make show-next optional
ag -inbox thread:000whatever
--
Aaron Ecay
thread:000whatever
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
On Fri, 30 Dec 2011 22:54:30 -0400, David Bremner wrote:
> pushed, although I had to mess with it a fair amount. Maybe it was
> against master, rather than release?
It was. I didn?t realize that the patch should be against the release
branch; sorry about that... :-|
--
Aaron Ecay
problems, though. Daniel, if you want to
un-conflict (and squash) the patches from James that might be useful, at
least to compare the two approaches.
Aaron
-cut-here-
>From f0a0fe04254d9b5e17c873b293c6a5a270cb909a Mon Sep 17 00:00:00 2001
From: Aaron Ecay <aarone...@gmail.com>
---
NEWS | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/NEWS b/NEWS
index eaed960..3688944 100644
--- a/NEWS
+++ b/NEWS
@@ -20,6 +20,16 @@ Automatic tag query optimization
exclude messages whose tags won't change. In the past, we've
suggested that people
e notmuch-hello, but when I do, I press `s' then look to
the bottom of the screen and am always confused not to see a minibuffer
prompt.
--
Aaron Ecay
use notmuch-hello, but when I do, I press `s' then look to
the bottom of the screen and am always confused not to see a minibuffer
prompt.
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
---
NEWS | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/NEWS b/NEWS
index eaed960..3688944 100644
--- a/NEWS
+++ b/NEWS
@@ -20,6 +20,16 @@ Automatic tag query optimization
exclude messages whose tags won't change. In the past, we've
suggested that people
-conflict (and squash) the patches from James that might be useful, at
least to compare the two approaches.
Aaron
-cut-here-
From f0a0fe04254d9b5e17c873b293c6a5a270cb909a Mon Sep 17 00:00:00 2001
From: Aaron Ecay aarone...@gmail.com
Date: Mon, 19 Dec 2011 12:14:31 -0500
Subject: [PATCH] [emacs
On Fri, 30 Dec 2011 22:54:30 -0400, David Bremner da...@tethera.net wrote:
pushed, although I had to mess with it a fair amount. Maybe it was
against master, rather than release?
It was. I didn’t realize that the patch should be against the release
branch; sorry about that... :-|
--
Aaron
C/DEL. The former moves by messages, and the latter by screenfuls
(with the added complication that the screenful movement commands also
stop at intervening message boundaries). I?d prefer to maintain that
symmetry.
--
Aaron Ecay
by messages, and the latter by screenfuls
(with the added complication that the screenful movement commands also
stop at intervening message boundaries). I’d prefer to maintain that
symmetry.
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
which emacs
versions/configurations show undesired behavior ? this is a useful patch
and it should be included once we can be sure it will work correctly.
Thanks,
--
Aaron Ecay
common case.
>
> Moreover, it's very annoying when `debug-on-error' is t.
+1 from me on this change. I had added this to `debug-ignored-errors'
long ago, and forgotten how annoying it was.
--
Aaron Ecay
- ;; screen - scroll.
> > - ((or (= start-of-message start-of-window)
> > - (< start-of-message start-of-window))
> > + ((= start-of-message (point))
> > + ;; The cursor is at the start of the current message - move to
> > + ;; the previous open message.
> > + (notmuch-show-previous-open-message))
>
> This will jump to the beginning of the previous message if I'm at the
> beginning of a message. I would expect rewind to show me the end of
> the previous message in this case.
Agreed. I would like to see this case move back one screenful of text or
to the previous beginning-of-message, whichever is shorter. Something
like this should do the trick (replacing the notmuch-show-prev-msg call):
(let ((last-msg-point (save-excursion
(notmuch-show-goto-message-previous)
(point
(scroll-down)
(if (> last-msg-point (window-start))
(goto-char last-msg-point)
(goto-char (window-start)))
(notmuch-show-message-adjust))
Thanks,
--
Aaron Ecay
)
(if ( last-msg-point (window-start))
(goto-char last-msg-point)
(goto-char (window-start)))
(notmuch-show-message-adjust))
Thanks,
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman
, as
this is the common case.
Moreover, it's very annoying when `debug-on-error' is t.
+1 from me on this change. I had added this to `debug-ignored-errors'
long ago, and forgotten how annoying it was.
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
http
– this is a useful patch
and it should be included once we can be sure it will work correctly.
Thanks,
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
David,
Would the problem you had with previous-s-c-prop-change be fixed by the
patch to the original function I sent in the thread starting at
id:"m2y5u5cykp.fsf at kcals.intra.maillard.im" ?
--
Aaron Ecay
Text properties change between characters; prev-s-c-property-change
returns the position after the change. Thus, it is still inside the
invisible region.
---
emacs/notmuch-show.el |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/emacs/notmuch-show.el
Text properties change between characters; prev-s-c-property-change
returns the position after the change. Thus, it is still inside the
invisible region.
---
emacs/notmuch-show.el |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/emacs/notmuch-show.el
David,
Would the problem you had with previous-s-c-prop-change be fixed by the
patch to the original function I sent in the thread starting at
id:m2y5u5cykp@kcals.intra.maillard.im ?
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
1 - 100 of 143 matches
Mail list logo
