On Mon, 10 Oct 2016, Keith Amidon <camalot@picnicpark.org> wrote: > I just upgraded to 0.23 and tried out the Fcc handling using notmuch- > insert. I think this is a significant improvement and I'm excited to > use it. I have it working successfully for my use case now, but it > did require one workaround that I didn't expect and that seems somewhat > fragile. > > The issue is that I'm synchronizing with Gmail and I'd like my sent > mail to be synchronized too. Therefore I have to insert into the > directory Gmail expects, which is "[Gmail]/Sent Mail". Notice the > space in the directory name. > > I was able to make this work by setting notmuch-fcc-dirs to: > > "\"[Gmail]/Sent Mail\" +sent -inbox -unread" That is correct and this should probably be documented. > This works because the Fcc handling constructs a shell command to run > by just appending the notmuch-fcc-dirs value to (in the simple case) > "notmuch-insert --folder=", so the extra double quotes in my notmuch- > fcc-dirs value quote things appropriately at the shell level. I don't think this is correct. I think the fcc line gets split using split-string-and-unquote and passes the arguments to notmuch insert using call-process; I don't think it goes via shell. > While this works, depending on passing through shell quoting seems very > fragile. Changes in the implementation could break this solution > without it being obvious why. It seems like it would be better if the > notmuch-fcc-dirs value could be something like: > > ("[Gmail]/Sent Mail" "+sent" "-inbox" "-unread") This is possible. However, in the current form it is possible for the user to edit the fcc header before sending, and that has to be a string. Now, we could do as you suggest, and use combine-and-quote-strings to make the fcc header. Note, it is going to make things pretty complex if we still want to allow the folder to specified based on the from address. > Then the code could generate the shell command with appropriate > quoting. I took a quick look at implementing this but it looked more > complicated then I had time to invested right now. I thought it would > be good to get the issue out for discussion ASAP since this new > functionality was just released. Thanks: yes if we want to do the above it should be soon. Best wishes Mark