Re: [PATCH] VIM: Make an option to save sent mail locally

Subject: Re: [PATCH] VIM: Make an option to save sent mail locally

Date: Thu, 05 Feb 2015 11:34:22 +0100

To: Bartosz Telenczuk

Cc:, Bartosz Telenczuk

From: Franz Fellner

Bartosz Telenczuk wrote:
> > > I would appreciate an option to configure the "sent" box per provider. I
> > > implemented this feature in this patch:
> > > 
> > >
> > 
> > Generally it might work. But there are other features that may rely on per-account-settings (drafts, outbox, templates, ...). Setting them all that way might get ugly. The best solution might be to introduce a setting for account information.
> Definitely, in my implementation this is done via a setting in the notmuch config file, which maps between accounts and provider dir. If this is not configure, it default to not storing sent emails. For example:
> [vim]

That's what I called "ugly": Using a probably long and/or unreadable mail address as identifier is errorprone, if you have several accounts those things tend to get unreadable. Especially if you need to write them over and over again for different folders/features (sent, drafts, ...).
I thought of one string to store the whole account manager config, just like

[default] # or call it "local" - not bound to any real account


sent=Sent  # gmail specific: using gmails smtp server stores sent mails automatically on the server

// and so on
(used an ini format, but might be done in any other way like ruby hashes or yaml or...)
The default settings get default values by our vim plugin. They get used automatically if a user-defined account does not specifically set a folder - that way account2 could just have left out the "sent" setting.
If the user overwrites the default-account and leaves out a folder, such as sent, he might want that feature to be deactivated. Though I still think it is dangerous: it applies well for sent, but deactivating drafts (probably as automatic temporary storage for mails that are currently written and should be restorable after a crash) can cause issues, e.g. lost mails. So I would vote for a different solution. E.g. a separate boolean setting. Or we could treat an empty string for non-default accounts as "deactivate":


I can start implementing this, but I currently have other important things to do, so it can take some time.


> Cheers,
> Bartosz