* [sup-talk] on sup [not found] <1188557360-sup-7369@bryma> @ 2007-08-31 15:31 ` William Morgan 2007-08-31 17:12 ` Magnus Therning 0 siblings, 1 reply; 12+ messages in thread From: William Morgan @ 2007-08-31 15:31 UTC (permalink / raw) Excerpts from Magnus Therning's message of Fri Aug 31 04:04:03 -0700 2007: > Hey! Sup is absolutely great! Thanks! Feel free to join the mailing list and tell all your friends. Especially if they can write Ruby. :) > Here are some things I'd like to see in sup in the future: > > - support for using the output of a command as signature (I don't seem > to even get the contents of ~/.signature inserted into new emails) It should be trivial to add a hook for this. 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. > - PGP/GPG support, this is really a show stopper for me at the moment 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. > - support for choosing where to save sent messages This I'm a little curious about. Why do you care where they live on disk, as long as they show up in the index? Thanks for the feedback, -- William <wmorgan-sup at masanjin.net> ^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] on sup 2007-08-31 15:31 ` [sup-talk] on sup William Morgan @ 2007-08-31 17:12 ` Magnus Therning 2007-09-02 23:03 ` William Morgan 2007-09-03 12:33 ` [sup-talk] saving sent mail to places other than the default jeff covey 0 siblings, 2 replies; 12+ messages in thread From: Magnus Therning @ 2007-08-31 17:12 UTC (permalink / raw) On Fri, Aug 31, 2007 at 08:31:04 -0700, William Morgan wrote: >Excerpts from Magnus Therning's message of Fri Aug 31 04:04:03 -0700 2007: >> Hey! Sup is absolutely great! > >Thanks! Feel free to join the mailing list and tell all your friends. >Especially if they can write Ruby. :) Here I am. Not very proficient in Ruby myself, but I suppose sup offers an incentive to check it out. >> Here are some things I'd like to see in sup in the future: >> >> - support for using the output of a command as signature (I don't seem >> to even get the contents of ~/.signature inserted into new emails) > >It should be trivial to add a hook for this. 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 :-) >> - PGP/GPG support, this is really a show stopper for me at the moment > >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? >> - support for choosing where to save sent messages > >This I'm a little curious about. Why do you care where they live on >disk, as long as they show up in the index? All right, here's some background :-) I have a fairly extensive configuration of procmail for sorting mails into maildir folders on a server at a friend's place. I then synchronise those folders onto a few different machines. This way I can read emails on all machines, both at home and work. When I'm travelling I can use the web-based reader hosted on the same server at my friend's. Given this I want to control where sent mails end up so that I can access those mails from all those locations. And I want to keep my hierarchy of folders so that reading emails is easy also on machines where I can't install sup and online. 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). /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus?therning?org Jabber: magnus?therning?gmail?com http://therning.org/magnus When the people fear their government, there is tyranny; when the government fears the people, there is liberty. -- Thomas Jefferson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://rubyforge.org/pipermail/sup-talk/attachments/20070831/8ae01aa6/attachment-0001.bin ^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] on sup 2007-08-31 17:12 ` Magnus Therning @ 2007-09-02 23:03 ` William Morgan 2007-09-05 7:48 ` Magnus Therning 2007-09-03 12:33 ` [sup-talk] saving sent mail to places other than the default jeff covey 1 sibling, 1 reply; 12+ messages in thread From: William Morgan @ 2007-09-02 23:03 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] on sup 2007-09-02 23:03 ` William Morgan @ 2007-09-05 7:48 ` Magnus Therning 2007-09-05 15:27 ` William Morgan 2007-09-05 21:55 ` William Morgan 0 siblings, 2 replies; 12+ messages in thread From: Magnus Therning @ 2007-09-05 7:48 UTC (permalink / raw) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Excerpts from William Morgan's message of Mon Sep 03 00:03:29 +0100 2007: > 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. Ah, cool. That all makes sense. I think I like the flow of things as they are. > > >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. I wouldn't mind to be a beta-tester for that. Let me know if you merge it, or share the changes in another branch or something. After thinking a little about this I think it's the receiving of encrypted/signed emails that's cumbersome to deal with at the moment. If I'm not completely daft it seems like sending is infinitely flexible through the hooks system. > > 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. I'll see if I can't get my head around this red-corundum language you're using and take a stab at adding this. ;-) One more question, is there anything "site specific" in the state data sup maintains? Would I run into problem if I use rsync/unison to synchronise sup's state to several machines? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG3l8kiMWTaatN+6QRAmP1AJ9ynvIgglFT4z1ku8LyjfeIoNOxoQCffjey bnjeItGmOKF/TOVTIBtWmF8= =zyyx -----END PGP SIGNATURE----- -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus?therning?org Jabber: magnus?therning?gmail?com http://therning.org/magnus What if I don't want to obey the laws? Do they throw me in jail with the other bad monads? -- Daveman ^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] on sup 2007-09-05 7:48 ` Magnus Therning @ 2007-09-05 15:27 ` William Morgan 2007-09-06 7:02 ` Magnus Therning 2007-09-05 21:55 ` William Morgan 1 sibling, 1 reply; 12+ messages in thread From: William Morgan @ 2007-09-05 15:27 UTC (permalink / raw) Excerpts from Magnus Therning's message of Wed Sep 05 00:48:03 -0700 2007: > After thinking a little about this I think it's the receiving of > encrypted/signed emails that's cumbersome to deal with at the moment. > If I'm not completely daft it seems like sending is infinitely > flexible through the hooks system. The hooks would be an option, but I'm actually planning to stick it in the code directly. What I'm thinking is that decoding will just hide the attachment and display a little message at the top of the message saying "signature verified", or a big nasty message if not. For encoding, I would like to have some nice way of choosing sign/sign&encrypt/nothing on a per-message basis, but I'm not sure what the best UI for that is. I was originally thinking something like the reply-mode options, but then how would the two interact? I could also make each option correspond to various keyboard combinations, but that seems a little obtuse. I don't really like the mutt-style prompt at the bottom on the screen (the "minibuffer", as I style it). > One more question, is there anything "site specific" in the state data > sup maintains? Would I run into problem if I use rsync/unison to > synchronise sup's state to several machines? Sup uses sources.yaml to map between integer source ids (which are stored in the index) and the source URIs, which for mbox files are absolute pathnames. So if you're using local mbox files and the paths differ between machines, you'll have to tweak sources.yaml to reflect that. If the source URIs are the same, then as long as sources.yaml is synchronized along with the ferret/ directory, you should be fine. Beyond that, Sup uses Ferret to store all state, so if the different sites have different architecture, it's going to be up to Ferret as to whether the indexes are portable. I'm not sure of the answer on this one. -- William <wmorgan-sup at masanjin.net> ^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] on sup 2007-09-05 15:27 ` William Morgan @ 2007-09-06 7:02 ` Magnus Therning 2007-09-11 22:08 ` William Morgan 0 siblings, 1 reply; 12+ messages in thread From: Magnus Therning @ 2007-09-06 7:02 UTC (permalink / raw) Excerpts from William Morgan's message of Wed Sep 05 16:27:14 +0100 2007: > Excerpts from Magnus Therning's message of Wed Sep 05 00:48:03 -0700 2007: > > After thinking a little about this I think it's the receiving of > > encrypted/signed emails that's cumbersome to deal with at the > > moment. If I'm not completely daft it seems like sending is > > infinitely flexible through the hooks system. > > The hooks would be an option, but I'm actually planning to stick it in > the code directly. What I'm thinking is that decoding will just hide > the attachment and display a little message at the top of the message > saying "signature verified", or a big nasty message if not. For > encoding, I would like to have some nice way of choosing > sign/sign&encrypt/nothing on a per-message basis, but I'm not sure > what the best UI for that is. I was originally thinking something like > the reply-mode options, but then how would the two interact? I could > also make each option correspond to various keyboard combinations, but > that seems a little obtuse. I don't really like the mutt-style prompt > at the bottom on the screen (the "minibuffer", as I style it). Yes, the UI will be hard to get right on this. What about adding an extra screen with extra options for sending (encryption/signing might only be one set of options that are needed). That would push the problem to being one of making sure that good, fairly powerful default behaviours are in place. These are the default behaviours I'd like to see: - Don't sign, don't encrypt - Sign all out-going messages, don't encrypt - Sign all replies to signed messages, don't encrypt - Sign all replies to signed messages, encrypt replies to encrypted messages - Sign all out-going messages, encrypt all messages to recipients with a known public key I hope that covers more usage so that visiting that extra screen won't be necessary in most cases. Making sure that it all works on emails with multiple recipients shouldn't be too difficult. (Signing isn't a problem, and encryption only happens if _all_ recipients have a known public key.) -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus?therning?org Jabber: magnus?therning?gmail?com http://therning.org/magnus What if I don't want to obey the laws? Do they throw me in jail with the other bad monads? -- Daveman ^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] on sup 2007-09-06 7:02 ` Magnus Therning @ 2007-09-11 22:08 ` William Morgan 2007-09-11 23:04 ` Magnus Therning 0 siblings, 1 reply; 12+ messages in thread From: William Morgan @ 2007-09-11 22:08 UTC (permalink / raw) Excerpts from Magnus Therning's message of Thu Sep 06 00:02:27 -0700 2007: > These are the default behaviours I'd like to see: > > - Don't sign, don't encrypt > - Sign all out-going messages, don't encrypt > - Sign all replies to signed messages, don't encrypt > - Sign all replies to signed messages, encrypt replies to encrypted > messages > - Sign all out-going messages, encrypt all messages to recipients with > a known public key I think you've convinced me to hold off any an UI changes and just have a set of behaviors for signing and encryption, configurable in config.yaml, that are sophisticated enough to minimize the need for per-message actions. That should be pretty easy to do. -- William <wmorgan-sup at masanjin.net> ^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] on sup 2007-09-11 22:08 ` William Morgan @ 2007-09-11 23:04 ` Magnus Therning 0 siblings, 0 replies; 12+ messages in thread From: Magnus Therning @ 2007-09-11 23:04 UTC (permalink / raw) On Tue, Sep 11, 2007 at 15:08:34 -0700, William Morgan wrote: >Excerpts from Magnus Therning's message of Thu Sep 06 00:02:27 -0700 2007: >> These are the default behaviours I'd like to see: >> >> - Don't sign, don't encrypt >> - Sign all out-going messages, don't encrypt >> - Sign all replies to signed messages, don't encrypt >> - Sign all replies to signed messages, encrypt replies to encrypted >> messages >> - Sign all out-going messages, encrypt all messages to recipients with >> a known public key > >I think you've convinced me to hold off any an UI changes and just have >a set of behaviors for signing and encryption, configurable in >config.yaml, that are sophisticated enough to minimize the need for >per-message actions. That should be pretty easy to do. Now I know this might not be a very user friendly idea and probably not ideal for the long run. It might be a good first step to simply have a hook like this: crypto_hook sender, recipient, reply_to_signed?, reply_to_encrypted? -> dosign, doencrypt (Apply your mad Ruby skills to make it Ruby-esque, but you get the idea.) That'd buy you some time to come to a conclusion, while still making sup a lot more useful for early adopters (like me :-). /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus?therning?org Jabber: magnus?therning?gmail?com http://therning.org/magnus -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://rubyforge.org/pipermail/sup-talk/attachments/20070912/91e2358f/attachment.bin ^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] on sup 2007-09-05 7:48 ` Magnus Therning 2007-09-05 15:27 ` William Morgan @ 2007-09-05 21:55 ` William Morgan 2007-09-06 6:50 ` Magnus Therning 1 sibling, 1 reply; 12+ messages in thread From: William Morgan @ 2007-09-05 21:55 UTC (permalink / raw) Excerpts from Magnus Therning's message of Wed Sep 05 00:48:03 -0700 2007: > > 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. > > I'll see if I can't get my head around this red-corundum language > you're using and take a stab at adding this. ;-) What little Sup currently does in the way of pushing state information back into sources, it does through sup-sync-back, which is meant to push a batch of state changes back to one or more sources in one go. Right now that's restricted to deleting messages marked as deleted or spam from mbox sources, but it would be the natural place to push the new/read state back as well, at least if you were happy with batch operation. -- William <wmorgan-sup at masanjin.net> ^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] on sup 2007-09-05 21:55 ` William Morgan @ 2007-09-06 6:50 ` Magnus Therning 2007-09-11 20:48 ` William Morgan 0 siblings, 1 reply; 12+ messages in thread From: Magnus Therning @ 2007-09-06 6:50 UTC (permalink / raw) Excerpts from William Morgan's message of Wed Sep 05 22:55:38 +0100 2007: [..] > What little Sup currently does in the way of pushing state information > back into sources, it does through sup-sync-back, which is meant to > push a batch of state changes back to one or more sources in one go. > Right now that's restricted to deleting messages marked as deleted or > spam from mbox sources, but it would be the natural place to push the > new/read state back as well, at least if you were happy with batch > operation. I'm more than happy with batch operations. I suspect that doing this outside of sup proper also keeps the main program itself a little simpler. I did look at the sup-sync-back tool and noticed that it performs some mbox operations on its own. Operations that I feel really belong in the mbox source class itself. I feel sup-sync-back would become simpler if polymorphism was put to use a bit more. So, do you have any philosophical problems with a `delete` method being added to the sources? (It would probably be followed by a `mark_as_read` in the future.) -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus?therning?org Jabber: magnus?therning?gmail?com http://therning.org/magnus What if I don't want to obey the laws? Do they throw me in jail with the other bad monads? -- Daveman ^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] on sup 2007-09-06 6:50 ` Magnus Therning @ 2007-09-11 20:48 ` William Morgan 0 siblings, 0 replies; 12+ messages in thread From: William Morgan @ 2007-09-11 20:48 UTC (permalink / raw) Excerpts from Magnus Therning's message of Wed Sep 05 23:50:33 -0700 2007: > I did look at the sup-sync-back tool and noticed that it performs some > mbox operations on its own. Operations that I feel really belong in > the mbox source class itself. I feel sup-sync-back would become > simpler if polymorphism was put to use a bit more. So, do you have > any philosophical problems with a `delete` method being added to the > sources? (It would probably be followed by a `mark_as_read` in the > future.) I don't have a philosophical problem with that, certainly. Sup-sync- back was written in that way because I was fleshing out a lot half-baked ideas about how things should work at the time, and it will definitely be necessary to move that code to Mbox::loader before it can support other source types. In order to support batch operations, I think there should be two methods per source, really: #delete and #write_deletes_to_disk (or whatever), with the semantics that #delete may or may not do something but you're guaranteed that deletions have happened after a call to #write_deletes_to_disk. Then Maildir, IMAP, etc can delete immediately, and mbox can defer (presumably building up an array of offset to be deleted, and then doing the batch deletion as it does currently.) (There are actually a couple other things that need to happen to mbox---it shouldn't keep the file pointers open all the time, it should wrap deletion and new message scanning with a call to dotlockfile, and the bizarre division of labor between loader, sshloader, and the source superclass has become a classic example of how not to use inheritance. Luckily, none of those things really affect this issue.) What do you think? -- William <wmorgan-sup at masanjin.net> ^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] saving sent mail to places other than the default 2007-08-31 17:12 ` Magnus Therning 2007-09-02 23:03 ` William Morgan @ 2007-09-03 12:33 ` jeff covey 1 sibling, 0 replies; 12+ messages in thread From: jeff covey @ 2007-09-03 12:33 UTC (permalink / raw) Excerpts from Magnus Therning's message of Fri Aug 31 13:12:34 -0400 2007: > > > - support for choosing where to save sent messages > > > > This I'm a little curious about. Why do you care where they live on > > disk, as long as they show up in the index? > > I have a fairly extensive configuration of procmail for sorting mails i also want my sent mail sorted by procmail instead of stored in ~/.sup, so i run it through "formail -s procmail". below is the script i run at the end of the day to empty ~/.sup/sent.mbox and file the messages with procmail; you might try something similar, perhaps by cron if it's on your friend's machine. #------------------------------------------------------ #!/bin/sh ruby='ruby -I lib -w' cd ~/tmp/sup/trunk tmpfile=~/tmp/sup-sent/sup-sent-`/bin/date +%F-%T`.mbox mv ~/.sup/sent.mbox $tmpfile touch ~/.sup/sent.mbox echo "processing messages..." formail -s procmail < $tmpfile $ruby bin/sup-sync --changed sup://sent echo "original sup sent mbox in $tmpfile" #------------------------------------------------------ this assumes that the resulting destinations for sent messages are checked by sup in its poll for new messages, so they show up in sup's index again. sincerely, -- jeff covey http://jeffcovey.net/ ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2007-09-11 23:04 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <1188557360-sup-7369@bryma>
2007-08-31 15:31 ` [sup-talk] on sup William Morgan
2007-08-31 17:12 ` Magnus Therning
2007-09-02 23:03 ` William Morgan
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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox