MIME restructuring [was: Re: release-candidate/0.6]
On Mon, 16 May 2011 13:59:51 -0700, Carl Worth wrote: > So what I'd love to see from here is a commit with a description like > the above, and then a test case looking like your example. > > From there, I'd next like a new version of the commit that gets the > intended behavior with less code duplication. > > I'll work on each of the above unless someone beats me to any of it. Let > me know. I've now pushed out my own version of the MIME restructuring feature. It differs from what was presented here in avoiding the code duplication. It also provides properly nested mutlipart/* output for the --format=text case. That's not that I expect anybody to *do* anything with that nested output, just that it was cleaner and easier to fix both text/json at the same time, (and avoiding doing that is perhaps what led to the original code duplication). I also cherry-picked in a piece of later patch from Jamie so that the existing emacs tests still pass. And I updated the documentation for this new feature. So I'm happy with this new feature now, (which I know provides an essential part of the basis for the rest of the crypto branch).
Header and other questions
On Mon, 16 May 2011 09:29:19 -0700, Jameson Graef Rollins wrote: > On Mon, 16 May 2011 11:27:52 -0400, Jesse Rosenthal > wrote: > > The decision, if I remember correctly, was that regions are so intuitive > > for emacs users, and many people reported trying to tag by region > > without thinking about it, that this approach would make sense for the > > emacs interface. In other words, keep the emacs interface emacsy. I > > think I still agree with that, since I feel like having both would be > > confusing (what do you do when you select a marked-line in a region?) > > and I like the one I tend toward intuitively. But I certainly see the > > benefit of the other functionality as well. > > I should mention that in my experience it's usually not that hard to > construct searches (or filters on searches) that pair down to just the > messages you want to tag, in which case you can just tag the entire > buffer. Maybe its more a question of key bindings: 1. add some special tag to messages 2. filter on this tag 3. do something with the whole buffer 4. remove special tag from all messages 5. close filter I'd welcome a standard set of key bindings for it. -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: flo at chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC -- 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/20110517/cad2c922/attachment.pgp>
[BUG] [PATCH] Fix appending of Received headers
We're not properly concatenating the Received headers if we parse them
while requesting a header that isn't Received.
this fixes notmuch-reply address detection in a bunch of situations.
diff --git a/lib/message-file.c b/lib/message-file.c
index 7722832..dd0f698 100644
--- a/lib/message-file.c
+++ b/lib/message-file.c
@@ -329,7 +329,7 @@ notmuch_message_file_get_header (notmuch_message_file_t
*message,
/* we treat the Received: header special - we want to concat ALL of
* the Received: headers we encounter.
* for everything else we return the first instance of a header */
- if (is_received) {
+ if (strcasecmp(header, "received") == 0) {
if (header_sofar == NULL) {
/* first Received: header we encountered; just add it */
g_hash_table_insert (message->headers, header, decoded_value);
--
Stewart Smith
Header and other questions
Hi, On Mon, 16 May 2011 09:29:19 -0700, Jameson Graef Rollins wrote: > On Mon, 16 May 2011 11:27:52 -0400, Jesse Rosenthal > wrote: > > The decision, if I remember correctly, was that regions are so intuitive > > for emacs users, and many people reported trying to tag by region > > without thinking about it, that this approach would make sense for the > > emacs interface. In other words, keep the emacs interface emacsy. I > > think I still agree with that, since I feel like having both would be > > confusing (what do you do when you select a marked-line in a region?) > > and I like the one I tend toward intuitively. But I certainly see the > > benefit of the other functionality as well. > > I should mention that in my experience it's usually not that hard to > construct searches (or filters on searches) that pair down to just the > messages you want to tag, in which case you can just tag the entire > buffer. That's true. I always end up doing that way. Though, many Gnus users are used to mark and to massage all those messages at once, thus offering this possibility could help. /Xavier
Multiple sender identities (composing)
On Mon, 16 May 2011 11:52:43 +0200, Thomas Jost wrote: > On Mon, 16 May 2011 19:29:07 +1000, Stewart Smith flamingspork.com> wrote: > (people who don't use or like ido may want to replace > ido-completing-read with completing-read) I couldn't get ido to work at all (Ubuntu Natty). It would just prompt and not tab complete or even accept enter (it would insert a newline in minibuffer) - which is why I just ended up using completing-read. > - function to change the SMTP server that will be used for sending the > mail according to the From header I actually just do this via postfix sender_dependent_relayhost_maps which ends up working quite nicely. -- Stewart Smith
MIME restructuring [was: Re: release-candidate/0.6]
lol, made my day! Simon On 05/16/2011 11:05 PM, Daniel Kahn Gillmor wrote: > On 05/16/2011 04:50 PM, Daniel Kahn Gillmor wrote: >> So a message like this: >> >> A???multipart/signed 355339 bytes >> B ???multipart/mixed 353462 bytes >> C ???text/plain 235 bytes >> D ???image/jpeg attachment [foo.jpg] 352752 bytes >> E ??application/pgp-signature attachment [signature.asc] 1030 bytes >> >> would come out with three parts: >> >> 1) C >> 2) D >> 3) E >> >> the new code assigns this message to 5 parts: >> >> 1) A >> 2) B >> 3) C >> 4) D >> 5) E > > This message should itself be a comparably complex message, with a tiny > attached image of a geek with a bike. Feel free to use this in the test > suite (the picture and this message are hereby released under the same > license as notmuch itself). > > Note that if the mailing list attaches a footer, the MIME tree will be > even more delightfully complicated, for added fun and games. > > --dkg > > > > ___ > notmuch mailing list > notmuch at notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch
Re: Header and other questions
On Mon, 16 May 2011 09:29:19 -0700, Jameson Graef Rollins jroll...@finestructure.net wrote: On Mon, 16 May 2011 11:27:52 -0400, Jesse Rosenthal jrosent...@jhu.edu wrote: The decision, if I remember correctly, was that regions are so intuitive for emacs users, and many people reported trying to tag by region without thinking about it, that this approach would make sense for the emacs interface. In other words, keep the emacs interface emacsy. I think I still agree with that, since I feel like having both would be confusing (what do you do when you select a marked-line in a region?) and I like the one I tend toward intuitively. But I certainly see the benefit of the other functionality as well. I should mention that in my experience it's usually not that hard to construct searches (or filters on searches) that pair down to just the messages you want to tag, in which case you can just tag the entire buffer. Maybe its more a question of key bindings: 1. add some special tag to messages 2. filter on this tag 3. do something with the whole buffer 4. remove special tag from all messages 5. close filter I'd welcome a standard set of key bindings for it. -- Florian Friesdorf f...@chaoflow.net GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgp0nZcnONRbJ.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: MIME restructuring [was: Re: release-candidate/0.6]
On Mon, 16 May 2011 13:59:51 -0700, Carl Worth cwo...@cworth.org wrote: So what I'd love to see from here is a commit with a description like the above, and then a test case looking like your example. From there, I'd next like a new version of the commit that gets the intended behavior with less code duplication. I'll work on each of the above unless someone beats me to any of it. Let me know. I've now pushed out my own version of the MIME restructuring feature. It differs from what was presented here in avoiding the code duplication. It also provides properly nested mutlipart/* output for the --format=text case. That's not that I expect anybody to *do* anything with that nested output, just that it was cleaner and easier to fix both text/json at the same time, (and avoiding doing that is perhaps what led to the original code duplication). I also cherry-picked in a piece of later patch from Jamie so that the existing emacs tests still pass. And I updated the documentation for this new feature. So I'm happy with this new feature now, (which I know provides an essential part of the basis for the rest of the crypto branch). From here, I'm hoping that my review of the rest of Jamie's release-candidate branch goes faster. The general shape of the commits and commit messages looks pretty good to me, so I think it will. I think there are still features added here and there without corresponding test cases (multipart/alternative is one that comes to mind) and perhaps without updated documentation (--decrypt is at least documented---but I do think it's strange that it's documented to only work for json output). More from me tomorrow. -Carl pgpzsmwWIBXKT.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
