From: wmorgan-sup@masanjin.net (William Morgan)
Subject: [sup-talk] on sup
Date: Sun, 02 Sep 2007 16:03:29 -0700 [thread overview]
Message-ID: <1188773706-sup-1502@south> (raw)
In-Reply-To: <20070831171234.GD8312@die.therning.org>
Excerpts from Magnus Therning's message of Fri Aug 31 10:12:34 -0700 2007:
> On Fri, Aug 31, 2007 at 08:31:04 -0700, William Morgan wrote:
> >By default ~/.signature should be appended to email (not in the
> >editor, but in Sup's review screen immediate post editing). If it's
> >not, it's probably that ~/.sup/config.yaml is pointing to a different
> >file.
>
> Ah, that's slightly confusing behaviour especially after being used to
> mutt. I think I can adapt though :-)
The signature selection algorithm is tied to Sup's multiple account
support: the signature file Sup uses is based on the From: address you
select. You can get the simpler mutt-style behavior by specifying
:edit_signature: true in config.yaml, which always takes the signature
of the default account and dumps it into the editor, or you can now
specify more complicated behavior now with the signature hook.
> >Yep, I plan to have first-order GPG support (i.e. not just in the
> >hooks system.) Not for the next release, but possibly the one after.
> >The time is nigh.
>
> Is anyone working on it already?
There were patches submitted by I think Christian Lee a while ago, but
they never made it into the svn, mostly because I was waiting for
multiple account support to stabilize a bit. Which it now pretty much
has.
> Given this I want to control where sent mails end up so that I can
> access those mails from all those locations.
Sup stores its sent mail in ~/.sup/sent.mbox by default. I'm not opposed
to making that filename configurable, but the quickest fix might be just
to make that a symlink to the actual destination file.
> This makes me think of another little detail, it seems sup's idea of
> what's read and what's new isn't based on the maildir notion of what's
> read and what's new (i.e. sup doesn't move mail from /new to /cur when
> it's read and doesn't recognise that mail in /cur is read).
Yeah, Sup doesn't sync back any state changes to the original sources.
The Sup philosophy has been to treat the sources as dumb, which means
Sup doesn't play well with others. I won't turn aside patches which do
sync back (partial) message state to the sources, but I'm not planning
on implementing that stuff myself.
--
William <wmorgan-sup at masanjin.net>
next prev parent reply other threads:[~2007-09-02 23:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1188557360-sup-7369@bryma>
2007-08-31 15:31 ` William Morgan
2007-08-31 17:12 ` Magnus Therning
2007-09-02 23:03 ` William Morgan [this message]
2007-09-05 7:48 ` Magnus Therning
2007-09-05 15:27 ` William Morgan
2007-09-06 7:02 ` Magnus Therning
2007-09-11 22:08 ` William Morgan
2007-09-11 23:04 ` Magnus Therning
2007-09-05 21:55 ` William Morgan
2007-09-06 6:50 ` Magnus Therning
2007-09-11 20:48 ` William Morgan
2007-09-03 12:33 ` [sup-talk] saving sent mail to places other than the default jeff covey
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1188773706-sup-1502@south \
--to=wmorgan-sup@masanjin.net \
/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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox