From: Tomi Ollila <tomi.ollila@iki.fi>
To: Keith Amidon <camalot@picnicpark.org>, notmuch@notmuchmail.org
Subject: Re: notmuch-insert Fcc handling w/spaces in dir name
Date: Mon, 10 Oct 2016 22:14:43 +0300 [thread overview]
Message-ID: <m2wphgrp7g.fsf@guru.guru-group.fi> (raw)
In-Reply-To: <1476123439.3172.12.camel@picnicpark.org>
On Mon, Oct 10 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"
>
> 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.
>
> 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")
>
> Then the code could generate the shell command with appropriate
> quoting.
Actually it looks like (also by quick look) that the elisp code does
not generate shell command with appropriate quoting, but first
splits the line with (split-string-and-unquote fcc-header) (*) and then
creates command line arguments based on that list...
(*) line 235 in notmuch-maildir-fcc.el
so, it could be somewhat trivial to allow fcc-header to be either
string or list -- and in the latter case use something like you presented
above…
Tomi
> 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.
>
> Cheers! Keith
>
>
> _______________________________________________
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch
next prev parent reply other threads:[~2016-10-10 19:13 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-10 18:17 notmuch-insert Fcc handling w/spaces in dir name Keith Amidon
2016-10-10 19:14 ` Tomi Ollila [this message]
2016-10-10 19:20 ` Mark Walters
2016-10-11 3:37 ` Keith Amidon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://notmuchmail.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2wphgrp7g.fsf@guru.guru-group.fi \
--to=tomi.ollila@iki.fi \
--cc=camalot@picnicpark.org \
--cc=notmuch@notmuchmail.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://yhetil.org/notmuch.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).