From: magnus@therning.org (Magnus Therning)
Subject: [sup-talk] Minor maildir change
Date: Wed, 19 Sep 2007 23:02:00 +0100 [thread overview]
Message-ID: <20070919220200.GA3436@die.therning.org> (raw)
In-Reply-To: <1190216731-sup-3428@south>
On Wed, Sep 19, 2007 at 08:59:58 -0700, William Morgan wrote:
>Excerpts from Magnus Therning's message of Sun Sep 16 11:19:36 -0700 2007:
>> It's also a little strange that after a message is read it doesn't
>> necessarily end up with the correct set of labels. Instead one has to
>> go to the index to get the proper set.
>
>What do you mean? For a new, unseen message, the initial set of label
>is uniquely determined by the source's default labels, unioned with
>whatever state (read/unread, flagged, etc) we carry over from the
>source. This is what Source#each does.
Yes, but once it's known Source#each still get labels off the state and
default flags from the source. The same goes for
PollManager#add_messages_from, where the messages will have different
labels compared to the entry. Here's code that hopefully highlight
what I mean:
#!/usr/bin/env ruby
require "uri"
require "sup"
Redwood::start
index = Redwood::Index.new
index.load
index.sources.each { |src|
if "maildir" == URI(src.uri).scheme
src.reset!
Redwood::PollManager.add_messages_from(src) { |m, offset, entry|
puts "#{offset} -"
puts "\t#{m.labels.join(' ')}"
puts "\t#{entry[:label]}"
nil
}
end
}
The output on a maildir source I use for some testing is:
[Wed Sep 19 22:55:02 +0100 2007] loading index...
[Wed Sep 19 22:55:02 +0100 2007] loaded index of 3 messages
11755314090094973 -
sup-test unread deleted inbox
sup-test
11765622040003515 -
sup-test unread inbox
sup-test deleted
11776152050016455 -
sup-test inbox unread
sup-test unread
What's gotten from the source is useful for an unseen message, but why
not mark known messages with the labels from the index?
>> Another strange thing was that when using
>> PollManager::add_messages_from all my emails ended up being unread
>> (according to the labels in the message). I tracked that down to it
>> using the value of a header ("Status") to see whether a mail was read
>> or not. Is that something that's used for mboxes? (I've attached a
>> patch that removes the code.)
>
>That is a hack to avoid having the mbox code read the header twice, one
>for the labels and again for the actual header contents. Since I'm
>planning on reworking mbox anyways (to avoid keeping the file pointer
>always open, and to clean up the interface between loader and
>ssh-loader), so I'll try and think of a better way to do this. There
>might not be.
>
>In the mean time, I'll remove the second half of that statement, which
>should make everyone happy.
Excellent.
[..]
>> - Make all sets of labels actual sets.
>
>Not sure what you mean by "actual sets", but I think this is pretty
>much the way Sup works now.
What I mean is the type set gotten from "require 'set'" :) Currently
labels are lists, not sets.
/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/20070919/8103ec01/attachment.bin
next prev parent reply other threads:[~2007-09-19 22:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-09 22:40 Magnus Therning
2007-09-14 3:33 ` William Morgan
2007-09-16 18:19 ` Magnus Therning
2007-09-19 15:59 ` William Morgan
2007-09-19 22:02 ` Magnus Therning [this message]
2007-09-24 2:29 ` William Morgan
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=20070919220200.GA3436@die.therning.org \
--to=magnus@therning.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