Re: Resending the same email
Sebastian Fischmeister sfisc...@uwaterloo.ca writes: Hi, My previous mail editor had a useful feature to resend already sent emails. It's essentially opening an already sent email and have the senders, subject, and body pre-filled as well as all attachments attached. Is this easy to achieve in notmuch? The attachments seem a bit tricky. I often pipe the message to sendmail, using emacs's notmuch-show-pipe-message command (bound to '|' by default). However I agree it would be much nicer to be able to edit the headers slightly, so as to add headers like Resent-To. On a related note, another feature I really miss is the ability to edit and re-send a bounced message. (I realize this could be problematic for notmuch, in that you really want to re-send it with the same message-ID.) David ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: muchsync files renames
Amadeusz Żołnowski aide...@aidecoe.name writes: Hi David, Fist of all thank you for such elaborate answer. I have missed the paragraph about maildir.synchronize_flags somehow. I have it enabled. So this must be source of a problem (?). I've only ever tested with mailder.synchronize_flags = true, because I'm worried that if I disable it I will have a hard time re-enabling it. I do think it is a source of inefficiency, but muchsync should still be usable. Here follows steps I followed: 1. I initialized server locally with muchsync -vv. My mail is stored in ~/Mail on the server. 2. I run muchsync --init ~/mail SERVER. (Directory names do not need to be the same, do they?) Confirmed that directory names do not need to be the same. 3. I run muchsync SERVER. 4. When it lasted much longer then initialization I canceled it by single SIGINT (^c). Interesting. I wish I knew why this was taking much longer than running it on the server, and whether the delay was caused by client activity or server activity. I don't suppose you'd be willing to make a copy of your mail database to repeat the experiment without any risk of messing up your real maildir? Basically what would be interesting to see is (assuming .notmuch-copy on server is configured for this disposable copy): # Log everything for later analysis script # Use new config file location for disposable copy export NOTMUCH_CONFIG=$HOME/.notmuch-copy # Set up a new initial database muchsync - --init ~/test-copy SERVER - --config=.notmuch-copy # Now initial copy is made, see if client is slow # Is notmuch new itself slow? notmuch new # Is resynchronizing muchsync with notmuch slow? muchsync - # Now see if something weird happened on server to make notmuch new slow ssh SERVER notmuch --config=.notmuch-copy new # Now see if something weird happened on server to make muchsync slow ssh SERVER muchsync - --config=.notmuch-copy # Now finally try resynchronizing to see if this is slow muchsync - SERVER - --config=.notmuch-copy # Save script file exit Does something along these lines make sense? If you can figure out which of these is slow (other than --init, which always will be), and what the verbose chatter is, that would help me narrow down and identify any problem. 5. I rerun muchsync SERVER and then it notified me that notmuch identified files names changes - more than 1000. Were the link changes on the client (sent) or the server (received) side? 6. I waited a bit and then I canceled it by SIGINT. 7. I run muchsync --noup SERVER. This took only seconds to finish. So this suggests the issue is on the client side. It sounds like a bug. I wonder if I we can just reproduce this using a public email corpus, so we don't have to worry about people's private email. I suspected that muchsync at step 3 and 5 tried to push files renames back to server. But now I am not sure what was going on. Have I desynchronized file mail flags? It's hard to say if anything has broken for me, but I am a bit worried anyway. If I just disable maildir.synchronize_flags and rerun muchsync, will everything get synchronized properly? I don't think that will change things. maildir.synchronized_flags will make things slower, but it shouldn't affect the SUMMARY numbers you see at the end of muchsync, other than maybe files moving from .../new to .../cur. But presumably most of your mail files were already in cur directories. David ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: muchsync files renames
Hi David, Fist of all thank you for such elaborate answer. I have missed the paragraph about maildir.synchronize_flags somehow. I have it enabled. So this must be source of a problem (?). Here follows steps I followed: 1. I initialized server locally with muchsync -vv. My mail is stored in ~/Mail on the server. 2. I run muchsync --init ~/mail SERVER. (Directory names do not need to be the same, do they?) 3. I run muchsync SERVER. 4. When it lasted much longer then initialization I canceled it by single SIGINT (^c). 5. I rerun muchsync SERVER and then it notified me that notmuch identified files names changes - more than 1000. 6. I waited a bit and then I canceled it by SIGINT. 7. I run muchsync --noup SERVER. This took only seconds to finish. I suspected that muchsync at step 3 and 5 tried to push files renames back to server. But now I am not sure what was going on. Have I desynchronized file mail flags? It's hard to say if anything has broken for me, but I am a bit worried anyway. If I just disable maildir.synchronize_flags and rerun muchsync, will everything get synchronized properly? -- Amadeusz Żołnowski signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Resending the same email
Hi, My previous mail editor had a useful feature to resend already sent emails. It's essentially opening an already sent email and have the senders, subject, and body pre-filled as well as all attachments attached. Is this easy to achieve in notmuch? The attachments seem a bit tricky. Thanks, Sebastian ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Resending the same email
On Sun, 23 Aug 2015, David Mazieres dm-list-email-notm...@scs.stanford.edu wrote: Sebastian Fischmeister sfisc...@uwaterloo.ca writes: Hi, My previous mail editor had a useful feature to resend already sent emails. It's essentially opening an already sent email and have the senders, subject, and body pre-filled as well as all attachments attached. Is this easy to achieve in notmuch? The attachments seem a bit tricky. I often pipe the message to sendmail, using emacs's notmuch-show-pipe-message command (bound to '|' by default). However I agree it would be much nicer to be able to edit the headers slightly, so as to add headers like Resent-To. On a related note, another feature I really miss is the ability to edit and re-send a bounced message. (I realize this could be problematic for notmuch, in that you really want to re-send it with the same message-ID.) http://notmuchmail.org/emacstips/#index16h2 (define-key notmuch-show-mode-map b (lambda (optional address) Bounce the current message. (interactive sBounce To: ) (notmuch-show-view-raw-message) (message-resend address))) This really should be part of notmuch-emacs, but as I recall it we just never came to a conclusion whether this does the right thing or not. BR, Jani. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: muchsync files renames
So just to follow up a bit. I looked into things a bit further, and here is what I found with maildir.synchronize_flags set to true. Initially, when you run muchsync --init, it copies all the files to your maildir, and for each file invokes notmuch_message_tags_to_maildir_flag. That changes the name of the file, with the result that the sql database and the actual mail directory end up out of sync. That on it's own is not a big deal, but it means that the next time muchsync, muchsync will have to rescan all of the files, as their names are no longer correct. That shouldn't cause any extra traffic between the two machines, but it will require time on the client. That is likely the source of the delay you were seeing. However, if you C-c the client during this process, I still don't see any problems arising that cause more links to be transferred between machines. So I'm kind of stumped about that part. Maybe muchsync should create the original file name based on tags, so as to avoid having to rescan in the common case. I wish there were some way of getting the renamed file after notmuch_message_tags_to_maildir_flags. David ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Resending the same email
On Sun, Aug 23 2015, Jani Nikula j...@nikula.org wrote: On Sun, 23 Aug 2015, David Mazieres dm-list-email-notm...@scs.stanford.edu wrote: Sebastian Fischmeister sfisc...@uwaterloo.ca writes: Hi, My previous mail editor had a useful feature to resend already sent emails. It's essentially opening an already sent email and have the senders, subject, and body pre-filled as well as all attachments attached. Is this easy to achieve in notmuch? The attachments seem a bit tricky. I often pipe the message to sendmail, using emacs's notmuch-show-pipe-message command (bound to '|' by default). However I agree it would be much nicer to be able to edit the headers slightly, so as to add headers like Resent-To. On a related note, another feature I really miss is the ability to edit and re-send a bounced message. (I realize this could be problematic for notmuch, in that you really want to re-send it with the same message-ID.) http://notmuchmail.org/emacstips/#index16h2 (define-key notmuch-show-mode-map b (lambda (optional address) Bounce the current message. (interactive sBounce To: ) (notmuch-show-view-raw-message) (message-resend address))) This really should be part of notmuch-emacs, but as I recall it we just never came to a conclusion whether this does the right thing or not. There is also http://article.gmane.org/gmane.mail.notmuch.general/20179 (which is now stale, due to context in defining key b) I've planned a new version which does *NOT* 1) initially do the comma (,) magic in notmuch-address-from-minibuffer 2) initially add the keybinding b in notmuch-show-mode-map ... that means a 3-patch series :D Tomi BR, Jani. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
