Re: Header and other questions

2011-05-17 Thread Florian Friesdorf
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]

2011-05-17 Thread Carl Worth
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


Multiple sender identities (composing)

2011-05-17 Thread Stewart Smith
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]

2011-05-17 Thread Simon Hürlimann
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



Header and other questions

2011-05-17 Thread Xavier Maillard
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


[BUG] [PATCH] Fix appending of Received headers

2011-05-17 Thread Stewart Smith
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

2011-05-17 Thread Florian Friesdorf
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>


MIME restructuring [was: Re: release-candidate/0.6]

2011-05-17 Thread Carl Worth
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).