Marc Hartstein wrote:
Excerpts from yanghatespam's message of Sun May 04 20:47:50 -0400 2008:
When dealing with IMAP servers, does sup store its labels as IMAP
keywords (i.e., are they stored on the server)?
By default no modification is made to your mail source. There are
recent discussions about the reason for this and what sorts of
write-back might/might not be accepted as patches in the future.
Does sup know how to "handle" IMAP keywords in a read-only fashion? Do
these appear as sup labels? Is sup able to remove these labels from the
local view? As an aside, how would sup resolve conflicting label
changes (e.g., I remove the label locally in sup, then add it back in on
the IMAP server)?
Does the no-source-modification policy apply to: Starring messages?
Moving files among folders? Marking items as read? How does it deal
with consistency (resolve conflicts) in all these cases?
BTW, if the main debate is whether to allow modification to the mail
source, then perhaps it would be sufficient to expose this as an option?
(3) How does sup group messages into the same thread? Does it rely on
References: header fields, subject-matching,
body-substring-matching/overlap, or something else?
Default behavior seems (I haven't looked at that code) to be to use the
References and In-Reply-To headers. There's an option you can turn on
in config.yaml thread_by_subject which seems to do what it says.
Good, thanks.
(4) [EMAIL PROTECTED] is the account I use for mailing lists. I
use many lists, so I needed a way to cope with the large message volume.
Most of the time, I am only interested in the threads in which I have
been a participant (e.g., I'm interested in replies to my posts). I
have Gmail filters that use simple heuristics like "If my name is in the
email, leave it marked as unread; otherwise mark it read." This, of
course, leads to many false positives/negatives (Gmail's filterts are
only so expressive).
If sup's thread-grouping is decent, then it would be neat/more accurate
to extend sup somehow to instead use these groupings for the filtering.
I.e., if an incoming message is grouped with a thread in which I was a
participant, then leave it marked unread; otherwise, mark it read.
I believe what you are looking for is a custom before-add-message hook.
That gets passed a message object. You might have to operate on the
References: header of that message to get to the information you're
looking for (I think threads only exist at the presentation level), but
it should be possible to get at least most of the way to what you're
looking for.
The power of hooks is that you have an entire programming language
available for this kind of computation if you want it.
See `sup --list-hooks` and http://sup.rubyforge.org/wiki/wiki.pl?Hooks
for more information.
If the no-source-modification policy applies to marking items as
read/unread (and starring them - I do star these threads), though, then
it sounds like sup is not the right tool for this job. Furthermore, if
I can't leverage the threading (as it's only available on the
presentation level), then that's moot as well. It sounds like my
original plan on writing my own stand-alone IMAP client is the way to
go, here.
(6) Scrolling through the buffer that is immediately presented to me
when starting sup, I only see about 3 pages of threads. Is this
correct? How do I get to the rest?
'M' to load more messages, or '!!' to load everything. You can
interrupt the latter with ^G. These work for any thread-index, not just
the inbox, so if a search returns a lot of results, you get the same
behavior.
Does anybody else find sup to be very slow at displaying these threads?
I can literally see the threads trickling into view. And this is done
on each startup. Hitting !! takes forever. sup feels sluggish overall
(even moving the arrows around in inbox-mode has a slight delay, such
that I can only move by about 30 lines per second). Is something wrong
with my configuration? Or is this expected? (I was mainly interested
in sup as an ultra-responsive mail client.)
(7) Does sup support Unicode? The inbox display seems to be a bit
screwy for me (extraneous floating characters, things changing when
highlighted, etc.), though it could also be my terminal (I'm using
putty, but I just verified that I'm running it in UTF-8 mode).
Yes, it does. However, the stock Ruby ncurses gem doesn't handle wide
characters well. See http://sup.rubyforge.org/wiki/wiki.pl?UTF8 for
information on how to deal with this.
That's unfortunate...
------------------------------------------------------------------------
_______________________________________________
sup-talk mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/sup-talk
--
Yang Zhang
http://www.mit.edu/~y_z/
_______________________________________________
sup-talk mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/sup-talk
