Pasky’s Log

I promised to post some minutes from the BOF in $SUBJ here for people who don’t remember all the tool names:

• [l]imit in mutt is very powerful functionality; my other blogpost describes notmuch integration to that
• new mutt-kz has good virtual folder support as notmuch integration; perhaps future of state-of-art text mail clients
• sup is interesting gmail-like text client, but way too slow!
• alot is worth a look as nice notmuch frontend; no screenshots on net though
• notmuch can filter by folder label, so single db is fine for all your folders
• dovecot sync (dsync)
• lookg at images when reading mail remotely – screenenv (set $DISPLAY based on last active screen client), new tool needed for seamless transfer of files back to local machine is needed!
• maildir sync using VCS (bazaar) instead of imap (read mails using “thick client”) (ccxcz)
• prioritization of downloaded mails by using uucp for transfer (lmw)
• sending mails by feeding them to procmail which decides how to send them (ccxcz)
• automatic addressbook building: lbdb (little brother db)
• Trojita is Qt MUA with very fast IMAP.
• another mutt tip: set edit_headers will make mutt not ask about recipient, subject etc. before starting editor, but let you put the headers in instead

screenenv is a gadget that should make your applications within GNU Screen use the right display and ssh agent information based on which attached screen client you call them from.

The motivation is simple – I have screen session that I create on my desktop, but when on the go (or in the next room ;) with my notebook, I want to ssh -X in and be able to still open image attachments in my mutt properly.

Several approaches are possible, I chose a fairly invasive one – I hijack getenv() calls by applications and substitute few chosen environment variables (mainly $DISPLAY and $SSH_* – e.g. $SSH_AUTH_SOCK) based on their settings in the most recently active screen client attached to the current session.

Thus, you can just keep going back’n’forth between two sessions, keep working seamlessly, no explicit action is required on your part and all your applications will Do The Right Thing.

Of course, the v0.1 release has many rough edges – if a long-term application saves the getenv’d variable, then keeps checking other volatile ones, it will probably crash (that’s fixable, though; and I think this should be very rare situation in practice, most or all of the volatile variables are for one-shot use within a single process). Also, we should cache the client lookup (which involves walking all processes) at least for few seconds…