[PATCH 4/4] Update NEWS for user.other_name

[notmuch-archives.git] / c3 / ff27efd075b05561a7d01d3407af79a0a4cb70

Return-Path: <pieter@praet.org>\r
X-Original-To: notmuch@notmuchmail.org\r
Delivered-To: notmuch@notmuchmail.org\r
Received: from localhost (localhost [127.0.0.1])\r
        by olra.theworths.org (Postfix) with ESMTP id 53BE942119B\r
        for <notmuch@notmuchmail.org>; Thu, 30 Jun 2011 00:45:59 -0700 (PDT)\r
X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
X-Spam-Flag: NO\r
X-Spam-Score: -0.7\r
X-Spam-Level: \r
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
        tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
Received: from olra.theworths.org ([127.0.0.1])\r
        by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
        with ESMTP id bR3G4IHA+ibj for <notmuch@notmuchmail.org>;\r
        Thu, 30 Jun 2011 00:45:58 -0700 (PDT)\r
Received: from mail-wy0-f181.google.com (mail-wy0-f181.google.com\r
        [74.125.82.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
        (No client certificate requested)\r
        by olra.theworths.org (Postfix) with ESMTPS id CF320421192\r
        for <notmuch@notmuchmail.org>; Thu, 30 Jun 2011 00:45:57 -0700 (PDT)\r
Received: by wyh22 with SMTP id 22so1508576wyh.26\r
        for <notmuch@notmuchmail.org>; Thu, 30 Jun 2011 00:45:56 -0700 (PDT)\r
Received: by 10.216.139.37 with SMTP id b37mr2472154wej.41.1309419955362;\r
        Thu, 30 Jun 2011 00:45:55 -0700 (PDT)\r
Received: from localhost ([109.131.21.173])\r
        by mx.google.com with ESMTPS id ex2sm1424138wbb.48.2011.06.30.00.45.53\r
        (version=TLSv1/SSLv3 cipher=OTHER);\r
        Thu, 30 Jun 2011 00:45:54 -0700 (PDT)\r
From: Pieter Praet <pieter@praet.org>\r
To: Carl Worth <cworth@cworth.org>,\r
 Brian May <brian@microcomaustralia.com.au>,\r
        Notmuch Mail <notmuch@notmuchmail.org>\r
Subject: Re: Preventing the user shooting themself in the foot\r
In-Reply-To: <874o37513c.fsf@yoom.home.cworth.org>\r
References: <86iproe86u.fsf@greenrd.plus.com>\r
        <87fwms45xz.fsf@yoom.home.cworth.org>\r
        <BANLkTi=StMS67+UwQbm8cUH3yNr_ySrN5A@mail.gmail.com>\r
        <874o37513c.fsf@yoom.home.cworth.org>\r
User-Agent: Notmuch/0.5-303-g00a1bf6 (http://notmuchmail.org) Emacs/23.1.50.1\r
        (x86_64-pc-linux-gnu)\r
Date: Thu, 30 Jun 2011 09:45:52 +0200\r
Message-ID: <877h837oen.fsf@praet.org>\r
MIME-Version: 1.0\r
Content-Type: text/plain; charset=us-ascii\r
X-BeenThere: notmuch@notmuchmail.org\r
X-Mailman-Version: 2.1.13\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: Thu, 30 Jun 2011 07:45:59 -0000\r
\r
On Wed, 29 Jun 2011 22:40:07 -0700, Carl Worth <cworth@cworth.org> wrote:\r
Non-text part: multipart/mixed\r
Non-text part: multipart/signed\r
> On Thu, 30 Jun 2011 13:04:23 +1000, Brian May <brian@microcomaustralia.com.au> wrote:\r
> > On 30 June 2011 08:40, Carl Worth <cworth@cworth.org> wrote:\r
> > > The 'a' keybinding, (in turn), was designed for cases when you *know*\r
> > > you don't want to read the rest of the thread.\r
> > \r
> > ... in which case it should also mark everything as read. IMHO.\r
> \r
> I know the current behavior only catches my opinion (and only an opinion\r
> I had at one particular point in time). So I won't say this is Right,\r
> but I will at least explain what I was thinking:\r
> \r
> The "unread" tag is distinct from the "inbox" tag. Why two tags? Don't\r
> they normally change at the same time? If a key like 'a' got rid of the\r
> "unread" tag as well as the "inbox" then there would be almost no need\r
> for having two tags.\r
> \r
> The idea I had is that "inbox" is fully under explicit control by the\r
> user. The user must make an intentional decision to "archive" a message\r
> in order for that tag to be removed.\r
> \r
> Distinct from that is "unread" which is handled automatically by the\r
> mail client (as well as it can tell what you've actually read or\r
> not). So this tag is removed only implicitly, (we don't have specific\r
> commands to manipulate the "unread" tag). When the client displays a\r
> message as the "current" message it immediately removes the "unread"\r
> tag.\r
> \r
>  Whenever it displays a message to the\r
> user, (as the "current" message), it removes the unread tag from that\r
> message.\r
> \r
> This means that messages can lose the "unread" tag while still remaining\r
> tagged "inbox", (you read a message, but don't archive it), and that\r
> messages can lose the "archive" tag while still remaining tagged\r
> "unread", (you archive a thread before reading all messages in the\r
> thread).\r
> \r
> The distinction ends up being useful to me. If at some point someone\r
> points me to a specific message, and when I search for it I see the\r
> "unread" tag, then this highlights to me that I never even looked at the\r
> message.\r
> \r
> > Are there any keyboard bindings to go forwards to the next message or\r
> > backwards to the last message without marking anything as archived?\r
> \r
> As mentioned by someone else, you can navigate the messages in a thread\r
> with 'n' and 'p'.\r
> \r
> One of the obviously missing keybindings is a way to easily navigate\r
> From the current thread to the next thread without archiving the current\r
> thread. We should probably add that keybinding at some point, but I want\r
> to at least point out why I didn't create it originally:\r
> \r
> The lack of a "move to next thread" binding helps encourage me to form\r
> good habits. The goal I have when processing my inbox is to get\r
> everything *out* of my inbox. I can do that by deciding one of several\r
> common things:\r
> \r
>     * I have nothing to do\r
> \r
>       In this case I should just archive the message immediately\r
> \r
>     * I can deal with this message "on the spot" (such as a quick reply)\r
> \r
>       In this case, I should deal with the message, then archive it\r
> \r
>     * I can't deal with this now, but need to later\r
> \r
>       This is the key scenario. The wrong thing to do is to leave the\r
>       message in my inbox, (that just makes things pile up and makes\r
>       my future inbox processing slow, demotivating, and\r
>       unreliable). The right thing to do is to tag this message in a\r
>       way that I'm sure I'll find it again when I will be equipped to\r
>       deal with it. And then I can archive the message.\r
> \r
> So the right answer always involves archiving the message nearly\r
> immediately, (at most after a quick reply or so), and the keybindings\r
> encourage archiving over leaving the message in the inbox.\r
> \r
> Of course, one does have an existing keybinding for "move to next\r
> message in thread without archiving"; it just consists of three key\r
> presses:\r
> \r
>       'q', 'n', Enter\r
> \r
> At that's long enough to discourage its frequent use.\r
> \r
> So that's a bit of my philosophy and methodology. But like I said, we\r
> should probably add the obviously missing keybindings so people with\r
> other philosophies and methodologies can use the program comfortably.\r
> \r
> > Also, just something I have noticed it isn't really obvious that a\r
> > thread has replies without scrolling down, and that takes time. Would\r
> > be really good if there could be some big/highlighted visual indicator\r
> > that there are still unread messages further down.\r
> \r
> That would be good, yes.\r
> \r
> -Carl\r
> \r
> -- \r
> carl.d.worth@intel.com\r
Non-text part: application/pgp-signature\r
> _______________________________________________\r
> notmuch mailing list\r
> notmuch@notmuchmail.org\r
> http://notmuchmail.org/mailman/listinfo/notmuch\r
\r
100% in agreement.\r
\r
\r
Besides 1: Keybinds are way too personal to be standardized upon.\r
\r
This might be of interest to some:\r
  http://permalink.gmane.org/gmane.comp.misc.suckless/6495\r
\r
Besides 2: Emacs allows to tailor *anything and everything* to\r
your needs, on the spot, in realtime (reflection and all that).\r
\r
\r
Peace\r
\r
-- \r
Pieter\r