Re: 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). 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
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
Re: 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: 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
