Re: [DRAFT PATCH] emacs: show local date next to Date: in case value differs

diff --git a/6a/cf60a5fe526f95c7663facb1deed19ade4929a b/6a/cf60a5fe526f95c7663facb1deed19ade4929a
new file mode 100644 (file)
index 0000000..0b33141
--- /dev/null
+++ b/6a/cf60a5fe526f95c7663facb1deed19ade4929a
@@ -0,0 +1,127 @@
+Return-Path: <tomi.ollila@iki.fi>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by arlo.cworth.org (Postfix) with ESMTP id 87D4D6DE1978\r
+ for <notmuch@notmuchmail.org>; Tue,  7 Apr 2015 01:43:15 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at cworth.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 1.19\r
+X-Spam-Level: *\r
+X-Spam-Status: No, score=1.19 tagged_above=-999 required=5 tests=[AWL=0.538,\r
+ SPF_NEUTRAL=0.652] autolearn=disabled\r
+Received: from arlo.cworth.org ([127.0.0.1])\r
+ by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id O6oqxXHF-OXt for <notmuch@notmuchmail.org>;\r
+ Tue,  7 Apr 2015 01:43:13 -0700 (PDT)\r
+Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34])\r
+ by arlo.cworth.org (Postfix) with ESMTP id 1A3006DE1974\r
+ for <notmuch@notmuchmail.org>; Tue,  7 Apr 2015 01:43:12 -0700 (PDT)\r
+Received: from guru.guru-group.fi (localhost [IPv6:::1])\r
+ by guru.guru-group.fi (Postfix) with ESMTP id 4304C10019F;\r
+ Tue,  7 Apr 2015 11:42:48 +0300 (EEST)\r
+From: Tomi Ollila <tomi.ollila@iki.fi>\r
+To: David Bremner <david@tethera.net>, notmuch@notmuchmail.org\r
+Subject: Re: [DRAFT PATCH] emacs: show local date next to Date: in case value\r
+ differs\r
+In-Reply-To: <87vbhf2zqk.fsf@maritornes.cs.unb.ca>\r
+References: <1427132722-20346-1-git-send-email-tomi.ollila@iki.fi>\r
+ <87vbhf2zqk.fsf@maritornes.cs.unb.ca>\r
+User-Agent: Notmuch/0.19+107~gab55bdb (http://notmuchmail.org) Emacs/24.3.1\r
+ (x86_64-unknown-linux-gnu)\r
+X-Face: HhBM'cA~<r"^Xv\KRN0P{vn'Y"Kd;zg_y3S[4)KSN~s?O\"QPoL\r
+ $[Xv_BD:i/F$WiEWax}R(MPS`^UaptOGD`*/=@\1lKoVa9tnrg0TW?"r7aRtgk[F\r
+ !)g;OY^,BjTbr)Np:%c_o'jj,Z\r
+Date: Tue, 07 Apr 2015 11:42:47 +0300\r
+Message-ID: <m2y4m4z5vc.fsf@guru.guru-group.fi>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.18\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch/>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Tue, 07 Apr 2015 08:43:15 -0000\r
+\r
+On Thu, Apr 02 2015, David Bremner <david@tethera.net> wrote:\r
+\r
+> Tomi Ollila <tomi.ollila@iki.fi> writes:\r
+>\r
+>> When adding Date: header of a message to notmuch-show buffer, compare the\r
+>> date string with local representation of it and if these differ, output\r
+>> Date: {original-date-string}  ({local-date-representation})\r
+>\r
+> One thing I found confusing is that the local date representation is\r
+> mostly redundant in the default configuration, as the date shown in the\r
+> "headerline" is already in the local time zone if\r
+> "notmuch-show-relative-dates" is t. From the fact that you made this\r
+> patch I'm guessing that you don't use that setting.\r
+\r
+I am using that setting...\r
+\r
+Now I took a little better look why the 'relative' date is not enough for\r
+me is that it doesn't always show the local date (it shows like \r
+(28 mins. ago) or (March 30)). If these were (28 mins. ago (07:22)) and\r
+(March 30 16:20) then it would be better (w/ +0300 that might be marginally\r
+more useful in general but perhaps something that can be lived without).\r
+\r
+In this position where I am now I often get email from person residing\r
+like 50 footsteps from me (in current tz +0300, yet the email server \r
+writes emails with tz -0500) Now if email was sent 28 minutes ago I cannot\r
+immediately crasp what is that email in local time. Other similar effect\r
+is when my old classmate puts a message to Facebook -- IIRC the timezones\r
+of the notification emails there are -0700.\r
+What makes this situation worse is that the notmuch-show buffer is showing\r
+email arrived 28 mins. ago but the buffer has been sitting there for 2\r
+hours while I've been doing something else; the relative date information\r
+is not updated.\r
+With (March 30) figuring out when that email was sent in local time is\r
+harder as the granularity in relative date is 'one day'.\r
+\r
+In IRC Jani mentioned it is feature to see the sender's TZ. I also consider\r
+it as a feature. But also knowing the local time (quickly) is a feature to\r
+me: An example: Someone(TM) sent email to a bunch of recipients yesterday\r
+18:28 (that is 6.28 pm) from TZ -0500. Relative date showed that it was\r
+sent (Today 02:28).\r
+Just an hour ago we had a meeting where knowing that "half past 2" was\r
+important information...\r
+\r
+Based on this I start experimenting how I could "improve" the headerline\r
+for my case -- so that in notmuch-show buffer the relative date has more\r
+information. In notmuch-search buffer there is just not enough space.\r
+Then I have to learn to look the headerline for this information...\r
+\r
+Also, thanks to Mark for his comments of the implementation. Those will \r
+be useful at least in some other stuff I've planned to do...\r
+\r
+> One option which would have the advantage not being as wide on the\r
+> screen (Maybe my use case is strange, but I often use notmuch is 66\r
+> column half screen-width terminals) would be to (optionally?) display\r
+> the non-relative date in the headerline in the local time zone.\r
+\r
+Before thinking how the "headerline" could be "improved" (for notmuch-show\r
+buffer) I thought whether the local date could just show (hh:mm [+-]nnnn).\r
+Also the comparison whether to show this additional info could be just\r
+based on difference in timezone strings...\r
+\r
+>> This is useful e.g. when mail system provides Date: strings with\r
+>> different timezone information than the sender is located at.\r
+>\r
+> I'm not sure how local time information helps with the sender?  Unless\r
+> you happen to be in the same time zone.\r
+\r
+Yes, it would be exceptionally irritating someone living in different\r
+timezone and the emails sent would show yet another timezone. Then seeing\r
+local time would be more informational than the original Date:\r
+\r
+>\r
+> d\r
+\r
+Tomi\r