From: cworth@cworth.org (Carl Worth)
Subject: [sup-talk] What's your sup workflow (and a spew of ideas)
Date: Tue, 18 Aug 2009 15:16:08 -0700 [thread overview]
Message-ID: <1250633501-sup-3981@yoom> (raw)
In-Reply-To: <1250632714-sup-9910@Longbow>
Excerpts from Andrei Thorp's message of Tue Aug 18 15:07:28 -0700 2009:
> Excerpts from Carl Worth's message of Tue Aug 18 17:02:05 -0400 2009:
> > Anyway, the current misfeature I'm hitting is that if I do postpone
> > a draft, then return to edit it more, then postpone it again,
> > etc. eventually when I send the message I'll have several
> > partially-composed drafts in various states that I need to go and
> > manually clean up. It seems like most email programs avoid this
> > problem by removing the draft as soon as its selected for editing
> > again, and I propose that sup do the same.
>
> I think I agree there, and vaguely recall someone attempting to
> implement being able to switch buffers even when an external editor is
> in effect.
That would be nice. In the meantime, I have realized that I don't need
to actually postpone my messages to do what I want---I can just exit
the editor and then switch buffers from compose-mode/reply-mode. So
that at least avoids the multiple-drafts issue, (but still leaves the
I-lose-my-state-when-I-quit-the-editor issue).
> Anyway, impressive post there. You seem to really abuse your e-mail
> client and know what you're on about. Good stuff.
Thanks. I have had a lot of ideas cooking for years about what my
dream email-system would look like. I think the impressive bit is that
of the half-dozen programs I've used in the last decade, sup is the
first one to get me to write up a post like that. (All other programs
were so far away from what I wanted as to make it infeasible to fix
them incrementally.)
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090818/6e240f41/attachment.bin>
next prev parent reply other threads:[~2009-08-18 22:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-18 21:02 Carl Worth
2009-08-18 21:46 ` Carl Worth
2009-08-18 22:07 ` Andrei Thorp
2009-08-18 22:16 ` Carl Worth [this message]
2009-08-18 23:02 ` Rich Lane
2009-08-19 1:58 ` Carl Worth
2009-08-19 3:02 ` Rich Lane
2009-08-19 14:03 ` Andrei Thorp
2009-08-19 23:21 ` Carl Worth
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=1250633501-sup-3981@yoom \
--to=cworth@cworth.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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox