Here are a couple things I''m interested in working on for an 0.5 release: - Maildir speedups - IMAP connection sharing - Mbox filehandle closing (currently every mbox gets its own filehandle which is kept open for the duration of the program) - Date conversion to the local timezone, for sorting and display - Configurable colors. Everyone''s favorite. - Notes. Like draft emails without a recipient, but treated specially by the UI. Never sent; just for local use. - gpg-hook for auto-selecting sign/encrypt/both based on whatever you want. Any critical issues for people that they''d like to see addressed? -- William <wmorgan-sup at masanjin.net>
Excerpts from William Morgan''s message of Thu Jan 24 22:59:43 -0700 2008:> Here are a couple things I''m interested in working on for an 0.5 > release: > > - Mbox filehandle closing (currently every mbox gets its own filehandle > which is kept open for the duration of the program)Is this a good thing? I''d rather set my open filehandle limit really high and have them kept open. Isn''t it slower to constantly have to reopen them? Well, I guess the unusual ones certainly don''t need an open handle.> - Date conversion to the local timezone, for sorting and displayYeah, there''s something wrong with my timestamps. Everything shows up as PM. The time is right but it always says PM in the display...> - Notes. Like draft emails without a recipient, but treated specially > by the UI. Never sent; just for local use. > - gpg-hook for auto-selecting sign/encrypt/both based on whatever you > want. >These would be nice.> Any critical issues for people that they''d like to see addressed? >I don''t know what your philosophical feelings are about this but it might be nice to combine IM into sup. It''d be a bunch more protocols to incorporate and the model might be completely different though. Also, is there a way to go from one thread-view directly to another? I always have to ''x'' to go back to the search-results-mode or the inbox-mode and then scroll to the message I want. I thought ''n'' and ''p'' would do this but I''ve never been able to get them to do anything for me. Maybe I''m just not understanding something? In case it''s not clear, I want the functionality of the ''Newer'' and ''Older'' links in gmail. Thanks again for all your hard work. I''m very happy about sup; it''s made me much more productive and much better organized. I really appreciate the efforts of you and all the other contributors.
On 25/01/2008, at 4:59 PM, William Morgan wrote:> Any critical issues for people that they''d like to see addressed?Hm, wouldn''t call them critical but here are some of my thoughts: - detect locale of system, or offer a choice, for VIM spellcheck. It''s currently hardcoded to en_us - detect from system somehow? - detect when kill has failed if launched with an extant .sup/lock - offer to delete the lockfile? If sup crashes, it''s currently impossible to reload without manually deleting the file. Maybe offer to do it after a couple of tries - better unicode (in and out) support - search in buffer doesn''t work at all, and scrolling through a mail with a lot of unicode causes severe graphical artifacts - at least a cursory effort to not store login credentials in plaintext .. how to store them whilst retaining simplicity and platform independence is an interesting question. Not sure how far sup (or anyone really) wants to go down that particular rabbit hole - attachments/downloads folder? again, I wonder how this fits in with sup''s philosophy - ability to send using something other than local sendmail? for remote mbox, we have a ssh session open and everything .. and dynamic IPs are often RBL''ed - DB store? in particular, sqlite? especially for user config ...? with a view to multiuser access sans user directories & setup files.....? - Launch cargo to high orbit for less than $100/ton and cook a 5-star gourmet bouillabaisse from garden scraps? ok ok ok i''ll stop now ..! thanks : ) Sho -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2429 bytes Desc: not available Url : http://rubyforge.org/pipermail/sup-talk/attachments/20080125/9abe7b64/attachment.bin
Excerpts from Sho Fukamachi''s message of Fri Jan 25 12:12:18 +0100 2008:> > On 25/01/2008, at 4:59 PM, William Morgan wrote: > > > Any critical issues for people that they''d like to see addressed? > > Hm, wouldn''t call them critical but here are some of my thoughts: > > - detect locale of system, or offer a choice, for VIM spellcheck. It''s > currently hardcoded to en_us - detect from system somehow?+1> - detect when kill has failed if launched with an extant .sup/lock - > offer to delete the lockfile? If sup crashes, it''s currently > impossible to reload without manually deleting the file. Maybe offer > to do it after a couple of tries+1> - better unicode (in and out) support - search in buffer doesn''t work > at all, and scrolling through a mail with a lot of unicode causes > severe graphical artifacts+1 Best regards, -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 186 bytes Desc: not available Url : http://rubyforge.org/pipermail/sup-talk/attachments/20080125/35ed436f/attachment.bin
Excerpts from William Morgan''s message of Fri Jan 25 00:59:43 -0500 2008:> Here are a couple things I''m interested in working on for an 0.5 > release: > > - Notes. Like draft emails without a recipient, but treated specially > by the UI. Never sent; just for local use.If we''re interested in ''Getting Things Done'', then a nice related feature might be the ability to tell sup not to exit on a ''q'' keypress if there are buffers open marked TODO (or whatever). One of the things I like about sup is the multi-window approach, because instead of making me feel *bad* about having lots of half-finished work, it makes me feel as though it''s reasonable I might just have it going in the background. I find this mis-truth appealing. Problem is, one ''q'' hit (very easily done, ex-mutt user, etc) and I''ve lost my TODO state. -- linkswarm.com :: Collaborative Insolence vasudeva.linkswarm.com/gallery :: For The Faint of Heart
Excerpts from William Morgan''s message of Thu Jan 24 22:59:43 -0700 2008:> Here are a couple things I''m interested in working on for an 0.5 > release: > > Any critical issues for people that they''d like to see addressed? >Not critical but in reading about ferret, I saw that it can search and index various mime-types such as pdf. Allowing search into attachments would be very cool.
Reformatted excerpts from John Bent''s message of 2008-01-24:> Excerpts from William Morgan''s message of Thu Jan 24 22:59:43 -0700 2008: > > - Mbox filehandle closing (currently every mbox gets its own > > filehandle which is kept open for the duration of the program) > > Is this a good thing? I''d rather set my open filehandle limit really > high and have them kept open. Isn''t it slower to constantly have to > reopen them? Well, I guess the unusual ones certainly don''t need an > open handle.It will introduce a very minor slowdown, but I don''t think it will really be that noticeable. And the current approach basically prevents people from having large numbers of mbox sources, which is a little contrary to the Sup philosophy of "put every email you''ve ever read in one program."> > - Date conversion to the local timezone, for sorting and display > Yeah, there''s something wrong with my timestamps. Everything shows up > as PM. The time is right but it always says PM in the display...That''s weird. Is this in thread-index-mode? What about when you expand the header (''h'') in thread-view-mode? Does the time appear correctly?> I don''t know what your philosophical feelings are about this but it > might be nice to combine IM into sup. It''d be a bunch more protocols > to incorporate and the model might be completely different though.Iiiinteresting. Making Sup an IM client proper is almost certainly a world of misery. Getting the current textfield stuff working was a goddamn nightmare, and it''s still very wonky. It does seem a little weird, philosophically speaking, but I wouldn''t throw such code away if it were dumped on my lap. :) That said, what WOULD be easy is to treat IM logs as a message source, and put conversations in the index, gmail style.> Also, is there a way to go from one thread-view directly to another? > I always have to ''x'' to go back to the search-results-mode or the > inbox-mode and then scroll to the message I want.Try the comma-commands. ",n", etc.> I thought ''n'' and ''p'' would do this but I''ve never been able to get > them to do anything for me.These jump between individual open messages in a thread.> Thanks again for all your hard work. I''m very happy about sup; it''s > made me much more productive and much better organized. I really > appreciate the efforts of you and all the other contributors.Glad to hear it. Sup is mostly to scratch my own itch. -- William <wmorgan-sup at masanjin.net>
Excerpts from William Morgan''s message of Fri Jan 25 17:52:20 +0100 2008:> Reformatted excerpts from John Bent''s message of 2008-01-24: > > Excerpts from William Morgan''s message of Thu Jan 24 22:59:43 -0700 2008: > > > - Mbox filehandle closing (currently every mbox gets its own > > > filehandle which is kept open for the duration of the program) > > > > Is this a good thing? I''d rather set my open filehandle limit really > > high and have them kept open. Isn''t it slower to constantly have to > > reopen them? Well, I guess the unusual ones certainly don''t need an > > open handle. > > It will introduce a very minor slowdown, but I don''t think it will > really be that noticeable. And the current approach basically prevents > people from having large numbers of mbox sources, which is a little > contrary to the Sup philosophy of "put every email you''ve ever read in > one program."I don''t get link between having a lot of mails and a lot of mbox sources, for instance I have only one big mbox, and don''t see the need for multiple sources (apart these backup considerations). -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 186 bytes Desc: not available Url : http://rubyforge.org/pipermail/sup-talk/attachments/20080125/cd384fcb/attachment.bin
Excerpts from William Morgan''s message of Fri Jan 25 09:52:20 -0700 2008:> Reformatted excerpts from John Bent''s message of 2008-01-24: > > Excerpts from William Morgan''s message of Thu Jan 24 22:59:43 -0700 2008: > > > > - Date conversion to the local timezone, for sorting and display > > Yeah, there''s something wrong with my timestamps. Everything shows up > > as PM. The time is right but it always says PM in the display... > > That''s weird. Is this in thread-index-mode? What about when you expand > the header (''h'') in thread-view-mode? Does the time appear correctly? >Still incorrect with the expanded header. I checked the mbox file to see if fetchmail was maybe screwing it up but it looks right in there.> Iiiinteresting. Making Sup an IM client proper is almost certainly > a world of misery. Getting the current textfield stuff working was a > goddamn nightmare, and it''s still very wonky. It does seem a little > weird, philosophically speaking, but I wouldn''t throw such code away if > it were dumped on my lap. :) > > That said, what WOULD be easy is to treat IM logs as a message source, > and put conversations in the index, gmail style. >That''d probably actually be what I most want. I have a separate IM client and I treat IM conversations and email slightly differently. But ultimately they are still conversations and it be great to integrate them into sup so I could search through them too.> > Also, is there a way to go from one thread-view directly to another? > > I always have to ''x'' to go back to the search-results-mode or the > > inbox-mode and then scroll to the message I want. > > Try the comma-commands. ",n", etc. >Ok, ",n" is great. Thanks. A ",p" would be nice too....
Excerpts from vasudeva''s message of Fri Jan 25 06:22:52 -0700 2008:> Excerpts from William Morgan''s message of Fri Jan 25 00:59:43 -0500 2008: > If we''re interested in ''Getting Things Done'', then a nice related > feature might be the ability to tell sup not to exit on a ''q'' keypress > if there are buffers open marked TODO (or whatever). One of the things I > like about sup is the multi-window approach, because instead of making > me feel *bad* about having lots of half-finished work, it makes me feel > as though it''s reasonable I might just have it going in the background. > I find this mis-truth appealing. >What is this TODO buffer you''re talking about please? Sounds useful!
Excerpts from John Bent''s message of Fri Jan 25 19:37:07 -0500 2008:> Excerpts from vasudeva''s message of Fri Jan 25 06:22:52 -0700 2008: > > Excerpts from William Morgan''s message of Fri Jan 25 00:59:43 -0500 2008: > > If we''re interested in ''Getting Things Done'', then a nice related > > feature might be the ability to tell sup not to exit on a ''q'' keypress > > if there are buffers open marked TODO (or whatever). One of the things I > > like about sup is the multi-window approach, because instead of making > > me feel *bad* about having lots of half-finished work, it makes me feel > > as though it''s reasonable I might just have it going in the background. > > I find this mis-truth appealing. > > > What is this TODO buffer you''re talking about please? Sounds useful!Sort of random association I made. There''s a neat type-A smartypants thing called ''Getting Things Done'' which seems to be a methodology for... getting things done. More here... http://en.wikipedia.org/wiki/Getting_Things_Done The bit William brought up about adding ''note'' objects piqued my interest and seemed kind of GTD-ish. Personally, I tend to use my inbox as my TODO list, so the ability to "stick" windows -- to set sup buffers non-volatile -- would be something I''d use a lot. As a long-time mutt user, a certain background portion of my brain, as I navigate sup, is devoted entirely to NOT hitting the ''q'' key, which is basically muscle memory at this point. -- linkswarm.com :: Collaborative Insolence vasudeva.linkswarm.com/gallery :: For The Faint of Heart
William Morgan @ 2008-1-24 11:59:43 PM "[sup-talk] 0.5 thoughts" <mid:1201240480-sup-1977 at south>> - IMAP connection sharing+1, shared connections, but still multiple connections (one for polling, one for downloading new messages, one for downloading the currently selected thread, &c.) -- Christopher Warrington <chrisw at rice.edu> "Crash programs fail because they are based on theory that, with nine women pregnant, you can get a baby in a month." -Werner von Braun -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 183 bytes Desc: not available Url : http://rubyforge.org/pipermail/sup-talk/attachments/20080125/df0b9917/attachment.bin
Excerpts from Sho Fukamachi''s message of Fri Jan 25 03:12:18 -0800 2008:> - detect locale of system, or offer a choice, for VIM spellcheck. It''s > currently hardcoded to en_us - detect from system somehow?That doesn''t sound right to me. Have you had a look in your config.yaml? More info on the Wiki page: http://sup.rubyforge.org/wiki/wiki.pl?VimIntegration I actually *like* that Sup doesn''t assume too much about my editor.> - at least a cursory effort to not store login credentials in > plaintext .. how to store them whilst retaining simplicity and > platform independence is an interesting question. Not sure how far sup > (or anyone really) wants to go down that particular rabbit holeI don''t like this idea. I think it was Gaim (now Pidgin) that first opened my eyes to the possibility that plaintext passwords might not be so bad. The Pidgin page seems to be down just now, so I can''t say for certain that this is the essay I originally read, but http://developer.pidgin.im/wiki/PlainTextPasswords?format=txt sounds like a promising result from Google.> - ability to send using something other than local sendmail? for > remote mbox, we have a ssh session open and everything .. and dynamic > IPs are often RBL''edMy config.yaml has an option for this, have a look there. Have fun! ~d
This is sort of a big-ish feature, but are there any plans for LDAP support? (I''m expecting "patches welcome" to go here. =) ~d
Excerpts from Daniel Wagner''s message of Fri Jan 25 21:03:33 -0800 2008:> > - at least a cursory effort to not store login credentials in > > plaintext .. how to store them whilst retaining simplicity and > > platform independence is an interesting question. Not sure how far sup > > (or anyone really) wants to go down that particular rabbit hole > > I don''t like this idea. I think it was Gaim (now Pidgin) that first > opened my eyes to the possibility that plaintext passwords might not be > so bad. The Pidgin page seems to be down just now, so I can''t say for > certain that this is the essay I originally read, but > http://developer.pidgin.im/wiki/PlainTextPasswords?format=txt > sounds like a promising result from Google.Wait, now that I stopped to think about it, I may have to take this back. I don''t actually know what credentials you mean, so the argument may not even apply. ~d
A thing which I would need (but that I guess it is not easy, at least from the complexity it has in mutt) is support fro S/MIME encryption, or at least encryption verification. -- Giorgio Lando <patroclo7 at gmail dot com>
On 25.1.2008, William Morgan wrote:> - Configurable colors. Everyone''s favorite.Preferably through a hook that gets some information about what is going to be coloured. For instance I''d like to colour my labels differently (not the email snippet, just the label itself) so the hook would have to be told that it should return a colour for a label, but also what label that is. Same thing applies for recipients/senders/snippets/threads I guess - you need some sort of context with the "type" you''re colouring.> - Notes. Like draft emails without a recipient, but treated specially > by the UI. Never sent; just for local use.This would be nice if they extend the message class so you get everything that comes with being an email for free like attachments etc. Marcus
I would like to add a further feature request: sup could accept an email address as a command line argument, going directly to prompt for a subject or a CC and then passing to the editor. This would be nice for interaction with browsers, when clicking on a certain address open a program designated to treat the mailto protocol. -- Giorgio Lando <patroclo7 at gmail dot com>
Reformatted excerpts from Giorgio Lando''s message of 2008-01-31:> I would like to add a further feature request: sup could accept an > email address as a command line argument, going directly to prompt for > a subject or a CC and then passing to the editor. This would be nice > for interaction with browsers, when clicking on a certain address open > a program designated to treat the mailto protocol.This is in. Use -c. -- William <wmorgan-sup at masanjin.net>
Excerpts from William Morgan''s message of Fri Feb 08 02:09:37 +0100 2008:> Reformatted excerpts from Giorgio Lando''s message of 2008-01-31: > > I would like to add a further feature request: sup could accept an > > email address as a command line argument, going directly to prompt for > > a subject or a CC and then passing to the editor. This would be nice > > for interaction with browsers, when clicking on a certain address open > > a program designated to treat the mailto protocol. > > This is in. Use -c. >Thank you a lot! -- Giorgio Lando <patroclo7 at gmail dot com>