* [sup-talk] Beginner questions
@ 2008-05-05 0:47 Yang Zhang
2008-05-05 1:02 ` Daniel Wagner
2008-05-05 18:09 ` Marc Hartstein
0 siblings, 2 replies; 12+ messages in thread
From: Yang Zhang @ 2008-05-05 0:47 UTC (permalink / raw)
Hi, I'm interested in getting started with sup. For now, I just ran
sup-config to use Gmail IMAP. Things seem to have gone smoothly, though
I have a few questions:
(1) sup did end up taking many, many hours to download my entire inbox
of messages. I'd rather it lazily download these messages. Is there
some way to achieve this?
(2) At some point, I was prompted:
Enter any labels to be automatically added to all messages from this
source, separated by spaces (or 'none') (enter for "inbox"): none
When dealing with IMAP servers, does sup store its labels as IMAP
keywords (i.e., are they stored on the server)? (A bunch of IMAP
servers support IMAP keywords. Gmail's labels manifest themselves as
folders, however, and not IMAP keywords. [1])
(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?
(4) yanghatespam at gmail.com 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.
Any thoughts on whether such an extension is possible, and if so, where
to start with it? Is sup at all extensible at the current time? Is a
feature such as this already in the works?
(5) I remember reading one archived list post on how others were using
the "[Gmail]/All Mail" folder as their. Should I have used that instead
of "Inbox"?
If I were using a more conventional IMAP server, in which messages don't
appear in multiple folders, does sup expect me to add all the folders,
so that it can display complete threads (e.g. merging Sent and Inbox)?
So is the difference with Gmail, then, that "[Gmail]/All Mail" is the
one and only folder to use?
In general, does sup play nicely with Gmail? Any experiences to be
shared? The only other quirk I'm aware of is that to truly delete a
message requires moving it to the Gmail/Trash folder (otherwise only a
label is removed).
Thanks in advance for any answers!
(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?
(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).
[1]
http://weblog.timaltman.com/archive/2008/02/24/gmails-buggy-imap-implementation
--
Yang Zhang
http://www.mit.edu/~y_z/
^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] Beginner questions
2008-05-05 0:47 [sup-talk] Beginner questions Yang Zhang
@ 2008-05-05 1:02 ` Daniel Wagner
2008-05-05 2:08 ` Yang Zhang
2008-05-05 18:09 ` Marc Hartstein
1 sibling, 1 reply; 12+ messages in thread
From: Daniel Wagner @ 2008-05-05 1:02 UTC (permalink / raw)
Excerpts from yanghatespam's message of Sun May 04 17:47:50 -0700 2008:
> 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.
Well, sup already has a pretty nice (and similar) feature for killing
entire threads. The '&' key will archive a thread permanently; that is,
if new mails arrive in that thread, they will automatically be archived.
So, you can hit '&' once for each thread you don't want to read; the
rest will reappear in you inbox as new mails arrive in them.
It's a bit inverted from what you want, but maybe it will do? In any
case, if you want to extend sup, you should look at how that key works.
> (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?
The 'M' key will load more threads.
Good luck!
~d
P.S. I'm running a slightly old version of sup, so the actual keys might
not be '&' and 'M' any more. '?' should list the available commands at
any time.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] Beginner questions
2008-05-05 1:02 ` Daniel Wagner
@ 2008-05-05 2:08 ` Yang Zhang
0 siblings, 0 replies; 12+ messages in thread
From: Yang Zhang @ 2008-05-05 2:08 UTC (permalink / raw)
Daniel Wagner wrote:
> Excerpts from yanghatespam's message of Sun May 04 17:47:50 -0700 2008:
>> 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.
>
> Well, sup already has a pretty nice (and similar) feature for killing
> entire threads. The '&' key will archive a thread permanently; that is,
> if new mails arrive in that thread, they will automatically be archived.
> So, you can hit '&' once for each thread you don't want to read; the
> rest will reappear in you inbox as new mails arrive in them.
>
> It's a bit inverted from what you want, but maybe it will do? In any
> case, if you want to extend sup, you should look at how that key works.
I do need to deal with a large volume of mail, so it's not really what
I'm looking for, because (1) I'd be doing this all day long, and (2)
it's error-prone - I can easily kill a relevant thread. BTW, Gmail has
had this feature in the form of the 'm' key (for "mute").
>
>> (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?
>
> The 'M' key will load more threads.
Thanks.
>
> Good luck!
> ~d
>
> P.S. I'm running a slightly old version of sup, so the actual keys might
> not be '&' and 'M' any more. '?' should list the available commands at
> any time.
> _______________________________________________
> sup-talk mailing list
> sup-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/sup-talk
--
Yang Zhang
http://www.mit.edu/~y_z/
^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] Beginner questions
2008-05-05 0:47 [sup-talk] Beginner questions Yang Zhang
2008-05-05 1:02 ` Daniel Wagner
@ 2008-05-05 18:09 ` Marc Hartstein
2008-05-05 18:29 ` Yang Zhang
2008-05-06 2:15 ` Christopher Warrington
1 sibling, 2 replies; 12+ messages in thread
From: Marc Hartstein @ 2008-05-05 18:09 UTC (permalink / raw)
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.
> (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.
> (4) yanghatespam at gmail.com 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.
> (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.
> (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.
-------------- 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/20080505/e324e364/attachment.bin>
^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] Beginner questions
2008-05-05 18:09 ` Marc Hartstein
@ 2008-05-05 18:29 ` Yang Zhang
2008-05-19 23:38 ` William Morgan
2008-05-06 2:15 ` Christopher Warrington
1 sibling, 1 reply; 12+ messages in thread
From: Yang Zhang @ 2008-05-05 18:29 UTC (permalink / raw)
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) yanghatespam at gmail.com 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
> sup-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/sup-talk
--
Yang Zhang
http://www.mit.edu/~y_z/
^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] Beginner questions
2008-05-05 18:29 ` Yang Zhang
@ 2008-05-19 23:38 ` William Morgan
0 siblings, 0 replies; 12+ messages in thread
From: William Morgan @ 2008-05-19 23:38 UTC (permalink / raw)
Reformatted excerpts from yanghatespam's message of 2008-05-05:
> Does anybody else find sup to be very slow at displaying these
> threads? I can literally see the threads trickling into view.
It's slower than it could be. I would like to cache the threading
(possibly directly in the index), as it's recomputed each time and even
though Ferret is fast, it could be faster.
> 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).
Another thing I would love to fix. Profiling is the first step.
--
William <wmorgan-sup at masanjin.net>
^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] Beginner questions
2008-05-05 18:09 ` Marc Hartstein
2008-05-05 18:29 ` Yang Zhang
@ 2008-05-06 2:15 ` Christopher Warrington
1 sibling, 0 replies; 12+ messages in thread
From: Christopher Warrington @ 2008-05-06 2:15 UTC (permalink / raw)
Marc Hartstein @ 2008-5-05 11:09:41 AM
"[sup-talk] Beginner questions" <mid:1210009778-sup-6833 at cabinet>
> 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.
Well, I guess I should get more code in good order and submit my
patch for the lack of threading in the before-add-message hook...
--
Christopher Warrington <chrisw at rice.edu>
How do I set my laser printer on stun?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20080505/7a11b64c/attachment.bin>
^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] Beginner questions
@ 2008-05-05 2:48 kendall at clarkparsia.com
2008-05-19 23:44 ` William Morgan
0 siblings, 1 reply; 12+ messages in thread
From: kendall at clarkparsia.com @ 2008-05-05 2:48 UTC (permalink / raw)
On Sunday, May 4, 2008 9:02pm, Daniel Wagner <daniel at wagner-home.com> said:
> Excerpts from yanghatespam's message of Sun May 04 17:47:50 -0700 2008:
>> 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.
>
> Well, sup already has a pretty nice (and similar) feature for killing
> entire threads. The '&' key will archive a thread permanently; that is,
> if new mails arrive in that thread, they will automatically be archived.
> So, you can hit '&' once for each thread you don't want to read; the
> rest will reappear in you inbox as new mails arrive in them.
Which reminds me that, as of 0.5 release, the bug I reported about &-killed threads reappearing is still present.
But, other than that, 0.5 is a treat.
Cheers,
Kendall
^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] Beginner questions
@ 2008-08-03 23:17 Thorsten Kramer
2008-08-04 1:41 ` William Morgan
0 siblings, 1 reply; 12+ messages in thread
From: Thorsten Kramer @ 2008-08-03 23:17 UTC (permalink / raw)
Hi,
recently I switched from mutt to sup. Everything works fine besides some
minor issues:
1) Unfortunately, the gpg integration doesn't work. If I want to sign my mails,
sup complains about: 'Problem sending mail: gpg: gpg-agent is not available in
this session' Any tipps to avoid this? With mutt, gpg works fine.
2) I've configured several accounts for sending mail. How can I switch
between them in the mail-compose view? Is changing the from address the
only way?
3) In mutt you can define macros. E.g. you press F2 and the
selected mail is moved from its maildir to a spam mbox. Is this
possible with sup?
Thanks!
^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] Beginner questions
2008-08-03 23:17 Thorsten Kramer
@ 2008-08-04 1:41 ` William Morgan
2008-08-05 21:52 ` Thorsten Kramer
0 siblings, 1 reply; 12+ messages in thread
From: William Morgan @ 2008-08-04 1:41 UTC (permalink / raw)
Hi Thorsten,
Reformatted excerpts from Thorsten Kramer's message of 2008-08-03:
> recently I switched from mutt to sup.
Welcome!
> 1) Unfortunately, the gpg integration doesn't work. If I want to sign
> my mails, sup complains about: 'Problem sending mail: gpg: gpg-agent
> is not available in this session' Any tipps to avoid this? With mutt,
> gpg works fine.
At least right now, the only way to run Sup with GPG is to use
gpg-agent. Sup doesn't ask for your password, store it, expire it, etc.
So you'll need to start gpg-agent in the background, and then gpg should
automatically trigger it to ask you for your password.
The one problem with this so far is that the curses version of gpg-agent
doesn't interact well with Sup. If you're using the X version, you'll be
fine.
> 2) I've configured several accounts for sending mail. How can I switch
> between them in the mail-compose view? Is changing the from address
> the only way?
Yes, that's the only way. (So far!)
> 3) In mutt you can define macros. E.g. you press F2 and the selected
> mail is moved from its maildir to a spam mbox. Is this possible with
> sup?
No. I would like to have this at some point, and I don't think it would
be terribly hard, but right now even the keybindings are not
configurable.
--
William <wmorgan-sup at masanjin.net>
^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] Beginner questions
2008-08-04 1:41 ` William Morgan
@ 2008-08-05 21:52 ` Thorsten Kramer
0 siblings, 0 replies; 12+ messages in thread
From: Thorsten Kramer @ 2008-08-05 21:52 UTC (permalink / raw)
Hi William,
Excerpts from William Morgan's message of Mon Aug 04 03:41:54 +0200 2008:
> The one problem with this so far is that the curses version of gpg-agent
> doesn't interact well with Sup. If you're using the X version, you'll be
> fine.
Well, it's strange. Sometimes the gpg-agent reacts, sometimes the
running daemon isn't recognized. Anyway, it's definitely a problem
caused by my gpg installation, not by sup.
> No. I would like to have this at some point, and I don't think it would
> be terribly hard, but right now even the keybindings are not
> configurable.
OK. Then the mark-as-spam hook will probably do for me.
Best regards,
Thorsten
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2008-08-05 21:52 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-05-05 0:47 [sup-talk] Beginner questions Yang Zhang
2008-05-05 1:02 ` Daniel Wagner
2008-05-05 2:08 ` Yang Zhang
2008-05-05 18:09 ` Marc Hartstein
2008-05-05 18:29 ` Yang Zhang
2008-05-19 23:38 ` William Morgan
2008-05-06 2:15 ` Christopher Warrington
2008-05-05 2:48 kendall at clarkparsia.com
2008-05-19 23:44 ` William Morgan
2008-08-03 23:17 Thorsten Kramer
2008-08-04 1:41 ` William Morgan
2008-08-05 21:52 ` Thorsten Kramer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox