Re: [PATCH] emacs: wash: make word-wrap bound message width
[notmuch-archives.git] / 2e / 1cff8756ecbae830a18ebc27fb48ed0cfd4fc6
1 Return-Path: <david@tethera.net>\r
2 X-Original-To: notmuch@notmuchmail.org\r
3 Delivered-To: notmuch@notmuchmail.org\r
4 Received: from localhost (localhost [127.0.0.1])\r
5  by arlo.cworth.org (Postfix) with ESMTP id 8E4356DE0032\r
6  for <notmuch@notmuchmail.org>; Sat, 19 Mar 2016 13:19:23 -0700 (PDT)\r
7 X-Virus-Scanned: Debian amavisd-new at cworth.org\r
8 X-Spam-Flag: NO\r
9 X-Spam-Score: -0.03\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=-0.03 tagged_above=-999 required=5 tests=[AWL=-0.019,\r
12   SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=disabled\r
13 Received: from arlo.cworth.org ([127.0.0.1])\r
14  by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
15  with ESMTP id TMRZDSUT7t-n for <notmuch@notmuchmail.org>;\r
16  Sat, 19 Mar 2016 13:19:14 -0700 (PDT)\r
17 Received: from fethera.tethera.net (fethera.tethera.net [198.245.60.197])\r
18  by arlo.cworth.org (Postfix) with ESMTPS id 7FB956DE0008\r
19  for <notmuch@notmuchmail.org>; Sat, 19 Mar 2016 13:19:14 -0700 (PDT)\r
20 Received: from remotemail by fethera.tethera.net with local (Exim 4.84)\r
21  (envelope-from <david@tethera.net>)\r
22  id 1ahNLf-0006C5-M6; Sat, 19 Mar 2016 16:19:47 -0400\r
23 Received: (nullmailer pid 31598 invoked by uid 1000);\r
24  Sat, 19 Mar 2016 20:19:09 -0000\r
25 From: David Bremner <david@tethera.net>\r
26 To: Tomi Ollila <tomi.ollila@iki.fi>, notmuch@notmuchmail.org\r
27 Subject: Re: [PATCH 6/6] WIP: support XDG database directory\r
28 In-Reply-To: <m2k2l56iiu.fsf@guru.guru-group.fi>\r
29 References: <1453561198-2893-1-git-send-email-david@tethera.net>\r
30  <1457785890-17058-1-git-send-email-david@tethera.net>\r
31  <1457785890-17058-7-git-send-email-david@tethera.net>\r
32  <m2k2l56iiu.fsf@guru.guru-group.fi>\r
33 User-Agent: Notmuch/0.21+74~g6c60fb1 (http://notmuchmail.org) Emacs/24.5.1\r
34  (x86_64-pc-linux-gnu)\r
35 Date: Sat, 19 Mar 2016 17:19:09 -0300\r
36 Message-ID: <8737rm2pc2.fsf@zancas.localnet>\r
37 MIME-Version: 1.0\r
38 Content-Type: text/plain\r
39 X-BeenThere: notmuch@notmuchmail.org\r
40 X-Mailman-Version: 2.1.20\r
41 Precedence: list\r
42 List-Id: "Use and development of the notmuch mail system."\r
43  <notmuch.notmuchmail.org>\r
44 List-Unsubscribe: <https://notmuchmail.org/mailman/options/notmuch>,\r
45  <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
46 List-Archive: <http://notmuchmail.org/pipermail/notmuch/>\r
47 List-Post: <mailto:notmuch@notmuchmail.org>\r
48 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
49 List-Subscribe: <https://notmuchmail.org/mailman/listinfo/notmuch>,\r
50  <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
51 X-List-Received-Date: Sat, 19 Mar 2016 20:19:23 -0000\r
52 \r
53 Tomi Ollila <tomi.ollila@iki.fi> writes:\r
54 \r
55 > This is good opening for (eventually "fixing" e.g. library interface...);\r
56 > in its current state I can come up 2 (easily solvable) problems\r
57 >\r
58 > 1) the xapian database holding email indexes can grow to be quite large;\r
59 > user may have large space for emails (somewhere else than HOME) but small\r
60 > HOME. This can be "fixed" by keeping the database still in the same hierarchy\r
61 > as email files. Making user to point XDG_DATA_HOME elsewhere is (I) global\r
62 > and (II) fragile for an user to do.\r
63 \r
64 Sure, once we find the database, the mail tree can be anywhere,\r
65 including the same place. The question is how do non-CLI clients find\r
66 the database. I agree that setting XDG_DATA_HOME just for notmuch sounds\r
67 ick. As you mention below we can fairly easily have our own environment\r
68 variable (NOTMUCH_DATABASE ?) that is checked in preference to XDG_DATA_HOME.\r
69 \r
70 > 2) User may have multiple separate email configurations under one user\r
71 > account; This is easy to fix with environment variable; if exists,\r
72 > overrides XDG_DATA_HOME or $HOME/.local/share -- actually if this holds\r
73 > "only" configurations, the XDG_CONFIG_HOME is more appropriate\r
74 > (again, in simple case users should not be bothered to set any environment\r
75 > variables themselves, but should be able to survive with large databases).\r
76 \r
77 For me, having an environment variable makes sense in terms of getting\r
78 various tools (scripts etc...) to cooperate. For multiple databases,\r
79 this seems less natural but of course the tools can still take some\r
80 parameter specifying a database. Also, I don't know how common it is for\r
81 people to have multiple databases.\r
82 \r
83 d\r