Re: [PATCH] implement a capf for address completion

[Antoine Beaupré]

On 2024-03-19 16:12:04, Antoine Beaupré wrote:

[...]

> The closest we have in the archive is (author in CC):
>
> <71a3382b-3f1b-4b81-883c-b4a8bd710888%40picnicpark.org>
>
> ... which writes a new `kea/notmuch-address-message-capf' function from
> scratch. It might, however, do a better job than i do at taking into
> account the "harvest" process, which I only discovered after writing the
> patch and decided I would pretend it doesn't exist (and is probably
> inaccurate). So that might be a flaw with my patch already, but in my
> defense, WTF is that harvest thing!? :)

Thinking about this more, I *think* the capf *can* return a *function*
instead of a list of strings, so we might be able to refactor this a bit
better and send a function that waits for the harvesting to complete, or
stream the results or something.

Above my pay grade, at this point.

-- 
We have no friends but the mountains.
- Kurdish saying
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH] implement a capf for address completion

[Antoine Beaupré]

I have *just* realized, after writing all this code and sending the
patch, that someone else might have discussed this here. Oops.

So, turns out, it *has* been discussed, but it doesn't look like anyone
tackled that problem fully just yet.

The closest we have in the archive is (author in CC):

<71a3382b-3f1b-4b81-883c-b4a8bd710888%40picnicpark.org>

... which writes a new `kea/notmuch-address-message-capf' function from
scratch. It might, however, do a better job than i do at taking into
account the "harvest" process, which I only discovered after writing the
patch and decided I would pretend it doesn't exist (and is probably
inaccurate). So that might be a flaw with my patch already, but in my
defense, WTF is that harvest thing!? :)

Another discussion about capf was about integration with EUDC:

<8a437e3f646f7972c86c4aae57ae7452%40condition-alpha.com>

But I don't quite understand what EUDC is or why it matters here. Might
be *some* overlap, not sure.

Finally, there's this whole other thread from 2022 about capf, but it's
quite diffuse and I couldn't make heads or tails of it. The head of the
thread according to the online archives is:



... but that's a reply to... something else, so I'm not sure.

As usual, your mileage may vary. :) To test my patch, you apply it,
restart Emacs (or rewire `message-completion-alist' like Keith Amidon
did), fire off a new email, start entering an address, and hit TAB (or,
if you have corfu, just wait for the timeout).

a.
-- 
We don't need any more heroes.
We just need someone to take out recycling.
- Banksy
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

[PATCH] implement a capf for address completion

[Antoine Beaupré]

I recently enabled corfu-mode everywhere, and was disappointed to find
out that I lost tab-completion on my message buffers. At most, corfu
would pop suggestions about existing words in the buffer, but no
address completion, even when I would hit TAB. I believe this is
because `message-tab' won't attempt completion if something else
already did it, and also because, somehow,
`notmuch-address-expand-name' ends up in
`message--old-style-completion-functions'.

Now, it seems to me a simple fix is to implement a proper
capf (`completion-at-point-function') for notmuch. And that, in turn,
is actually pretty simple compared to the code hidden underneath
`notmuch-address-expand-name', which not only finds completion
candidates, but also does the whole trouble of editing the buffer.

So this patch turns `notmuch-address-expand-name' into a wrapper
around the capf, and hooks the capf instead of the old function in the
message-mode completion hooks.

This ... works. Now I have popup completion, automatically (even
before hitting TAB), in my message-mode buffers. It's a bit jarring
because I'm so used to having completion in the minibuffer, but I
think I'll get used to it.

I haven't figured out how to make an escape hatch for this, to get
autocompletion in the minibuffer the same wauy way we did
before. Maybe we'd need something like the
`notmuch-address-from-minibuffer', but interactive somehow. Not
sure. But for now, this allows me to keep corfu globally active, and I
suspect will make things easier and faster going forward.
---
 emacs/notmuch-address.el | 33 +++--
 1 file changed, 23 insertions(+), 10 deletions(-)

diff --git a/emacs/notmuch-address.el b/emacs/notmuch-address.el
index f756254c..0c57add8 100644
--- a/emacs/notmuch-address.el
+++ b/emacs/notmuch-address.el
@@ -171,7 +171,7 @@ matching `notmuch-address-completion-headers-regexp'."
   (require 'company nil t))
   (notmuch-company-setup))
 (cl-pushnew (cons notmuch-address-completion-headers-regexp
- #'notmuch-address-expand-name)
+ #'notmuch-address-complete-at-point)
message-completion-alist :test #'equal)))
 
 (defun notmuch-address-toggle-internal-completion ()
@@ -225,15 +225,10 @@ requiring external commands."
 (bound-and-true-p company-mode))
 (company-manual-begin))
(notmuch-address-command
-(let* ((end (point))
-  (beg (save-excursion
- (re-search-backward "\\(\\`\\|[\n:,]\\)[ \t]*")
- (goto-char (match-end 0))
- (point)))
-  (orig (buffer-substring-no-properties beg end))
-  (completion-ignore-case t)
-  (options (with-temp-message "Looking for completion candidates..."
- (notmuch-address-options orig)))
+(let* ((capf (notmuch-address-complete-at-point))
+  (beg (pop capf))
+  (end (pop capf))
+  (options (pop capf))
   (num-options (length options))
   (chosen (cond
((eq num-options 0)
@@ -256,6 +251,24 @@ requiring external commands."
(ding
(t nil)))
 
+(defun notmuch-address-complete-at-point ()
+  "Complete the address using `notmuch-address-command'.
+
+This replaces the old `notmuch-address-expand-name' with the new
+`completion-at-point-functions' (capf) system that's compatible
+with corfu, company and friends."
+  (when notmuch-address-command
+(let* ((end (point))
+  (beg (save-excursion
+ (re-search-backward "\\(\\`\\|[\n:,]\\)[ \t]*")
+ (goto-char (match-end 0))
+ (point)))
+  (orig (buffer-substring-no-properties beg end))
+  (completion-ignore-case t)
+  (options (with-temp-message "Looking for completion candidates..."
+ (notmuch-address-options orig
+  (list beg end options
+
 ;;; Harvest
 
 (defun notmuch-address-harvest-addr (result)
-- 
2.39.2

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: revisiting Autocrypt in notmuch, MVP

[Antoine Beaupré]

On 2024-02-22 22:22:13, Antoine Beaupré wrote:
> On 2023-04-26 12:10:09, Antoine Beaupré wrote:

[...]

> ... but it feels a bit too intrusive... Do I really want to divulge my
> cryptographic identity to the world constantly? I'm using ed25519 keys
> now, so the header is small, but for other users, that grows the message
> size significantly...

After talking with dkg on IRC, I realized my concerns were overblown:
autocrypt actually strips out the other identities, so i'm not divulging
more than already present in the mail (apart from the public key
material itself of course).

So I've reverted this.

-- 
One of the things the Web teaches us is that everything is connected
(hyperlinks) and we all should work together (standards). Too often
school teaches us that everything is separate (many different
'subjects') and that we should all work alone.  - Aaron Swartz
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: revisiting Autocrypt in notmuch, MVP

[Antoine Beaupré]

On 2023-04-26 12:10:09, Antoine Beaupré wrote:
[...]

> And while autocrypt has a nice beautiful and brilliant spec that does
> everything, that's not what I'm looking at right now. And I don't think
> it's productive to block in this way at this point.
>
> So I made a bespoke implementation that just calls out to sequoia (and
> yes, also gpg, hopefully one day the latter can just go away) to insert
> autocrypt headers to outgoing mail. Here's the implementation:
>
> https://gitlab.com/anarcat/emacs-d/-/blob/354fabad24100f69310dd16a0d30ac3bd96d7244/notmuch-config.el#L14-31
>
> It's brittle, but it works for my case.
>
> I don't think this is something that can be merged as-is in notmuch. It
> depends on gnupg and sequoia, and it's probably incorrect as far as the
> Autocrypt spec is concerned (in particular it doesn't use a UID to
> fingerprint map), but this all seems like things could be improved.

A small update on this: I just realized I was sending autocrypt headers
regardless of whether or not I was signing / encrypting mails. I'm not
sure this is a good idea. The spec says that I "SHOULD", I believe:

https://autocrypt.org/level1.html#header-injection-in-outbound-mail

... but it feels a bit too intrusive... Do I really want to divulge my
cryptographic identity to the world constantly? I'm using ed25519 keys
now, so the header is small, but for other users, that grows the message
size significantly...

Patch is:

https://gitlab.com/anarcat/emacs-d/-/commit/c79495f8580735c23748a62db99b3d9f34f413f5

Interestingly, i had to make a new mml-* function; there's a predicate
to check if a message is encrypted, but not if it's signed, which seems
silly. So I vendored and improved the code, which also feels silly.

So there you go, diverging from the standard already. :)

A.

-- 
You Are What You Is
- Frank Zappa
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

revisiting Autocrypt in notmuch, MVP

[Antoine Beaupré]

Hi!

I'm giving an OpenPGP training this week, which I haven't done in
ages. A lot has changed since then: keyservers are basically dead (or
have changed significantly), WKD and Autocrypt exist and are supported
out of the box by Thunderbird, which simplifies a lot of things.

While testing out Thunderbird, I realized I wasn't sending out autocrypt
headers. I find those headers really precious, as they allow me to TOFU
users when they send me encrypted email. I have a rough hack to parse
incoming email and manually importing them in my keyring:

https://gitlab.com/anarcat/scripts/-/blob/dd898332c4e6c829fd18455fe3f1bbbee37e9551/autocrypt-key-import

That used to be a complicated Python program, but it turns out that
sequoia directly supports parsing those headers! So it's now this
one-liner:

sq autocrypt decode | gpg --import

So I have a basic MVP (minimal viable product) for importing keys. But
what about *sending* keys, i.e. embedding keys in outgoing messages?

Well, this (and parsing incoming keys too, obviously) is something that
was discussed before:

https://nmbug.notmuchmail.org/nmweb/show/20210221152132.2302112-1-dme%40dme.org

That discussion somewhat died out as dkg suggested to fix the problem
more broadly, and things stalled there.

And while autocrypt has a nice beautiful and brilliant spec that does
everything, that's not what I'm looking at right now. And I don't think
it's productive to block in this way at this point.

So I made a bespoke implementation that just calls out to sequoia (and
yes, also gpg, hopefully one day the latter can just go away) to insert
autocrypt headers to outgoing mail. Here's the implementation:

https://gitlab.com/anarcat/emacs-d/-/blob/354fabad24100f69310dd16a0d30ac3bd96d7244/notmuch-config.el#L14-31

It's brittle, but it works for my case.

I don't think this is something that can be merged as-is in notmuch. It
depends on gnupg and sequoia, and it's probably incorrect as far as the
Autocrypt spec is concerned (in particular it doesn't use a UID to
fingerprint map), but this all seems like things could be improved.

So that's what I got. I hope that helps! :)

a.

-- 
Celui qui ne connaît pas l'histoire est condamné à la revivre.
- Karl Marx


signature.asc
Description: PGP signature
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: crash on incoming email

[Antoine Beaupré]

On 2023-02-22 16:23:27, David Bremner wrote:
> Antoine Beaupré  writes:
>
>> When I have the attached email in my `inbox` and hit ENTER on the email
>> (notmuch-search-show-thread here), Emacs crashes completely with:
>>
>> fév 22 11:57:10 angela emacs[112721]: 
>> /home/anarcat/.emacs.d/eln-cache/28.2-8532cd27/tab-line-e55f541b-b1fd08d4.eln(F7461622d6c696e652d6175746f2d687363726f6c6c_tab_li>
>> fév 22 11:57:10 angela emacs[112721]: 
>> /usr/bin/emacs(+0x1b811b)[0x55d1080b011b]
>> fév 22 11:57:10 angela emacs[112721]: 
>> /home/anarcat/.emacs.d/eln-cache/28.2-8532cd27/tab-line-e55f541b-b1fd08d4.eln(F7461622d6c696e652d666f726d61742d74656d706c617465_>
>> fév 22 11:57:10 angela emacs[112721]: 
>> /usr/bin/emacs(+0x1b811b)[0x55d1080b011b]
>> fév 22 11:57:10 angela emacs[112721]: 
>> /home/anarcat/.emacs.d/eln-cache/28.2-8532cd27/tab-line-e55f541b-b1fd08d4.eln(F7461622d6c696e652d666f726d6174_tab_line_format_0+>
>
> I can't duplicate this here (at least not with emacs -q). I suspect we
> have pretty similar Debian environments, but maybe try moving your
> .emacs.d/eln-cache out of the way.

I keep forgetting those tricks, sorry. I didn't do anything (other than
restarting emacs and rebooting and I can'T reproduce this issue
anymore...

So I guess whenever i'll see those backtraces next, i'll flush the cache
and retry.

Still, one has to wonder: if emacs can just dump core if someone messes
with my eln-cache, that's... bad, no?

(I guess you can do pretty much *anything* if you get to mess with that
folder anyways, which also makes me quite uncomfortable... but you have
a lisp machine or you do not, i guess...)

a.

-- 
Lorsque l'on range des objets dans des tiroirs, et que l'on a plus
d'objets que de tiroirs, alors un tiroir au moins contient deux
objets.
- Lejeune-Dirichlet, Peter Gustav
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

crash on incoming email

[Antoine Beaupré]

When I have the attached email in my `inbox` and hit ENTER on the email
(notmuch-search-show-thread here), Emacs crashes completely with:

fév 22 11:57:10 angela emacs[112721]: Backtrace:
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0x1536c3)[0x55d10804b6c3]
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0x48835)[0x55d107f40835]
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0x48d25)[0x55d107f40d25]
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0x473cc)[0x55d107f3f3cc]
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0xf0eac)[0x55d107fe8eac]
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0x81ed8)[0x55d107f79ed8]
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0x82e1a)[0x55d107f7ae1a]
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0x7f728)[0x55d107f77728]
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0x84579)[0x55d107f7c579]
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0x85477)[0x55d107f7d477]
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0x17d9cb)[0x55d1080759cb]
fév 22 11:57:10 angela emacs[112721]: 
/home/anarcat/.emacs.d/eln-cache/28.2-8532cd27/tab-line-e55f541b-b1fd08d4.eln(F7461622d6c696e652d6175746f2d687363726f6c6c_tab_li>
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0x1b811b)[0x55d1080b011b]
fév 22 11:57:10 angela emacs[112721]: 
/home/anarcat/.emacs.d/eln-cache/28.2-8532cd27/tab-line-e55f541b-b1fd08d4.eln(F7461622d6c696e652d666f726d61742d74656d706c617465_>
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0x1b811b)[0x55d1080b011b]
fév 22 11:57:10 angela emacs[112721]: 
/home/anarcat/.emacs.d/eln-cache/28.2-8532cd27/tab-line-e55f541b-b1fd08d4.eln(F7461622d6c696e652d666f726d6174_tab_line_format_0+>
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0x1ba9fd)[0x55d1080b29fd]
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0x1bc488)[0x55d1080b4488]
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0x1b811b)[0x55d1080b011b]
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0x1b73f9)[0x55d1080af3f9]
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0x68504)[0x55d107f60504]
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0x68620)[0x55d107f60620]
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0x88839)[0x55d107f80839]
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0x8a0e0)[0x55d107f820e0]
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0x8a54a)[0x55d107f8254a]
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0xa4bf7)[0x55d107f9cbf7]
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0xa8ffb)[0x55d107fa0ffb]
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0x1b7164)[0x55d1080af164]
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0x6ab49)[0x55d107f62b49]
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0x93d51)[0x55d107f8bd51]
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0x95c15)[0x55d107f8dc15]
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0x52244)[0x55d107f4a244]
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0x1b811b)[0x55d1080b011b]
fév 22 11:57:10 angela emacs[112721]: 
/home/anarcat/.emacs.d/eln-cache/28.2-8532cd27/notmuch-show-7f6eba8e-bdb6e2e2.eln(F6e6f746d7563682d73686f772d636f6d6d616e642d686>
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0x1b811b)[0x55d1080b011b]
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0x1b8238)[0x55d1080b0238]
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0x1b73f9)[0x55d1080af3f9]
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0x139151)[0x55d108031151]
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0x1b783d)[0x55d1080af83d]
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0x13ef45)[0x55d108036f45]
fév 22 11:57:10 angela emacs[112721]: /usr/bin/emacs(+0x148a84)[0x55d108040a84]
fév 22 11:57:10 angela emacs[112721]: ...
fév 22 11:57:11 angela systemd[3301]: emacs.service: Main process exited, 
code=killed, status=6/ABRT

I'm not sure what's going on, but it scares the heck out of me.

A.

-- 
Life is like riding a bicycle. To keep your balance you must keep moving.
   - Albert Einstein


1677084681.110728_1.angela,,U=63246:2,S
Description: Binary data


signature.asc
Description: PGP signature
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

[PATCH] emacs/show: use read-shell-command instead of read-string

[Antoine Beaupré]

This enables auto-completion of commands, something which plain
read-string does not do. It's otherwise a drop-in
replacement. According to `C-h f`, read-shell-command was introduced
in Emacs 23.1 or earlier.
---
 emacs/notmuch-show.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 2dcef981..ec998ede 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -2192,7 +2192,7 @@ message."
   (interactive (let ((query-string (if current-prefix-arg
   "Pipe all open messages to command: "
 "Pipe message to command: ")))
-(list current-prefix-arg (read-string query-string
+(list current-prefix-arg (read-shell-command query-string
   (let (shell-command)
 (if entire-thread
(setq shell-command
-- 
2.30.2

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: WIP fixes for rfc822/attachement display

[Antoine Beaupré]

On 2021-07-09 07:23:55, David Bremner wrote:
> Antoine Beaupré  writes:
>
>> On 2021-07-06 12:49:23, David Bremner wrote:
>>> David Bremner  writes:
>>>
>>>> This is not finished/correct yet, but maybe it will save someone else
>>>> some debugging.
>>>>
>>>> [PATCH 2/3] emacs: don't inline message/rfc822 parts without content
>>>>
>>>
>>> I have confirmed that thanks to larsi's quick fix, patch 2/3 alone makes
>>> things copacetic in emacs master. I have marked the other two patches as
>>> obsolete, although if people thing this case is important enough, we
>>> could try to work around the issues with pre-28 emacs in a more
>>> careful way.
>>>
>>> Antoine, is this a common annoyance for you, or a rare issue?
>>
>> I actually fumble upon similar errors somewhat frequently, but it's the
>> first time it's reproducible. Typically, it happens under other, more
>> neboulous circumstances and the fix then is to restart emacs (!).
>>
>> Are you saying the fix is to upgrade to emacs 28?
>
> Pretty much. Along with a patch to notmuch, if you care about the
> display of !!! error messages. Of course, Emacs 28 is unreleased
> software, so may have other uncomfortable aspects.

I'm not at a place in my life where I compile my own Emacs. Once a upon
a time, that was a thing, before I found out about binary
distributions. But those days are (fortunately) over. ;)

a.

-- 
A developed country is not a place where the poor have cars. It's
where the rich use public transportation.
- Gustavo Petro 
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: WIP fixes for rfc822/attachement display

[Antoine Beaupré]

On 2021-07-06 12:49:23, David Bremner wrote:
> David Bremner  writes:
>
>> This is not finished/correct yet, but maybe it will save someone else
>> some debugging.
>>
>> [PATCH 2/3] emacs: don't inline message/rfc822 parts without content
>>
>
> I have confirmed that thanks to larsi's quick fix, patch 2/3 alone makes
> things copacetic in emacs master. I have marked the other two patches as
> obsolete, although if people thing this case is important enough, we
> could try to work around the issues with pre-28 emacs in a more
> careful way.
>
> Antoine, is this a common annoyance for you, or a rare issue?

I actually fumble upon similar errors somewhat frequently, but it's the
first time it's reproducible. Typically, it happens under other, more
neboulous circumstances and the fix then is to restart emacs (!).

Are you saying the fix is to upgrade to emacs 28?

a.

-- 
Ou bien Dieu voudrait supprimer le mal, mais il ne le peut pas
Ou bien Dieu pourrait supprimer le mal, mais il ne le veut pas.
- Sébastien Faure
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

BUG: unexpected prompt for Recipients during Fcc

[Antoine Beaupré]

I'm having trouble writing long encrypted emails.

On startup, this works:

 1. start emacs
 2. start notmuch (M-x notmuch-hello)
 3. compose email ("c"), encrypted ("control-enter e")
 4. send ("control-c c")

But eventually, I get into this weird state. I originally thought it was
related with the `notmuch-draft-save-plaintext` prompt because in both
cases I had saved the long email before the issue was triggered. But now
i'm trying to reproduce with this:

 1. start emacs
 2. start notmuch
 3. compose email, encrypted
 4. save email ("control-x s")
 5. refuse to answer ("control-g") or say no ("n") to the "Really save
and index an unencrypted copy?" question
 5. send

... but that, unexpectedly, works right now, which confuses me slightly.

The problematic behavior is that instead of working, the "send" step
does the following:

 1. email is sent
 2. the Fcc step unexpectedly prompts me for a "Recipient:" in the
modeline
 3. enter a valid OpenPGP identity (I tried an email address and OpenPGP
key)
 4. emacs fires up a `gpg --list-keys` process (according to ps) and
then fails with "Wrong type argument: stringp, nil"
 5. email is not saved to disk

A workaround, at that stage, is to:

 1. save the email as a draft ("control-c p")
 2. exit emacs
 3. restart emacs
 4. find the draft ("s tag:draft")
 5. resume draft ("e")
 6. send the email (now a duplicate, but fcc will work now)

I'm a bit at a loss on why this is happening or how to trigger it. I
also don't have a debug backtrace of the problem, unfortunately, but I
promise to submit one when it happens again, because it's extremely
irritating. :) At least there's a way to not drop the email, even though
it means duplicate emails in the recipient's inbox.

This is on notmuch 0.28.4-1, Debian buster, Emacs 26.1, and
notmuch-config.el:

https://gitlab.com/anarcat/emacs-d/blob/master/notmuch-config.el
-- 
PHP was originally designed explicitly for non-programmers (and, reading
between the lines, non-programs); it has not well escaped its roots.
 - Alex Munroe, PHP: a fractal of bad design


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: [aperezdc/notmuch-addrlookup-c] Possibility to upstream (#23)

[Antoine Beaupré]

On 2020-02-18 21:21:01, David Bremner wrote:
> anarcat  writes:
>
>
>> One improvement we could *already* do with notmuch-address would be to 
>> enforce searching for to/from headers, which doesn't seem to be the case 
>> right now. I have a [wrapper 
>> script](https://gitlab.com/anarcat/scripts/-/blob/master/notmuch-address) 
>> where I do basically this:
>>
>> exec notmuch address from:"$*"
>>
>> I would love to be able to do `to:"$*"` here, but that gives the unexpected 
>> result of the `From` addresses instead of `To` in that search... And 
>> `--output=recipients` does not fix that at all...
>
> If you have a way to reproduce this (e.g. that works with the notmuch
> test corpus, or at least doesn't depend on your mail), please let us
> know. I can't really understand the problem from the description here,
> so it's not likely to get fixed.
>
> PS this is not sent via github, as it's not about notmuch-addrlookup

It's quite simple really. If I do:

 notmuch address to:anarcat

I get all the email addresses that wrote *to* anarcat. In other words,
notmuch-address seems to look only at the From header to extract emails
it shows the user, regardless of the query provided. For example, right
after you sent that email, the first result was:

David Bremner 

.. because you were the last email address that sent me an email.

Not sure I can work that out in a test case, but at least it should
explain a bit more how that problem occurs...

A.

-- 
A developed country is not a place where the poor have cars. It's
where the rich use public transportation.
- Gustavo Petro 
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: proposing "notmuch purge"

[Antoine Beaupré]

On 2020-01-14 17:48:34, Ryan Tate wrote:
> Daniel Kahn Gillmor  writes:
>> So i'm proposing "notmuch purge", which could be something as simple as
>> the equivalent of:
>>
>>notmuch search --output=files --format=text0 tag:deleted | \
>>   xargs --null --no-run-if-empty rm && \
>>  notmuch new --no-hooks
>>
>> (credit for the pipeline above goes to anarcat, in Cc; i added the
>> "notmuch new --no-hooks" part, because i would want the items gone from
>> the db as well)
>
> Is there any other notmuch command that results in a change to the state
> of actual mail files, as opposed to the database?

As jrollins said, mail flags can be changed, but that's about it. Email
contents are never modified and files are never removed, by principle,
so far.

> Personally, I would be surprised to learn that the command "notmuch
> purge" deleted actual emails on my filesystem. I would expect any
> notmuch command would only operate on the database. As far as I can tell
> -- and I could be forgetting something! -- the current suite of commands
> simply mutate the database, never the actual files.
>
> What I would expect to happen is that "notmuch purge" removes mails
> tagged "deleted" from the notmuch index. (And perhaps with a flag, like
> say "--rmfiles", would take the step of actually deleting files.)
>
> Of course, I like to think I'd read the manpage of a command involving
> the word "purge" before executing said command :-) But I think I'd be
> surprised when I did, in this case.

That's an excellent point!! If we have one user that has that
misconception and runs the command and destroys email, maybe it's worth
thinking more about ways of preventing such catastrophes! :)

Maybe some --force argument would be useful here? Or would "notmuch
delete" be more obvious to you? Or maybe a confirmation dialog unless
--yes or --force is passed?

> (Thank you to anyone on thread who has helped build notmuch, it has
> helped me enormously.)

Hey that's a nice touch, thanks! (even though I haven't done much on
notmuch)

(pun intended)

(and probably failed)

a.
-- 
La destruction de la société totalitaire marchande n'est pas une affaire
d'opinion. Elle est une nécessité absolue dans un monde que l'on sait
condamné. Puisque le pouvoir est partout, c'est partout et tout le temps
qu'il faut le combattre. - Jean-François Brient, de la servitude moderne
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: proposing "notmuch purge"

[Antoine Beaupré]

On 2020-01-14 11:55:36, Jameson Graef Rollins wrote:
> On Tue, Jan 14 2020, Daniel Kahn Gillmor  wrote:
>>> I think that the "SEARCH-TERMS" part should be configurable, not
>>> hard-coded. A user could have setting like
>>> "search.purge_tags=deleted;spam" and that would lead to search terms
>>> "tag:deleted OR tag:spam" in the purge operation.
>>
>> I want the user to be able to run "notmuch purge", with no arguments, to
>> "Do What I Mean"™
>>
>> I also want the "purge" subcommand to have its own configuration
>> space -- it's *not* a specialized form of "search".
>
> Honestly I don't see the point of any user configuration here.  Seems
> likely to only add confusion and possibly improperly deleted messages,
> which would be very bad.
>
> Just use the "deleted" tag only.  It's already being used in multiple
> place to mean that the message should be deleted.

Agreed. If you want to delete messages matching an another tag, you just
run:

notmuch tag +deleted tag:another
notmuch purge

Composability wins over configurability in this case. :)

A.

-- 
Le péché est né avant la vertu, comme le moteur avant le frein.
 - Jean-Paul Sartre
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: proposing "notmuch purge"

[Antoine Beaupré]

On 2020-01-13 17:28:38, Daniel Kahn Gillmor wrote:
> This e-mail proposes a new notmuch subcommand "purge", which actually
> removes explicitly deleted messages from the mailstore.
>
> Notmuch currently never deletes mail, but notmuch-emacs makes it easy to
> tag mail with "deleted" (via the "d") key, and "notmuch setup"
> automatically adds "deleted" to the search.exclude_tags setting.
>
> Users typically do actually want to delete messages, and they want them
> gone from their filesystem and from the index.

I certainly do! :)

> while everyone who has used notmuch for a while probably has a clever
> way of doing this, those techniques are all probably slightly different
> (and possibly buggy), and the cognitive burden of figuring out how to do
> this sensibly for new users seems like something we should avoid.

Agreed.

> So i'm proposing "notmuch purge", which could be something as simple as
> the equivalent of:
>
>notmuch search --output=files --format=text0 tag:deleted | \
>   xargs --null --no-run-if-empty rm && \
>  notmuch new --no-hooks
>
> (credit for the pipeline above goes to anarcat, in Cc; i added the
> "notmuch new --no-hooks" part, because i would want the items gone from
> the db as well)

I don't quite understand that last bit. I deliberately do *not* run
notmuch-new in my notmuch-purge script:

https://gitlab.com/anarcat/scripts/blob/master/notmuch-purge

... because it's setup as a pre-new hook, so it runs right before
new. So it doesn't need to call new.

> If i was to implement this, i'd probably implement it directly in C, not
> as a shell script, because this lets us drop messages from the db as we
> unlink() the files.

I also agree it might be faster than forking like crazy and rescanning
the entire DB.

But maybe we can just start with a shell wrapper for now. That's how
many git subcommands start, by the way, and it might just be "good
enough" for most people.

> Inevitably, someone will come up with some more clever
> options/generalizations (i can already think of at least one), but if we
> have a particular implementation to hang these proposals on, it should
> help us to build something sensibly robust with a wider consensus, and
> new users can pick up and use that functionality easily/safely/with
> confidence.
>
> I note that this is a divergence from the historical expectation of
> having all "notmuch" subcommands not directly tamper with the
> mailstore.  I think given the context that divergence is OK.

Well, we're already tampering with the mailstore: we're changing flags!
:)

> Any objections to this approach?

Not from me, I've been advocating for data destruction for years
now. Happy to get one more on my crew! ;)

A.

-- 
People arbitrarily, or as a matter of taste, assigning numerical values
to non-numerical things. And then they pretend that they haven't just
made the numbers up, which they have. Economics is like astrology in
that sense, except that economics serves to justify the current power
structure, and so it has a lot of fervent believers among the powerful.
- Kim Stanley Robinson, Red Mars
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] debian: Add packaging for python3-notmuch2

[Antoine Beaupré]

On 2020-01-08 16:58:04, Daniel Kahn Gillmor wrote:
> On Mon 2019-12-23 17:17:22 -0500, Daniel Kahn Gillmor wrote:
>> Ship a new debian package for the notmuch2 CFFI-based Python interface
>> to notmuch.
>>
>> Unlike the notmuch python module, the new notmuch2 module is no longer
>> arch-independent, because it builds and ships a shared object in
>> addition to the python code.
>>
>> This patch encourages new downstream development to rely on notmuch2
>> instead of on notmuch, to get the benefits of the new module.
>>
>> I welcome any suggested improvements to this packaging, but it appears
>> to me to be sufficient to get "import notmuch2" to work and do some
>> basic tests.
>> ---
>>  debian/control | 24 +++-
>>  debian/rules   | 11 ++-
>>  2 files changed, 29 insertions(+), 6 deletions(-)
>>
>> diff --git a/debian/control b/debian/control
>> index fb2b31c1..a1371fc8 100644
>> --- a/debian/control
>> +++ b/debian/control
>> @@ -98,6 +98,25 @@ Depends:
>>   libnotmuch5 (>= ${source:Version}),
>>   ${misc:Depends},
>>   ${python3:Depends},
>> +Description: Python 3 legacy interface to the notmuch mail search and index 
>> library
>> + Notmuch is a system for indexing, searching, reading, and tagging
>> + large collections of email messages in maildir or mh format. It uses
>> + the Xapian library to provide fast, full-text search with a very
>> + convenient search syntax.
>> + .
>> + This package provides a legacy Python 3 interface to the notmuch
>> + functionality, directly interfacing with a shared notmuch library.
>> + .
>> + New projects are encouraged to use python3-notmuch2 instead.
>> +
>> +Package: python3-notmuch2
>> +Architecture: any
>> +Section: python
>> +Depends:
>> + libnotmuch5 (>= ${source:Version}),
>> + ${misc:Depends},
>> + ${python3:Depends},
>> + ${shlibs:Depends},
>>  Description: Python 3 interface to the notmuch mail search and index library
>>   Notmuch is a system for indexing, searching, reading, and tagging
>>   large collections of email messages in maildir or mh format. It uses
>> @@ -105,7 +124,10 @@ Description: Python 3 interface to the notmuch mail 
>> search and index library
>>   convenient search syntax.
>>   .
>>   This package provides a Python 3 interface to the notmuch
>> - functionality, directly interfacing with a shared notmuch library.
>> + functionality using CFFI bindings, which interface with a shared
>> + notmuch library.
>> + .
>> + This is the preferred way to use notmuch via Python.
>>  
>>  Package: ruby-notmuch
>>  Architecture: any
>> diff --git a/debian/rules b/debian/rules
>> index bf9d0bbd..8de49d0f 100755
>> --- a/debian/rules
>> +++ b/debian/rules
>> @@ -1,7 +1,5 @@
>>  #!/usr/bin/make -f
>>  
>> -export PYBUILD_NAME=notmuch
>> -
>>  export DEB_BUILD_MAINT_OPTIONS = hardening=+all
>>  
>>  %:
>> @@ -19,17 +17,20 @@ override_dh_auto_configure:
>>  
>>  override_dh_auto_build:
>>  dh_auto_build -- V=1
>> -dh_auto_build --buildsystem=pybuild --sourcedirectory bindings/python
>> +PYBUILD_NAME=notmuch dh_auto_build --buildsystem=pybuild 
>> --sourcedirectory bindings/python
>> +PYBUILD_NAME=notmuch2 dh_auto_build --buildsystem=pybuild 
>> --sourcedirectory bindings/python-cffi
>>  $(MAKE) -C contrib/notmuch-mutt
>>  
>>  override_dh_auto_clean:
>>  dh_auto_clean
>> -dh_auto_clean --buildsystem=pybuild --sourcedirectory bindings/python
>> +PYBUILD_NAME=notmuch dh_auto_clean --buildsystem=pybuild 
>> --sourcedirectory bindings/python
>> +PYBUILD_NAME=notmuch2 dh_auto_clean --buildsystem=pybuild 
>> --sourcedirectory bindings/python-cffi
>>  dh_auto_clean --sourcedirectory bindings/ruby
>>  $(MAKE) -C contrib/notmuch-mutt clean
>>  
>>  override_dh_auto_install:
>>  dh_auto_install
>> -dh_auto_install --buildsystem=pybuild --sourcedirectory bindings/python
>> +PYBUILD_NAME=notmuch dh_auto_install --buildsystem=pybuild 
>> --sourcedirectory bindings/python
>> +PYBUILD_NAME=notmuch2 dh_auto_install --buildsystem=pybuild 
>> --sourcedirectory bindings/python-cffi
>>  $(MAKE) -C contrib/notmuch-mutt DESTDIR=$(CURDIR)/debian/tmp install
>>  dh_auto_install --sourcedirectory bindings/ruby
>> -- 
>
> Pinging on this patch as well.  If we want the notmuch2 python module to
> be used, we need to get it in wider distribution.  having it installable
> via "apt install python3-notmuch2" would be a good start.
>
> Note that making this change means that the notmuch package will pass
> through the NEW queue, which can take longer than we might like,
> depending on the Debian FTP team's available time.  I see this as an
> argument for making this change earlier, rather than later, though, so
> that the NEW queue doesn't trip us up if we have a more urgent change we
> want to see made later.

I don't of the merits of the two python libraries or how they compare. I
think i used the former (non-CFFI) version, and it worked fine. Assuming
we do want to migrate to the new one, it 

Re: [PATCH] debian: add Build-Depends-Package for libnotmuch5.symbols

[Antoine Beaupré]

On 2020-01-08 16:44:50, Daniel Kahn Gillmor wrote:
> On Mon 2019-12-23 15:14:38 -0500, Daniel Kahn Gillmor wrote:
>> See lintian informational tag
>> symbols-file-missing-build-depends-package-field for hints about this
>> minor metadata update.
>>
>> Signed-off-by: Daniel Kahn Gillmor 
>> ---
>>  debian/libnotmuch5.symbols | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/debian/libnotmuch5.symbols b/debian/libnotmuch5.symbols
>> index 308567b8..2ae73dad 100644
>> --- a/debian/libnotmuch5.symbols
>> +++ b/debian/libnotmuch5.symbols
>> @@ -1,4 +1,5 @@
>>  libnotmuch.so.5 libnotmuch5 #MINVER#
>> +* Build-Depends-Package: libnotmuch-dev
>>   notmuch_built_with@Base 0.23~rc0
>>   notmuch_config_list_destroy@Base 0.23~rc0
>>   notmuch_config_list_key@Base 0.23~rc0
>> -- 
>
> Ping on this patch.  it should be unobjectionable, but i'd appreciate a
> review!

I didn't know about this feature, but after reading the lintian tag, you
seem to have done the right thing.

a.
-- 
Ou bien Dieu voudrait supprimer le mal, mais il ne le peut pas
Ou bien Dieu pourrait supprimer le mal, mais il ne le veut pas.
- Sébastien Faure
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: rfc: notmuch-status.el - notmuch status reporting

[Antoine Beaupré]

On 2019-12-05 12:56:46, David Edmondson wrote:
> The idea is to layer on top of the existing `notmuch-saved-searches' as
> a set of queries that you find interesting. When combined with
> `notmuch-jump' it provides, I think, a quick way of seeing the state of
> queries that you care about and then jumping to the corresponding
> messages.

That's pretty neat!
-- 
Quidquid latine dictum sit, altum sonatur.
Whatever is said in Latin sounds profound.

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: Complete Debian packaging transition to dh 12

[Antoine Beaupré]

On 2019-12-09 13:49:06, Daniel Kahn Gillmor wrote:
> This series follows the series introduced by
> id:20191204084742.398298-1-...@fifthhorseman.net
>
> Its goal is to move the notmuch debian packaging to dh 12.
>
> To do this, the series accepts the conclusions about info files
> reached in the thread anchored at id:87a7887akl@fifthhorseman.net,
> and it also relies on dh_elpa having #946142 resolved, for example, by
> merging https://salsa.debian.org/emacsen-team/dh-elpa/merge_requests/2
> into that project.
>
> What remains here is pretty simple mechanical work, which shouldn't
> have an effect on anything else in notmuch other than how the debian
> package itself gets assembled.

I'm not very familiar with the dh-elpa and dh-missing voodoo that's
going on here, I must admit. But this otherwise seems to make sense
after a quick review, so: LGTM! :)

a.
-- 
C'est trop facile quand les guerres sont finies
D'aller gueuler que c'était la dernière
Amis bourgeois vous me faites envie
Ne voyez vous pas donc point vos cimetières?
- Jaques Brel
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: More debian packaging cleanup

[Antoine Beaupré]

On 2019-12-04 03:47:37, Daniel Kahn Gillmor wrote:
> This series should apply after "wrap-and-sort -ast" v2 is applied
> (id:20191110173748.25792-5-...@fifthhorseman.net).
>
> In this series, i clean up a few things that i noticed from applying
> dh_missing to the debian packaging.  In particular, we were failing to
> ship notmuch(3) (programmer's manual for libnotmuch) and
> notmuch-setup(1) (a symlink or copy of notmuch(1) that is referenced
> in notmuch-config(1)).
>
> This doesn't get us to the point of enabling dh 12 cleanly yet (more
> elpa-notmuch cleanup might be blocked on #946142 and answers to the
> questions i raised in id:87a7887akl@fifthhorseman.net), but it's
> a lot of the way there.

Wow, that's great work! I can't believe we weren't shipping those
manpages! :)

LGTM...

a.
-- 
If we do not do the impossible, we shall be faced with the unthinkable.
- Murray Bookchin
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: compacting the notmuch database through systemd

[Antoine Beaupré]

On 2019-12-05 08:29:44, Jorge P. de Morais Neto wrote:
> Hello.
>
> Em [2019-12-04 qua 14:51:12-0500], Antoine Beaupré escreveu:
>
>>> What should happen if the user hasn't set up notmuch?  Maybe we need a
>>> ConditionPathExists= or something like that on either the .timer or the
>>> .service?
>>
>> Maybe:
>>
>> ConditionPathExists=$HOME/.notmuch-config
>>
>> ?
>
> But the user might have changed ~NOTMUCH_CONFIG~.  On my Debian install
> it is "~/.config/notmuch/config" (XDG compliant).

Then you get what you desserve? :p You can still override those in your
local config...

I'm not sure how else to fix this, really...

A.

-- 
Secrecy is the keystone to all tyranny. Not force, but secrecy and
censorship.
   -  Robert A. Heinlein
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: compacting the notmuch database through systemd

[Antoine Beaupré]

On 2019-12-04 13:09:03, Daniel Kahn Gillmor wrote:
> Thanks for raising this, Anarcat!
>
> One more advantage that i think you haven't noted yet about regular
> database compaction:
>
> "notmuch compact" tends to get rid of a lot of lingering written data
> that is no longer referenced.  While this isn't robust "secure
> deletion", it's a lot better than not compacting.  see
> https://trac.xapian.org/ticket/742 for more discussion.

Cool.

> Some questions below…
>
> On Sun 2019-12-01 15:52:19 -0500, Antoine Beaupré wrote:
>
>> Thanks to Bremner, I just realized that notmuch-compact(1) is a thing,
>> and that thing allows me to compress my notmuch databases by about 50%.
>
> do you know why you get the large size/speed gain?

Not sure, but if I'd venture a guess: I never ran notmuch-compact(1) as
far as I can remember.

> do you regularly delete files from your message archive?

Yes, all the time. I have had `d` mapped to `+deleted` basically
forever, and have a pre-new hook that actually deletes those messages
from this.

Yes, I am an heretic. ;)

>> So I whipped together two systemd units (attached) that will run that
>> command every month on my notmuch database. Just drop them in
>> `~/.config/systemd/user/` and run:
>>
>> systemctl --user daemon-reload
>> systemctl --user enable notmuch-compact.timer
>> systemctl --user start notmuch-compact.timer
>
> ("systemctl --user enable --now notmuch-compact.timer" will suffice for
> the final two commands on any reasonably modern version of systemd)

Whoa. TIL.

> How long does it take for these the notmuch-compact.service to complete?

I don't remember... it took less than a minute at the first run, I
think.

> What happens if this is happening when, say, you put your machine to
> sleep, or you power it down?

No idea. I think it's an atomic process as notmuch-compact(1) says:

   The compacted database is built in a temporary directory and is
   later moved into the place of the origin database. The original
   uncompacted database is discarded, unless the
   --backup= option is used.

> While notmuch-compact.service is running, does "notmuch new" or "notmuch
> insert" work?  If not, how do they fail (e.g. blocking indefinitely,
> returning a comprehensible error message)?

No idea. Manpage says:

   Note that the database write lock will be held during the
   compaction process (which may be quite long) to protect data
   integrity.

> Can you read your mail while notmuch-compact.service is running?

I don't see why not, but I haven't tried. Considering I run it once a
week, it would seem like a small tradeoff if that would cause problems
anyways.

>> Maybe those could be shipped with the Debian package somehow? Not sure
>> how that works, but I think that's how gpg-agent gets started now, if
>> you want any inspiration...
>
> gpg-agent is socket-activated, which is different from the
> timer-activation you are proposing here.

I thought about socket activation, but I don't think it would work in
this case.

> We could easily ship these systemd user unit files in the notmuch
> package now that #764678 is resolved.  Do you think that the timer
> should be enabled by default?

Sure, I don't see why not, unless we have concerns about
notmuch-compact(1) being unsafe or counter-productive.

> What should happen if the user hasn't set up notmuch?  Maybe we need a
> ConditionPathExists= or something like that on either the .timer or the
> .service?

Maybe:

ConditionPathExists=$HOME/.notmuch-config

?

> Do we expect this to run even when the user isn't logged in at all (a
> background compaction?)

Maybe not? No idea.

> it always gets more complex when you think about trying to do it at
> scale :)

Yes.

>> It would be great if notmuch-new ran this on its own, when it
>> thought that this was "important", somehow like git-gc sometimes runs on
>> its own.
>
> I'm not convinced i like this idea without more profiling and an
> understanding of what it might cause.  I have grown to *really* dislike
> the highly variable latency and warnings caused by GnuPG's
> "auto-check-trustdb", for example (especially as the keyring grows
> larger).

Again, tradeoffs: I prefer to have my trustdb actually checked once in a
while (right?) and not pay that latency cost at some random gpg
invocation (which seems to happen all the time). So I disable the
built-in, inline checks and queue them in a timer instead.

>>  [ notmuch-compact.timer: text/plain ]
>>  [Unit]
>>  Description=compact the notmuch database
>
> systemd timer unit descriptions typically include some mention of the
> duration.  See for example:
>
> /

Re: compacting the notmuch database through systemd

[Antoine Beaupré]

On 2019-12-01 15:52:19, Antoine Beaupré wrote:
> PS: any humor or comedy in this email is purely accidental and shouldn't
> be construed as a feeble attempt at making you smile.

The joke is on me, I guess. I thought I had written some hooks to ever
prevent this from happening again, but it looks like either (a) they
didn't work in this case or (b) they are disabled because I forgot the
attachments...

A.

-- 
There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult.
- C.A.R. Hoare
[Unit]
Description=compact the notmuch database

[Timer]
OnCalendar=monthly

[Install]
WantedBy=timers.target
[Unit]
Description=compact the notmuch database

[Service]
Type=simple
Nice=10
ExecStart=/usr/bin/notmuch compact
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

compacting the notmuch database through systemd

[Antoine Beaupré]

Hi!

Thanks to Bremner, I just realized that notmuch-compact(1) is a thing,
and that thing allows me to compress my notmuch databases by about 50%.

So I whipped together two systemd units (attached) that will run that
command every month on my notmuch database. Just drop them in
`~/.config/systemd/user/` and run:

systemctl --user daemon-reload
systemctl --user enable notmuch-compact.timer
systemctl --user start notmuch-compact.timer

... and you're done.

Maybe those could be shipped with the Debian package somehow? Not sure
how that works, but I think that's how gpg-agent gets started now, if
you want any inspiration...

It would be great if notmuch-new ran this on its own, when it
thought that this was "important", somehow like git-gc sometimes runs on
its own.

Of course, I suspect the 50% saving will not happen every month, but
hopefully this will keep my database size from exploding in the
future...

Finally, Bremner said that "it could make some operations slower to
compact the database, but I haven't notced that effect". That is strange
because the manpage says that compact "can both reduce the space
required by the database and improve lookup performance". ;) Hopefully,
the documentation is true and the rumors are false and the sky is not
falling and I want my mommy.

A.

PS: any humor or comedy in this email is purely accidental and shouldn't
be construed as a feeble attempt at making you smile.

-- 
I prefer the tumult of liberty to the quiet of servitude.
- Thomas Jefferson


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: unifying and automating draft ("postpone/resume") behavior [was: Re: notmuch "lost" email during power failure]

[Antoine Beaupré]

On 2019-11-14 03:16:51, Daniel Kahn Gillmor wrote:
> On Wed 2019-11-13 10:19:05 -0500, Antoine Beaupré wrote:
>> Fundamentally, I think message-mode should treat emails the same way
>> epg.el treats encrypted files: the data in the buffer isn't the same as
>> the on-disk data, and there should be translation between the two. At
>> the very least, the on-disk data could be a properly formed email
>> message. If it's marked as needing encryption, then it should be
>> encrypted.
>
> i think it might be easier for notmuch-emacs to override message-mode
> entirely, than to try to convince message-mode to do something so
> radically different.

Possibly.

> but i agree with you that it would be nice for the whole emacs MUA
> ecosystem if they were more sensible there.

I would just hate to think of notmuch as a (yet another) Emacs MUA that
reinvents everything for itself, with nice little "edges" compared to
the other clients. But I guess that's the easier way to move forward and
I would certainly prefer that to not having a solution for this. :)

>> Arguably, I haven't looked in details at how epg.el works: maybe it
>> suffers from the same flaw. But from what I can tell, it simply bypasses
>> the autosave functionality. If you have edit an ecrypted file called
>> `foo.gpg` (note the non-standard extension), the `#foo.gpg` file is just
>> a symlink, a lockfile instead of the normal autosave.
>>
>> This is probably because it would be prohibitively expensive to
>> constantly call gpg every time a buffer changes to do the autosave. I
>> think that is actually a fairly reasonable tradeoff.
>
> if it's prohibitively expensive to encrypt-when-saving on a modern
> machine, then we should be using a different encryption tool.

The individual calls are not what's prohibitively expensive. The problem
is latency. Even if it just takes 100ms[1] to save the file to the disk,
that's a huge delay in terms of human interface, because the entire
Emacs UI will *freeze* for that amount of time whenever it thinks it
should do an autosave.

So yes, that's prohibitively expensive, and I'm not sure it's realistic
to blame gpg for this here. We are, after all, shelling out to a
different process and most runtimes have at least *some* overhead on
started (e.g. cPython 2 is ~13ms here and cPython 3 is around 25ms, both
noticeable latencies).

In other words, maybe the right solution for autosave is to skip it in
some cases.

A.

[1] anarcat@curie:~(master)$ multitime -n 10 -r 'rm -f motd.gpg' -v gpg -e -r 
anar...@debian.org motd
===> multitime results
1: -r "rm -f motd.gpg" gpg -e -r anar...@debian.org motd
MeanStd.Dev.Min Median  Max
real0.096   0.007   0.088   0.099   0.104   
user0.062   0.011   0.041   0.061   0.080   
sys 0.023   0.008   0.012   0.023   0.037   


-- 
There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult.
- C.A.R. Hoare
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: unifying and automating draft ("postpone/resume") behavior [was: Re: notmuch "lost" email during power failure]

[Antoine Beaupré]

On 2019-11-12 18:03:58, Daniel Kahn Gillmor wrote:
> Hi Antoine--
>
> [epic story and funny rnat trimmed down to the salient bug reports and
>  feature requests because i'm a boring person]

Hi!

[I don't remember what RNAT (reverse network address translation) have to
do with anything, but it's true it was a rather long RANT so maybe I
forgot that I went through some weird addressing along the way. ;)]

> On Tue 2019-11-12 17:19:05 -0500, Antoine Beaupré wrote:
>> I would argue that notmuch should at least allow me to recover from a
>> power failure like this, as a MUA. It should "know" that message-mode
>> stores those messages there, and, why not, also store its tempfiles
>> there.
>
> This seems like a very specific ask.  I think what we want more
> generally is a sensible unification of the notmuch-emacs drafting
> behaviors such that message-mode autosaves are discoverable and
> recoverable in the same way that deliberately-saved drafts are.

Yeah. That is pretty much what I meant to say, but said in a more
useful, constructive and clever way. :p

> If that means that notmuch learns about message-mode drafts, that's one
> solution.  But it could also mean that notmuch-emacs overrides
> message-mode's autosave drafting approach, and fixes things there too.

I think the main problem right now is that "control-x control-s" does
something special in notmuch, in that it adds a message-id to the saved
message even if the message isn't saved yet.

But then when *message-mode* auto-saves those files, the message-id is
not present (just checked). For example this very message has 
References (hidden), From, To, Cc, Subject, In-Reply-To and Fcc headers
on disk, along with the fancy `--text follows this line--` magic blob on
disk, in ~/Mail/drafts/#...

While if I save this message to disk, it looks like a proper email
message. It has a (properly encoded) From header, To, Cc, Subject,
In-Reply-To, Fcc (so far pretty close to message-mode), but then also a
Message-ID, Date, X-Notmuch-Emacs-Draft, MIME-Version, Content-type and
Content-transfer-encoding. And of course, the content *is*
quoted-printable-encoded, which might be a problem for message-mode.

In my opinion, that's the fundamental conflict between the two modes:
message-mode expects buffers (and auto-saved files) to have this weird
exotic format to operate, but it's pretty much exactly the same on-disk
format, while notmuch expects a standard email message, which *differs*
from the actual buffer content. It will be fundamentally difficult to
reconcile those two.

> or, we somehow fix message-mode?

That could be a huge challenge. We'd need to teach it to parse real
RFC852 messages properly, without the magic separator, and to include
proper message IDs and other headers.

Alternatively, maybe message-mode could do the same translation magic
that notmuch does when it saves and loads those files, on write. By
moving the notmuch logic upwards in the stack, everyone could benefit.

But it's kind of a big change.

>> And indeed, if I hit [control-x control-s] on this message, it *does*
>> get saved as a "draft" in that it gets written in:
>>
>> ~/Maildir/drafts/cur/1573596264.M156307P32312.curie:2,DF
>>
>> That's a great improvement already. I don't remember exactly when or how
>> this happened, but that's great and I thank whoever did that for us
>> here.
>
> That was Mark Walters (in Cc), see the series from 2016 starting at:
>
>  id:1479046130-2716-1-git-send-email-markwalters1...@gmail.com
>
> Thank you, Mark!

Yeeeaay! thank you Mark!

>> To make a long story short, I think the following should happen:
>>
>>  1. message-mode should automatically cleanup after itself a little
>> better (not notmuch's job? yay double-negative, that means it's much
>> job!)
>>
>>  2. encrypted emails should *never* be written in cleartext on the
>> filesystem (not notmuch job, which also means it's much job!)
>>
>>  3. notmuch's draft subsystem should know about Emacs' autosave files
>> and somehow show them in the UI
>
> Much of the above sounds like message-mode cleanup work to me.  It might
> be worth asking the message-mode folks to weigh on in this strategy.

For what it's worth, I reviewed the original patchset that was merged
from Mark, and notmuch *does* the right thing with encrypted messages
(issue 2 above): it asks users (configurable) what to do. This, again,
could be moved up into message-mode as well...

> Alternately, it might help to characterize the differences between
> message-mode autosaving and notmuch explicit drafting.
>
>  - message-mode autosaves happen without your knowledge.
>notmuch draft saving only happens when you explicitly C-x C-s
>  
>  - message-mode autosaves

Re: [PATCH] Add --message-headers flag to notmuch-show

[Antoine Beaupré]

On 2019-11-12 12:19:01, Daniel Kahn Gillmor wrote:
> On Tue 2019-11-12 10:48:54 -0500, Antoine Beaupré wrote:
>> They need User-Agent:, I want Archive-At:, they will want
>> X-Mailer... when is it going to stop?
>
> It's going to stop when users are satisfied. :)  I highly doubt that we
> will reach all possible headers.

I wouldn't be surprised, actually. :p

>> I would rather have configurability here than and endless stream of
>> patches to grow a possibly boundless list...
>
> Configurability is at least as expensive to maintain as a (not actually
> endless) short stream of patches, but i understand different people have
> different tradeoffs they're willing to make.
>
> Can you suggest which kind of configurability you would prefer: complete
> override, or differential modification?  And if so, why do you prefer it
> over the other choice?  or should there be both?

I have no idea, to be honest. But it's something I banged my head a few
times against in notmuch and I would hate to have to recompile the
entire thing to fix this on a local copy.

a.

-- 
The idea that Bill Gates has appeared like a knight in shining armour to
lead all customers out of a mire of technological chaos neatly ignores
the fact that it was he who, by peddling second-rate technology, led
them into it in the first place. - Douglas Adams (1952-2001)
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] Add --message-headers flag to notmuch-show

[Antoine Beaupré]

On 2019-11-11 10:39:11, Daniel Kahn Gillmor wrote:
> On Mon 2019-11-11 10:26:18 -0500, Daniel Kahn Gillmor wrote:
>>  - What is the specific use case for this? For example, can you identify
>>situations where different headers need to be emitted by different
>>users?  Even one motivating example would help others on this list
>>understand why they might want to care :)
>
> ah, sorry, i've just read id:20191109221358.4349-1-johan.pa...@gmail.com
> and its associated messages, so i can see that some of the questions i'm
> asking are already under discussion.
>
> I see that you just want user-agent and x-mailer for your own purposes.
>
> Maybe it would be worthwhile to propose that narrow, limited change as a
> simple patch, without configurability and see what it looks like?  I
> would personally be more likely to advocate for merging a patch that
> meets the specific needs of a notmuch user, and increase the
> configurability surface of notmuch.
>
> If processing a couple of extra headers on a long thread is too
> expensive for some consumer, i'd suggest that is an optimization for the
> consumer to tackle.

They need User-Agent:, I want Archive-At:, they will want
X-Mailer... when is it going to stop? I would rather have
configurability here than and endless stream of patches to grow a
possibly boundless list...

a.

-- 
Brief is this existence, as a fleeting visit in a strange house.
The path to be pursued is poorly lit by a flickering consciousness.
   - Albert Einstein

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: Debian packaging cleanup

[Antoine Beaupré]

On 2019-11-10 12:37:42, Daniel Kahn Gillmor wrote:
> This series offers a set of simple and small changes to the debian
> packaging for notmuch.  they apply to the master branch.
>
> I've reviewed these changes, and tested a build with them with no
> problems.
>
> A modern, canonicalized debian package is easier to work with.
>
> Please consider applying these changes!  If you're uncomfortable with
> any of them, I'm happy to hear feedback.

Looks good to me.

-- 
The history of any one part of the earth, like the life of a soldier,
consists of long periods of boredom and short periods of terror.
   - British geologist Derek V. Ager

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

RFC: desktop entry for xdg-email

[Antoine Beaupré]

On my system, if I click on mailto: links in my web browser (yes, those
still exist), Thunderbird starts up. Oh the horror!

Wouldn't it be nice if notmuch-emacs-mua would start instead?

Worry not my notmuch friends! I have a solution for you!11!!!

First, you need to drop something like this in 
/usr/share/applications/notmuch-emacs-mua.desktop

[Desktop Entry]
Categories=Office;Network;Email;
Comment=Notmuch mail
Exec=notmuch-emacs-mua --client --create-frame --auto-daemon %u
Name=notmuch-emacs-mua
MimeType=x-scheme-handler/mailto;
Type=Application

Liberally inspired by mutt.desktop and probably horribly wrong in many
ways:

 * missing an icon (do we ship one of those?)
 * doesn't handle message/rfc822something (a job for
   notmuch-slurp-something?)
 * might hurt your cat (poor tokenized thing)
 * do you like .INI files? me neither!
 * what the heck is that thing anyways and how do I include that in a
   Debian package?

I know right? It's great. Once you have figured out all that good stuff,
the next step is to hook that up in your web browser. You will be happy
to know there is a "standard" (as in "it starts with X so it *must* be
cool because mutants are cool") that defines how that work, from the
"Cross Desktop Group"

https://specifications.freedesktop.org/mime-apps-spec/latest/index.html

(The "Cross" in this context probably refers to:

 11. Hence: A mixing of breeds or stock, especially in cattle
 breeding; or the product of such intermixture; a hybrid
 of any kind.

... and obviously not:

 1. A gibbet, consisting of two pieces of timber placed
transversely upon one another, in various forms, as a T,
or +, with the horizontal piece below the upper end of the
upright, or as an X. It was anciently used in the
execution of criminals.

... and probably not:

 3. Affiction regarded as a test of patience or virtue; trial;
disappointment; opposition; misfortune.

... anyways, I disgress.)

Apparently, to figure out the current setting, you (obviously) will need
to run something like this:

xdg-mime query default x-scheme-handler/mailto

It will probably not show you notmuch. Sad face. At that point, you will
probably launch whatever control panel, dashboard, settings app,
resource editor, or whatever that thing is called these days, and set
your prefered app. If you are an old obstinate grumpy graybeard like me
that refuse any sort of progress and is stuck in a mostly black and
white "GUI" full of text that no one understands, you know everyone
fundamentally hates each other and the world is pain, so *obviously* you
will need to edit another text file to make the above behave.

So head over your favorite text editor (let's not discuss that further
shall we) to .config/mimeapps.list and add a line like this:

x-scheme-handler/mailto=notmuch-emacs-mua.desktop

You'll note the file probably already exists if you use any modern web
browser because those folks *love* to fight with each other (told you,
hate, hate everywhere) for supremacy over that file. Just add that line
somewhere meaningful until `xdg-email` and the above `xdg-mime` query
works correctly.

Then you can thank me the next (last?) time you ever encounter a mailto:
link. It's going to be a funny surprise!

Oh, and the next time you find a contact form to send email, just fax
bomb it or something.

Have a good weekend.

A.

PS: I tried to make this one entertaining, sorry if it's a bit long or
offensive to some, let me know if I went too far. :)

-- 
Perl is "some assembly required". Python is "batteries included". PHP
is "kitchen sink, but it’s from Canada and both faucets are labeled C".
 - Alex Munroe, PHP: a fractal of bad design
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: how do i split my email view (AKA I got a new job)

[Antoine Beaupré]

On 2019-03-10 17:54:54, Ralph Seichter wrote:
> * Antoine Beaupré:
>
>> How can I make that "All tags" junk disappear?
>
> If it bugs you that much, you can use the "this page" link in "Customize
> Notmuch or this page".

Ooooh... I remember now! I digged in the source last time we chatted
about this in #notmuch. I did so again and found what I was looking for:

(setq notmuch-hello-tag-list-make-query "tag:unread and not tag:work")

Now I need to figure out how to make schedules in Emacs... :) It looks
like I need to do something with `run-at-time' or something to that
effect:

https://www.gnu.org/software/emacs/manual/html_node/elisp/Timers.html#Timers

I also found out about the "midnight" mode, but that seems to support
only a single time trigger:

https://www.emacswiki.org/emacs/MidnightMode

I also found idle timers, but that seems irrelevant:

https://www.emacswiki.org/emacs/IdleTimers#toc2

Anyone else played with scheduling like this?

In any case, I guess just having a defun that flips that around would be
a good start. :) I'm thinking of something like:

(defun anarcat/notmuch-work-off ()
  (interactive)
  (setq notmuch-hello-tag-list-make-query "tag:unread and not tag:work")
  (notmuch-refresh-this-buffer))

(defun anarcat/notmuch-work-on ()
  (interactive)
  (setq notmuch-hello-tag-list-make-query "tag:unread")
  (notmuch-refresh-this-buffer))

That's actually two defun - and it looks rather silly, mayb there's a
way to make that a toggle somehow?

Anyways, does that look sane?

A.

-- 
When spider webs unite, they can tie up a lion.
- ethiopian proverb
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

how do i split my email view (AKA I got a new job)

[Antoine Beaupré]

Hello!

So I got a new job, and that means I have a new email address that
forwards to my regular mail spool. *Normally*, all that junk should end
up in a separate folder so I am tagging it all as "+work" (there are
quite a few corner cases which I handle individually, but from here on
we can assume there's a single tag to identify all that mail).

How do I stay sane during the weekends? There's a *lot* of junk coming
in that's polluting my "notmuch-hello" view. Here's a "screenshot":

   Welcome to notmuch. You have 188 359 messages.

Saved searches: [edit]

  67 inbox259 sent   3 drafts 2 todo

Search: 
  .

All tags: [hide]

   1 attachment   27 logwatch  3 
work-project
  72 commit   13 nagios9 work-admin
  17 cron124 rapports  3 trac
  16 lists   147 work151 unread

  Hit `?' for context-sensitive help in any Notmuch screen.
   Customize Notmuch or this page.

How can I make that "All tags" junk disappear? Or, more specifically,
how do I make it ignore that crowded "work" tag? Bonus points for
flipping back and forth outside of business hours and weekends. :)

I know I can make a billion saved searches to cover for all those
cases. But so far I've used a technique where I tag messages instead of
doing saved searches and it serves me well.

Thanks!

-- 
The most prudent course for any society is to start from the
assumption that the Internet should be fundamentally outside the
domain of capital.
- The Internet's Unholy Marriage to Capitalism
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: non-ascii email forwarding failures

[Antoine Beaupré]

On 2019-02-26 10:56:34, David Edmondson wrote:
> On Tuesday, 2019-02-26 at 00:33:33 -05, Antoine Beaupré wrote:
>
>> So I have no idea what's going on with mail forwards, but this is the
>> kind of stuff that happens to me all the time and I can't describe
>> correctly enough to file a bug.
>>
>> The gist of it is that, under some weird circumstances, notmuch-emacs
>> (message-mode.el?) will screw up email forwards in a big time. I just
>> forwarded (or did I just reply? not sure) that private email to the list
>> to trigger that bug...
>>
>> I get that from time to time. I think the key is that it's an email I
>> *sent* not *received*, which are somewhat different in their storage
>> mechanism...
>>
>> The first symptom will be that, when sending, I'd get a prompt like
>> this:
>>
>> Non-printable characters found.  Continue sending? (delete, replace, send, 
>> edit, ?): 
>
> After looking at something related but not the same, I ended up with:
>
>  ;; Do forward as MIME (the default), but don't show me the
>  ;; MML.
>  ;;
>  ;; Showing the MML causes decoding and recoding problems, where the
>  ;; headers of an message/rfc822 part end up being very long and
>  ;; opensmtpd decides to wrap them via QP encoding. Unfortunately it
>  ;; QP encodes the MIME separators as well. No idea who is actually in
>  ;; the wrong here, but this fixes it so far.
>  message-forward-as-mime t

I have that same setting here...

>  message-forward-show-mml nil

... but this is set to "best". Setting it to "nil" might solve some of
the problems I'm seeing (specifically with forwarding) but do note the
same problems occur when I reply to an email that has a patch with my
last name in it. For example this message construct will yield the same
error as described earlier because the attached patch has "Beaupré" in
it which will freak out message-mode (or whatever is going on here).

Content-Type: multipart/mixed;
boundary="_004_eb33b55506b743279ad0320cb4a1f036XBOX01axiscom_"
MIME-Version: 1.0
--_004_eb33b55506b743279ad0320cb4a1f036XBOX01axiscom_
Content-Type: multipart/alternative;
boundary="_000_eb33b55506b743279ad0320cb4a1f036XBOX01axiscom_"

--_000_eb33b55506b743279ad0320cb4a1f036XBOX01axiscom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Salut Antoine,

[...]

--_000_eb33b55506b743279ad0320cb4a1f036XBOX01axiscom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

[...]
--_000_eb33b55506b743279ad0320cb4a1f036XBOX01axiscom_--

--_004_eb33b55506b743279ad0320cb4a1f036XBOX01axiscom_
Content-Type: application/octet-stream; name="CVE-2018-16864.patch"
Content-Description: CVE-2018-16864.patch
Content-Disposition: attachment; filename="CVE-2018-16864.patch"; size=1796;
creation-date="Tue, 26 Feb 2019 13:23:19 GMT";
modification-date="Tue, 26 Feb 2019 13:23:19 GMT"
Content-Transfer-Encoding: base64

RGVzY3JpcHRpb246IGpvdXJuYWxkOiBkbyBub3Qgc3RvcmUgdGhlIGlvdmVjIGVudHJ5IGZvciBw
cm9jZXNzIGNvbW1hbmRsaW5lIG9uIHN0YWNrCiBUaGlzIGZpeGVzIGEgY3Jhc2ggKENWRS0yMDE4
LTE2ODY0KSB3aGVyZSB3ZQogd291bGQgcmVhZCB0aGUgY29tbWFuZGxpbmUsIHdob3NlIGxlbmd0
aCBpcyB1bmRlciBjb250cm9sIG9mIHRoZQogc2VuZGluZyBwcm9ncmFtLCBhbmQgdGhlbiBjcmFz
aCB3aGVuIHRyeWluZyB0byBjcmVhdGUgYSBzdGFjawogYWxsb2NhdGlvbiBmb3IgaXQuCiAuCiBU
aGlzIGlzIGEgYmFja3BvcnQgb2YgaHR0cHM6Ly9naXRodWIuY29tL3N5c3RlbWQvc3lzdGVtZC9j
b21taXQvMDg0ZWViODY1Y2E2Mzg4NzA5OGUwOTQ1ZmI0ZTkzYzg1MmI5MWIwZgpBdXRob3I6IEFu
dG9pbmUgQmVhdXByw6kgPGFuYXJjYXRAZGViaWFuLm9yZz4KQnVnLURlYmlhbjogaHR0cHM6Ly9i
dWdzLmRlYmlhbi5vcmcvOTE4ODQxCk9yaWdpbjogRGViaWFuCkJ1ZzogaHR0cHM6Ly9idWd6aWxs
YS5yZWRoYXQuY29tL3Nob3dfYnVnLmNnaT9pZD0xNjUzODU1CkZvcndhcmRlZDogbm90LW5lZWRl
ZApMYXN0LVVwZGF0ZTogMjAxOS0wMS0yMgoKLS0tIHN5c3RlbWQtMjE1Lm9yaWcvc3JjL2pvdXJu
YWwvam91cm5hbGQtc2VydmVyLmMKKysrIHN5c3RlbWQtMjE1L3NyYy9qb3VybmFsL2pvdXJuYWxk
LXNlcnZlci5jCkBAIC02MDIsNyArNjAyLDEwIEBAIHN0YXRpYyB2b2lkIGRpc3BhdGNoX21lc3Nh
Z2VfcmVhbCgKIAogICAgICAgICAgICAgICAgIHIgPSBnZXRfcHJvY2Vzc19jbWRsaW5lKHVjcmVk
LT5waWQsIDAsIGZhbHNlLCAmdCk7CiAgICAgICAgICAgICAgICAgaWYgKHIgPj0gMCkgewotICAg
ICAgICAgICAgICAgICAgICAgICAgeCA9IHN0cmFwcGVuZGEoIl9DTURMSU5FPSIsIHQpOworICAg
ICAgICAgICAgICAgICAgICAgICAgLyogQXQgbW9zdCBfU0NfQVJHX01BWCAoMk1CIHVzdWFsbHkp
LCB3aGljaCBpcworICAgICAgICAgICAgICAgICAgICAgICAgICogdG9vIG11Y2ggdG8gcHV0IG9u
IHN0YWNrLiBMZXQncyB1c2UgYSBoZWFwCisgICAgICAgICAgICAgICAgICAgICAgICAgKiBhbGxv
Y2F0aW9uIGZvciB0aGlzIG9uZS4gKi8gCisgICAgICAgICAgICAgICAgICAgICAgICB4ID0gc3Ry
YXBwZW5kKCJfQ01ETElORT0iLCB0KTsKICAgICAgICAgICAgICAgICAgICAgICAgIGZyZWUodCk7
CiAgICAgICAgICAgICAgICAgICAgICAgICBJT1ZFQ19TRVRfU1RSSU5HKGlvdmVjW24rK10sIHgp
OwogICAgICAgICAgICAgICAgIH0KQEAgLTcxNiw3ICs3

Re: non-ascii email forwarding failures

[Antoine Beaupré]

On 2019-02-26 00:56:53, Daniel Kahn Gillmor wrote:
> On Tue 2019-02-26 00:33:33 -0500, Antoine Beaupré wrote:
>> Message contains characters with unknown encoding.  Really send? (y or n) y
>> Use ASCII as charset? (y or n) y
>
> The right answer in 2019 is to use UTF-8 as a charset, everywhere.  How
> to convince message mode to do that, i don't know.
>
> Presumably your locale is configured as $something.UTF-8 (fr_CA.UTF-8
> perhaps?).

It is.

> Maybe there's some other setting that would also be useful,
> though.  hopefully someone with deeper emacs-fu can weigh in here.

I have no idea. :)

a.

-- 
Non qui parum habet, sed qui plus cupit, pauper est.
It is not the man who has too little, but the man who craves more,
that is poor.- Lucius Annaeus Seneca (65 AD)
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

non-ascii email forwarding failures

[Antoine Beaupré]

On 2019-02-25 18:15:21, Daniel Kahn Gillmor wrote:
> On Mon 2019-02-25 18:01:55 -0500, Antoine Beaupré wrote:
>> I seem to have forgotten to CC the list in my reply, sorry for the
>> noise.
>>
>> I elided the attachment here because I sent a newer version in
>> 87r2bvjx02@curie.anarc.at.
>
> thanks!
>
>> On 2019-02-25 17:11:26, Antoine Beaupr wrote:
>
> Interesting, your MUA is relying on the default charset=iso-8859-1
> (latin-1) or is it charset=iso-8859-15 (latin-7)?
>
> it's sending me octal 0o351 as the last letter of your last name, which
> my notmuch-emacs renders as a raw octet ("Beaupr\351"), maybe because
> i'm in a UTF-8 locale?
>
> wtf, why are we still failing at this in 2019, with updated MUAs?  i
> guess it might be my own fault for having this line in my
> custom-set-variables in ~/.emacs:
>
> '(message-default-charset (quote utf-8))
>
> but the docs for message-default-charset say:
>
>   This variable is obsolete since 26.1;
>   The default charset comes from the language environment
>
> shouldn't emacs mml mode explicitly mark the charset in the Content-Type
> header when generating a text/plain part no matter what?

So I have no idea what's going on with mail forwards, but this is the
kind of stuff that happens to me all the time and I can't describe
correctly enough to file a bug.

The gist of it is that, under some weird circumstances, notmuch-emacs
(message-mode.el?) will screw up email forwards in a big time. I just
forwarded (or did I just reply? not sure) that private email to the list
to trigger that bug...

I get that from time to time. I think the key is that it's an email I
*sent* not *received*, which are somewhat different in their storage
mechanism...

The first symptom will be that, when sending, I'd get a prompt like
this:

Non-printable characters found.  Continue sending? (delete, replace, send, 
edit, ?): 

I never know what to answer to that, i usually just hit "send" or
"PLOKTA". Then I get two more annoying prompts, just to make sure I
really know about the bug. It also reminds me of how I speak a weird
language with weird characters and I don't belong on the american
Internet (capital I):

Message contains characters with unknown encoding.  Really send? (y or n) y
Use ASCII as charset? (y or n) y

ASSCII indeed. Anyways, what you saw is the result of that *amazing*
user experience.

I wish I knew how to fix that or make that more useful to folks who have
more of a clue than me. ;)

(and sorry for the cussin'...)

A.

-- 
Man really attains the state of complete humanity when he produces,
without being forced by physical need to sell himself as a commodity.
- Ernesto "Che" Guevara
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: How old a version of xapian should notmuch support?

[Antoine Beaupré]

On 2018-09-10 20:54:11, David Bremner wrote:
> Antoine Beaupre  writes:
>
>>
>> There are other and better CI systems out there, in case Notmuch is
>> stuck in Travis-land. I have had good experiences working with GitLab CI
>> which is based on a slightly saner approach: it uses Docker containers
>> as a base, so you can run any base system you want. You can also supply
>> your own physical machines as runners for the CI system if you're not
>> happy with the provided options.
>>
>
> Well, we had a buildbot installation, which was nice enough, but the
> volunteer who ran it moved on to other things. Travis mainly has the
> advantage that I don't have to maintain it. Well, except for patching
> notmuch to work on it, which hasn't been too heinous so far.

Well, GitLab CI runs on its own as well. You don't *have* to provide a
runner. :)

A.

-- 
Au nom de l'état, la force s'appelle droit.
Au main de l'individu, elle s'appelle crime.
- Max Stirner
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 1/1] RFC: add attachment checks

[Antoine Beaupré]

On 2018-09-07 10:14:46, David Edmondson wrote:
> Antoine, are you happy to have this marked as super-ceded by
> id:20180906181456.21719-2-...@dme.org?

Absolutely.

-- 
Cyberspace. A consensual hallucination experienced daily by billions
of legitimate operators, in every nation, by children being taught
mathematical concepts...
   - William Gibson
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 1/1] RFC: add attachment checks

[Antoine Beaupré]

On 2018-09-04 17:39:31, David Edmondson wrote:
> On Tuesday, 2018-09-04 at 12:07:01 -04, Antoine Beaupré wrote:
>
>> On 2018-09-04 16:42:07, David Edmondson wrote:
>>> Here is my version of this, updated to use your regexp. I actually
>>> stopped using this because I was annoyed by the question too many
>>> times...
>>
>> That does look prettier than my version - i didn't know about
>> message-goto-body. Should I reroll with yours?
>
> Are you planning to write a test? I could have a go at that, but it
> probably won't be today.

That's my big blocker, really. I have no idea where to begin, as I
explained. So I'd be happy to leave that to someone else...

A.

-- 
"Faith" means not wanting to know what is true.
 - Friedrich Nietzshe
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 1/1] RFC: add attachment checks

[Antoine Beaupré]

On 2018-09-04 16:42:07, David Edmondson wrote:
> Here is my version of this, updated to use your regexp. I actually
> stopped using this because I was annoyed by the question too many
> times...

That does look prettier than my version - i didn't know about
message-goto-body. Should I reroll with yours?

a.

-- 
The lazy man does not stand in the way of progress. When he sees
progress roaring down upon him he steps nimbly out of the way
 - Christopher Morley, "On Laziness"
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: feature request: fetch missing keys in the background

[Antoine Beaupré]

On 2018-09-04 14:39:57, David Edmondson wrote:
> On Tuesday, 2018-09-04 at 09:34:02 -04, Antoine Beaupré wrote:
>
>> On 2018-09-04 14:32:16, David Edmondson wrote:
>>> On Monday, 2018-09-03 at 15:49:09 -04, Antoine Beaupré wrote:
>>>
>>>> That's great! It's basically what I was looking for, but unfortunately
>>>> it does not work here. I am not sure why, but it never actually updates
>>>> the widget, even if I do not move the point.
>>>
>>> That's odd. Forcing the connection type to 'pipe improves things on
>>> macOS, but I figured that you were using Linux.
>>>
>>> Could you test the patch that I posted and see if it works better?
>>
>> Err... That *was* with the new patch in 
>> cunwos2xx33@disaster-area.hh.sledj.net
>>
>> Did i miss something?
>
> I just sent another set.

Ah yes, in another thread.. I'm not on the list so I missed that,
sorry. :)

So I tried that and it works, if I really don't touch anything. It's
certainly an improvement over the previous behavior. Once the "message"
is gone (ie. as soon as anything else is done in Emacs), it's a little
hard to figure out what is happening without going through the status
buffer.

Maybe that's fine, but it would be nice if the button would immediately
update with that status. For example, the text could change to
"... updating" or something. Of course, we're back to the same place
that it can't be updated without shuffling the buffer around if the
point moved, but at least the UI would "remember" there was some change
in the status (it's not just "Failure" but "We're working on it").

I also quite like the changes to the *..-gpg-out* buffer: it's a little
more readable than it was before.

Anyways, as is, I think it's a great improvement already and would
recommend this for merging.

A.

PS: As it turns out, I had a lot of trouble importing those patches. I
tried first to download the 2018 archive from here:

https://notmuchmail.org/pipermail/notmuch/2018.txt.gz

I tried converting this to a maildir and move it to ~/Maildir/.notmuch/
with spwhitton's mailscripts:

mbox2maildir notmuch-2018.txt notmuch-2018
mdmv notmuch-2018/*/* ~/Maildir/.notmuch/
notmuch new

But the last command did not find any new messages, which left me quite
puzzled. The same thing occured with the full archive at:

https://notmuchmail.org/archives/notmuch.mbox

So I am not sure what I was doing wrong there... I ended up using mutt
(bleeergh! ;)) to extract the patchset...

-- 
We will create a civilization of the Mind in Cyberspace. May it be
more humane and fair than the world your governments have made
before.
 - John Perry Barlow
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: feature request: fetch missing keys in the background

[Antoine Beaupré]

On 2018-09-04 14:32:16, David Edmondson wrote:
> On Monday, 2018-09-03 at 15:49:09 -04, Antoine Beaupré wrote:
>
>> That's great! It's basically what I was looking for, but unfortunately
>> it does not work here. I am not sure why, but it never actually updates
>> the widget, even if I do not move the point.
>
> That's odd. Forcing the connection type to 'pipe improves things on
> macOS, but I figured that you were using Linux.
>
> Could you test the patch that I posted and see if it works better?

Err... That *was* with the new patch in 
cunwos2xx33@disaster-area.hh.sledj.net

Did i miss something?

-- 
Lorsque l'on range des objets dans des tiroirs, et que l'on a plus
d'objets que de tiroirs, alors un tiroir au moins contient deux
objets.
- Lejeune-Dirichlet, Peter Gustav
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

[PATCH 0/1] RFC: add attachment checks

[Antoine Beaupré]

This is a re-issue of my "attachment checks" patch, which failed to
raise comments or interest in its last round. I'm resubmitting it in
the hope it will fare better this time around.

This code is working: I use it daily and never worry about missing
attachments anymore. It did catch a few occurences but also a few
false positives, which I did not mind.

There are still no unit tests: bremner suggested I add some in
test/T310-emacs.sh and I looked there briefly, but couldn't figure out
where to add a blurb. I would need help to complete this.

I did some summary tests using `re-builder' to see the effect the
regex has on random strings. I tested the possible false positive "a
joint attaché presse" which doesn't match and "here is an attachment,
attached in the pièce jointe or piece jointe" which does. I am not
sure how to implement this in a unit test: should we try to send an
email and check if it aborts like the "Sending a message via (fake)
SMTP" test? Or should I just check that `notmuch-message-check-attach'
works against a temporary buffer? Is there a harness that allows
matching against messages like that already?

I'd also welcome comments on the approach in general. Another user
came up on IRC recently (impatkor) with the same need and used the
following snippet instead:

https://pastebin.com/N9ku3DBD

It is a very similar implementation although it checks for
`Content-Disposition: attachment` instead of `<#part>`: not sure which
one is actually accurate. It also adds the word `bifoga` as a pattern,
but I haven't verified that in swedish and would wait for feedback on
the multilingual approach before adding new words here.

Finally, note that an earlier version of this used
`save-mark-and-excursion` but I had to revert back to `save-excursion`
because the function was missing in some other version of Emacs I was
testing. That part does not work anyways: something else is moving the
mark around when sending, but I figured I would keep this hook
well-behaving even if others screw that up. I did remove the "XXX"
note there because there's nothing else to do on that front.

Antoine Beaupré (1):
  RFC: add attachment checks

 emacs/notmuch-message.el | 37 +
 1 file changed, 37 insertions(+)

-- 
2.18.0

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

[PATCH 1/1] RFC: add attachment checks

[Antoine Beaupré]

This implements basic attachment checks like those present in other
MUAs (e.g. Thunderbird, IIRC). A hook watches for keywords implemented
using a customizable regex. The keywords are assume to indicate the
user forgot to add an attachment.

This currently checks for words in english and french and some care
was taken to avoid false positive, but those are bound to happen and
we embrace them with open arms: it's better to warn by mistake than
forget an attachment ever again. New languages can be added through
customization, which help string suggests contributing it back to the
community.

---
 emacs/notmuch-message.el | 37 +
 1 file changed, 37 insertions(+)

diff --git a/emacs/notmuch-message.el b/emacs/notmuch-message.el
index 55e4cfee..ccf0906c 100644
--- a/emacs/notmuch-message.el
+++ b/emacs/notmuch-message.el
@@ -47,6 +47,43 @@ the \"inbox\" and \"todo\" tags, you would set:
 
 (add-hook 'message-send-hook 'notmuch-message-mark-replied)
 
+;; attachment checks
+;;
+;; should be sent upstream, but needs unit tests in test/T310-emacs.sh
+(defcustom notmuch-message-attach-regex
+  "\\b\\(attache\?ment\\|attached\\|attach\\|pi[èe]ce\s+jointe?\\)\\b"
+  "Pattern of text announcing there should be an attachment.
+
+This is used by `notmuch-message-check-attach' to check email
+bodies for words that might indicate the email should have an
+attachement. If the pattern matches and there is no attachment (a
+`<#part ...>' magic block), notmuch will show a confirmation
+prompt before sending the email.
+
+The default regular expression is deliberately liberal: we prefer
+false positive than forgotten attachments. This should be
+customized for non-english languages and notmuch welcomes
+additions to the pattern for your native language, unless it
+conflicts with common words in other languages."
+  :type '(regexp)
+  :group 'notmuch-send)
+
+(defun notmuch-message-check-attach ()
+  """Check for missing attachments.
+
+This is normally added to `message-send-hook' and is configured
+through `notmuch-message-attach-regex'."""
+  (save-excursion
+(goto-char (point-min))
+(if (re-search-forward notmuch-message-attach-regex nil t)
+(progn
+  (goto-char (point-min))
+  (unless (re-search-forward "<#part [^>]*filename=[^>]*>" nil t)
+(or (y-or-n-p "Email seem to refer to attachment, but nothing 
attached, send anyways?")
+(error "No attachment found, aborting")))
+
+(add-hook 'message-send-hook 'notmuch-message-check-attach)
+
 (provide 'notmuch-message)
 
 ;;; notmuch-message.el ends here
-- 
2.18.0

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

PATCH: fetch missing keys in the background

[Antoine Beaupré]

On 2018-09-03 18:21:32, David Edmondson wrote:
> How about this patch?
>
> You'll need to set “notmuch-crypto-get-keys-asynchronously” to “t” to
> see any benefit.

This is great!

As you said on IRC, the patch is more likely:

diff --git i/emacs/notmuch-crypto.el w/emacs/notmuch-crypto.el
index fc2b5301..175dc5f2 100644
--- i/emacs/notmuch-crypto.el
+++ w/emacs/notmuch-crypto.el
@@ -43,6 +43,18 @@ mode."
   :package-version '(notmuch . "0.25")
   :group 'notmuch-crypto)
 
+(defcustom notmuch-crypto-get-keys-asynchronously nil
+  "Retrieve gpg keys asynchronously.
+
+If this variable is non-nil, hitting the crypto button will
+trigger network operations in the background. This will also have
+the effect of disabling the automatic refresh on completion. Keep
+this set to nil to make sure the button display is up to date,
+but this will freeze everything until the crypto operation is
+completed, which can take a long time for larger keyrings."
+  :type 'boolean
+  :group 'notmuch-crypto)
+
 (defface notmuch-crypto-part-header
   'class color)
   (background dark))
@@ -145,19 +157,35 @@ mode."
 	(call-process epg-gpg-program nil t t "--list-keys" fingerprint))
   (recenter -1
 
+(defun notmuch-crypto--async-key-sentinel (process event)
+  (let ((status (process-status process))
+	(exit-status (process-exit-status process)))
+(when (memq status '(exit signal))
+  (message "Asynchronous GPG key retrieval %s."
+	   (if (= exit-status 0)
+		   "completed"
+		 "failed")
+
 (defun notmuch-crypto-sigstatus-error-callback (button)
   (let* ((sigstatus (button-get button :notmuch-sigstatus))
 	 (keyid (concat "0x" (plist-get sigstatus :keyid)))
-	 (buffer (get-buffer-create "*notmuch-crypto-gpg-out*"))
-	 (window (display-buffer buffer t nil)))
-(with-selected-window window
-  (with-current-buffer buffer
-	(goto-char (point-max))
-	(call-process epg-gpg-program nil t t "--recv-keys" keyid)
-	(insert "\n")
-	(call-process epg-gpg-program nil t t "--list-keys" keyid))
-  (recenter -1))
-(notmuch-show-refresh-view)))
+	 (buffer (get-buffer-create "*notmuch-crypto-gpg-out*")))
+(if notmuch-crypto-get-keys-asynchronously
+	(progn
+	  (message "Getting the GPG key %s asynchronously..." keyid)
+	  (make-process :name "notmuch GPG key retrieval"
+		   :buffer buffer
+		   :command (list epg-gpg-program "--recv-keys" keyid)
+		   :sentinel #'notmuch-crypto--async-key-sentinel))
+  (let ((window (display-buffer buffer t nil)))
+	(with-selected-window window
+	  (with-current-buffer buffer
+	(goto-char (point-max))
+	(call-process epg-gpg-program nil t t "--recv-keys" keyid)
+	(insert "\n")
+	(call-process epg-gpg-program nil t t "--list-keys" keyid))
+	  (recenter -1))
+	(notmuch-show-refresh-view)
 
 (defun notmuch-crypto-insert-encstatus-button (encstatus)
   (let* ((status (plist-get encstatus :status))

One thing that's missing is to refresh the view automatically. I
understand this might be difficult to implement however. For example, I
naively tried to add this at the end of the sentinel:

  (when (= exit-status 0)
(notmuch-show-refresh-view))

Then switch to another buffer (back to the search view, FWIW). The
sentinel then fails with:

error in process sentinel: notmuch-escape-boolean-term: Wrong type argument: 
stringp, nil
error in process sentinel: Wrong type argument: stringp, nil

Not sure why exactly. But I would certainly take the async update over
automatic refresh any time. It would also be useful to indicate that
will be the effect of the variable in the customize help as well. I gave
that a try in the above patch.

Thanks for the ultra-fast response!

A.

-- 
The United States is a nation of laws:
badly written and randomly enforced.
- Frank Zappa
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: feature request: fetch missing keys in the background

[Antoine Beaupré]

On 2018-09-03 17:46:00, David Edmondson wrote:

[...]

> I'm puzzled about the currently expected behaviour based on your
> question.

[...]

> Enabling “auto-key-retrieve” changes this behaviour, as you would expect
> (I see a delay opening the message while the key is retrieved, and then
> the button shows it as good).

The current behavior is somewhat expected: I'm happy notmuch fetches the
keys on click. The problem is it takes forever (that's GPG's fault) and
that Emacs freezes while it happens (that's Notmuch's fault).

> (Caveat: I'm using “remote-notmuch”, so emacs and notmuch/gpg are on
> different machines, but I don't know that this changes any of the
> above.)

I'm not sure either.

A.
-- 
If I can't dance, I don't want to be part of your revolution.
- Emma Goldman
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

feature request: fetch missing keys in the background

[Antoine Beaupré]

Hi!

Because I have a rather large keyring, fetching new keys or refreshing
old ones takes a long time. When I click on the red red button saying
"Unknown key ID [...] or unsupported algorithm", Emacs freezes for a
good 90 seconds. Considering I use that editor^Wvirtual machine for
nearly everything, it's quite annoying and sends me off browsing the web
in Firefox forever. I end up having a horde of shaven yaks and then
finally remember that I had that key update, by which time I had
forgotten what I was doing reading email in the first place, let alone
what I was doing *before* opening my inbox...

So. It would be great if Notmuch would run those key updates
asynchronously. I am not sure how that would work: as Bremner said on
IRC, it might make it difficult to update the button automatically. But
I don't mind that: I can refresh the page myself. He suggested running
things in the background when clicking with a prefix (C-u?) but I would
argue that freezing Emacs is just a no-no in general.

I couldn't find directly what function was called behind that button:
"C-h k" just says it's, obviously, `push-button'. Bremner says it might
be `notmuch-crypto-sigstatus-good-callback' which looks reasonable. I'm
only a junior elisp programmer, but it seems to me the
`notmuch-show-refresh-view' call there could be an asynchronous callback
to an async `make-process' call, as opposed to `call-process', which is
synchronous.

But I'd like others to chime in here: is this something that would be
accepted? Would the above work?

A.

-- 
If quantum mechanics hasn't profoundly shocked you, you haven't
understood it yet.
   - Niels Bohr
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] WIP: add attachment checks

[Antoine Beaupré]

This implements basic attachment checks like those present in other
MUAs (e.g. Thunderbird, IIRC). A hook watches for keywords, which are
implemented using a customizable regex, that indicate the user might
have wanted to include an attachement while writing the email, but has
forgotten.

We currently check for words in english and french and some care was
taken to avoid false positive, but those are bound to happen and we
embrace them with open arms: it's better to warn by mistake than
forget an attachment ever again. New languages can be added through
customization, which help string suggests contributing it back to the
community here. I am not sure this is the best way, but I'm unfamiliar
with Notmuch's translation system (if any).

This code is working: I use it daily and never worry about missing
attachments anymore (mostly because I'm always *thinking* about
putting the attachment because I want this script to trigger, so I
never forget attachments anymore). However there are no unit tests:
bremner suggested I add some in test/T310-emacs.sh and I looked there
briefly, but couldn't figure out where to add a blurb.

I did some summary tests using `re-builder' to see the effect the
regex has on random strings. I tested the possible false positive "a
joint attaché presse" which doesn't match and "here is an attachment,
attached in the pièce jointe or piece jointe" which does. I am not
sure how to implement this in a unit test: should we try to send an
email and check if it aborts like the "Sending a message via (fake)
SMTP" test? Or should I just check that `notmuch-message-check-attach'
works against a temporary buffer? Is there a hardness that allows
matching against messages like that already?

I'd also welcome comments on the approach in general. Another user
came up on IRC recently (impatkor) with the same need and used the
following snippet instead:

https://pastebin.com/N9ku3DBD

It is a very similar implementation although it checks for
`Content-Disposition: attachment` instead of `<#part>`: not sure which
one is actually accurate. It also adds the word `bifoga` as a pattern,
but I haven't verified that in swedish and would wait for feedback on
the multilingual approach before adding new words here.

Finally, note that an earlier version of this used
`save-mark-and-excursion` but I had to revert back to `save-excursion`
because the function was missing in some other version of Emacs I was
testing. That part does not work anyways: something else is moving the
mark around when sending, but I figured I would keep this hook
well-behaving even if others screw that up.

Oh, and one last thing: this commit log is longer than the patch,
which is probably wrong. Sorry about that. :p
---
 emacs/notmuch-message.el | 37 +
 1 file changed, 37 insertions(+)

diff --git a/emacs/notmuch-message.el b/emacs/notmuch-message.el
index 55e4cfee..60df5498 100644
--- a/emacs/notmuch-message.el
+++ b/emacs/notmuch-message.el
@@ -47,6 +47,43 @@ the \"inbox\" and \"todo\" tags, you would set:
 
 (add-hook 'message-send-hook 'notmuch-message-mark-replied)
 
+;; attachment checks
+;;
+;; should be sent upstream, but needs unit tests in test/T310-emacs.sh
+(defcustom notmuch-message-attach-regex
+  "\\b\\(attache\?ment\\|attached\\|attach\\|pi[èe]ce\s+jointe?\\)\\b"
+  "Pattern of text announcing there should be an attachment.
+
+This is used by `notmuch-message-check-attach' to check email
+bodies for words that might indicate the email should have an
+attachement. If the pattern matches and there is no attachment (a
+`<#part ...>' magic block), notmuch will show a confirmation
+prompt before sending the email.
+
+The default regular expression is deliberately liberal: we prefer
+false positive than forgotten attachments. This should be
+customized for non-english languages and notmuch welcomes
+additions to the pattern for your native language, unless it
+conflicts with common words in other languages."
+  :type '(regexp)
+  :group 'notmuch-send)
+
+(defun notmuch-message-check-attach ()
+  """Check for missing attachments.
+
+This is normally added to `message-send-hook' and is configured
+through `notmuch-message-attach-regex'."""
+  (save-excursion ;; XXX: this fails somehow: point is at the end of the 
buffer on error
+(goto-char (point-min))
+(if (re-search-forward notmuch-message-attach-regex nil t)
+(progn
+  (goto-char (point-min))
+  (unless (re-search-forward "<#part [^>]*filename=[^>]*>" nil t)
+(or (y-or-n-p "Email seem to refer to attachment, but nothing 
attached, send anyways?")
+(error "No attachment found, aborting")))
+
+(add-hook 'message-send-hook 'notmuch-message-check-attach)
+
 (provide 'notmuch-message)
 
 ;;; notmuch-message.el ends here
-- 
2.11.0

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] WIP: add attachment checks

[Antoine Beaupré]

This implements basic attachment checks like those present in other
MUAs (e.g. Thunderbird, IIRC). A hook watches for keywords, which are
implemented using a customizable regex, that indicate the user might
have wanted to include an attachement while writing the email, but has
forgotten.

We currently check for words in english and french and some care was
taken to avoid false positive, but those are bound to happen and we
embrace them with open arms: it's better to warn by mistake than
forget an attachment ever again. New languages can be added through
customization, which help string suggests contributing it back to the
community here. I am not sure this is the best way, but I'm unfamiliar
with Notmuch's translation system (if any).

This code is working: I use it daily and never worry about missing
attachments anymore (mostly because I'm always *thinking* about
putting the attachment because I want this script to trigger, so I
never forget attachments anymore). However there are no unit tests:
bremner suggested I add some in test/T310-emacs.sh and I looked there
briefly, but couldn't figure out where to add a blurb.

I did some summary tests using `re-builder' to see the effect the
regex has on random strings. I tested the possible false positive "a
joint attaché presse" which doesn't match and "here is an attachment,
attached in the pièce jointe or piece jointe" which does. I am not
sure how to implement this in a unit test: should we try to send an
email and check if it aborts like the "Sending a message via (fake)
SMTP" test? Or should I just check that `notmuch-message-check-attach'
works against a temporary buffer? Is there a hardness that allows
matching against messages like that already?

I'd also welcome comments on the approach in general. Another user
came up on IRC recently (impatkor) with the same need and used the
following snippet instead:

https://pastebin.com/N9ku3DBD

It is a very similar implementation although it checks for
`Content-Disposition: attachment` instead of `<#part>`: not sure which
one is actually accurate. It also adds the word `bifoga` as a pattern,
but I haven't verified that in swedish and would wait for feedback on
the multilingual approach before adding new words here.

Finally, note that an earlier version of this used
`save-mark-and-excursion` but I had to revert back to `save-excursion`
because the function was missing in some other version of Emacs I was
testing. That part does not work anyways: something else is moving the
mark around when sending, but I figured I would keep this hook
well-behaving even if others screw that up.

Oh, and one last thing: this commit log is longer than the patch,
which is probably wrong. Sorry about that. :p
---
 emacs/notmuch-message.el | 37 +
 1 file changed, 37 insertions(+)

diff --git a/emacs/notmuch-message.el b/emacs/notmuch-message.el
index 55e4cfee..c4e301cc 100644
--- a/emacs/notmuch-message.el
+++ b/emacs/notmuch-message.el
@@ -47,6 +47,43 @@ the \"inbox\" and \"todo\" tags, you would set:
 
 (add-hook 'message-send-hook 'notmuch-message-mark-replied)
 
+;; attachment checks
+;;
+;; should be sent upstream, but needs unit tests in test/T310-emacs.sh
+(defcustom notmuch-message-attach-regex
+  "\\b\\(attache\?ment\\|attached\\|attach\\|pi[èe]ce\s+jointe?\\)\\b"
+  "Pattern of text announcing there should be an attachment.
+
+This is used by `notmuch-message-check-attach' to check email
+bodies for words that might indicate the email should have an
+attachement. If the pattern matches and there is no attachment (a
+`<#part ...>' magic block), notmuch will show a confirmation
+prompt before sending the email.
+
+The default regular expression is deliberately liberal: we prefer
+false positive than forgotten attachments. This should be
+customized for non-english languages and notmuch welcomes
+additions to the pattern for your native language, unless it
+conflicts with common words in other languages."
+  :type '(regexp)
+  :group 'notmuch-send)
+
+(defun notmuch-message-check-attach ()
+  """Check for missing attachments.
+
+This is normally added to `message-send-hook' and is configured
+through `notmuch-message-attach-regex'."""
+  (save-excursion ;; XXX: this fails somehow: point is at the end of the 
buffer on error
+(goto-char (point-min))
+(if (re-search-forward notmuch-attach-regex nil t)
+(progn
+  (goto-char (point-min))
+  (unless (re-search-forward "<#part [^>]*filename=[^>]*>" nil t)
+(or (y-or-n-p "Email seem to refer to attachment, but nothing 
attached, send anyways?")
+(error "No attachment found, aborting")))
+
+(add-hook 'message-send-hook 'notmuch-message-check-attach)
+
 (provide 'notmuch-message)
 
 ;;; notmuch-message.el ends here
-- 
2.11.0

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] WIP: test patch for reference loop problem

[Antoine Beaupré]

Hi!

So I've tried the patch and it seems to fix the bug. I'll run with a
patch version for a while to see if anything's off, but so far so good
I'd say.

Furthermore, it's not possible for me to reproduce the bug in my regular
mailbox anymore. I suspect this is because new mail came in and the file
order in the directories changed, so the bug isn't triggered anymore.

I was able to trigger the bug with the reproducer with an older build of
the code though, so don't worry about that part. :)

Let me know if you need anything else from me before this gets merged.

Cheers!

A.

-- 
Only in the darkness can you see the stars.
- Martin Luther King, Jr.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: bug: "no top level messages" crash on Zen email loops

[Antoine Beaupré]

On 2018-03-29 04:17:21, Olly Betts wrote:
> On Mon, Mar 19, 2018 at 05:03:21PM -0300, David Bremner wrote:
>> I can confirm this reproduces both the xapian-check and the notmuch-show
>> error. Olly agrees that whatever notmuch is doing wrong, it shouldn't
>> lead to a corrupted database
>
> There was a Xapian bug here, which I fixed on master last week and will
> be fixed in 1.4.6.

An honor. It's not every day you find a bug in a database software. ;)

> If changes to a new database which didn't modify the termlist table were
> committed, then a disk block which had been allocated to be the root
> block in the termlist table was leaked (not used but not on the
> freelist of blocks the table can recycle).  This was largely harmless,
> except that it was detected by Database::check() and caused an error.

Hmm... but if I understand correctly, that's one part of the story: I
could get that error and not have the problem with `notmuch show`. Does
that *also* resolve the issue with email loops?

A.

-- 
Travail, du latin Tri Palium trois pieux, instrument de torture.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: tip: how to not forget attachments

[Antoine Beaupré]

On 2018-03-19 17:40:40, Brian Sniffen wrote:
> Throw your function name, catch it outside the save-excursion, and raise an 
> error there?

You mean to catch/throw to have save-excursion save the point correctly?
But my tests show the point is moved by something else in message-send
anyways, so I'm not sure I should even bother at that point...

Or should I?

a.

-- 
Il faut tout un village pour élever un enfant.
- Proverbe africain
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: tip: how to not forget attachments

[Antoine Beaupré]

On 2018-03-19 15:57:05, Brian Sniffen wrote:
> `error` doesn’t do any unwinding; it leaves the program state wherever it was 
> for analysis.  You probably want throw/catch, as described at 
> https://www.gnu.org/software/emacs/manual/html_node/elisp/Catch-and-Throw.html#Catch-and-Throw

Wait, but what tag would I throw? message-send doesn't do any catching
around the hook calls...

a.

-- 
The United States is a nation of laws:
badly written and randomly enforced.
- Frank Zappa
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

tip: how to not forget attachments

[Antoine Beaupré]

On 2018-03-19 13:56:54, Antoine Beaupré wrote:
> PS: don't we have a "you forgot to actually attach the damn file" plugin
> when we detect the word "attachment" and there's no attach? :p

So I figured that one out, I think. Before adding it to the wiki, I'd
like a review of the code (attached) from more adept elisp programmers.

I'm particularly surprised that save-excursion doesn't work the way I
expect: when I answer "no" to the question, I go back to the email
buffer, but the point is invariably at the end of the buffer, whereas I
would expect it to be where it was when I send the message. It looks
like something else moves the mark before my hook, but I'm not sure
what...

How else than (error) or (keyboard-quit) am I supposed to abort email
sending? (message-send) uses the latter but it would seem better to use
an actual error message than to just "beep" our way out here..

Other advice? (save-excursion) + (goto-char (point-min)) +
(re-search-forward), is that idiomatic? or is there something more
clever that should be done?

thanks!

-- 
Tu connaîtras la vérité de ton chemin à ce qui te rend heureux.
- Aristote


notmuch-buddha.el
Description: application/emacs-lisp
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: bug: "no top level messages" crash on Zen email loops

[Antoine Beaupré]

And obviously I forget the frigging attachment.



zendesk-email-loop2.tgz
Description: application/gtar-compressed

PS: don't we have a "you forgot to actually attach the damn file" plugin
when we detect the word "attachment" and there's no attach? :p
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: bug: "no top level messages" crash on Zen email loops

[Antoine Beaupré]

On 2018-03-19 13:36:49, David Bremner wrote:
> Antoine Beaupré <anar...@orangeseeds.org> writes:
>
>> Hi!
>>
>> Here's a fun bug for you Xapian tricksters.
>>
>> Two emails attached make notmuch crash when trying to display the
>> folder.
>>
>> $ notmuch show thread:0001
>> Internal error: Thread 0001 has no toplevel messages.
>>  (notmuch-show.c:1012)
>>
>> Those are the two messages:
>>
>> $ notmuch search --output messages  thread:0001
>> id:9379qm5z39_5aa86b134fcfb_174033fc97a2cb98c7198d_sp...@zendesk.com
>> id:9379qm5z39_5aa86b1350504_174eb3fc97a2cb98c71674_sp...@zendesk.com
>>
>> `notmuch show` on either messages crashes the same way:
>>
>> $ notmuch show 
>> id:9379qm5z39_5aa86b1350504_174eb3fc97a2cb98c71674_sp...@zendesk.com
>> Internal error: Thread 0001 has no toplevel messages.
>>  (notmuch-show.c:1012)
>
> I can't duplicate that part.  

That's very strange. I can reproduce this on my workstation here, but
taking the tarball I sent in the original message, I can't reproduce
anymore. So something changed! I suspect it's the "flags" on the
message. I have "F" everywhere because I'm experimenting with syncing
(badly) my inbox tag everywhere, through the flagged tag. All post-new
hooks stuff that shouldn't affect this because it's in a new
environment, but it does change the flag on the files sometimes.

So attached is a *new* reproducer, with which I *can* reproduce in a
clean VM with notmuch from stretch (0.23?).

To reproduce, with a `debian/stretch64` vagrant VM:

host$ vagrant init debian/stretch64 && vagrant up && vagrant ssh
guest$ sudo apt install notmuch
guest$ notmuch setup # pick all defaults
guest$ wget $url_of_the_reproducer
guest$ tar zxfv zendesk-mail-loop2.tgz
guest$ mv gitlab mail # to put it where notmuch expects
guest$ notmuch new
guest$ notmuch show thread:0001
Internal error: Thread 0001 has no toplevel messages.
 (notmuch-show.c:957)

I can reproduce this reproducibly here now.

Phew, that is definitely weird! For what it's worth, here's the diff
between the two tarballs:

[429]anarcat@curie:~1$ diffoscope zendesk-email-loop.tgz zendesk-email-loop2.tgz
 
||
  100% Time: 0:00:00 
--- zendesk-email-loop.tgz
+++ zendesk-email-loop2.tgz
├── metadata
│ @@ -1 +1 @@
│ -gzip compressed data, last modified: Mon Mar 19 13:21:40 2018, from Unix
│ +gzip compressed data, last modified: Mon Mar 19 17:38:29 2018, from Unix
│   --- zendesk-email-loop.tgz-content
├── +++ zendesk-email-loop2.tgz-content
├── file list
│ │ @@ -1,5 +1,5 @@
│ │ -drwx--   0 anarcat   (1000) anarcat   (1000)0 2018-03-19 
13:11:45.00 gitlab/cur/
│ │ --rw---   0 anarcat   (1000) anarcat   (1000) 8858 2018-03-14 
00:27:37.00 gitlab/cur/1521465105.R3423354954039434325.curie:2,FS
│ │ --rw---   0 anarcat   (1000) anarcat   (1000)11861 2018-03-19 
08:50:10.00 gitlab/cur/1521464914.R16228666356894086807.curie:2,F
│ │ +drwx--   0 anarcat   (1000) anarcat   (1000)0 2018-03-19 
17:35:32.00 gitlab/cur/
│ │ +-rw---   0 anarcat   (1000) anarcat   (1000) 8858 2018-03-14 
00:27:37.00 gitlab/cur/1521463753.R9368947314807690338.curie:2,FS
│ │ +-rw---   0 anarcat   (1000) anarcat   (1000) 8720 2018-03-14 
00:30:59.00 gitlab/cur/1521463752.R13151765805797588408.curie:2,FS
│ │  drwx--   0 anarcat   (1000) anarcat   (1000)0 2018-03-19 
12:49:12.00 gitlab/new/
│ │ -drwx--   0 anarcat   (1000) anarcat   (1000)0 2018-03-19 
13:11:45.00 gitlab/tmp/
│ │ +drwx--   0 anarcat   (1000) anarcat   (1000)0 2018-03-19 
12:49:13.00 gitlab/tmp/
│   --- gitlab/cur/1521465105.R3423354954039434325.curie:2,FS
├── +++ gitlab/cur/1521463753.R9368947314807690338.curie:2,FS

ie. the files are identical, but the serial numbers, timestamps and
flags differ. Maybe this makes the directory ordering (so the load order
in notmuch new) differ? No idea.

But hopefully this will allow you to reproduce more reliably.

A.

-- 
La seule excuse de Dieu, c'est qu'il n'existe pas.
- Stendhal
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

bug: "no top level messages" crash on Zen email loops

[Antoine Beaupré]

Hi!

Here's a fun bug for you Xapian tricksters.

Two emails attached make notmuch crash when trying to display the
folder.

$ notmuch show thread:0001
Internal error: Thread 0001 has no toplevel messages.
 (notmuch-show.c:1012)

Those are the two messages:

$ notmuch search --output messages  thread:0001
id:9379qm5z39_5aa86b134fcfb_174033fc97a2cb98c7198d_sp...@zendesk.com
id:9379qm5z39_5aa86b1350504_174eb3fc97a2cb98c71674_sp...@zendesk.com

`notmuch show` on either messages crashes the same way:

$ notmuch show 
id:9379qm5z39_5aa86b1350504_174eb3fc97a2cb98c71674_sp...@zendesk.com
Internal error: Thread 0001 has no toplevel messages.
 (notmuch-show.c:1012)

Note that displaying the messages weith `--format raw` doesn't crash, so
it's really the thread structure that's broken. Obviously, emacs can't
display the messages either and doesn't touch the unread tags when
trying to load the message, which is to be expected I guess.

Xapian is also unhappy with the database created by notmuch new:

$ xapian-check gitlab/.notmuch/xapian/
docdata:
blocksize=8K items=1 firstunused=1 revision=7 levels=0 root=0
B-tree checked okay
docdata table structure checked OK

termlist:
blocksize=8K items=12 firstunused=4 revision=7 levels=0 root=3
xapian-check: DatabaseError: 1 unused block(s) missing from the free list, 
first is 0

Valgrind is not particularly unhappy with notmuch, so it doesn't seem
like a memory error:

==26723== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

I tried to track this down in gdb, i got as far as finding that, in
`notmuch_thread_get_toplevel_messages`, the `list` object is corrupt (?)
already (`list->head == NULL`) which obviously makes it hard to, er,
list messages in a thread. :p I lost the exact backtrace and so on, but
I'm not sure there's much we can get from gdb: it seems the problem
might be in notmuch-new, but I'm a little out of my depth to debug
*that* without any further pointers.

This is with 0.26-1~bpo9+1 on Debian stretch, but I can also reproduce
with 0.23 on another Debian stretch machine, using a similar mail
spool.

My guess is that those messages are somewhat special: notice how the
reply-to identifiers *loop* between the two messages?

Message one:

Message-ID: <9379qm5z39_5aa86b134fcfb_174033fc97a2cb98c7198d_sp...@zendesk.com>
In-Reply-To: <9379qm5...@zendesk.com>
 <9379qm5z39_5aa86b1350504_174eb3fc97a2cb98c71674_sp...@zendesk.com>

Message two:

Message-ID: <9379qm5z39_5aa86b1350504_174eb3fc97a2cb98c71674_sp...@zendesk.com>
In-Reply-To: <9379qm5...@zendesk.com>
 <9379qm5z39_5aa86b134fcfb_174033fc97a2cb98c7198d_sp...@zendesk.com>

And indeed, a mailbox with only *one* of those messages doesn't cause
the crash. But also: the original thread is now made of *three*
messages, and taking any one of the two messages above with that *third*
message doesn't cause the crash:

Message three:

Message-ID: <9379qm5z39_5aaf79c126a_94233ffb30ecb9982187c0_sp...@zendesk.com>
In-Reply-To: <9379qm5...@zendesk.com>
 <9379qm5z39_5aa86b1350504_174eb3fc97a2cb98c71674_sp...@zendesk.com>

This message also shows correctly threaded with message two if present,
otherwise the thread is (obviously) broken with only message one and
three.

Mutt displays those messages as a "normal" three-level thread:

   1   ! mar 14 GitLab Support  (4,7K) Your GitLab support request has been 
received
   2   ! mar 14 GitLab Support  (4,5K) └>comments not showing up?
   3 O ! mar 19 XXX (7,9K)  └>[GitLab, Inc.] Re: comments not 
showing up?

The numbers on the left (1, 2, 3) correspond to the labeling I used
above as well (one, two, three).

The third message is not included here because it's an actual reply from
a human from GitLab (yay gitlab! :) which I'd need approval before
sharing here. The first message is an automated response so I thought it
was fair game to share publicly. The second is a copy of my own message
which triggered the autoreply, which is probably the source of the
loop. The software generating this mess is Zendesk.com. I haven't had
that problem with other interactions with Zendesk, maybe because I
never talked with a Zendesk that sent autoreplies.

To reproduce this, untar the attachment anywhere (say $HOME) and then
hack a notmuch config file pointing there, e.g.:

$ diff .notmuch-config*
15c15
< path=/home/anarcat/Maildir/
---
> path=/home/anarcat/gitlab/

Then point notmuch to that config (export
NOTMUCH_CONFIG=~/.notmuch-config-test) and run notmuch new (which should
find only two messages). Then run the commands from the above of this
email, of course. :)

Thanks for any input,

A.

PS: I must say I am grateful and impressed by the reliability of
notmuch. I've been using notmuch for *years* now and it's the *first*
time, for as long as I remember, that I had to go back to mutt to read
email. So kudos to the team, good job. :)

-- 
Si les élections n'étaient pas indispensables à la prospérité du
capital, on ne nous 

Re: [PATCH] NEWS: cleartext indexing

[Antoine Beaupré]

Another thing I forgot. You mentioned dedicated LUKS partitions as an
example solution. I wonder if you know about the `tomb` and `ctmg`
projects which more or less implement those features as commandline tool
wrappers.

Tomb is a simple shell-script wrapper around cryptsetup to easily create
and manage loop-mounted LUKS partitions:

http://tomb.dyne.org/

An example use of this for notmuch would be the `pass-tomb` extension to
the `pass` password manager, which uses tomb to hide password entries
when not in use:

https://github.com/roddhjav/pass-tomb

CTMG is basically the same thing but written by Donenfeld instead of
Jaromil:

https://git.zx2c4.com/ctmg/about/

Both require root to run. In both cases, my primary concern would be how
to manage the size of the LUKS partition just right: it shouldn't take
up space needlessly, but then it needs to expand when new space is
needed. As far as I know, none of those tools elegantly solve that
problem, except maybe the new ext4 encryption system...

Thanks again for this precious patchset, I hope it gets rolled in soon!
0.26 will be even more amazing it gets shipped with this.

A.

-- 
Gods don't like people not doing much work. People who aren't busy all
the time might start to think.
- Terry Pratchett, Small Gods
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] NEWS: cleartext indexing

[Antoine Beaupré]

Hi,

Sorry for the long delay in my response, but it was a long email to
review - there's a lot of stuff in here - so I didn't quite know how to
respond. I'll just respond inline but will try to keep it brief.

On 2017-11-01 04:13:26, Daniel Kahn Gillmor wrote:
> On Mon 2017-10-30 12:16:25 -0400, Antoine Beaupré wrote:
>> I think that assumption should be made clear in the documentation,
>> because "security of your index" means nothing to me. Explicitly mention
>> FDE as an example may be a good start.
>
> again, i'm not convinced that "full disk" encryption is what's
> warranted, although filesystem, directory, or per-file encryption might
> be part of the solution.
>
> I don't want the documentation produced here to prescribe a particular
> solution, because i *want* people to experiment and investigate.
>
> I also don't think that the notmuch documentation is the right place to
> put a primer on filesystem encryption, or a treatise on the comparison
> of data at rest to data in flight.  I wouldn't object to pointers to
> more discussion here though, for people who want to read more.

The problem is we do not have such documentation to point to. The
original text I was critical of is this, to put things back in context:

> +  Note that the contents of the index are sufficient to roughly
> +  reconstruct the cleartext of the message itself, so please ensure
> +  that the notmuch index itself is adequately protected.  DO NOT USE
> +  this feature without considering the security of your index.

In other words, the documentation uses "adequately protected" and
"security of your index" as deliberately vague terms to urge the user to
consider practices. My concerns here is that those words may mean *very*
different things to different people. Just this discussion shows the
range of possible outcomes - I was thinking FDE, but then you suggested
that this was not adequate, with a plethora of possible solutions.

Which one do *you* use? I suspect most people that will adopt this
technology will simply *ignore* that warning and just store their index
in plaintext. In which case this warning is pointless and joins a long
series of fatigue-generating warnings that we constantly train our users
to ignore.

If we will warn, at least we should give guidelines of how to fix the
warning.

[... on-the-fly encryption of notmuch DB discarded ...]

[... possible actual solutions brainstorm for a notmuch lock / unlock
command based on ( ext4 encryption | notmuch-specific filesystem |
removable notmuch storage | etc ) ... ]

> Again, i don't think that notmuch documentation is a great place to
> document these ideas, unless we're actually implementing them in a
> simple and straightforward way so that the user can trigger the actions
> easily.

Sure. But this discussion shows that we do *not* have a clear and simple
recommendation for people. That's too bad, and bound to the limitation
of the system we're using of course (e.g. Linux instead of iOS) but we
shouldn't pretend there *are* solutions when there aren't, out of the
box, ways to secure the index.

[...]

>> Having my emails encrypted adds another layer of security to that
>> content. FDE is good for data "at rest", e.g. when i travel with my
>> laptop. But when my laptop is opened and running, I like to think that a
>> part of it isn't accessible without the security layers behind PGP and
>> actual human confirmation.

[...]

> So in practice, one authorization of your PGP key is likely to enable
> arbitrary programs to access it for the duration of the gpg-agent
> cache.  So your data is still actually accessible to any process that
> can access both the agent and the message store.

Sure. But the point is exactly that - there is *some* level of
control. I don't use a crypto token for encryption now, but when/if I
will there will be a satisfying, hardware, way of ensuring things are
encrypted at rest: just yank the key out. :) Short of that, yes, having
gpg-agent prompt me for stuff is a good compromise.

> That said, if there is a specific message which you think should not be
> in the index, the cleartext-index series and the session-key series both
> provide means for keeping a *specific* encrypted message in the
> mailstore while ensuring that it is not indexed and no session-keys are
> stashed.
>
> An interesting proposal might be to add an additional per-message
> property, which says explicitly "do not index cleartext or store session
> keys for this message".  I don't believe there are many users who would
> actually use this feature, but i would review a patch for it and provide
> feedback.

That would be an interesting feature, but I don't know how it could be
practically implemented. Notmuch feature discovery is limited, at best,
with t

Re: [PATCH] NEWS: cleartext indexing

[Antoine Beaupré]

On 2017-10-30 16:47:49, Daniel Kahn Gillmor wrote:
> On Mon 2017-10-30 08:46:12 -0400, Antoine Beaupré wrote:
>> On 2017-10-22 11:36:34, Daniel Kahn Gillmor wrote:
>>> +  Note that the contents of the index are sufficient to roughly
>>> +  reconstruct the cleartext of the message itself, so please ensure
>>> +  that the notmuch index itself is adequately protected.  DO NOT USE
>>> +  this feature without considering the security of your index.
>>
>> Could we expand on what those security options could be? Full disk
>> encryption? Or is there some way to PGP-encrypt the index and have it
>> decrypted on the fly?
>
> This is deliberately out of scope of the series -- i don't want this
> series to introduce notmuch-specific index encryption. Though if someone
> wanted to propose that i'd be happy to review it; fwiw, i have looked at
> a few deterministic mail index encryption schemes, and i'm not convinced
> that they meet any realistic threat model.
>
> But yes, my basic assumption is that people who care will keep their
> index on an encrypted filesystem, or at least on a filesystem that sits
> atop an encrypted block device layer.  I don't know whether it's
> relevant if the encryption layer is "full-disk" or not.

I think that assumption should be made clear in the documentation,
because "security of your index" means nothing to me. Explicitly mention
FDE as an example may be a good start.

>> Security, in this context, seems a little broad... I do have a antsy
>> feeling at decrypting all my private emails in a cleartext database
>> without additional measures. I'd sure love to see this notion expanded
>> here somehow.
>
> expand away!  I'd be interested in reading your detailed thoughts on
> this.

Frankly, I don't have a good solution for this. I was thinking that
there may be a way to just encrypt the whole notmuch database with gpg
and decrypt it on the fly as needed, but that's probably a ludicrous
idea.

> My basic rationale is:
>
>  * i find myself not encrypting some e-mails because encrypted e-mails
>are too hard to use.  in particular, they're hard to search through,
>and they are expensive to render. ("where was the address of that
>restaurant again?  if only i had sent it in cleartext...")
>
>  * the result is that i either send those mails in the clear (leaking
>the cleartext irrevocably), or i move my communications off of e-mail
>(typically to platforms on which i have even less control than
>e-mail).
>
>  * This is actually a messaging security *anti-pattern*, and i've
>observed it in someone who takes communications confidentiality
>seriously (myself).
>
>  * furthermore, it harms the ability for a conscientious sender to
>produce encrypted e-mail by default, because they're likely to be
>concerned about the same usability obstacles on the receiver's side.
>
>  * making the use of encrypted e-mails more fluid and accessible should
>actually increase the total amount of encrypted mail, providing more
>protection in general.
>
>  * the steps you need to take to secure your cleartext index are similar
>(though not congruent) to the steps you need to take to secure your
>MUA itself (endpoint-level security hardening).  If you aren't
>already taking basic steps to protect your endpoint, it's not clear
>to me that keeping encrypted messages out of your index protects them
>significantly against a motivated attacker.

So I hear all those arguments and mostly agree with them. That's the
"rationale about the decision" part, what I'm missing is the "mitigation
strategies". What I'm hearing is simply "use FDE", but I already do that
and I don't feel it brings much added security.

Having my emails encrypted adds another layer of security to that
content. FDE is good for data "at rest", e.g. when i travel with my
laptop. But when my laptop is opened and running, I like to think that a
part of it isn't accessible without the security layers behind PGP and
actual human confirmation. I don't feel that FDE brings that level of
security because "at rest" means "when the computer is shutdown" not
"when I'm not using the thing", unfortunately.

Now, I understand there may be no solution to this. But shifting the
burden of "secure this" to the user doesn't seem fair in this
context. We should clearly expose this as a compromise that the user
must be ready to take, not just be left as an exercise to the reader,
because there may be *no* solution.

In other words, what I think you are proposing with this patchset is to
consider PGP email encryption as a end to end encryption mechanism, but
*not* as a "

synchronizing the inbox flag

[Antoine Beaupré]

Hi notmuchers! :)

I've done numerous attemps at making notmuch work across different
machines in the past. (See below for the details.) The only thing
missing now is the "inbox" tag synchronization. My use case is this: I
mostly use this one machine all the time. I have a [notmuch-tag][1]
script that sets a number of tags on messages depending on the folder
they're in and so on, so most tags are actually static and basically
shortcuts for saved searches.

Except the inbox tag: that tag is "floating" in the notmuch database and
is not sync'd on the server, which means when i pickup that laptop for
my next travel, i need to resync the whole notmuch database with notmuch
dump / restore. That is error-prone and annoying, and obviously fails
often because I don't regularly perform that sync.

What I would like to see in notmuch would be a way for the inbox tag to
be sync'd to the maildir storage. It could be an extra arbitrary flag in
the maildir filenames. From what I can tell from the [maildir
standard][2], there are 26 possible such such flags, with 6 formally
defined: P (passed), R (replied), S (seen, mapped as unread), F
(flagged), D (draft), T (trashed). The latter is not sync'd in notmuch,
the others are sync'd if synchronized_tags is true (default) in the
config file.

I would propose using the `A` or `I` flag, and sync it with the `inbox`
tag the same way the `S` flag is sync'd with the `unread` tag (ie. add
the flag when `inbox` is removed). Ideally, we could let the user
customize which flags are synchronized with which tags in the
configuration file. Given the limitations of the config file format
(ini-style), I'm not sure how that could be implemented.

Also note that certain IMAP servers treat non-standard flags as IMAP
keywords. [Dovecot][4], in particular, allows users to modify those
mappings by editing the `dovecot-keywords` file. In my local
configuration, where I have not manually edited that file, its contents
are:

0 Junk
1 NonJunk
2 $Forwarded

This is presumably something that Thunderbird did at some point, or it
could be the default Dovecot configuration. So this may mean letters,
`A-C` are already taken, which means there could be interoperability
issues with using `A`: it could mean we tag all inbox messages as junk!
In this case, the `I` flag may be more appropriate (with a meaning the
opposite of `A`, ie. sync'd directly with the inbox tag).

Since there is a considerable range of foot-shooting potential here, it
may be better to just add an extra flag without allowing users to
customize the flags on their own. But I like the idea of allowing that
flexibility: it could fix a bunch of other use cases (like deleting mail
and syncing junk flags as well).

Anyone else working on this? Ideas of how this could be implemented?

Some more historical context follows...

My first attempt was a very old patch (2011!) to add resume
support in Notmuch - something that thankfully landed 6 years later:

1310808075-787-1-git-send-email-anar...@koumbit.org

My second attempt was the synchronization of the "deleted" tag to the T
(trashed) IMAP/maildir flag (~2012):

1310874973-28437-1-git-send-email-anar...@koumbit.org

That also failed and I ended up setting up a [script][3] to delete
messages tagged "deleted" automatically. The script also synchronizes
ham/spam flags.

Finally, I have also experimented with [muchsync][5] but that basically
failed for me: the thing would just run out of ram and fail to
synchronize tags.

[1]: https://gitlab.com/anarcat/scripts/blob/master/notmuch-tag
[2]: https://cr.yp.to/proto/maildir.html
[3]: https://gitlab.com/anarcat/scripts/blob/master/notmuch-purge
[4]: https://wiki2.dovecot.org/MailboxFormat/Maildir#IMAP_keywords
[5]: http://www.muchsync.org/

Thanks for any feedback!

-- 
Blind respect for authority is the greatest enemy of truth.
   - Albert Einstein
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: BUG: trouble with forwarding with accents

[Antoine Beaupré]

On 2016-02-06 12:14:57, David Edmondson wrote:
> On Fri, Feb 05 2016, Antoine Beaupré wrote:
>> So I have an accent in my family name, as you can see from the From
>> header here. This has a tendency of finding the greatest and finest
>> UTF-8 bug, and often no one believes me because they don't have that
>> interesting property.
>>
>> Notmuch has been bugging me with such a problem for ages now. When I
>> forward a mail, the accents in my name (or in the signature inserted)
>> are broken.
>
> I tried to reproduce this (by modifying my name in .notmuch-config to
> include an accented character and then forwarding your mail), but
> everything worked fine (on "GNU Emacs 24.5.1 (x86_64-apple-darwin15.0.0,
> NS apple-appkit-1404.11) of 2015-10-05 on heart-of-gold").
>
> It's tempting to ask whether or not you have any localisation or
> language settings in either your shell or emacs, but I probably wouldn't
> know how to interpret them even if so :-/

I have a french utf-8 locale:

[997]anarcat@angela:~1$ locale
LANG=fr_CA.UTF-8
LANGUAGE=
LC_CTYPE="fr_CA.UTF-8"
LC_NUMERIC="fr_CA.UTF-8"
LC_TIME="fr_CA.UTF-8"
LC_COLLATE="fr_CA.UTF-8"
LC_MONETARY="fr_CA.UTF-8"
LC_MESSAGES="fr_CA.UTF-8"
LC_PAPER="fr_CA.UTF-8"
LC_NAME="fr_CA.UTF-8"
LC_ADDRESS="fr_CA.UTF-8"
LC_TELEPHONE="fr_CA.UTF-8"
LC_MEASUREMENT="fr_CA.UTF-8"
LC_IDENTIFICATION="fr_CA.UTF-8"
LC_ALL=

In a terminal and in emacs.

I am not sure if i have any emacs-specific l10n settings.

a.
-- 
"Faith" means not wanting to know what is true.
 - Friedrich Nietzshe
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

BUG: trouble with forwarding with accents

[Antoine Beaupré]

So I have an accent in my family name, as you can see from the From
header here. This has a tendency of finding the greatest and finest
UTF-8 bug, and often no one believes me because they don't have that
interesting property.

Notmuch has been bugging me with such a problem for ages now. When I
forward a mail, the accents in my name (or in the signature inserted)
are broken. (Interstingly, I haven't *actually* been bothered by that
bug for a while because I was using Emacs through an SSH console. Now,
I'm using Emacs within a X11 terminal instead, "GNU Emacs 24.4.1
(x86_64-pc-linux-gnu, GTK+ Version 3.14.5) of 2015-03-07 on trouble,
modified by Debian".)

Interestingly, piping that buffer into patebinit doesn't yield any errors:

http://paste.debian.net/378776/

Yet there is clearly an issue while writing the buffer, as you can see
on this screenshot:

http://paste.anarc.at/snap-2016.02.05-17.28.30.png

Look at the buffer on the bottom: my accent (a ) is all busted
in the From line, even though it is perfectly fine in *this* buffer. If
I try to send that message (say to the `devnull` recipient), I get a
nasty warning:

```
These default coding systems were tried to encode text
in the buffer `1454711375.18796_680127_47.angela':
  (utf-8-unix (21 . 4194243) (22 . 4194217))
However, each of them encountered characters it couldn't encode:
  utf-8-unix cannot encode these: \303 \251

Click on a character (or switch to this window by `C-x o'
and select the characters by RET) to jump to the place it appears,
where `C-u C-x =' will give information about it.

Select one of the safe coding systems listed below,
or cancel the writing with C-g and edit the buffer
   to remove or modify the problematic characters,
or specify any other coding system (and risk losing
   the problematic characters).

  raw-text no-conversion
```

(Note that I rewrote the actual escape characters above to avoid to be
"backslash number number number" instead of the actual escape sequence
to avoid trouble, as I am sending this through emacs as well.)

I usually [PLOKTA][1] my way through that warning, but I have no idea if
the recipient receives something that is jumbled up or not. Besides,
PLOKTA is not fun, I just feel like I look like this:

http://i1.kym-cdn.com/photos/images/original/000/234/765/b7e.jpg

 [1]: https://en.wikipedia.org/wiki/PLOKTA

This sure smells like double-encoding. Is this notmuch's fault or
message-mode, and how can i fix this stuff?

This is notmuch 0.18 in Debian jessie.

Thanks for any advice,

A.

-- 
Code is law.
 - Lawrence Lessig
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

muchsync runs out of memory

[Antoine Beaupré]

I have been impressed with the features of muchsync when I recently
found out about it. muchsync seems to do everything i want: i have my
server where i usually take my mail, but then my laptop that i want to
sync and run notmuch + emacs on...

however, when i tried it, it failed:

[1011]anarcat@angela:~$ muchsync -v --noup --init Maildir
marcos.anarc.at
[SERVER] [notmuch] Note: Ignoring non-mail file:
/home/anarcat/Maildir//.Archives/dovecot-uidlist
[SERVER] [notmuch] Note: Ignoring non-mail file:
/home/anarcat/Maildir//.Archives/dovecot.index.log
[SERVER] [notmuch] Note: Ignoring non-mail file:
/home/anarcat/Maildir//.Drafts/dovecot-uidlist
[...]
[SERVER] [notmuch] Note: Ignoring non-mail file:
/home/anarcat/Maildir//courierimaphieracl/notmuch
[SERVER] [notmuch] Note: Ignoring non-mail file:
/home/anarcat/Maildir//courierimapkeywords/:list
[SERVER] [notmuch] Processed 53 total files in almost no time.
[SERVER] [notmuch] Added 4 new messages to the database.
[SERVER] [notmuch] Tagging spam (still incomplete)
[SERVER] [notmuch] tagging folders
[SERVER] [notmuch] tagging feeds
[SERVER] [notmuch] Tagging the rest
[notmuch] No new mail.
synchronizing muchsync database with Xapian... 4.525728 (+4.525728)
starting scan of Xapian database... 4.526494 (+0.000766)
opened Xapian... 4.530846 (+0.004351)
scanned message IDs... 4.531486 (+0.000640)
scanned tags... 4.532962 (+0.001477)
scanned directories in xapian... 4.533484 (+0.000521)
scanned filenames in xapian... 4.534243 (+0.000760)
adjusted link counts... 4.534790 (+0.000546)
finished synchronizing muchsync database with Xapian... 4.585857
(+0.051067)
received server's version vector... 4.673185 (+0.087328)
received hashes of new files... 13.704394 (+9.031209)
created directory /home/anarcat/Maildir/.Archives.2010
created directory /home/anarcat/Maildir/.Archives.2010/cur
created directory /home/anarcat/Maildir/.Archives.2010/new
created directory /home/anarcat/Maildir/.Archives.2010/tmp
created directory /home/anarcat/Maildir/.ham
created directory /home/anarcat/Maildir/.ham/cur
created directory /home/anarcat/Maildir/.ham/new
created directory /home/anarcat/Maildir/.ham/tmp
created directory /home/anarcat/Maildir/.Archives.2011
created directory /home/anarcat/Maildir/.Archives.2011/cur
created directory /home/anarcat/Maildir/.Archives.2011/new
created directory /home/anarcat/Maildir/.Archives.2011/tmp
Warning:
/home/anarcat/Maildir/.Archives.2011/cur/1447185197.M640040073P4037Q12085Rc1c3db4c.angela:2,
is an mbox containing a single message,
likely caused by misconfigured mail delivery.  Support for
single-message
mboxes is deprecated and may be removed in the future.
A Xapian exception occurred opening database: Unable to get write lock
on /home/anarcat/Maildir/.notmuch/xapian: Couldn't fork: Cannot allocate
memory
/home/anarcat/Maildir: A Xapian exception occurred
Processus arrêté

when i run it again, it thinks everything is fine:

[1012]anarcat@angela:~137$ muchsync -v --noup Maildir marcos.anarc.at
[notmuch] Processed 1 file in almost no time.
[notmuch] Added 1 new message to the database.
synchronizing muchsync database with Xapian... 1.304332 (+1.304332)
starting scan of Xapian database... 1.306140 (+0.001807)
opened Xapian... 1.310448 (+0.004308)
scanned message IDs... 1.656520 (+0.346072)
scanned tags... 1.744574 (+0.088054)
scanned directories in xapian... 1.746279 (+0.001704)
scanned filenames in xapian... 20.900691 (+19.154412)
adjusted link counts... 20.939274 (+0.038584)
finished synchronizing muchsync database with Xapian... 21.248633
(+0.309359)

but it's not fine:

[1019]anarcat@angela:~$ notmuch count
6289
[1021]anarcat@angela:~$ ssh anarc.at notmuch count
202094

at first, it did not look like it used up all the RAM, because
I was looking at Munin graphs which are updated every 5 minutes..

after talking with the author privately (the above is a copy of a
previous conversation), I was told to try the following patch

--- a/muchsync.cc
+++ b/muchsync.cc
@@ -15,7 +15,7 @@

 using namespace std;

-#if 0
+#if 1
 // This gives core dumps to make it easier to debug
 struct no_such_exception_t {
   const char *what() noexcept { return "no such exception"; }

Then I could confirm muchsync was killed by the OOM killer:

In the end, it did run out of memory:

[47386.773767] [ pid ]   uid  tgid total_vm  rss nr_ptes nr_pmds swapents 
oom_score_adj name
[...]
[47386.774287] [15162]  1000 15162  1280802   8352322478   8 405017 
0 muchsync
[...]
[47386.774303] Out of memory: Kill process 15162 (muchsync) score 866 or 
sacrifice child

... so around 1.2GB in use... I don't think it dumped core - if so, I
couldn't find the core file.

Note that only 500MB of mails were transfered, out of around 11GB of
notmuch db + mail in my remote maildir.

Anyone using muchsync with similar data sizes?

I'd love to get this working - I had trouble reseting my offlineimap +
local notmuch synchronisation the last time I tried... Notmuch tags
would 

Message deletion wisdom

[Antoine Beaupré]

On Wed, 04 Apr 2012 07:38:37 +, Jani Nikula  wrote:
> To amend that (with mostly historical and not so helpful info), notmuch
> used to have the ability to sync the "deleted" tag with the T
> ("trashed") maildir flag (with maildir.synchronize_flags option
> set). Other mail clients or offlineimap were then able to delete the
> mails locally and/or on a server. However, this too had some issues
> (concerning multiple files with the same message-id) making it
> potentially dangerous, and was removed [1]. Whether this feature ever
> makes a comeback depends on someone tackling the problems. And taking
> into account the fact that current users of the deleted tag probably do
> not expect the files to be actually deleted.

I rolled patches for this in the past, see the following message:

id:"1310874973-28437-1-git-send-email-anarcat at koumbit.org"
id:"1310874973-28437-2-git-send-email-anarcat at koumbit.org"

They were indeed refused by the community, but I felt they were still
useful.

I do not use those patches nowadays, however, but to me they would fit
in a broader architectural view of notmuch, where tags are not only
metadata sitting outside of your email, but is also written to the
messages themselves.

The idea is that you can then run notmuch from multiple places without
having to worry about synchronising your tags manually: the tags would
sit in the messages themselves.

A.
-- 
Ce que les si?cles des grands abatoirs nous aura appris
Devrait ?tre inscrit au fond de toutes les ?coles;
Voici l'homme: le destructeur des mondes est arriv?.
- [no one is innocent]
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Message deletion wisdom

[Antoine Beaupré]

On Tue, 03 Apr 2012 16:32:04 -0700, Jameson Graef Rollins  wrote:
> So in summary, if you would like to "delete" messages, you can:
> 
>  * add a key binding to emacs (or your favorite ui) to add a "deleted"
>tag to messages that you want to delete:
> 
> (define-key notmuch-show-mode-map "d"
>   (lambda ()
> (interactive)
> (notmuch-show-tag-message "+deleted")))

Thank you for this. I had tried to reroll your patches
(id:"1326826969-23545-1-git-send-email-jrollins at finestructure.net") on
top of 0.12 and that was a miserable failure, so the above works
well. In fact, I have made it like this instead:

(define-key notmuch-show-mode-map "d"
  (lambda ()
(interactive)
(notmuch-show-tag-message "+deleted")
(notmuch-show-next-open-message)))

... but it doesn't seem to actually go to the next message... oh well,
at least I can delete mail.

Also note that you can delete whole threads with this:

(define-key notmuch-search-mode-map "d"
  (lambda ()
(interactive)
(notmuch-search-tag-thread "+deleted")
(notmuch-search-next-thread)))

... and I have added an undelete function:

(define-key notmuch-search-mode-map "u" 
  (lambda ()
(interactive)
(notmuch-search-tag-thread "-deleted")
(notmuch-search-next-thread)))

>  * and if you really want them purged from disk, delete them manually
>with:
> 
> notmuch search --output=files tag:deleted | xargs -l rm

I use this script:

-- next part --
A non-text attachment was scrubbed...
Name: notmuch-purge
Type: application/x-sh
Size: 219 bytes
Desc: not available
URL: 

-- next part --

Finally, I want to voice that I feel a "delete" key, even if it doesn't
delete mails, seems like an important part of a mail user
agent. Archiving mail is one thing, but for the love and respect of
sysadmins and the infrastructure they maintain, please consider adding
at least a way to *tag* those deleted emails.

Having the above keys being defined as standard in notmuch don't seem
like much to ask.

This may be a dissenting view here, but your mail is not that
important. :P

Cheers,

A.
-- 
L'art n'est pas un bureau d'anthropom?trie.
- L?o Ferr?, "Pr?face"
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: Message deletion wisdom

[Antoine Beaupré]

On Wed, 04 Apr 2012 07:38:37 +, Jani Nikula j...@nikula.org wrote:
 To amend that (with mostly historical and not so helpful info), notmuch
 used to have the ability to sync the deleted tag with the T
 (trashed) maildir flag (with maildir.synchronize_flags option
 set). Other mail clients or offlineimap were then able to delete the
 mails locally and/or on a server. However, this too had some issues
 (concerning multiple files with the same message-id) making it
 potentially dangerous, and was removed [1]. Whether this feature ever
 makes a comeback depends on someone tackling the problems. And taking
 into account the fact that current users of the deleted tag probably do
 not expect the files to be actually deleted.

I rolled patches for this in the past, see the following message:

id:1310874973-28437-1-git-send-email-anar...@koumbit.org
id:1310874973-28437-2-git-send-email-anar...@koumbit.org

They were indeed refused by the community, but I felt they were still
useful.

I do not use those patches nowadays, however, but to me they would fit
in a broader architectural view of notmuch, where tags are not only
metadata sitting outside of your email, but is also written to the
messages themselves.

The idea is that you can then run notmuch from multiple places without
having to worry about synchronising your tags manually: the tags would
sit in the messages themselves.

A.
-- 
Ce que les siècles des grands abatoirs nous aura appris
Devrait être inscrit au fond de toutes les écoles;
Voici l'homme: le destructeur des mondes est arrivé.
- [no one is innocent]


pgp3Hmn5AFgRT.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH 2/2 v2] emacs: Prefer '[No Subject]' to blank subjects.

[Antoine Beaupré]

On Sun, 05 Feb 2012 23:07:02 -0800, Jameson Graef Rollins  wrote:
> Sorry to be so late on this, but I'm not a big fan of this new feature.
> I would prefer to always see the subject (or any other field for that
> matter) as is.

I agree. as a native french speaker, for example, it's annoying having
to change those settings everywhere I got...

a.
-- 
To be naive and easily deceived is impermissible, today more than
ever, when the prevailing untruths may lead to a catastrophe because
they blind people to real dangers and real possibilities.
- Erich Fromm
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: [PATCH 2/2 v2] emacs: Prefer '[No Subject]' to blank subjects.

[Antoine Beaupré]

On Sun, 05 Feb 2012 23:07:02 -0800, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 Sorry to be so late on this, but I'm not a big fan of this new feature.
 I would prefer to always see the subject (or any other field for that
 matter) as is.

I agree. as a native french speaker, for example, it's annoying having
to change those settings everywhere I got...

a.
-- 
To be naive and easily deceived is impermissible, today more than
ever, when the prevailing untruths may lead to a catastrophe because
they blind people to real dangers and real possibilities.
- Erich Fromm


pgpTvohZnwAwD.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: Emacs: Crypto: How to get automatic encryption?

[Antoine Beaupré]

Jumping in here, I have modified the previously posted code here to
provide me with a more complete solution.

With the attach code, I can:

 * automatically encrypt mails if all recipients have a *valid* public
   key. The previous patch allowed encryption if a key existed but was
   revoked, which cause a weird UX issue where the user would be
   bothered with No public key for...

 * not have specify if i want to encrypt the mail or not: it is
   encrypted if possible

 * try to autodetect (by running the function directly) if the mail will
   be crypted and signed or just signed before sending

 * explicitely request the mail to be encrypted or just signed, if I
   want to, using the usual keybindings (ie. the existing #secure tags
   are respected)

So basically, this replaces the common hook:

(add-hook 'message-setup-hook 'mml-secure-sign-pgpmime)

with this:

(add-hook 'message-send-hook 'anarcat/message-set-encryption)

The rationale behind this technique is that the setup-hook runs when
recipients are not yet defined so it will always set the mail to be only
signed, even though your final recipients should be crypted. 

An alternative would be for notmuch to prompt the To: header before
setting up the buffer (à la Mutt), but I didn't feel like going that
way.

Code is attached. Obviously, those function names would change if they
would be to integrate into notmuch. ;)



notmuch-opportunistic.el
Description: application/emacs-lisp

Opportunistic encryption, here we go.

a.

-- 
Evil exists to glorify the good. Evil is negative good.
It is a relative term. Evil can be transmuted into good.
What is evil to one at one time,
becomes good at another time to somebody else.
- Sivananda


pgpksLGKp0nOb.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: Emacs: Crypto: How to get automatic encryption?

[Antoine Beaupré]

On Tue, 17 Jan 2012 09:19:51 +, David Edmondson d...@dme.org wrote:
 On Mon, 16 Jan 2012 23:48:30 -0500, Antoine Beaupré anar...@anarcat.ath.cx 
 wrote:
  Jumping in here, I have modified the previously posted code here to
  provide me with a more complete solution.
 
 This looks good. I'll switch over to using it.

Awesome!

  Code is attached. Obviously, those function names would change if they
  would be to integrate into notmuch. ;)
 
 I wondered about pushing to have notmuch do this by default. In general
 I like the idea, but it suffers if a recipient occasionally uses a mail
 client that does not support decryption (phone, PDA, webmail, ...).

Well, it your call: you can disable encryption on the fly by setting the
message to just signing...

I have also found out (to great pains) that it is kind of difficult to
*completely* disable signing or encrypting, as the send-hook will
happily add back the #secure line even if you remove it.

A workaround is to set mode=none in the #secure line manually. Maybe
C-c RET C-n could do that instead of just removing the line?

On Tue, 17 Jan 2012 15:39:52 +, David Edmondson d...@dme.org wrote:
 (if (and force (re-search-forward #secure [ ]*\n nil t))
 (replace-match  nil nil))
 ;; If we can encrypt, do so, else just sign.
 (if (or force (not (re-search-forward #secure [ ]*\n nil t)))
 
 Is this second test for `force' necessary? If `force' is set then you'll
 remove the #secure.. just above, so it will not be found here.

Yes, it is. If force is true, the search-forward will not be ran at
all. The idea here is that if we do not force (ie. if we're running in
the hook), we do not want to override the existing #secure tags, to
respect the users' choices.

Cheers,

A.

-- 
Antoine Beaupré +++ Réseau Koumbit Networks +++ +1.514.387.6262 #208

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH v3] Make buttons for attachments allow viewing as well as saving

[Antoine Beaupré]

On Tue, 17 Jan 2012 23:44:46 +, Mark Walters  
wrote:
> Define a keymap for attachment buttons to allow multiple actions.
> Define 3 possible actions:
> save attachment: exactly as currently,
> view attachment: uses mailcap entry,
> view attachment with user chosen program
> 
> Keymap on a button is: s for save, v for view and o for view with
> other program. Default (i.e. enter or mouse button) is save but this
> is configurable in notmuch customize.
> 
> One implementation detail: the view attachment function forces all
> attachments to be "displayed" using mailcap even if emacs could
> display them itself. Thus, for example, text/html appears in a browser
> and text/plain asks whether to save (on a standard debian setup)

This works pretty much as advertised, +1 from me, good work.

A.

-- 
C'est trop facile quand les guerres sont finies
D'aller gueuler que c'?tait la derni?re
Amis bourgeois vous me faites envie
Ne voyez vous pas donc point vos cimeti?res?
- Jaques Brel
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

on deleting messages

[Antoine Beaupré]

Hi Jamie!

I have taken the time to test those patches and those in the other
thread[1], and I like it! I was able to run all tests with the patches
applied and I am now running them alongside with most recent master
gd51b784 and Mark Walter's attachment buttons patch[2].

So I support those patches and hope they get in. The only issue I could
find was that I have the reflex of hitting A (capital a) instead of just
"a" in the search view because that's the key i hit in the show
view... but that's probably something i should get used to.

If something pops up I'll let you know!

A.

[1] id:"1325975294-646-2-git-send-email-jrollins at finestructure.net"
[2] id:"1326843886-18387-1-git-send-email-markwalters1009 at gmail.com"

-- 
Antoine Beaupr? +++ R?seau Koumbit Networks +++ +1.514.387.6262 #208

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Emacs: Crypto: How to get automatic encryption?

[Antoine Beaupré]

On Tue, 17 Jan 2012 09:19:51 +, David Edmondson  wrote:
> On Mon, 16 Jan 2012 23:48:30 -0500, Antoine Beaupr?  anarcat.ath.cx> wrote:
> > Jumping in here, I have modified the previously posted code here to
> > provide me with a more complete solution.
> 
> This looks good. I'll switch over to using it.

Awesome!

> > Code is attached. Obviously, those function names would change if they
> > would be to integrate into notmuch. ;)
> 
> I wondered about pushing to have notmuch do this by default. In general
> I like the idea, but it suffers if a recipient occasionally uses a mail
> client that does not support decryption (phone, PDA, webmail, ...).

Well, it your call: you can disable encryption on the fly by setting the
message to just signing...

I have also found out (to great pains) that it is kind of difficult to
*completely* disable signing or encrypting, as the send-hook will
happily add back the #secure line even if you remove it.

A workaround is to set "mode=none" in the #secure line manually. Maybe
C-c RET C-n could do that instead of just removing the line?

On Tue, 17 Jan 2012 15:39:52 +, David Edmondson  wrote:
> >(if (and force (re-search-forward "<#secure [> >]*>\n" nil t))
> >(replace-match "" nil nil))
> >;; If we can encrypt, do so, else just sign.
> >(if (or force (not (re-search-forward "<#secure [> >]*>\n" nil t)))
> 
> Is this second test for `force' necessary? If `force' is set then you'll
> remove the <#secure..> just above, so it will not be found here.

Yes, it is. If force is true, the search-forward will not be ran at
all. The idea here is that if we do not force (ie. if we're running in
the hook), we do not want to override the existing #secure tags, to
respect the users' choices.

Cheers,

A.

-- 
Antoine Beaupr? +++ R?seau Koumbit Networks +++ +1.514.387.6262 #208

Emacs: Crypto: How to get automatic encryption?

[Antoine Beaupré]

Jumping in here, I have modified the previously posted code here to
provide me with a more complete solution.

With the attach code, I can:

 * automatically encrypt mails if all recipients have a *valid* public
   key. The previous patch allowed encryption if a key existed but was
   revoked, which cause a weird UX issue where the user would be
   bothered with "No public key for..."

 * not have specify if i want to encrypt the mail or not: it is
   encrypted if possible

 * try to autodetect (by running the function directly) if the mail will
   be crypted and signed or just signed before sending

 * explicitely request the mail to be encrypted or just signed, if I
   want to, using the usual keybindings (ie. the existing #secure tags
   are respected)

So basically, this replaces the common hook:

(add-hook 'message-setup-hook 'mml-secure-sign-pgpmime)

with this:

(add-hook 'message-send-hook 'anarcat/message-set-encryption)

The rationale behind this technique is that the setup-hook runs when
recipients are not yet defined so it will always set the mail to be only
signed, even though your final recipients should be crypted. 

An alternative would be for notmuch to prompt the To: header before
setting up the buffer ("? la" Mutt), but I didn't feel like going that
way.

Code is attached. Obviously, those function names would change if they
would be to integrate into notmuch. ;)

-- next part --
A non-text attachment was scrubbed...
Name: notmuch-opportunistic.el
Type: application/emacs-lisp
Size: 1839 bytes
Desc: not available
URL: 

-- next part --

Opportunistic encryption, here we go.

a.

-- 
Evil exists to glorify the good. Evil is negative good.
It is a relative term. Evil can be transmuted into good.
What is evil to one at one time,
becomes good at another time to somebody else.
- Sivananda
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

[PATCH 1/2] lib: Add back the synchronization of 'T' flag with deleted tag.

[Antoine Beaupré]

On Sat, 07 Jan 2012 00:37:07 +0200, Jani Nikula  wrote:
> On Sat, 16 Jul 2011 23:56:12 -0400, Antoine Beaupr?  
> wrote:
> > +// TODO: this should probably be moved up in the stack to avoid
> > +// opening the config file on every message (!)
> > +config = notmuch_config_open (ctx, NULL, NULL);
> 
> The config file is for notmuch the command line tool, *not* for the
> lib. You can't call the cli from from the lib. The config (or command
> line argument) should be passed as argument, but that would require
> changing the lib interface.

I see. I wasn't aware of that.

> > + *   'T' iff the message has the "trashed" tag and
> > + *   state->reckless_trash is TRUE.
> 
> "trashed" tag?

That should probably be "deleted".

> The comment (and the commit message) is incorrect. You only check for
> reckless_trash in maildir_flags_to_tags, not tags_to_maildir_flags.
> With this patch, one-way syncing from tags to flags would be done
> unconditionally. And if I understand the problem correctly, you're
> fixing the less critical one of the two!

Indeed! What an oversight...

> I am wondering (but I'm too tired to check) if the original problem
> could be avoided by simply refusing to sync "deleted" tag to 'T' flag if
> there are more than one file for that message.

That would be a great idea.

> This is a dangerous feature, which is why it was originally
> disabled. Accidentally deleting mail is not something people take
> lightly. They'll be amused by "reckless trash" - until it recklessly
> deletes an important mail.

Yes, I understand this.

> However, something like this might be a useful feature to have for
> people who want to delete mail. It would need good tests to accompany
> it, though.

And to be honest, that's where I got off the boat. :) It just got too
hard, and anyways I use a custom script that deletes mails from notmuch
search tag:deleted, so syncing that flag isn't so important for me.

I guess this got everything covered for me. I would be ready to accept
this patch being dropped from the queue, although I think it's a key
step in having a more general tag to maildir flags synchronisation
strategy that would allow to run notmuch from multiple clients, without
having to sync databases around.

Thanks for the review, this patch is indeed not ready, and I am not sure
when I will have time to push it further.

Cheers,

A.

-- 
Modern man has a kind of poverty of the spirit which stands
in great contrast to his remarkable scientific and technological
achievements. We've learned to walk in outer space and yet we
haven't learned to walk to earth as brothers and sisters.
- Dr. Martin Luther King, Jr.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

[PATCH 1/2] add notmuch keybinding 'd'

[Antoine Beaupré]

On Wed, 04 Jan 2012 08:52:13 +, David Edmondson  wrote:
> On Tue, 03 Jan 2012 14:56:50 +, David Edmondson  wrote:
> > On Sat, 16 Jul 2011 14:39:59 -0400, Antoine Beaupr?  > koumbit.org> wrote:
> > > It adds a tag 'deleted' and removes the tags 'inbox' and 'unread'. It
> > > works in show as well as in search mode
> > 
> > Various people have asked for a keybinding to add a 'delete' tag. Is
> > this version the right one to choose?
> 
> No-one has spoken up in favour of this particular change (and the removal
> of "unread" seems questionable) so I plan to mark it 'obsolete'. If
> anyone would like to bring it back, please post an updated version of
> the patch and argue for it.

I do think this is superseded by this:

id:"1325975294-646-4-git-send-email-jrollins at finestructure.net"

Thanks again Jamie. :)

A.

-- 
La nature n'a cr?? ni ma?tres ni esclaves
Je ne veux ni donner ni recevoir de lois.
- Denis Diderot
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

[PATCH 1/2] add notmuch keybinding 'd'

[Antoine Beaupré]

On Fri, 06 Jan 2012 16:51:51 -0400, David Bremner  wrote:
> On Fri, 06 Jan 2012 15:10:57 -0500, Antoine Beaupr?  
> wrote:
> > On Tue, 03 Jan 2012 21:57:22 +0200, Jani Nikula  wrote:
> 
> >  * lib: add 'safe' setting for flags
> >  * lib: Add back the synchronization of 'T' flag with deleted tag
> >  * run notmuch-hello-mode-hook at the end of the hello mode setup
> 
> > 
> > Most of those do not change the current behavior, and I have been
> > running them for more than 4 months.
> > 
> > I'd very much like to get help to get this in... 
> 
> Hi Antoine;
> 
> I understand your frustration; it's not very motivating to feel
> ignored. Over the last few months we have been working to develop a
> patch review process for notmuch [1], but as you can see from [2] there
> is still a backlog of patches that have not been reviewed, the two lib
> patches you mention among them. More reviewers are always welcome ;).

Hi,

Thanks for the nice words.

I am sorry I whined on the list like this. :) I guess I was a bit tired
and disappointed no progress had been done on those patches, but I
understand how hard it is to keep up with the crazy flood on the list.

> [1]: http://notmuchmail.org/nmbug/
> [2]: http://nmbug.tethera.net/status/

This is a great initiative!

I am glad to see my patches still sitting there at least! ;) And I am
also happy to see Jamie's patches for the delete key there, if I had
more time I would actually go through and review them, unfortunately, I
have very little time to review stuff that, honestly, "just works" for
me right now. ;)

Sorry again for the outburst, keep up the good work!

A.

-- 
La guerre, c'est le massacre d'hommes qui ne se connaissent pas,
au profit d'hommes qui se connaissent mais ne se massacreront pas.
- Paul Val?ry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: [PATCH 1/2] add notmuch keybinding 'd'

[Antoine Beaupré]

On Fri, 06 Jan 2012 16:51:51 -0400, David Bremner da...@tethera.net wrote:
 On Fri, 06 Jan 2012 15:10:57 -0500, Antoine Beaupré anar...@koumbit.org 
 wrote:
  On Tue, 03 Jan 2012 21:57:22 +0200, Jani Nikula j...@nikula.org wrote:
 
   * lib: add 'safe' setting for flags
   * lib: Add back the synchronization of 'T' flag with deleted tag
   * run notmuch-hello-mode-hook at the end of the hello mode setup
 
  
  Most of those do not change the current behavior, and I have been
  running them for more than 4 months.
  
  I'd very much like to get help to get this in... 
 
 Hi Antoine;
 
 I understand your frustration; it's not very motivating to feel
 ignored. Over the last few months we have been working to develop a
 patch review process for notmuch [1], but as you can see from [2] there
 is still a backlog of patches that have not been reviewed, the two lib
 patches you mention among them. More reviewers are always welcome ;).

Hi,

Thanks for the nice words.

I am sorry I whined on the list like this. :) I guess I was a bit tired
and disappointed no progress had been done on those patches, but I
understand how hard it is to keep up with the crazy flood on the list.

 [1]: http://notmuchmail.org/nmbug/
 [2]: http://nmbug.tethera.net/status/

This is a great initiative!

I am glad to see my patches still sitting there at least! ;) And I am
also happy to see Jamie's patches for the delete key there, if I had
more time I would actually go through and review them, unfortunately, I
have very little time to review stuff that, honestly, just works for
me right now. ;)

Sorry again for the outburst, keep up the good work!

A.

-- 
La guerre, c'est le massacre d'hommes qui ne se connaissent pas,
au profit d'hommes qui se connaissent mais ne se massacreront pas.
- Paul Valéry


pgpYinAvqsFLV.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 1/2] lib: Add back the synchronization of 'T' flag with deleted tag.

[Antoine Beaupré]

On Sat, 07 Jan 2012 00:37:07 +0200, Jani Nikula j...@nikula.org wrote:
 On Sat, 16 Jul 2011 23:56:12 -0400, Antoine Beaupré anar...@koumbit.org 
 wrote:
  +// TODO: this should probably be moved up in the stack to avoid
  +// opening the config file on every message (!)
  +config = notmuch_config_open (ctx, NULL, NULL);
 
 The config file is for notmuch the command line tool, *not* for the
 lib. You can't call the cli from from the lib. The config (or command
 line argument) should be passed as argument, but that would require
 changing the lib interface.

I see. I wasn't aware of that.

  + *   'T' iff the message has the trashed tag and
  + *   state-reckless_trash is TRUE.
 
 trashed tag?

That should probably be deleted.

 The comment (and the commit message) is incorrect. You only check for
 reckless_trash in maildir_flags_to_tags, not tags_to_maildir_flags.
 With this patch, one-way syncing from tags to flags would be done
 unconditionally. And if I understand the problem correctly, you're
 fixing the less critical one of the two!

Indeed! What an oversight...

 I am wondering (but I'm too tired to check) if the original problem
 could be avoided by simply refusing to sync deleted tag to 'T' flag if
 there are more than one file for that message.

That would be a great idea.

 This is a dangerous feature, which is why it was originally
 disabled. Accidentally deleting mail is not something people take
 lightly. They'll be amused by reckless trash - until it recklessly
 deletes an important mail.

Yes, I understand this.

 However, something like this might be a useful feature to have for
 people who want to delete mail. It would need good tests to accompany
 it, though.

And to be honest, that's where I got off the boat. :) It just got too
hard, and anyways I use a custom script that deletes mails from notmuch
search tag:deleted, so syncing that flag isn't so important for me.

I guess this got everything covered for me. I would be ready to accept
this patch being dropped from the queue, although I think it's a key
step in having a more general tag to maildir flags synchronisation
strategy that would allow to run notmuch from multiple clients, without
having to sync databases around.

Thanks for the review, this patch is indeed not ready, and I am not sure
when I will have time to push it further.

Cheers,

A.

-- 
Modern man has a kind of poverty of the spirit which stands
in great contrast to his remarkable scientific and technological
achievements. We've learned to walk in outer space and yet we
haven't learned to walk to earth as brothers and sisters.
- Dr. Martin Luther King, Jr.


pgpTZLrCrIF2C.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH 1/2] add notmuch keybinding 'd'

[Antoine Beaupré]

On Tue, 03 Jan 2012 21:57:22 +0200, Jani Nikula  wrote:
> I wouldn't use it either, and I don't use "deleted" tag in the first
> place. And even if I used it, I'd still like to keep the distinction
> between "deleted after reading" and "deleted unread", which this patch
> loses by removing the "unread" tag.

I have been using this for months now.

But honestly, I don't care much anymore: the hard part is not the tag,
it's what you do with it after (hint: just remove the damn file).

Most patches I have submitted here haven't been accepted and I have to
painfully reroll my own packages every time there's a new release, which
has been a very frustrating experience. To see such a trivial patch
obsoleted tops it.

For the curious, those (other) patches are:

 * lib: add 'safe' setting for flags
 * lib: Add back the synchronization of 'T' flag with deleted tag
 * run notmuch-hello-mode-hook at the end of the hello mode setup

Most of those do not change the current behavior, and I have been
running them for more than 4 months.

I'd very much like to get help to get this in... 

A.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: [PATCH 1/2] add notmuch keybinding 'd'

[Antoine Beaupré]

On Tue, 03 Jan 2012 21:57:22 +0200, Jani Nikula j...@nikula.org wrote:
 I wouldn't use it either, and I don't use deleted tag in the first
 place. And even if I used it, I'd still like to keep the distinction
 between deleted after reading and deleted unread, which this patch
 loses by removing the unread tag.

I have been using this for months now.

But honestly, I don't care much anymore: the hard part is not the tag,
it's what you do with it after (hint: just remove the damn file).

Most patches I have submitted here haven't been accepted and I have to
painfully reroll my own packages every time there's a new release, which
has been a very frustrating experience. To see such a trivial patch
obsoleted tops it.

For the curious, those (other) patches are:

 * lib: add 'safe' setting for flags
 * lib: Add back the synchronization of 'T' flag with deleted tag
 * run notmuch-hello-mode-hook at the end of the hello mode setup

Most of those do not change the current behavior, and I have been
running them for more than 4 months.

I'd very much like to get help to get this in... 

A.


pgpBBUYcqd9cb.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH 2/2] add edit function to resume postponed emails

[Antoine Beaupré]

On Thu, 21 Jul 2011 14:58:22 -0700, Jameson Graef Rollins  wrote:
> As for resuming postponed messages, I have defined the following key
> binding, which I use on draft messages that have been indexed by
> notmuch:
[...]

So I have improved on this, I believe. I now have this in my .emacs as
test code for a new postpone workflow. I have completely ditched my
older patches in favor of this approach.

The general workflow is this:

 1. start writing an email
 2. postpone it with C-c C-d, as usual
   -> the mail gets saved to a (currently hardcoded) maildir mailbox
 using the notmuch's FCC routines
 3. notmuch new eventually happens (not ran automatically, maybe we should?)
 4. load the "tag:draft" search or the above mailbox in some way or
 another
 5. show the draft you want to resume and hit R
 6. finish editing the email and send it
   -> the mail gets deleted from the maildir

If instead of sending the mail the buffer is killed, the draft is left
alone.

I can already think of a few improvements:

 * make variable for the draft folder
 * automatically tag drafts with the draft tag (so notmuch new is not
   necessary)
 * hotkey for loading the draft search
 * kill or save a draft (after confirmation) when killing a buffer

It's still quite messy, but I wanted to share with the list here the
working code I had. I would welcome feedback on how to integrate this
into notmuch...

Thanks!

A.

(defun anarcat/notmuch-message-setup ()
  "Configures a bunch of hooks for notmuch message windows"
  (message-add-action `(message "debug: done exit actions") 'exit)
  (message-add-action `(message "debug: done postpone actions") 'postpone)
  (message-add-action `(message "debug: done kill actions") 'kill)
  (message-add-action 'notmuch-message-postpone-keep 'postpone)
  (message-add-action 'notmuch-message-postpone-cleanup 'exit)
)
(add-hook 'message-mode-hook 'anarcat/notmuch-message-setup)

(defun notmuch-message-postpone-cleanup ()
  "Remove autosave and postponed messages for that buffer"
  (message "debug: postpone cleanup hook")
  (message "deleting draft file: %s" notmuch-draft-filename)
  (if (file-exists-p notmuch-draft-filename)
  (progn 
(kill-buffer)
(delete-file notmuch-draft-filename)
(if (file-exists-p notmuch-draft-filename)
(message "failed to delete file %s" notmuch-draft-filename)
  (message "debug: file deleted"))
)
(message "draft file %s doesn't exist" notmuch-draft-filename)))

(defun notmuch-message-postpone-keep ()
  "Moves the previous buffer into the postponed folder and then kill it"
  ;; shouldn't be necessary: why the heck aren't we in the right buffer?
  (save-excursion
(set-buffer (last-buffer))
(notmuch-maildir-fcc-write-buffer-to-maildir "~/Maildir/Anarcat/postponed/" 
t)
(kill-buffer))
)

(defun notmuch-show-resume-message ()
  "Resume a postponed message."
  (interactive)
  (setq tmpfilename (notmuch-show-get-filename))
  (notmuch-show-view-raw-message)
  (setq buffer-file-name tmpfilename)
  (message "debug: set buffer file name to %s" buffer-file-name)
  (setq notmuch-draft-filename buffer-file-name)
  (make-local-variable 'notmuch-draft-filename)
  (message "debug: set draft file name to %s" notmuch-draft-filename)
  (message-mode))

(define-key notmuch-show-mode-map "R" 'notmuch-show-resume-message)

-- 
O gentilshommes, la vie est courte.
Si nous vivons, nous vivons 
pour marcher sur la t?te des rois.
- William Shakespeare
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

[PATCH] run notmuch-hello-mode-hook at the end of the hello mode setup

[Antoine Beaupré]

i mostly use this to start offlineimap.el, but it could be used for
other purposes. i have not added hooks to other modes, but those could
be interesting as well. i am unsure as to how to make unit tests for
this.
---
 emacs/notmuch-hello.el |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index 65fde75..6389ac8 100644
--- a/emacs/notmuch-hello.el
+++ b/emacs/notmuch-hello.el
@@ -118,6 +118,11 @@ Typically \",\" in the US and UK and \".\" in Europe."
   :group 'notmuch
   :type 'string)

+(defcustom notmuch-hello-mode-hook nil
+  "Hook run at the end of `notmuch-hello-mode'."
+  :group 'notmuch
+  :type 'hook)
+
 (defvar notmuch-hello-url "http://notmuchmail.org;
   "The `notmuch' web site.")

@@ -336,6 +341,7 @@ Complete list of currently available key bindings:
  (setq major-mode 'notmuch-hello-mode
mode-name "notmuch-hello")
  ;;(setq buffer-read-only t)
+ (run-mode-hooks 'notmuch-hello-mode 'notmuch-hello-mode-hook)
 )

 (defun notmuch-hello-generate-tag-alist ()
-- 
1.7.2.5

[PATCH] run notmuch-hello-mode-hook at the end of the hello mode setup

[Antoine Beaupré]

i mostly use this to start offlineimap.el, but it could be used for
other purposes. i have not added hooks to other modes, but those could
be interesting as well. i am unsure as to how to make unit tests for
this.
---
 emacs/notmuch-hello.el |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index 65fde75..6389ac8 100644
--- a/emacs/notmuch-hello.el
+++ b/emacs/notmuch-hello.el
@@ -118,6 +118,11 @@ Typically \,\ in the US and UK and \.\ in Europe.
   :group 'notmuch
   :type 'string)
 
+(defcustom notmuch-hello-mode-hook nil
+  Hook run at the end of `notmuch-hello-mode'.
+  :group 'notmuch
+  :type 'hook)
+
 (defvar notmuch-hello-url http://notmuchmail.org;
   The `notmuch' web site.)
 
@@ -336,6 +341,7 @@ Complete list of currently available key bindings:
  (setq major-mode 'notmuch-hello-mode
mode-name notmuch-hello)
  ;;(setq buffer-read-only t)
+ (run-mode-hooks 'notmuch-hello-mode 'notmuch-hello-mode-hook)
 )
 
 (defun notmuch-hello-generate-tag-alist ()
-- 
1.7.2.5

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 2/2] add edit function to resume postponed emails

[Antoine Beaupré]

On Thu, 21 Jul 2011 14:58:22 -0700, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 As for resuming postponed messages, I have defined the following key
 binding, which I use on draft messages that have been indexed by
 notmuch:
[...]

So I have improved on this, I believe. I now have this in my .emacs as
test code for a new postpone workflow. I have completely ditched my
older patches in favor of this approach.

The general workflow is this:

 1. start writing an email
 2. postpone it with C-c C-d, as usual
   - the mail gets saved to a (currently hardcoded) maildir mailbox
 using the notmuch's FCC routines
 3. notmuch new eventually happens (not ran automatically, maybe we should?)
 4. load the tag:draft search or the above mailbox in some way or
 another
 5. show the draft you want to resume and hit R
 6. finish editing the email and send it
   - the mail gets deleted from the maildir

If instead of sending the mail the buffer is killed, the draft is left
alone.

I can already think of a few improvements:

 * make variable for the draft folder
 * automatically tag drafts with the draft tag (so notmuch new is not
   necessary)
 * hotkey for loading the draft search
 * kill or save a draft (after confirmation) when killing a buffer

It's still quite messy, but I wanted to share with the list here the
working code I had. I would welcome feedback on how to integrate this
into notmuch...

Thanks!

A.

(defun anarcat/notmuch-message-setup ()
  Configures a bunch of hooks for notmuch message windows
  (message-add-action `(message debug: done exit actions) 'exit)
  (message-add-action `(message debug: done postpone actions) 'postpone)
  (message-add-action `(message debug: done kill actions) 'kill)
  (message-add-action 'notmuch-message-postpone-keep 'postpone)
  (message-add-action 'notmuch-message-postpone-cleanup 'exit)
)
(add-hook 'message-mode-hook 'anarcat/notmuch-message-setup)

(defun notmuch-message-postpone-cleanup ()
  Remove autosave and postponed messages for that buffer
  (message debug: postpone cleanup hook)
  (message deleting draft file: %s notmuch-draft-filename)
  (if (file-exists-p notmuch-draft-filename)
  (progn 
(kill-buffer)
(delete-file notmuch-draft-filename)
(if (file-exists-p notmuch-draft-filename)
(message failed to delete file %s notmuch-draft-filename)
  (message debug: file deleted))
)
(message draft file %s doesn't exist notmuch-draft-filename)))

(defun notmuch-message-postpone-keep ()
  Moves the previous buffer into the postponed folder and then kill it
  ;; shouldn't be necessary: why the heck aren't we in the right buffer?
  (save-excursion
(set-buffer (last-buffer))
(notmuch-maildir-fcc-write-buffer-to-maildir ~/Maildir/Anarcat/postponed/ 
t)
(kill-buffer))
)

(defun notmuch-show-resume-message ()
  Resume a postponed message.
  (interactive)
  (setq tmpfilename (notmuch-show-get-filename))
  (notmuch-show-view-raw-message)
  (setq buffer-file-name tmpfilename)
  (message debug: set buffer file name to %s buffer-file-name)
  (setq notmuch-draft-filename buffer-file-name)
  (make-local-variable 'notmuch-draft-filename)
  (message debug: set draft file name to %s notmuch-draft-filename)
  (message-mode))

(define-key notmuch-show-mode-map R 'notmuch-show-resume-message)

-- 
O gentilshommes, la vie est courte.
Si nous vivons, nous vivons 
pour marcher sur la tête des rois.
- William Shakespeare


pgp3ot1ZRpvIe.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH 2/2] add edit function to resume postponed emails

[Antoine Beaupré]

On Thu, 21 Jul 2011 14:58:22 -0700, Jameson Graef Rollins  wrote:
> On Thu, 21 Jul 2011 23:32:58 +0200, Xavier Maillard  
> wrote:
> > Maybe I misunderstood original goal but what I had in mind reading this
> > is certainly not editing a priviously received message in order to
> > (re)send it again but sending a postponed/draft message which, I guess,
> > means no full header(s) (no received header and such and probably
> > partially filled header, if any).
> 
> Hey, Xavier.  I was just responding to Antoine's comment that he had
> "trouble making message-mode digest an existing buffer".
> 
> As for resuming postponed messages, I have defined the following key
> binding, which I use on draft messages that have been indexed by
> notmuch:
> 
> (define-key notmuch-show-mode-map "R"
>   (lambda ()
> "Resume a postponed message."
> (interactive)
> (notmuch-show-view-raw-message)
> (message-mode)))

Now that's a pretty good start!

It will not work to edit sent mails (which are QP-encoded, for example),
but it should work for postponed messages..

How about we patch that in? Seems like a major feature missing...

A.

-- 
L'art n'est pas un bureau d'anthropom?trie.
- L?o Ferr?, "Pr?face"
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: [PATCH 2/2] add edit function to resume postponed emails

[Antoine Beaupré]

On Thu, 21 Jul 2011 14:58:22 -0700, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 On Thu, 21 Jul 2011 23:32:58 +0200, Xavier Maillard xav...@maillard.im 
 wrote:
  Maybe I misunderstood original goal but what I had in mind reading this
  is certainly not editing a priviously received message in order to
  (re)send it again but sending a postponed/draft message which, I guess,
  means no full header(s) (no received header and such and probably
  partially filled header, if any).
 
 Hey, Xavier.  I was just responding to Antoine's comment that he had
 trouble making message-mode digest an existing buffer.
 
 As for resuming postponed messages, I have defined the following key
 binding, which I use on draft messages that have been indexed by
 notmuch:
 
 (define-key notmuch-show-mode-map R
   (lambda ()
 Resume a postponed message.
 (interactive)
 (notmuch-show-view-raw-message)
 (message-mode)))

Now that's a pretty good start!

It will not work to edit sent mails (which are QP-encoded, for example),
but it should work for postponed messages..

How about we patch that in? Seems like a major feature missing...

A.

-- 
L'art n'est pas un bureau d'anthropométrie.
- Léo Ferré, Préface


pgpL6Mll8rQsq.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH 2/2] add edit function to resume postponed emails

[Antoine Beaupré]

On Sat, 16 Jul 2011 15:31:31 -0400, Austin Clements  wrote:
> I think this could be simplified a lot and many of the known issues
> addressed if this were narrowed to *only* resuming from drafts.
> message-mode draft files aren't MIME messages (or, at least, they're
> never multipart, and message-mode has its own special annotations over
> basic RFC 822), so rather than treating the draft as a MIME message
> and trying to transform it back into a message-mode-compatible draft
> (which, in full generality, would be somewhere between hard and
> impossible), what about just dumping the raw contents of the draft
> file into a buffer and pointing message-mode at it?  If the draft file
> is available, you could even open it directly (this wouldn't work for
> remote usage, but remote drafts introduce many other problems, too).

I think this is a great idea. Unfortunately, I had a lot of trouble
making message-mode digest an existing buffer. For example, if you take
any existing buffer and call (message-mode) on it, you will notice it
will clear the buffer completely.

I guess I would need to look at how (notmuch-mua-edit-mail) does it but
it was the blocker i had when i tried to figure this out..

Any suggestions?

A.

-- 
To be naive and easily deceived is impermissible, today more than
ever, when the prevailing untruths may lead to a catastrophe because
they blind people to real dangers and real possibilities.
- Erich Fromm
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: [PATCH 2/2] add edit function to resume postponed emails

[Antoine Beaupré]

On Sat, 16 Jul 2011 15:31:31 -0400, Austin Clements amdra...@mit.edu wrote:
 I think this could be simplified a lot and many of the known issues
 addressed if this were narrowed to *only* resuming from drafts.
 message-mode draft files aren't MIME messages (or, at least, they're
 never multipart, and message-mode has its own special annotations over
 basic RFC 822), so rather than treating the draft as a MIME message
 and trying to transform it back into a message-mode-compatible draft
 (which, in full generality, would be somewhere between hard and
 impossible), what about just dumping the raw contents of the draft
 file into a buffer and pointing message-mode at it?  If the draft file
 is available, you could even open it directly (this wouldn't work for
 remote usage, but remote drafts introduce many other problems, too).

I think this is a great idea. Unfortunately, I had a lot of trouble
making message-mode digest an existing buffer. For example, if you take
any existing buffer and call (message-mode) on it, you will notice it
will clear the buffer completely.

I guess I would need to look at how (notmuch-mua-edit-mail) does it but
it was the blocker i had when i tried to figure this out..

Any suggestions?

A.

-- 
To be naive and easily deceived is impermissible, today more than
ever, when the prevailing untruths may lead to a catastrophe because
they blind people to real dangers and real possibilities.
- Erich Fromm


pgp2pNs2TFrvJ.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH 2/2] lib: add 'safe' setting for flags

[Antoine Beaupré]

the 'safe' setting needs to be 'true' for flags to be manipulated by
notmuch new/tag/restore.

for now, only the (T)rash tag is configurable and set to false (by
default) but this could be extended to allow the user to configure which
flags are allowed to be synchronized.

the reason why only T is configurable is because (a) it's the the only
one that is actually dangerous and (b) I couldn't figure out how to
properly configure multiple settings like this.
---
 lib/message.cc|   40 +---
 lib/notmuch.h |   20 
 notmuch-new.c |1 +
 notmuch-restore.c |1 +
 notmuch-tag.c |1 +
 5 files changed, 44 insertions(+), 19 deletions(-)

diff --git a/lib/message.cc b/lib/message.cc
index f633887..f812648 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -50,16 +50,17 @@ struct maildir_flag_tag {
 char flag;
 const char *tag;
 bool inverse;
+bool safe;
 };

 /* ASCII ordered table of Maildir flags and associated tags */
 static struct maildir_flag_tag flag2tag[] = {
-{ 'D', "draft",   false},
-{ 'F', "flagged", false},
-{ 'P', "passed",  false},
-{ 'R', "replied", false},
-{ 'S', "unread",  true },
-{ 'T', "deleted", false},
+{ 'D', "draft",   false, true},
+{ 'F', "flagged", false, true},
+{ 'P', "passed",  false, true},
+{ 'R', "replied", false, true},
+{ 'S', "unread",  true , true},
+{ 'T', "deleted", false, false},
 };

 /* We end up having to call the destructor explicitly because we had
@@ -994,7 +995,6 @@ notmuch_message_maildir_flags_to_tags (notmuch_message_t 
*message)
 char *combined_flags = talloc_strdup (message, "");
 unsigned i;
 int seen_maildir_info = 0;
-notmuch_bool_t reckless_trash;

 for (filenames = notmuch_message_get_filenames (message);
 notmuch_filenames_valid (filenames);
@@ -1022,15 +1022,8 @@ notmuch_message_maildir_flags_to_tags (notmuch_message_t 
*message)
 if (status)
return status;

-// TODO: this should probably be moved up in the stack to avoid
-// opening the config file on every message (!)
-config = notmuch_config_open (ctx, NULL, NULL);
-if (config == NULL)
-   return 1;
-reckless_trash = notmuch_config_get_maildir_reckless_trash (config);
-
 for (i = 0; i < ARRAY_SIZE(flag2tag); i++) {
-   if (flag2tag[i].flag == 'T' && !reckless_trash) {
+   if (!flag2tag[i].safe) {
continue;
}
if ((strchr (combined_flags, flag2tag[i].flag) != NULL)
@@ -1119,6 +1112,9 @@ _get_maildir_flag_actions (notmuch_message_t *message,
tag = notmuch_tags_get (tags);

for (i = 0; i < ARRAY_SIZE (flag2tag); i++) {
+   if (!flag2tag[i].safe) {
+   continue;
+   }
if (strcmp (tag, flag2tag[i].tag) == 0) {
if (flag2tag[i].inverse)
to_clear = talloc_asprintf_append (to_clear,
@@ -1134,6 +1130,9 @@ _get_maildir_flag_actions (notmuch_message_t *message,

 /* Then, find the flags for all tags not present. */
 for (i = 0; i < ARRAY_SIZE (flag2tag); i++) {
+   if (!flag2tag[i].safe) {
+   continue;
+   }
if (flag2tag[i].inverse) {
if (strchr (to_clear, flag2tag[i].flag) == NULL)
to_set = talloc_asprintf_append (to_set, "%c", 
flag2tag[i].flag);
@@ -1256,6 +1255,17 @@ _new_maildir_filename (void *ctx,
 return filename_new;
 }

+void
+notmuch_message_set_flag_safety (char flag, notmuch_bool_t safe)
+{
+unsigned i;
+for (i = 0; i < ARRAY_SIZE (flag2tag); i++) {
+if (flag2tag[i].flag == flag) {
+flag2tag[i].safe = safe;
+}
+}
+}
+
 notmuch_status_t
 notmuch_message_tags_to_maildir_flags (notmuch_message_t *message)
 {
diff --git a/lib/notmuch.h b/lib/notmuch.h
index f0c1b67..475e75a 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -922,8 +922,7 @@ notmuch_message_remove_all_tags (notmuch_message_t 
*message);
  * 'P' Adds the "passed" tag to the message
  * 'R' Adds the "replied" tag to the message
  * 'S' Removes the "unread" tag from the message
- * 'T' Adds the "deleted" tag to the message and
- * state->reckless_trash is TRUE.
+ * 'T' Adds the "deleted" tag to the message
  *
  * For each flag that is not present, the opposite action (add/remove)
  * is performed for the corresponding tags.
@@ -941,6 +940,9 @@ notmuch_message_remove_all_tags (notmuch_message_t 
*message);
  * notmuch_database_add_message. See also
  * notmuch_message_tags_to_maildir_flags for synchronizing tag changes
  * back to maildir flags.
+ *
+ * Actions are performed only if the tag is marked as "safe" in the
+ * configuration (only used by maildir_reckless_trash for now).
  */
 notmuch_status_t
 notmuch_message_maildir_flags_to_tags (notmuch_message_t *message);
@@ -964,8 +966,7 @@ notmuch_message_maildir_flags_to_tags (notmuch_message_t 

[PATCH 1/2] lib: Add back the synchronization of 'T' flag with deleted tag.

[Antoine Beaupré]

This adds a special configuration, off by default, that allows notmuch
to synchronize the T flag again. The configuration is named
maildir_reckless_trash and quite clearly indicates that it could be
dangerous to use in the context described in commit 2c26204, which I
could actually reproduce.

In contexts where notmuch is the only mail client used, this is actually
safe to use. Besides, (T)rashed messages are not necessarily immediately
expunged from the Maildir by the client or the IMAP server.

Signed-off-by: Antoine Beaupr? 
---
 lib/message.cc   |   14 +-
 lib/notmuch.h|4 
 notmuch-client.h |7 +++
 notmuch-config.c |   50 +++---
 4 files changed, 71 insertions(+), 4 deletions(-)

diff --git a/lib/message.cc b/lib/message.cc
index d993cde..f633887 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -58,7 +58,8 @@ static struct maildir_flag_tag flag2tag[] = {
 { 'F', "flagged", false},
 { 'P', "passed",  false},
 { 'R', "replied", false},
-{ 'S', "unread",  true }
+{ 'S', "unread",  true },
+{ 'T', "deleted", false},
 };

 /* We end up having to call the destructor explicitly because we had
@@ -993,6 +994,7 @@ notmuch_message_maildir_flags_to_tags (notmuch_message_t 
*message)
 char *combined_flags = talloc_strdup (message, "");
 unsigned i;
 int seen_maildir_info = 0;
+notmuch_bool_t reckless_trash;

 for (filenames = notmuch_message_get_filenames (message);
 notmuch_filenames_valid (filenames);
@@ -1020,7 +1022,17 @@ notmuch_message_maildir_flags_to_tags (notmuch_message_t 
*message)
 if (status)
return status;

+// TODO: this should probably be moved up in the stack to avoid
+// opening the config file on every message (!)
+config = notmuch_config_open (ctx, NULL, NULL);
+if (config == NULL)
+   return 1;
+reckless_trash = notmuch_config_get_maildir_reckless_trash (config);
+
 for (i = 0; i < ARRAY_SIZE(flag2tag); i++) {
+   if (flag2tag[i].flag == 'T' && !reckless_trash) {
+   continue;
+   }
if ((strchr (combined_flags, flag2tag[i].flag) != NULL)
^ 
flag2tag[i].inverse)
diff --git a/lib/notmuch.h b/lib/notmuch.h
index 974be8d..f0c1b67 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -922,6 +922,8 @@ notmuch_message_remove_all_tags (notmuch_message_t 
*message);
  * 'P' Adds the "passed" tag to the message
  * 'R' Adds the "replied" tag to the message
  * 'S' Removes the "unread" tag from the message
+ * 'T' Adds the "deleted" tag to the message and
+ * state->reckless_trash is TRUE.
  *
  * For each flag that is not present, the opposite action (add/remove)
  * is performed for the corresponding tags.
@@ -962,6 +964,8 @@ notmuch_message_maildir_flags_to_tags (notmuch_message_t 
*message);
  *   'P' iff the message has the "passed" tag
  *   'R' iff the message has the "replied" tag
  *   'S' iff the message does not have the "unread" tag
+ *   'T' iff the message has the "trashed" tag and
+ *   state->reckless_trash is TRUE.
  *
  * Any existing flags unmentioned in the list above will be preserved
  * in the renaming.
diff --git a/notmuch-client.h b/notmuch-client.h
index 63be337..62d1e0e 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -235,6 +235,13 @@ notmuch_config_set_maildir_synchronize_flags 
(notmuch_config_t *config,
  notmuch_bool_t synchronize_flags);

 notmuch_bool_t
+notmuch_config_get_maildir_reckless_trash (notmuch_config_t *config);
+
+void
+notmuch_config_set_maildir_reckless_trash (notmuch_config_t *config,
+  notmuch_bool_t reckless_trash);
+
+notmuch_bool_t
 debugger_is_active (void);

 #endif
diff --git a/notmuch-config.c b/notmuch-config.c
index 485fa72..613fefc 100644
--- a/notmuch-config.c
+++ b/notmuch-config.c
@@ -67,9 +67,11 @@ static const char maildir_config_comment[] =
 " The following option is supported here:\n"
 "\n"
 "\tsynchronize_flags  Valid values are true and false.\n"
+"\treckless_trash Valid values are true and false.\n"
 "\n"
-"\tIf true, then the following maildir flags (in message filenames)\n"
-"\twill be synchronized with the corresponding notmuch tags:\n"
+"\tIf synchronize_flags is true, then the following maildir flags\n"
+"\t(in message filenames) will be synchronized with the corresponding\n"
+"\tnotmuch tags:\n"
 "\n"
 "\t\tFlag  Tag\n"
 "\t\t  ---\n"
@@ -78,10 +80,26 @@ static const char maildir_config_comment[] =
 "\t\tP passed\n"
 "\t\tR replied\n"
 "\t\tS unread (added when 'S' flag is not present)\n"
+"\t\tT trashed (only if maildir_reckless_trash is enabled)\n"
 "\n"
 "\tThe \"notmuch new\" command will notice flag changes in filenames\n"
 "\tand update tags, while the \"notmuch 

[PATCH 1/2] add notmuch keybinding 'd'

[Antoine Beaupré]

It adds a tag 'deleted' and removes the tags 'inbox' and 'unread'. It
works in show as well as in search mode

Based on previous work by: Sebastian Spaeth 

Signed-off-by: Antoine Beaupr? 
---
 emacs/notmuch-show.el |8 
 emacs/notmuch.el  |   11 +++
 2 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index f96743b..c83b992 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -875,6 +875,7 @@ function is used. "
(define-key map "+" 'notmuch-show-add-tag)
(define-key map "x" 'notmuch-show-archive-thread-then-exit)
(define-key map "a" 'notmuch-show-archive-thread)
+   (define-key map "d" 'notmuch-show-delete)
(define-key map "N" 'notmuch-show-next-message)
(define-key map "P" 'notmuch-show-previous-message)
(define-key map "n" 'notmuch-show-next-open-message)
@@ -1297,6 +1298,13 @@ the result."
 (mapcar (lambda (s) (concat "-" s)) toremove))
   (notmuch-show-set-tags new-tags

+(defun notmuch-show-delete ()
+  "Delete current mail (tag +deleted -unread -inbox)."
+  (interactive)
+  (notmuch-show-add-tag "deleted")
+  (notmuch-show-remove-tag "unread")
+  (notmuch-show-remove-tag "inbox"))
+
 (defun notmuch-show-toggle-headers ()
   "Toggle the visibility of the current message headers."
   (interactive)
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index f11ec24..f6fb07b 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -215,6 +215,7 @@ For a mouse binding, return nil."
 (define-key map [mouse-1] 'notmuch-search-show-thread)
 (define-key map "*" 'notmuch-search-operate-all)
 (define-key map "a" 'notmuch-search-archive-thread)
+(define-key map "d" 'notmuch-search-delete-thread-or-region)
 (define-key map "-" 'notmuch-search-remove-tag)
 (define-key map "+" 'notmuch-search-add-tag)
 (define-key map (kbd "RET") 'notmuch-search-show-thread)
@@ -611,6 +612,16 @@ This function advances the next thread when finished."
   "Data that has not yet been processed.")
 (make-variable-buffer-local 'notmuch-search-process-filter-data)

+(defun notmuch-search-delete-thread-or-region ()
+  "Delete the currently selected thread (tag \"+deleted -inbox -unread\").
+
+This function advances the next thread when finished."
+  (interactive)
+  (notmuch-search-add-tag "deleted")
+  (notmuch-search-remove-tag "inbox")
+  (notmuch-search-remove-tag "unread")
+  (forward-line))
+
 (defun notmuch-search-process-sentinel (proc msg)
   "Add a message to let user know when \"notmuch search\" exits"
   (let ((buffer (process-buffer proc))
-- 
1.7.5.4

[PATCH] add edit function to resume postponed emails (v2)

[Antoine Beaupré]

Add a new function to allow editing a new message starting from an
existing one, roughly the equivalent of Mutt's resend-message
functionality.

Hooks into the search and show views through the "e" keybinding.

"postponed" tag is removed after the email is sent and the target thread
is marked as deleted.

Known issues:

 1. only the first MIME part of the email is used
 2. running this on a thread with more than one message has not been
 tested

Signed-off-by: Antoine Beaupr? 
---
Previous patch actually had a parse error, thanks to eval-defun...

 emacs/notmuch-mua.el  |   50 +
 emacs/notmuch-show.el |6 +
 emacs/notmuch.el  |7 ++
 3 files changed, 63 insertions(+), 0 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index 274c5da..cd32c55 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -201,6 +201,56 @@ the From: address first."
   (list (cons 'from (notmuch-mua-prompt-for-sender))
 (notmuch-mua-mail nil nil other-headers)))

+(defun notmuch-mua-delete-postponed (query-string)
+  "Delete postponed mail after sending."
+  (notmuch-tag query-string "+delete")
+  (notmuch-tag query-string "-postponed")
+)
+
+(defun notmuch-mua-edit-mail (query-string)
+  "Create a new mail composition window based on the current mail."
+  (interactive)
+  (let (headers
+   body
+   (args '("show" "--format=raw")))
+(if notmuch-show-process-crypto
+   (setq args (append args '("--decrypt"
+(setq args (append args (list query-string)))
+;; This make assumptions about the output of `notmuch show', but
+;; really only that the headers come first followed by a blank
+;; line and then the body.
+(with-temp-buffer
+  (apply 'call-process (append (list notmuch-command nil (list t t) nil) 
args))
+  (goto-char (point-min))
+  (if (re-search-forward "^$" nil t)
+ (save-excursion
+   (save-restriction
+ (narrow-to-region (point-min) (point))
+ (goto-char (point-min))
+ (setq headers (mail-header-extract
+ )
+  (forward-line 1)
+  (setq body (buffer-substring (point) (point-max)))
+  )
+
+(let ((message-signature nil))
+  (notmuch-mua-mail (mail-header 'to headers)
+   (mail-header 'subject headers)
+   (message-headers-to-generate headers t '(to subject))
+   t nil nil (notmuch-mua-delete-postponed query-string))
+)
+
+;; insert the message body - but put it in front of the signature
+;; if one is present
+(goto-char (point-max))
+(if (re-search-backward message-signature-separator nil t)
+ (forward-line -1)
+  (goto-char (point-max)))
+(insert body))
+  (set-buffer-modified-p nil)
+
+  (message-goto-body))
+
 (defun notmuch-mua-new-forward-message ( prompt-for-sender)
   "Invoke the notmuch message forwarding window.

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index f96743b..3698767 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -865,6 +865,7 @@ function is used. "
(define-key map "m" 'notmuch-mua-new-mail)
(define-key map "f" 'notmuch-show-forward-message)
(define-key map "r" 'notmuch-show-reply)
+   (define-key map "e" 'notmuch-show-edit)
(define-key map "|" 'notmuch-show-pipe-message)
(define-key map "w" 'notmuch-show-save-attachments)
(define-key map "V" 'notmuch-show-view-raw-message)
@@ -1164,6 +1165,11 @@ any effects from previous calls to
   (interactive "P")
   (notmuch-mua-new-reply (notmuch-show-get-message-id) prompt-for-sender))

+(defun notmuch-show-edit ()
+  "Edit the current message as new."
+  (interactive)
+  (notmuch-mua-edit-mail (notmuch-show-get-message-id)))
+
 (defun notmuch-show-forward-message ( prompt-for-sender)
   "Forward the current message."
   (interactive "P")
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index f11ec24..f18b739 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -204,6 +204,7 @@ For a mouse binding, return nil."
 (define-key map "p" 'notmuch-search-previous-thread)
 (define-key map "n" 'notmuch-search-next-thread)
 (define-key map "r" 'notmuch-search-reply-to-thread)
+(define-key map "e" 'notmuch-search-edit)
 (define-key map "m" 'notmuch-mua-new-mail)
 (define-key map "s" 'notmuch-search)
 (define-key map "o" 'notmuch-search-toggle-order)
@@ -448,6 +449,12 @@ Complete list of currently available key bindings:
   (let ((message-id (notmuch-search-find-thread-id)))
 (notmuch-mua-new-reply message-id prompt-for-sender)))

+(defun notmuch-search-edit ()
+  "Edit the current message as new."
+  (interactive)
+  (let ((message-id (notmuch-search-find-thread-id)))
+(notmuch-mua-edit-mail message-id)))
+
 (defun notmuch-call-notmuch-process ( args)
   "Synchronously invoke \"notmuch\" with the given list of 

[PATCH] add edit function to resume postponed emails

[Antoine Beaupré]

Add a new function to allow editing a new message starting from an
existing one, roughly the equivalent of Mutt's resend-message
functionality.

Hooks into the search and show views through the "e" keybinding.

"postponed" tag is removed after the email is sent and the target thread
is marked as deleted.

Known issues:

 1. only the first MIME part of the email is used
 2. running this on a thread with more than one message has not been
 tested

Signed-off-by: Antoine Beaupr? 
---
 emacs/notmuch-mua.el  |   51 +
 emacs/notmuch-show.el |6 +
 emacs/notmuch.el  |7 ++
 3 files changed, 64 insertions(+), 0 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index 274c5da..83d7d2b 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -201,6 +201,57 @@ the From: address first."
   (list (cons 'from (notmuch-mua-prompt-for-sender))
 (notmuch-mua-mail nil nil other-headers)))

+(defun notmuch-mua-delete-postponed (query-string)
+  "Delete postponed mail after sending."
+  (notmuch-tag query-string "+delete")
+  (notmuch-tag query-string "-postponed")
+)
+
+(defun notmuch-mua-edit-mail (query-string)
+  "Create a new mail composition window based on the current mail."
+  (interactive)
+  (let (headers
+   body
+   (args '("show" "--format=raw")))
+(if notmuch-show-process-crypto
+   (setq args (append args '("--decrypt"
+(setq args (append args (list query-string)))
+;; This make assumptions about the output of `notmuch show', but
+;; really only that the headers come first followed by a blank
+;; line and then the body.
+(with-temp-buffer
+  (apply 'call-process (append (list notmuch-command nil (list t t) nil) 
args))
+  (goto-char (point-min))
+  (if (re-search-forward "^$" nil t)
+ (save-excursion
+   (save-restriction
+ (narrow-to-region (point-min) (point))
+ (goto-char (point-min))
+ (setq headers (mail-header-extract
+ )
+  (forward-line 1)
+  (setq body (buffer-substring (point) (point-max)))
+  )
+
+(let ((message-signature nil))
+  (notmuch-mua-mail (mail-header 'to headers)
+   (mail-header 'subject headers)
+   (message-headers-to-generate headers t '(to subject))
+   t nil nil (notmuch-mua-delete-postponed query-string))
+)
+
+;; insert the message body - but put it in front of the signature
+;; if one is present
+(goto-char (point-max))
+(if (re-search-backward message-signature-separator nil t)
+ (forward-line -1)
+  (goto-char (point-max)))
+(insert body))
+  (set-buffer-modified-p nil)
+
+  (message-goto-body))
+)
+
 (defun notmuch-mua-new-forward-message ( prompt-for-sender)
   "Invoke the notmuch message forwarding window.

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index f96743b..3698767 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -865,6 +865,7 @@ function is used. "
(define-key map "m" 'notmuch-mua-new-mail)
(define-key map "f" 'notmuch-show-forward-message)
(define-key map "r" 'notmuch-show-reply)
+   (define-key map "e" 'notmuch-show-edit)
(define-key map "|" 'notmuch-show-pipe-message)
(define-key map "w" 'notmuch-show-save-attachments)
(define-key map "V" 'notmuch-show-view-raw-message)
@@ -1164,6 +1165,11 @@ any effects from previous calls to
   (interactive "P")
   (notmuch-mua-new-reply (notmuch-show-get-message-id) prompt-for-sender))

+(defun notmuch-show-edit ()
+  "Edit the current message as new."
+  (interactive)
+  (notmuch-mua-edit-mail (notmuch-show-get-message-id)))
+
 (defun notmuch-show-forward-message ( prompt-for-sender)
   "Forward the current message."
   (interactive "P")
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index f11ec24..f18b739 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -204,6 +204,7 @@ For a mouse binding, return nil."
 (define-key map "p" 'notmuch-search-previous-thread)
 (define-key map "n" 'notmuch-search-next-thread)
 (define-key map "r" 'notmuch-search-reply-to-thread)
+(define-key map "e" 'notmuch-search-edit)
 (define-key map "m" 'notmuch-mua-new-mail)
 (define-key map "s" 'notmuch-search)
 (define-key map "o" 'notmuch-search-toggle-order)
@@ -448,6 +449,12 @@ Complete list of currently available key bindings:
   (let ((message-id (notmuch-search-find-thread-id)))
 (notmuch-mua-new-reply message-id prompt-for-sender)))

+(defun notmuch-search-edit ()
+  "Edit the current message as new."
+  (interactive)
+  (let ((message-id (notmuch-search-find-thread-id)))
+(notmuch-mua-edit-mail message-id)))
+
 (defun notmuch-call-notmuch-process ( args)
   "Synchronously invoke \"notmuch\" with the given list of arguments.

-- 
1.7.5.4

[PATCH] add edit function to resume postponed emails

[Antoine Beaupré]

Add a new function to allow editing a new message starting from an
existing one, roughly the equivalent of Mutt's resend-message
functionality.

Hooks into the search and show views through the e keybinding.

postponed tag is removed after the email is sent and the target thread
is marked as deleted.

Known issues:

 1. only the first MIME part of the email is used
 2. running this on a thread with more than one message has not been
 tested

Signed-off-by: Antoine Beaupré anar...@koumbit.org
---
 emacs/notmuch-mua.el  |   51 +
 emacs/notmuch-show.el |6 +
 emacs/notmuch.el  |7 ++
 3 files changed, 64 insertions(+), 0 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index 274c5da..83d7d2b 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -201,6 +201,57 @@ the From: address first.
   (list (cons 'from (notmuch-mua-prompt-for-sender))
 (notmuch-mua-mail nil nil other-headers)))
 
+(defun notmuch-mua-delete-postponed (query-string)
+  Delete postponed mail after sending.
+  (notmuch-tag query-string +delete)
+  (notmuch-tag query-string -postponed)
+)
+
+(defun notmuch-mua-edit-mail (query-string)
+  Create a new mail composition window based on the current mail.
+  (interactive)
+  (let (headers
+   body
+   (args '(show --format=raw)))
+(if notmuch-show-process-crypto
+   (setq args (append args '(--decrypt
+(setq args (append args (list query-string)))
+;; This make assumptions about the output of `notmuch show', but
+;; really only that the headers come first followed by a blank
+;; line and then the body.
+(with-temp-buffer
+  (apply 'call-process (append (list notmuch-command nil (list t t) nil) 
args))
+  (goto-char (point-min))
+  (if (re-search-forward ^$ nil t)
+ (save-excursion
+   (save-restriction
+ (narrow-to-region (point-min) (point))
+ (goto-char (point-min))
+ (setq headers (mail-header-extract
+ )
+  (forward-line 1)
+  (setq body (buffer-substring (point) (point-max)))
+  )
+
+(let ((message-signature nil))
+  (notmuch-mua-mail (mail-header 'to headers)
+   (mail-header 'subject headers)
+   (message-headers-to-generate headers t '(to subject))
+   t nil nil (notmuch-mua-delete-postponed query-string))
+)
+
+;; insert the message body - but put it in front of the signature
+;; if one is present
+(goto-char (point-max))
+(if (re-search-backward message-signature-separator nil t)
+ (forward-line -1)
+  (goto-char (point-max)))
+(insert body))
+  (set-buffer-modified-p nil)
+
+  (message-goto-body))
+)
+
 (defun notmuch-mua-new-forward-message (optional prompt-for-sender)
   Invoke the notmuch message forwarding window.
 
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index f96743b..3698767 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -865,6 +865,7 @@ function is used. 
(define-key map m 'notmuch-mua-new-mail)
(define-key map f 'notmuch-show-forward-message)
(define-key map r 'notmuch-show-reply)
+   (define-key map e 'notmuch-show-edit)
(define-key map | 'notmuch-show-pipe-message)
(define-key map w 'notmuch-show-save-attachments)
(define-key map V 'notmuch-show-view-raw-message)
@@ -1164,6 +1165,11 @@ any effects from previous calls to
   (interactive P)
   (notmuch-mua-new-reply (notmuch-show-get-message-id) prompt-for-sender))
 
+(defun notmuch-show-edit ()
+  Edit the current message as new.
+  (interactive)
+  (notmuch-mua-edit-mail (notmuch-show-get-message-id)))
+
 (defun notmuch-show-forward-message (optional prompt-for-sender)
   Forward the current message.
   (interactive P)
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index f11ec24..f18b739 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -204,6 +204,7 @@ For a mouse binding, return nil.
 (define-key map p 'notmuch-search-previous-thread)
 (define-key map n 'notmuch-search-next-thread)
 (define-key map r 'notmuch-search-reply-to-thread)
+(define-key map e 'notmuch-search-edit)
 (define-key map m 'notmuch-mua-new-mail)
 (define-key map s 'notmuch-search)
 (define-key map o 'notmuch-search-toggle-order)
@@ -448,6 +449,12 @@ Complete list of currently available key bindings:
   (let ((message-id (notmuch-search-find-thread-id)))
 (notmuch-mua-new-reply message-id prompt-for-sender)))
 
+(defun notmuch-search-edit ()
+  Edit the current message as new.
+  (interactive)
+  (let ((message-id (notmuch-search-find-thread-id)))
+(notmuch-mua-edit-mail message-id)))
+
 (defun notmuch-call-notmuch-process (rest args)
   Synchronously invoke \notmuch\ with the given list of arguments.
 
-- 
1.7.5.4

___
notmuch mailing list

[PATCH 1/2] add notmuch keybinding 'd'

[Antoine Beaupré]

It adds a tag 'deleted' and removes the tags 'inbox' and 'unread'. It
works in show as well as in search mode

Based on previous work by: Sebastian Spaeth sebast...@sspaeth.de

Signed-off-by: Antoine Beaupré anar...@koumbit.org
---
 emacs/notmuch-show.el |8 
 emacs/notmuch.el  |   11 +++
 2 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index f96743b..c83b992 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -875,6 +875,7 @@ function is used. 
(define-key map + 'notmuch-show-add-tag)
(define-key map x 'notmuch-show-archive-thread-then-exit)
(define-key map a 'notmuch-show-archive-thread)
+   (define-key map d 'notmuch-show-delete)
(define-key map N 'notmuch-show-next-message)
(define-key map P 'notmuch-show-previous-message)
(define-key map n 'notmuch-show-next-open-message)
@@ -1297,6 +1298,13 @@ the result.
 (mapcar (lambda (s) (concat - s)) toremove))
   (notmuch-show-set-tags new-tags
 
+(defun notmuch-show-delete ()
+  Delete current mail (tag +deleted -unread -inbox).
+  (interactive)
+  (notmuch-show-add-tag deleted)
+  (notmuch-show-remove-tag unread)
+  (notmuch-show-remove-tag inbox))
+
 (defun notmuch-show-toggle-headers ()
   Toggle the visibility of the current message headers.
   (interactive)
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index f11ec24..f6fb07b 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -215,6 +215,7 @@ For a mouse binding, return nil.
 (define-key map [mouse-1] 'notmuch-search-show-thread)
 (define-key map * 'notmuch-search-operate-all)
 (define-key map a 'notmuch-search-archive-thread)
+(define-key map d 'notmuch-search-delete-thread-or-region)
 (define-key map - 'notmuch-search-remove-tag)
 (define-key map + 'notmuch-search-add-tag)
 (define-key map (kbd RET) 'notmuch-search-show-thread)
@@ -611,6 +612,16 @@ This function advances the next thread when finished.
   Data that has not yet been processed.)
 (make-variable-buffer-local 'notmuch-search-process-filter-data)
 
+(defun notmuch-search-delete-thread-or-region ()
+  Delete the currently selected thread (tag \+deleted -inbox -unread\).
+
+This function advances the next thread when finished.
+  (interactive)
+  (notmuch-search-add-tag deleted)
+  (notmuch-search-remove-tag inbox)
+  (notmuch-search-remove-tag unread)
+  (forward-line))
+
 (defun notmuch-search-process-sentinel (proc msg)
   Add a message to let user know when \notmuch search\ exits
   (let ((buffer (process-buffer proc))
-- 
1.7.5.4

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH 1/2] lib: Add back the synchronization of 'T' flag with deleted tag.

[Antoine Beaupré]

This adds a special configuration, off by default, that allows notmuch
to synchronize the T flag again. The configuration is named
maildir_reckless_trash and quite clearly indicates that it could be
dangerous to use in the context described in commit 2c26204, which I
could actually reproduce.

In contexts where notmuch is the only mail client used, this is actually
safe to use. Besides, (T)rashed messages are not necessarily immediately
expunged from the Maildir by the client or the IMAP server.

Signed-off-by: Antoine Beaupré anar...@koumbit.org
---
 lib/message.cc   |   14 +-
 lib/notmuch.h|4 
 notmuch-client.h |7 +++
 notmuch-config.c |   50 +++---
 4 files changed, 71 insertions(+), 4 deletions(-)

diff --git a/lib/message.cc b/lib/message.cc
index d993cde..f633887 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -58,7 +58,8 @@ static struct maildir_flag_tag flag2tag[] = {
 { 'F', flagged, false},
 { 'P', passed,  false},
 { 'R', replied, false},
-{ 'S', unread,  true }
+{ 'S', unread,  true },
+{ 'T', deleted, false},
 };
 
 /* We end up having to call the destructor explicitly because we had
@@ -993,6 +994,7 @@ notmuch_message_maildir_flags_to_tags (notmuch_message_t 
*message)
 char *combined_flags = talloc_strdup (message, );
 unsigned i;
 int seen_maildir_info = 0;
+notmuch_bool_t reckless_trash;
 
 for (filenames = notmuch_message_get_filenames (message);
 notmuch_filenames_valid (filenames);
@@ -1020,7 +1022,17 @@ notmuch_message_maildir_flags_to_tags (notmuch_message_t 
*message)
 if (status)
return status;
 
+// TODO: this should probably be moved up in the stack to avoid
+// opening the config file on every message (!)
+config = notmuch_config_open (ctx, NULL, NULL);
+if (config == NULL)
+   return 1;
+reckless_trash = notmuch_config_get_maildir_reckless_trash (config);
+
 for (i = 0; i  ARRAY_SIZE(flag2tag); i++) {
+   if (flag2tag[i].flag == 'T'  !reckless_trash) {
+   continue;
+   }
if ((strchr (combined_flags, flag2tag[i].flag) != NULL)
^ 
flag2tag[i].inverse)
diff --git a/lib/notmuch.h b/lib/notmuch.h
index 974be8d..f0c1b67 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -922,6 +922,8 @@ notmuch_message_remove_all_tags (notmuch_message_t 
*message);
  * 'P' Adds the passed tag to the message
  * 'R' Adds the replied tag to the message
  * 'S' Removes the unread tag from the message
+ * 'T' Adds the deleted tag to the message and
+ * state-reckless_trash is TRUE.
  *
  * For each flag that is not present, the opposite action (add/remove)
  * is performed for the corresponding tags.
@@ -962,6 +964,8 @@ notmuch_message_maildir_flags_to_tags (notmuch_message_t 
*message);
  *   'P' iff the message has the passed tag
  *   'R' iff the message has the replied tag
  *   'S' iff the message does not have the unread tag
+ *   'T' iff the message has the trashed tag and
+ *   state-reckless_trash is TRUE.
  *
  * Any existing flags unmentioned in the list above will be preserved
  * in the renaming.
diff --git a/notmuch-client.h b/notmuch-client.h
index 63be337..62d1e0e 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -235,6 +235,13 @@ notmuch_config_set_maildir_synchronize_flags 
(notmuch_config_t *config,
  notmuch_bool_t synchronize_flags);
 
 notmuch_bool_t
+notmuch_config_get_maildir_reckless_trash (notmuch_config_t *config);
+
+void
+notmuch_config_set_maildir_reckless_trash (notmuch_config_t *config,
+  notmuch_bool_t reckless_trash);
+
+notmuch_bool_t
 debugger_is_active (void);
 
 #endif
diff --git a/notmuch-config.c b/notmuch-config.c
index 485fa72..613fefc 100644
--- a/notmuch-config.c
+++ b/notmuch-config.c
@@ -67,9 +67,11 @@ static const char maildir_config_comment[] =
  The following option is supported here:\n
 \n
 \tsynchronize_flags  Valid values are true and false.\n
+\treckless_trash Valid values are true and false.\n
 \n
-\tIf true, then the following maildir flags (in message filenames)\n
-\twill be synchronized with the corresponding notmuch tags:\n
+\tIf synchronize_flags is true, then the following maildir flags\n
+\t(in message filenames) will be synchronized with the corresponding\n
+\tnotmuch tags:\n
 \n
 \t\tFlag  Tag\n
 \t\t  ---\n
@@ -78,10 +80,26 @@ static const char maildir_config_comment[] =
 \t\tP passed\n
 \t\tR replied\n
 \t\tS unread (added when 'S' flag is not present)\n
+\t\tT trashed (only if maildir_reckless_trash is enabled)\n
 \n
 \tThe \notmuch new\ command will notice flag changes in filenames\n
 \tand update tags, while the \notmuch tag\ and \notmuch restore\\n
-\tcommands

[PATCH 2/2] lib: add 'safe' setting for flags

[Antoine Beaupré]

the 'safe' setting needs to be 'true' for flags to be manipulated by
notmuch new/tag/restore.

for now, only the (T)rash tag is configurable and set to false (by
default) but this could be extended to allow the user to configure which
flags are allowed to be synchronized.

the reason why only T is configurable is because (a) it's the the only
one that is actually dangerous and (b) I couldn't figure out how to
properly configure multiple settings like this.
---
 lib/message.cc|   40 +---
 lib/notmuch.h |   20 
 notmuch-new.c |1 +
 notmuch-restore.c |1 +
 notmuch-tag.c |1 +
 5 files changed, 44 insertions(+), 19 deletions(-)

diff --git a/lib/message.cc b/lib/message.cc
index f633887..f812648 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -50,16 +50,17 @@ struct maildir_flag_tag {
 char flag;
 const char *tag;
 bool inverse;
+bool safe;
 };
 
 /* ASCII ordered table of Maildir flags and associated tags */
 static struct maildir_flag_tag flag2tag[] = {
-{ 'D', draft,   false},
-{ 'F', flagged, false},
-{ 'P', passed,  false},
-{ 'R', replied, false},
-{ 'S', unread,  true },
-{ 'T', deleted, false},
+{ 'D', draft,   false, true},
+{ 'F', flagged, false, true},
+{ 'P', passed,  false, true},
+{ 'R', replied, false, true},
+{ 'S', unread,  true , true},
+{ 'T', deleted, false, false},
 };
 
 /* We end up having to call the destructor explicitly because we had
@@ -994,7 +995,6 @@ notmuch_message_maildir_flags_to_tags (notmuch_message_t 
*message)
 char *combined_flags = talloc_strdup (message, );
 unsigned i;
 int seen_maildir_info = 0;
-notmuch_bool_t reckless_trash;
 
 for (filenames = notmuch_message_get_filenames (message);
 notmuch_filenames_valid (filenames);
@@ -1022,15 +1022,8 @@ notmuch_message_maildir_flags_to_tags (notmuch_message_t 
*message)
 if (status)
return status;
 
-// TODO: this should probably be moved up in the stack to avoid
-// opening the config file on every message (!)
-config = notmuch_config_open (ctx, NULL, NULL);
-if (config == NULL)
-   return 1;
-reckless_trash = notmuch_config_get_maildir_reckless_trash (config);
-
 for (i = 0; i  ARRAY_SIZE(flag2tag); i++) {
-   if (flag2tag[i].flag == 'T'  !reckless_trash) {
+   if (!flag2tag[i].safe) {
continue;
}
if ((strchr (combined_flags, flag2tag[i].flag) != NULL)
@@ -1119,6 +1112,9 @@ _get_maildir_flag_actions (notmuch_message_t *message,
tag = notmuch_tags_get (tags);
 
for (i = 0; i  ARRAY_SIZE (flag2tag); i++) {
+   if (!flag2tag[i].safe) {
+   continue;
+   }
if (strcmp (tag, flag2tag[i].tag) == 0) {
if (flag2tag[i].inverse)
to_clear = talloc_asprintf_append (to_clear,
@@ -1134,6 +1130,9 @@ _get_maildir_flag_actions (notmuch_message_t *message,
 
 /* Then, find the flags for all tags not present. */
 for (i = 0; i  ARRAY_SIZE (flag2tag); i++) {
+   if (!flag2tag[i].safe) {
+   continue;
+   }
if (flag2tag[i].inverse) {
if (strchr (to_clear, flag2tag[i].flag) == NULL)
to_set = talloc_asprintf_append (to_set, %c, 
flag2tag[i].flag);
@@ -1256,6 +1255,17 @@ _new_maildir_filename (void *ctx,
 return filename_new;
 }
 
+void
+notmuch_message_set_flag_safety (char flag, notmuch_bool_t safe)
+{
+unsigned i;
+for (i = 0; i  ARRAY_SIZE (flag2tag); i++) {
+if (flag2tag[i].flag == flag) {
+flag2tag[i].safe = safe;
+}
+}
+}
+
 notmuch_status_t
 notmuch_message_tags_to_maildir_flags (notmuch_message_t *message)
 {
diff --git a/lib/notmuch.h b/lib/notmuch.h
index f0c1b67..475e75a 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -922,8 +922,7 @@ notmuch_message_remove_all_tags (notmuch_message_t 
*message);
  * 'P' Adds the passed tag to the message
  * 'R' Adds the replied tag to the message
  * 'S' Removes the unread tag from the message
- * 'T' Adds the deleted tag to the message and
- * state-reckless_trash is TRUE.
+ * 'T' Adds the deleted tag to the message
  *
  * For each flag that is not present, the opposite action (add/remove)
  * is performed for the corresponding tags.
@@ -941,6 +940,9 @@ notmuch_message_remove_all_tags (notmuch_message_t 
*message);
  * notmuch_database_add_message. See also
  * notmuch_message_tags_to_maildir_flags for synchronizing tag changes
  * back to maildir flags.
+ *
+ * Actions are performed only if the tag is marked as safe in the
+ * configuration (only used by maildir_reckless_trash for now).
  */
 notmuch_status_t
 notmuch_message_maildir_flags_to_tags (notmuch_message_t *message);
@@ -964,8 +966,7 @@ notmuch_message_maildir_flags_to_tags (notmuch_message_t 
*message);
  *   'P' iff the message has the