Steve Kemp's Blog Writings relating to Debian & Free Software

Some good, some bad

Tue, 14 May 2013 12:32:38 GMT

Today my main machine was down for about 8 hours. Oops.

That meant when I got home, after a long and dull train journey, I received a bunch of mails from various hosts each saying:

  • Failed to fetch slaughter policies from rsync://www.steve.org.uk/slaughter

Slaughter is my sysadmin utility which pulls policies/recipies from a central location and applies them to the local host.

Slaughter has a bunch of different transports, which are the means by which policies and files are transferred from the remote "central host" to the local machine. Since git is supported I've now switched my policies to be fetched from the master github repository.

This means:

  • All my servers need git installed. Which was already the case.
  • I can run one less service on my main box.
  • We now have a contest: Is my box more reliable than github?

In other news I've fettled with lumail a bit this week, but I'm basically doing nothing until I've pondered my way out of the hole I've dug myself into.

Like mutt lumail has the notion of "limiting" the display of things:

  • Show all maildirs.
  • Show all maildirs with new mail in them.
  • Show all maildirs that match a pattern.
  • Show all messages in the currently selected folder(s)
    • More than one folder may be selected :)
  • Shall all unread messages in the currently selected folder(s).

Unfortunately the latter has caused an annoying, and anticipated, failure case. If you open a folder and cause it to only show unread messages all looks good. Until you read a message. At which point it is no longer allowed to be displayed, so it disappears. Since you were reading a message the next one is opened instead. WHich then becomes marked as read, and no longer should be displayed, because we've said "show me new/unread-only messages please".

The net result is if you show only unread messages and make the mistake of reading one .. you quickly cycle through reading all of them, and are left with an empty display. As each message in turn is opened, read, and marked as non-new.

There are solutions, one of which I documented on the issue. But this has a bad side-effect that message navigation is suddenly complicated in ways that are annoying.

For the moment I'm mulling the problem over and I will only make trivial cleanup changes until I've got my head back in the game and a good solution that won't cause me more pain.

| 6 comments.

 

Comments On This Entry

[gravitar] RogerBW

Submitted at 21:41:14 on 14 May 2013

I think the mutt way is a reasonably good one: apply the limit when it's first commanded, but not on refreshes thereafter. Quite often I've limited to new messages, skipped past something, then decided to go back to it - and it's still displayed, even though it's no longer new.

Contrast newsbeuter, which makes a message vanish from the unread list as soon as you open it - so going back becomes a tedious dance of returning to the index, showing all messages, finding the one before the first unread, looking at it again, looking at the next one, then remembering to turn unread-only back on.

[gravitar] Steve Kemp

Submitted at 22:00:57 on 14 May 2013

My initial thought is that makes a great simplification. I just need a persistent set of "current messages". The display code would always display those.

I'd update that set if:

  • The limit in force were changed.
  • The number folders currently selected changed.

I think I could implement that very very easily; so I'll have a stab at it tomorrow and see if it works out as well as it feels like it should.

Thanks very much for the idea.

[gravitar] John Hedges

Submitted at 07:54:57 on 15 May 2013

This is a problem in many email clients (well at least mutt and thunderbird) and a common cause of missed mail. If a message pane is open (however minimal), scrolling though a mailbox marks messages as read.

I don't think it's a decision that should be left to the computer. I decide when I've read a mail and would prefer to mark it as read once I've done so. This would make the read flag far more reliable in human terms - ie message has been read rather than displayed, and if I tag a mail as read in a new message view I'll not be surprised when it disappears.

[gravitar] Anonymous

Submitted at 15:37:47 on 16 May 2013

Thanks for making pwsafe available. I just compiled your source tree on my Loongson-2F and now I'll have it at least until the next version of Debian is out. I can't find out why they ditched it though. Do you have a link to the list of bugs which made them pull it out of stable? Again, thanks for saving my day.

[gravitar] Steve Kemp

Submitted at 15:43:08 on 16 May 2013

The bug list is here:

I'm not sure which was the main reason though..

[gravitar] Steve Kemp

Submitted at 15:35:59 on 17 May 2013

Interesting, John, that you want to decouple the "mark read" from "reading messages". I've just switched the code from clearing the new-flag on display to doing that in the lua.

If you were to edit the default config file you could do this your own way. Something like:

function on_read_message( path )
   -- nop.  Just don't call mark-read
end

-- Mark current message as new/read
keymap['message']['N'] = 'mark_new();'
keymap['message']['R'] = 'mark_read();'

Or even something to toggle the state:

function toggle_message()
   if ( is_new() ) then
      mark_read();
   else
      mark_new()
   end
end
keymap['index']['T'] = 'toggle_message();'

Seeing things like this written down makes me pleased that lua is a good choice, and a real language is a good thing for scripting.

 

Comments are closed on posts which are more than ten days old.

Spiral Logo

Search

Recent Posts

Recent Tags

Links

RSS Feed

  • Subscribe to feed