[PATCH v2] emacs: show: stop stderr appearing in buffer
In emacs 24.3+ the stdout/stderr from externally displaying an
attachment gets inserted into the show buffer. This is caused by
changes in mm-display-external in mm-decode.el.
Ideally, we would put this output in the notmuch errors buffer but the
handler is called asynchronously so we don't know when the output will
appear. Thus if we put it straight into the errors buffer it could get
interleaved with other errors. Also we can't easily tell when we
have got all the error output so can't wait until the process is complete.
One solution would be to create a new buffer for the stderr of each
attachment viewed. Again, since we can't tell when the process has
finished, we can't close these buffers automatically so this will
leave lots of buffers around.
Thus we add a debug variable notmuch-show-attachment-debug: it this is
non-nil we create a new buffer for each viewer; if this variable is
nil we just use a temp buffer which means all error output is
discarded (this is the same behaviour as with emacs pre 24.3).
---
This version just adds a docstring to the debug variable describing
what it does and where the debug data is stored (ie what the buffer
name is).
Best wishes
Mark
emacs/notmuch-show.el | 19 ++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index f00273a..784644c 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -159,6 +159,15 @@ indentation."
(make-variable-buffer-local 'notmuch-show-indent-content)
(put 'notmuch-show-indent-content 'permanent-local t)
+(defvar notmuch-show-attachment-debug nil
+ "If t log stdout and stderr from attachment handlers
+
+When set to nil (the default) stdout and stderr from attachment
+handlers is discarded. When set to t the stdout and stderr from
+each attachment handler is logged in buffers with names beginning
+\" *notmuch-part*\". This option requires emacs version at least
+24.3 to work.")
+
(defcustom notmuch-show-stash-mlarchive-link-alist
'(("Gmane" . "http://mid.gmane.org/;)
("MARC" . "http://marc.info/?i=;)
@@ -2089,8 +2098,16 @@ caller is responsible for killing this buffer as
appropriate."
This ensures that the temporary buffer created for the mm-handle
is destroyed when FN returns."
(let ((handle (notmuch-show-current-part-handle)))
+;; emacs 24.3+ puts stdout/stderr into the calling buffer so we
+;; call it from a temp-buffer, unless
+;; notmuch-show-attachment-debug is non-nil in which case we put
+;; it in " *notmuch-part*".
(unwind-protect
- (funcall fn handle)
+ (if notmuch-show-attachment-debug
+ (with-current-buffer (generate-new-buffer " *notmuch-part*")
+ (funcall fn handle))
+ (with-temp-buffer
+ (funcall fn handle)))
(kill-buffer (mm-handle-buffer handle)
(defun notmuch-show-part-button-default ( button)
--
1.7.9.1
fix for failing tests with gmime 2.6.19
On Sun, Nov 10 2013, David Bremner wrote:
> Although Jeffrey Stedfast fixed gmime bug 711305 amazingly quickly, it
> looks like many people still have to live with a buggy version of
> gmime for a while yet. Here is an opt-in fix that stops the test suite
> from failing; this is a simple fix for e.g. the debian build process.
After looking throught all the comments and thinking about the options
I see the following 2 options
1) Keep things as those currently are. Anyone who runs tests when
gmime 2.6.19 is in use will see some tests fail (and some may not have
a clue what's going on). We could mention this first thing in the NEWS
so that the "professional" users who run test *and* reads NEWS will
get the clue.
2) Push the current patches to release branch *only* (maybe the test
could be changed to if [ pkg-config --exact-version=2.6.19 gmime-2.6 ] (*)
instead of checking the WORKAROUNDS flag so that users would not have
to bother (and some may not have a clue what's going on)). During merge
to master (as it has been done in the past) these changes would probably
be dropped.
2b) Merge to master, release 0.17, follow gmime deployments, revert
patches.
IMHO for temporary problems there could be temporary cruft (which would
not be cruft if the problem wasn't temporary). The test system must
be as strict as it can be to ensure best failure coverage.
Tomi
(*) The fastest (& most cruftiest) implementation:
notmuch_reply_sanitize ()
{
if pkg-config --exact-version=2.6.19 gmime-2.6 >/dev/null
then
notmuch_reply_sanitize () {
# work around GMIME bug #711305
sed -e 's/^References: /References: /'
}
else
notmuch_reply_sanitize () {
cat
}
fi
notmuch_reply_sanitize # call just rewritten version of this function
}
notmuch-lib questions and observations
Hi, I found out about notmuch quite recently, and now I've been tinkering with it, prototyping a GUI client. I have some questions and observations: 1. The API seems to be a bit broken. I think many of the functions should return notmuch_status_t. I encountered this issue with get_header() and get_date(), which I happened to call after the DB had been changed twice, leading to Xapian::DatabaseModifiedError. Neither function handle the exception, causing a crash, which is obviously a bug, but even if they did handle the exception they don't return any sensible error information. Even worse, consider count_messages(), for which return value of 0 is valid. So, as far as I see, many of the funcs should be changed to something like: notmuch_status_t notmuch_query_count_messages (notmuch_query_t *query, unsigned *count); 2. This is more about Xapian, I guess. The behavior that a db reader will start failing if the db has been changed twice is rather bad. If I'm not mistaken, having a rather long read-only query could be blocked (or, well, re-tried) forever, if there just happens to be a few db writes during the read. I think a better approach would be to allow only one change to the db if there are open db readers. If a second db writer tries to open the db, it would get a failure (instead of the readers). Anyone know if this has been discussed, or if my suggestion is plain silly? 3. How is a client using notmuch supposed to find out there are new messages, and which messages are new? My current thought is to make 'notmuch new' run a script that tags the messages, and make it add a 'new-gui' or such tag to all new messages. The client would then periodically make a query for that tag, and at the same time remove the tag for any returned messages. 4. Has there been discussion on returning integer IDs instead of strings from various functions like notmuch_message_get_message_id() and notmuch_tags_get()? I have two things behind this question: - Marshaling strings from native code to managed code requires allocating memory and copying the string, whereas returning an int is more or less a no-op [1][2]. E.g. at the moment if I fetch tag 'inbox' for 10k messages, I'm creating a new 'inbox' string 10k times. I'd rather fetch an int 10k times, and the 'inbox' string once. - My prototype fetches the message ids for all the messages returned by the query, so that it can later load the message if the user wants to read it. Fetching and storing only an int per message versus a long-ish string per message would most likely be good for performance with large queries. 5. This one is just a vague thought that came to my mind. At the moment notmuch hides Xapian totally behind notmuch's interface, which probably makes things simpler (and gives a nice C API), but also (afaik) prevents using Xapian features that are not at the moment supported in the notmuch API. I wonder how would an approach work where notmuch would be a bit more like a helper library, allowing full use of Xapian's features but making it simple to manage notmuch database. So, for example, when making a query, you'd create a Xapian query with notmuch, and then use Xapian to run the query. I don't have anything clear in mind, and obviously Xapian being C++ might make the whole idea unimplementable. Tomi [1] That's on C#. I wouldn't be surprised if it's also the same with other higher level languages. [2] That's not entirely true, as strings can be passed as is, if the managed code is given the ownership of the string, and the managed code will free the string eventually. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20131118/d43b5e4c/attachment.pgp>
alot: can't read sent emails, after encryption
Quoting Jameson Graef Rollins (2013-11-17 20:43:25) > On Sun, Nov 17 2013, Patrick Totzke wrote: > > Is this how notmuch emacs does it? I mean, is there some option to tell > > emacs to always call gpg with --encrypt-to=me ? > > I wonder if I need to change alot in any way or if one can simply globally > > configure > > gnupg.. alot does not call the gpg binary but uses pygpgme. > > You do not need to change alot, just notmuch emacs also doesn't need to > do anything special to allow for this. Just add an > > encrypt-to > > line to your ~/.gnupg/gpg.conf, where is your personal keyid. > Then all encrypted data is also encrypted to your personal key, making > it always viewable by you as well. Then you can just open your > encrypted sent mail as you would any other encrypted mail. If I have to identities, with two different gpg keys (key1 and key2), and I set 'encrypt-to key1' when I send emails with my identity of key2 it will also encrypt it with my key1 and will reveal to its receivers that I own key1. Isn't it? -- Ruben Pollan | http://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: http://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: signature URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20131118/78d34560/attachment-0001.pgp>
alot: can't read sent emails, after encryption
Quoting Alain-Pierre Manine (2013-11-18 08:38:33) > Quoting Jameson Graef Rollins (2013-11-17 20:43:25) > > On Sun, Nov 17 2013, Patrick Totzke wrote: > > > Quoting Jameson Graef Rollins (2013-11-16 21:47:02) > > >> On Tue, Nov 12 2013, apmanine at idaaas.com wrote: > > >> > I have recently switched to notmuch. Thank you for it! > > >> > I'm using "alot" as a frontend (thank you for it, too!). Everything > > >> > works smoothly, apart from one problem: with alot, I can't figure out > > >> > how > > >> > to read encrypted emails I previously sent: they appear to be encrypted > > >> > using the addressee's key. > > >> > > > >> > Is there some way to store encrypted sent emails with my own public gpg > > >> > key? > > >> > > >> What you really want is to tell gpg to always encrypt messages to your > > >> personal key as well, which will always make them viewable by you. This > > >> way you don't have to worry about saving unencrypted versions of the > > >> message to disk, or there being two distinct versions of the message > > >> (one encrypted to the recipient and a different one encrypted to you). > > >> > > >> See the "encrypt-to" gpg option [0]. > > >> > > >> jamie. > > >> > > >> [0] > > >> http://www.gnupg.org/documentation/manuals/gnupg-devel/GPG-Key-related-Options.html > > > > > > Is this how notmuch emacs does it? I mean, is there some option to tell > > > emacs to always call gpg with --encrypt-to=me ? > > > I wonder if I need to change alot in any way or if one can simply > > > globally configure > > > gnupg.. alot does not call the gpg binary but uses pygpgme. > > > > You do not need to change alot, just notmuch emacs also doesn't need to > > do anything special to allow for this. Just add an > > > > encrypt-to > > > > line to your ~/.gnupg/gpg.conf, where is your personal keyid. > > Then all encrypted data is also encrypted to your personal key, making > > it always viewable by you as well. Then you can just open your > > encrypted sent mail as you would any other encrypted mail. > > > > jamie. > > It's working! Thanks for the explanations. Excelent, thanks Jamie. I wasn't aware of this setting and assumed that the stuff in the gnupg config file only applies to gpg itself and not, as in alot, for calls through the gpgme library. Thanks for testing this Alain-Pierre. /p -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: signature URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20131118/3016a867/attachment.pgp>
alot: can't read sent emails, after encryption
On Mon, Nov 18 2013, Patrick Totzke wrote: > Excelent, thanks Jamie. > I wasn't aware of this setting and assumed that the stuff in the > gnupg config file only applies to gpg itself and not, as in alot, > for calls through the gpgme library. Actually, bizarrely, there is no actual gpg library. gpgme just calls the gpg binary underneath. Therefore all gpg settings work for gpgme as well. jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20131118/b8cc309f/attachment.pgp>
alot: can't read sent emails, after encryption
Quoting Jameson Graef Rollins (2013-11-17 20:43:25) > On Sun, Nov 17 2013, Patrick Totzke wrote: > > Quoting Jameson Graef Rollins (2013-11-16 21:47:02) > >> On Tue, Nov 12 2013, apmanine at idaaas.com wrote: > >> > I have recently switched to notmuch. Thank you for it! > >> > I'm using "alot" as a frontend (thank you for it, too!). Everything > >> > works smoothly, apart from one problem: with alot, I can't figure out how > >> > to read encrypted emails I previously sent: they appear to be encrypted > >> > using the addressee's key. > >> > > >> > Is there some way to store encrypted sent emails with my own public gpg > >> > key? > >> > >> What you really want is to tell gpg to always encrypt messages to your > >> personal key as well, which will always make them viewable by you. This > >> way you don't have to worry about saving unencrypted versions of the > >> message to disk, or there being two distinct versions of the message > >> (one encrypted to the recipient and a different one encrypted to you). > >> > >> See the "encrypt-to" gpg option [0]. > >> > >> jamie. > >> > >> [0] > >> http://www.gnupg.org/documentation/manuals/gnupg-devel/GPG-Key-related-Options.html > > > > Is this how notmuch emacs does it? I mean, is there some option to tell > > emacs to always call gpg with --encrypt-to=me ? > > I wonder if I need to change alot in any way or if one can simply globally > > configure > > gnupg.. alot does not call the gpg binary but uses pygpgme. > > You do not need to change alot, just notmuch emacs also doesn't need to > do anything special to allow for this. Just add an > > encrypt-to > > line to your ~/.gnupg/gpg.conf, where is your personal keyid. > Then all encrypted data is also encrypted to your personal key, making > it always viewable by you as well. Then you can just open your > encrypted sent mail as you would any other encrypted mail. > > jamie. It's working! Thanks for the explanations.
alot: can't read sent emails, after encryption
On 11/18/2013 05:17 AM, Ruben Pollan wrote: > If I have t[w]o identities, with two different gpg keys (key1 and key2), and > I set > 'encrypt-to key1' when I send emails with my identity of key2 it will also > encrypt it with my key1 and will reveal to its receivers that I own key1. > Isn't > it? It won't formally *prove* that you own key1 (no one will be able to say for sure that the public key encrypted session key packet actually is decryptable by key1, it just has the 64-bit keyid embedded in the PKESK, and even if it did, it could arguably have been added as a Bcc: to another independent person), but it will certainly imply to anyone who gets more than a single message from you that there is this other key involved somehow. If you have multiple identities, there are other approaches you could take without changing alot itself, for example: You could have two separate ~/.gnupg directories, and you could launch alot differently, with "GNUPGHOME=~/.gnupg-key1 alot" or "GNUPGHOME=~/.gnupg-key2 alot" to make these responses. If you really care deeply about keeping the identities distinct, you might even want to split your notmuch dataset into two places as well, so that you don't accidentally reply from one identity to another identity's message: NOTMUCH_CONFIG=~/.notmuch-config-key1 GNUPGHOME=~/.gnupg-key1 alot and so forth. or you could use two distinct user accounts or virtual machines so that the data as even fewer possibilities of being mixed (e.g. ensuring that the outbound SMTP path, and/or the message-IDs generated when sending each message don't share any features that might leak their common provenance). None of this is particularly convenient; maintaining separate identities that are difficult for an adversary to re-correlate is a serious challenge. That said, i can imagine that alot (and other notmuch frontends) could be improved to support this use case directly without forcing users to go through the extra hoops i've envisioned above. --dkg -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20131118/8ff02e4d/attachment.pgp>
[PATCH] emacs: show: stop stderr appearing in buffer
Mark Walters writes: > Thus we add a debug variable notmuch-show-attachment-debug: it this is > non-nil we create a new buffer for each viewer; if this variable is > nil we just use a temp buffer which means all error output is > discarded (this is the same behaviour as with emacs pre 24.3). This seems to work fine, but I couldn't find the temp buffer name until I looked at the source. How about a docstring? d
Re: alot: can't read sent emails, after encryption
Quoting Alain-Pierre Manine (2013-11-18 08:38:33) Quoting Jameson Graef Rollins (2013-11-17 20:43:25) On Sun, Nov 17 2013, Patrick Totzke patricktot...@gmail.com wrote: Quoting Jameson Graef Rollins (2013-11-16 21:47:02) On Tue, Nov 12 2013, apman...@idaaas.com wrote: I have recently switched to notmuch. Thank you for it! I'm using alot as a frontend (thank you for it, too!). Everything works smoothly, apart from one problem: with alot, I can't figure out how to read encrypted emails I previously sent: they appear to be encrypted using the addressee's key. Is there some way to store encrypted sent emails with my own public gpg key? What you really want is to tell gpg to always encrypt messages to your personal key as well, which will always make them viewable by you. This way you don't have to worry about saving unencrypted versions of the message to disk, or there being two distinct versions of the message (one encrypted to the recipient and a different one encrypted to you). See the encrypt-to gpg option [0]. jamie. [0] http://www.gnupg.org/documentation/manuals/gnupg-devel/GPG-Key-related-Options.html Is this how notmuch emacs does it? I mean, is there some option to tell emacs to always call gpg with --encrypt-to=me ? I wonder if I need to change alot in any way or if one can simply globally configure gnupg.. alot does not call the gpg binary but uses pygpgme. You do not need to change alot, just notmuch emacs also doesn't need to do anything special to allow for this. Just add an encrypt-to keyid line to your ~/.gnupg/gpg.conf, where keyid is your personal keyid. Then all encrypted data is also encrypted to your personal key, making it always viewable by you as well. Then you can just open your encrypted sent mail as you would any other encrypted mail. jamie. It's working! Thanks for the explanations. Excelent, thanks Jamie. I wasn't aware of this setting and assumed that the stuff in the gnupg config file only applies to gpg itself and not, as in alot, for calls through the gpgme library. Thanks for testing this Alain-Pierre. /p signature.asc Description: signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: show: stop stderr appearing in buffer
Mark Walters markwalters1...@gmail.com writes: Thus we add a debug variable notmuch-show-attachment-debug: it this is non-nil we create a new buffer for each viewer; if this variable is nil we just use a temp buffer which means all error output is discarded (this is the same behaviour as with emacs pre 24.3). This seems to work fine, but I couldn't find the temp buffer name until I looked at the source. How about a docstring? d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: alot: can't read sent emails, after encryption
Quoting Jameson Graef Rollins (2013-11-17 20:43:25) On Sun, Nov 17 2013, Patrick Totzke patricktot...@gmail.com wrote: Is this how notmuch emacs does it? I mean, is there some option to tell emacs to always call gpg with --encrypt-to=me ? I wonder if I need to change alot in any way or if one can simply globally configure gnupg.. alot does not call the gpg binary but uses pygpgme. You do not need to change alot, just notmuch emacs also doesn't need to do anything special to allow for this. Just add an encrypt-to keyid line to your ~/.gnupg/gpg.conf, where keyid is your personal keyid. Then all encrypted data is also encrypted to your personal key, making it always viewable by you as well. Then you can just open your encrypted sent mail as you would any other encrypted mail. If I have to identities, with two different gpg keys (key1 and key2), and I set 'encrypt-to key1' when I send emails with my identity of key2 it will also encrypt it with my key1 and will reveal to its receivers that I own key1. Isn't it? -- Ruben Pollan | http://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: http://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan. signature.asc Description: signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
notmuch-lib questions and observations
Hi, I found out about notmuch quite recently, and now I've been tinkering with it, prototyping a GUI client. I have some questions and observations: 1. The API seems to be a bit broken. I think many of the functions should return notmuch_status_t. I encountered this issue with get_header() and get_date(), which I happened to call after the DB had been changed twice, leading to Xapian::DatabaseModifiedError. Neither function handle the exception, causing a crash, which is obviously a bug, but even if they did handle the exception they don't return any sensible error information. Even worse, consider count_messages(), for which return value of 0 is valid. So, as far as I see, many of the funcs should be changed to something like: notmuch_status_t notmuch_query_count_messages (notmuch_query_t *query, unsigned *count); 2. This is more about Xapian, I guess. The behavior that a db reader will start failing if the db has been changed twice is rather bad. If I'm not mistaken, having a rather long read-only query could be blocked (or, well, re-tried) forever, if there just happens to be a few db writes during the read. I think a better approach would be to allow only one change to the db if there are open db readers. If a second db writer tries to open the db, it would get a failure (instead of the readers). Anyone know if this has been discussed, or if my suggestion is plain silly? 3. How is a client using notmuch supposed to find out there are new messages, and which messages are new? My current thought is to make 'notmuch new' run a script that tags the messages, and make it add a 'new-gui' or such tag to all new messages. The client would then periodically make a query for that tag, and at the same time remove the tag for any returned messages. 4. Has there been discussion on returning integer IDs instead of strings from various functions like notmuch_message_get_message_id() and notmuch_tags_get()? I have two things behind this question: - Marshaling strings from native code to managed code requires allocating memory and copying the string, whereas returning an int is more or less a no-op [1][2]. E.g. at the moment if I fetch tag 'inbox' for 10k messages, I'm creating a new 'inbox' string 10k times. I'd rather fetch an int 10k times, and the 'inbox' string once. - My prototype fetches the message ids for all the messages returned by the query, so that it can later load the message if the user wants to read it. Fetching and storing only an int per message versus a long-ish string per message would most likely be good for performance with large queries. 5. This one is just a vague thought that came to my mind. At the moment notmuch hides Xapian totally behind notmuch's interface, which probably makes things simpler (and gives a nice C API), but also (afaik) prevents using Xapian features that are not at the moment supported in the notmuch API. I wonder how would an approach work where notmuch would be a bit more like a helper library, allowing full use of Xapian's features but making it simple to manage notmuch database. So, for example, when making a query, you'd create a Xapian query with notmuch, and then use Xapian to run the query. I don't have anything clear in mind, and obviously Xapian being C++ might make the whole idea unimplementable. Tomi [1] That's on C#. I wouldn't be surprised if it's also the same with other higher level languages. [2] That's not entirely true, as strings can be passed as is, if the managed code is given the ownership of the string, and the managed code will free the string eventually. signature.asc Description: OpenPGP digital signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: alot: can't read sent emails, after encryption
On 11/18/2013 05:17 AM, Ruben Pollan wrote: If I have t[w]o identities, with two different gpg keys (key1 and key2), and I set 'encrypt-to key1' when I send emails with my identity of key2 it will also encrypt it with my key1 and will reveal to its receivers that I own key1. Isn't it? It won't formally *prove* that you own key1 (no one will be able to say for sure that the public key encrypted session key packet actually is decryptable by key1, it just has the 64-bit keyid embedded in the PKESK, and even if it did, it could arguably have been added as a Bcc: to another independent person), but it will certainly imply to anyone who gets more than a single message from you that there is this other key involved somehow. If you have multiple identities, there are other approaches you could take without changing alot itself, for example: You could have two separate ~/.gnupg directories, and you could launch alot differently, with GNUPGHOME=~/.gnupg-key1 alot or GNUPGHOME=~/.gnupg-key2 alot to make these responses. If you really care deeply about keeping the identities distinct, you might even want to split your notmuch dataset into two places as well, so that you don't accidentally reply from one identity to another identity's message: NOTMUCH_CONFIG=~/.notmuch-config-key1 GNUPGHOME=~/.gnupg-key1 alot and so forth. or you could use two distinct user accounts or virtual machines so that the data as even fewer possibilities of being mixed (e.g. ensuring that the outbound SMTP path, and/or the message-IDs generated when sending each message don't share any features that might leak their common provenance). None of this is particularly convenient; maintaining separate identities that are difficult for an adversary to re-correlate is a serious challenge. That said, i can imagine that alot (and other notmuch frontends) could be improved to support this use case directly without forcing users to go through the extra hoops i've envisioned above. --dkg signature.asc Description: OpenPGP digital signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: fix for failing tests with gmime 2.6.19
On Sun, Nov 10 2013, David Bremner da...@tethera.net wrote:
Although Jeffrey Stedfast fixed gmime bug 711305 amazingly quickly, it
looks like many people still have to live with a buggy version of
gmime for a while yet. Here is an opt-in fix that stops the test suite
from failing; this is a simple fix for e.g. the debian build process.
After looking throught all the comments and thinking about the options
I see the following 2 options
1) Keep things as those currently are. Anyone who runs tests when
gmime 2.6.19 is in use will see some tests fail (and some may not have
a clue what's going on). We could mention this first thing in the NEWS
so that the professional users who run test *and* reads NEWS will
get the clue.
2) Push the current patches to release branch *only* (maybe the test
could be changed to if [ pkg-config --exact-version=2.6.19 gmime-2.6 ] (*)
instead of checking the WORKAROUNDS flag so that users would not have
to bother (and some may not have a clue what's going on)). During merge
to master (as it has been done in the past) these changes would probably
be dropped.
2b) Merge to master, release 0.17, follow gmime deployments, revert
patches.
IMHO for temporary problems there could be temporary cruft (which would
not be cruft if the problem wasn't temporary). The test system must
be as strict as it can be to ensure best failure coverage.
Tomi
(*) The fastest ( most cruftiest) implementation:
notmuch_reply_sanitize ()
{
if pkg-config --exact-version=2.6.19 gmime-2.6 /dev/null
then
notmuch_reply_sanitize () {
# work around GMIME bug #711305
sed -e 's/^References: /References: /'
}
else
notmuch_reply_sanitize () {
cat
}
fi
notmuch_reply_sanitize # call just rewritten version of this function
}
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: alot: can't read sent emails, after encryption
On Mon, Nov 18 2013, Patrick Totzke patricktot...@gmail.com wrote: Excelent, thanks Jamie. I wasn't aware of this setting and assumed that the stuff in the gnupg config file only applies to gpg itself and not, as in alot, for calls through the gpgme library. Actually, bizarrely, there is no actual gpg library. gpgme just calls the gpg binary underneath. Therefore all gpg settings work for gpgme as well. jamie. pgpCf2XT8bChV.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v2] emacs: show: stop stderr appearing in buffer
In emacs 24.3+ the stdout/stderr from externally displaying an attachment gets inserted into the show buffer. This is caused by changes in mm-display-external in mm-decode.el. Ideally, we would put this output in the notmuch errors buffer but the handler is called asynchronously so we don't know when the output will appear. Thus if we put it straight into the errors buffer it could get interleaved with other errors. Also we can't easily tell when we have got all the error output so can't wait until the process is complete. One solution would be to create a new buffer for the stderr of each attachment viewed. Again, since we can't tell when the process has finished, we can't close these buffers automatically so this will leave lots of buffers around. Thus we add a debug variable notmuch-show-attachment-debug: it this is non-nil we create a new buffer for each viewer; if this variable is nil we just use a temp buffer which means all error output is discarded (this is the same behaviour as with emacs pre 24.3). --- This version just adds a docstring to the debug variable describing what it does and where the debug data is stored (ie what the buffer name is). Best wishes Mark emacs/notmuch-show.el | 19 ++- 1 files changed, 18 insertions(+), 1 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index f00273a..784644c 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -159,6 +159,15 @@ indentation. (make-variable-buffer-local 'notmuch-show-indent-content) (put 'notmuch-show-indent-content 'permanent-local t) +(defvar notmuch-show-attachment-debug nil + If t log stdout and stderr from attachment handlers + +When set to nil (the default) stdout and stderr from attachment +handlers is discarded. When set to t the stdout and stderr from +each attachment handler is logged in buffers with names beginning +\ *notmuch-part*\. This option requires emacs version at least +24.3 to work.) + (defcustom notmuch-show-stash-mlarchive-link-alist '((Gmane . http://mid.gmane.org/;) (MARC . http://marc.info/?i=;) @@ -2089,8 +2098,16 @@ caller is responsible for killing this buffer as appropriate. This ensures that the temporary buffer created for the mm-handle is destroyed when FN returns. (let ((handle (notmuch-show-current-part-handle))) +;; emacs 24.3+ puts stdout/stderr into the calling buffer so we +;; call it from a temp-buffer, unless +;; notmuch-show-attachment-debug is non-nil in which case we put +;; it in *notmuch-part*. (unwind-protect - (funcall fn handle) + (if notmuch-show-attachment-debug + (with-current-buffer (generate-new-buffer *notmuch-part*) + (funcall fn handle)) + (with-temp-buffer + (funcall fn handle))) (kill-buffer (mm-handle-buffer handle) (defun notmuch-show-part-button-default (optional button) -- 1.7.9.1 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/2] fix compilation without emacs
If emacs is not installed, the following error is printed while compiling: /bin/sh: 1: emacs: not found This patch fixes the build. It might be better to exclude the whole emacs directory from build when compiling without emacs, but that's a bigger change. Signed-off-by: Tomi Valkeinen tomi.valkei...@iki.fi --- emacs/Makefile.local | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/emacs/Makefile.local b/emacs/Makefile.local index 92467a3..0fcf64c 100644 --- a/emacs/Makefile.local +++ b/emacs/Makefile.local @@ -24,6 +24,7 @@ emacs_images := \ emacs_bytecode = $(emacs_sources:.el=.elc) +ifeq ($(WITH_EMACS),1) # Because of defmacro's and defsubst's, we have to account for load # dependencies between Elisp files when byte compiling. Otherwise, # the byte compiler may load an old .elc file when processing a @@ -39,7 +40,6 @@ CLEAN+=$(dir)/.eldeps $(dir)/.eldeps.tmp %.elc: %.el $(global_deps) $(call quiet,EMACS) --directory emacs -batch -f batch-byte-compile $ -ifeq ($(WITH_EMACS),1) ifeq ($(HAVE_EMACS),1) all: $(emacs_bytecode) endif -- 1.8.3.2 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2/2] lib: fix error handling
Currently if a Xapian exception happens in notmuch_message_get_header,
the exception is not caught leading to crash. In
notmuch_message_get_date the exception is caught, but an internal error
is raised, again leading to crash.
This patch fixes the error handling by making both functions catch the
Xapian exceptions, print an error and return NULL or 0.
The 'notmuch-exception_reported' is also set, as is done elsewhere,
even if I don't really get the idea of that field.
Signed-off-by: Tomi Valkeinen tomi.valkei...@iki.fi
---
lib/message.cc | 34 ++
1 file changed, 22 insertions(+), 12 deletions(-)
diff --git a/lib/message.cc b/lib/message.cc
index 1b46379..c91f3a5 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -412,19 +412,27 @@ _notmuch_message_ensure_message_file (notmuch_message_t
*message)
const char *
notmuch_message_get_header (notmuch_message_t *message, const char *header)
{
-std::string value;
+try {
+ std::string value;
-/* Fetch header from the appropriate xapian value field if
- * available */
-if (strcasecmp (header, from) == 0)
- value = message-doc.get_value (NOTMUCH_VALUE_FROM);
-else if (strcasecmp (header, subject) == 0)
- value = message-doc.get_value (NOTMUCH_VALUE_SUBJECT);
-else if (strcasecmp (header, message-id) == 0)
- value = message-doc.get_value (NOTMUCH_VALUE_MESSAGE_ID);
+ /* Fetch header from the appropriate xapian value field if
+* available */
+ if (strcasecmp (header, from) == 0)
+ value = message-doc.get_value (NOTMUCH_VALUE_FROM);
+ else if (strcasecmp (header, subject) == 0)
+ value = message-doc.get_value (NOTMUCH_VALUE_SUBJECT);
+ else if (strcasecmp (header, message-id) == 0)
+ value = message-doc.get_value (NOTMUCH_VALUE_MESSAGE_ID);
-if (!value.empty())
- return talloc_strdup (message, value.c_str ());
+ if (!value.empty())
+ return talloc_strdup (message, value.c_str ());
+
+} catch (Xapian::Error error) {
+ fprintf (stderr, A Xapian exception occurred when reading header:
%s\n,
+error.get_msg().c_str());
+ message-notmuch-exception_reported = TRUE;
+ return NULL;
+}
/* Otherwise fall back to parsing the file */
_notmuch_message_ensure_message_file (message);
@@ -766,7 +774,9 @@ notmuch_message_get_date (notmuch_message_t *message)
try {
value = message-doc.get_value (NOTMUCH_VALUE_TIMESTAMP);
} catch (Xapian::Error error) {
- INTERNAL_ERROR (Failed to read timestamp value from document.);
+ fprintf (stderr, A Xapian exception occurred when reading date: %s\n,
+error.get_msg().c_str());
+ message-notmuch-exception_reported = TRUE;
return 0;
}
--
1.8.3.2
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
