[PATCH 2/3] ruby: allow build with RUNPATH

[notmuch-archives.git] / 2b / 729ea6f11fc82a2605443fc922147d44514d73

Return-Path: <cworth@cworth.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 DC27E42119B\r
        for <notmuch@notmuchmail.org>; Wed, 29 Jun 2011 22:40:21 -0700 (PDT)\r
X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
X-Spam-Flag: NO\r
X-Spam-Score: 0.01\r
X-Spam-Level: \r
X-Spam-Status: No, score=0.01 tagged_above=-999 required=5\r
        tests=[T_MIME_NO_TEXT=0.01] 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 cOs0eLWilzxr for <notmuch@notmuchmail.org>;\r
        Wed, 29 Jun 2011 22:40:21 -0700 (PDT)\r
Received: from arlo.cworth.org (arlo.cworth.org [50.43.72.2])\r
        by olra.theworths.org (Postfix) with ESMTP id 22CD4421192\r
        for <notmuch@notmuchmail.org>; Wed, 29 Jun 2011 22:40:21 -0700 (PDT)\r
Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
        by arlo.cworth.org (Postfix) with ESMTP id 1BDD429A87B;\r
        Wed, 29 Jun 2011 22:40:20 -0700 (PDT)\r
Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
        id 079182541A8; Wed, 29 Jun 2011 22:40:20 -0700 (PDT)\r
From: Carl Worth <cworth@cworth.org>\r
To: 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: <BANLkTi=StMS67+UwQbm8cUH3yNr_ySrN5A@mail.gmail.com>\r
References: <86iproe86u.fsf@greenrd.plus.com>\r
        <87fwms45xz.fsf@yoom.home.cworth.org>\r
        <BANLkTi=StMS67+UwQbm8cUH3yNr_ySrN5A@mail.gmail.com>\r
User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.3.1\r
        (i486-pc-linux-gnu)\r
Date: Wed, 29 Jun 2011 22:40:07 -0700\r
Message-ID: <874o37513c.fsf@yoom.home.cworth.org>\r
MIME-Version: 1.0\r
Content-Type: multipart/signed; boundary="=-=-=";\r
        micalg=pgp-sha1; protocol="application/pgp-signature"\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 05:40:22 -0000\r
\r
--=-=-=\r
Content-Transfer-Encoding: quoted-printable\r
\r
On Thu, 30 Jun 2011 13:04:23 +1000, Brian May <brian@microcomaustralia.com.=\r
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
>=20\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=20the 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
=2DCarl\r
\r
=2D-=20\r
carl.d.worth@intel.com\r
\r
--=-=-=\r
Content-Type: application/pgp-signature\r
\r
-----BEGIN PGP SIGNATURE-----\r
Version: GnuPG v1.4.11 (GNU/Linux)\r
\r
iEYEARECAAYFAk4MDDcACgkQ6JDdNq8qSWg6LwCggA6kOcDN+iGUof+zNxcmo6/x\r
u1sAoKV5qOXFfkf05xPla5Th1h9J8H2X\r
=kiRM\r
-----END PGP SIGNATURE-----\r
--=-=-=--\r