sup talk - Nov 2007 - [PATCH] label-list-mode with no unread messages

This patch sets the status to "No labels with unread messages" for
label-list-mode when unread_only is toggled on and there are, well, no labels
with unread messages. I thought the blank buffer looked a little odd.

It would be nicer if label-list-mode wasn''t modal. I keep hitting
''b'' and ''x'' and ''q'' with
no effect, and then hitting C-g. It would be more work to keep the counts up to
date, but that could use some work anyway. If I read all the new mail in one
label and then activate label-list-mode, the unread count will be wrong...
unless I kill the label buffer or sync it first.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: label-list-no-unread.diff
Type: application/octet-stream
Size: 912 bytes
Desc: not available
Url :
http://rubyforge.org/pipermail/sup-talk/attachments/20071121/760d8bb6/attachment.obj

Excerpts from Grant Hollingworth''s message of Wed Nov 21 11:53:34 -0800
2007:
> This patch sets the status to "No labels with unread messages"
for
> label-list-mode when unread_only is toggled on and there are, well, no
> labels with unread messages. I thought the blank buffer looked a
> little odd.
> 
> It would be nicer if label-list-mode wasn''t modal. I keep hitting
''b''
> and ''x'' and ''q'' with no effect, and
then hitting C-g.
I''ve committed the following changes to SVN:

1. LabelListMode is no longer modal (it was bugging me too)
2. Hitting tab now cycles the cursor between labels with unread
   messages, just like in ThreadIndexMode.
3. Hitting ''u'' does the toggle that tab used to. (Sorry to
everyone who
   has to retrain their fingers---maybe this is motivation to submit a
   configurable keybinding patch!)
> It would be more work to keep the counts up to date, but that could
> use some work anyway. If I read all the new mail in one label and then
> activate label-list-mode, the unread count will be wrong... unless I
> kill the label buffer or sync it first.
Shouldn''t be too hard to do this if you use catch the appropriate
events from UpdateManager.

-- 
William <wmorgan-sup at masanjin.net>

Excerpts from William Morgan''s message of Sat Nov 24 15:47:34 -0500
2007:
> Shouldn''t be too hard to do this if you use catch the appropriate
> events from UpdateManager.
I hadn''t looked at the UpdateManager before... that''s pretty
cool.

The problem is that the text in label-list-mode is created by
LabelListMode#regen_text. It would be awkward to fiddle with @text outside of
there. Since regen_text gets its numbers from Index.num_results_for, the other
buffer has to sync to the index before the label list will know about it. So it
seems to be just as effective to add ''def focus; reload; end''
to LabelListMode.

Handling the unread counts in LabelListMode seems dirty, anyway. You''d
have to watch more than just the :read event, right? If a thread is archived
from the inbox, for instance, the unread count for ''Inbox''
should go down.

So I haven''t done any of that... but I found a related problem: the
inbox doesn''t update if you unarchive a thread elsewhere. I made a
na?ve patch that works in some cases.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: sup-inbox-unarchived.diff
Type: application/octet-stream
Size: 988 bytes
Desc: not available
Url :
http://rubyforge.org/pipermail/sup-talk/attachments/20071126/5ad3bba1/attachment.obj

Excerpts from Grant Hollingworth''s message of Mon Nov 26 10:57:49 -0800
2007:
> Handling the unread counts in LabelListMode seems dirty, anyway.
You''d
> have to watch more than just the :read event, right? If a thread is
> archived from the inbox, for instance, the unread count for
''Inbox''
> should go down.
Yes, probably the ideal solution is to have a CountManager (sigh) which
maintains all these numbers, and listens to all events. Then
LabelListMode would be a consumer of this.
> So I haven''t done any of that... but I found a related problem:
the
> inbox doesn''t update if you unarchive a thread elsewhere. I made a
> na?ve patch that works in some cases.
I''ve just committed a fairly large changeset that improves the update
relaying thing. It should fix most problems, including this one. I think
the one thing it doesn''t quite get is the case where you remove a label
from a thread that''s displayed in a different label-search-results-mode
buffer. Or something like that.

-- 
William <wmorgan-sup at masanjin.net>