Re: [PATCH] emacs: wash: make word-wrap bound message width
[notmuch-archives.git] / 25 / 28d7ae7d3df33f8007c3823fa2e73a05a4dd52
1 Return-Path: <m.walters@qmul.ac.uk>\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 olra.theworths.org (Postfix) with ESMTP id CD121431FB6\r
6         for <notmuch@notmuchmail.org>; Fri, 28 Dec 2012 01:03:23 -0800 (PST)\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
8 X-Spam-Flag: NO\r
9 X-Spam-Score: -1.098\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5\r
12         tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001,\r
13         NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled\r
14 Received: from olra.theworths.org ([127.0.0.1])\r
15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
16         with ESMTP id qS5yJYryADAc for <notmuch@notmuchmail.org>;\r
17         Fri, 28 Dec 2012 01:03:20 -0800 (PST)\r
18 Received: from mail2.qmul.ac.uk (mail2.qmul.ac.uk [138.37.6.6])\r
19         (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
20         (No client certificate requested)\r
21         by olra.theworths.org (Postfix) with ESMTPS id C34B3431FAF\r
22         for <notmuch@notmuchmail.org>; Fri, 28 Dec 2012 01:03:19 -0800 (PST)\r
23 Received: from smtp.qmul.ac.uk ([138.37.6.40])\r
24         by mail2.qmul.ac.uk with esmtp (Exim 4.71)\r
25         (envelope-from <m.walters@qmul.ac.uk>)\r
26         id 1ToVqP-0006xO-Vt; Fri, 28 Dec 2012 09:03:10 +0000\r
27 Received: from 93-97-24-31.zone5.bethere.co.uk ([93.97.24.31] helo=localhost)\r
28         by smtp.qmul.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69)\r
29         (envelope-from <m.walters@qmul.ac.uk>)\r
30         id 1ToVqP-0001Zr-Kh; Fri, 28 Dec 2012 09:03:09 +0000\r
31 From: Mark Walters <markwalters1009@gmail.com>\r
32 To: Austin Clements <amdragon@MIT.EDU>\r
33 Subject: Re: [PATCH] emacs: tweak error buffer handling\r
34 In-Reply-To: <20121227230402.GY6187@mit.edu>\r
35 References: <1356209345-11712-1-git-send-email-markwalters1009@gmail.com>\r
36         <m2y5glvo40.fsf@guru.guru-group.fi> <87k3s4fnz8.fsf@qmul.ac.uk>\r
37         <20121227230402.GY6187@mit.edu>\r
38 User-Agent: Notmuch/0.14+236~g1d0044f (http://notmuchmail.org) Emacs/23.4.1\r
39         (i486-pc-linux-gnu)\r
40 Date: Fri, 28 Dec 2012 09:03:08 +0000\r
41 Message-ID: <87ip7my2er.fsf@qmul.ac.uk>\r
42 MIME-Version: 1.0\r
43 Content-Type: text/plain; charset=us-ascii\r
44 X-Sender-Host-Address: 93.97.24.31\r
45 X-QM-SPAM-Info: Sender has good ham record.  :)\r
46 X-QM-Body-MD5: 6f2abbe81e6558d471008d586310a8dc (of first 20000 bytes)\r
47 X-SpamAssassin-Score: -1.8\r
48 X-SpamAssassin-SpamBar: -\r
49 X-SpamAssassin-Report: The QM spam filters have analysed this message to\r
50         determine if it is\r
51         spam. We require at least 5.0 points to mark a message as spam.\r
52         This message scored -1.8 points.\r
53         Summary of the scoring: \r
54         * -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/,\r
55         *      medium trust\r
56         *      [138.37.6.40 listed in list.dnswl.org]\r
57         * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail\r
58         provider *      (markwalters1009[at]gmail.com)\r
59         * -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay\r
60         *      domain\r
61         *  0.5 AWL AWL: From: address is in the auto white-list\r
62 X-QM-Scan-Virus: ClamAV says the message is clean\r
63 Cc: Tomi Ollila <tomi.ollila@iki.fi>, notmuch@notmuchmail.org\r
64 X-BeenThere: notmuch@notmuchmail.org\r
65 X-Mailman-Version: 2.1.13\r
66 Precedence: list\r
67 List-Id: "Use and development of the notmuch mail system."\r
68         <notmuch.notmuchmail.org>\r
69 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
70         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
71 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
72 List-Post: <mailto:notmuch@notmuchmail.org>\r
73 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
74 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
75         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
76 X-List-Received-Date: Fri, 28 Dec 2012 09:03:23 -0000\r
77 \r
78 \r
79 Austin Clements <amdragon@MIT.EDU> writes:\r
80 \r
81 > Quoth Mark Walters on Dec 26 at 10:27 pm:\r
82 >> \r
83 >> On Tue, 25 Dec 2012, Tomi Ollila <tomi.ollila@iki.fi> wrote:\r
84 >> > On Sat, Dec 22 2012, Mark Walters <markwalters1009@gmail.com> wrote:\r
85 >> >\r
86 >> >> view-mode-enter changed between emacs 23 and emacs 24: the current\r
87 >> >> code makes the error buffer disappear in emacs 24 on quitting it (ie\r
88 >> >> pressing q) but this just kills the buffer without closing the split\r
89 >> >> window in emacs 23.\r
90 >> >>\r
91 >> >> This patch makes the error buffer window disappear in emacs 23\r
92 >> >> too. Since the view-mode-enter function changed we have to test for\r
93 >> >> version and do the correct thing in each case.\r
94 >> >> ---\r
95 >> >>\r
96 >> >> This seems to work but I have only tested on 23.4 and 24.2\r
97 >> >\r
98 >> > I run emacs 23.1.1 to get the documentation of view-mode-enter\r
99 >> > there. So, this patch instructs to delete WINDOW when exiting\r
100 >> > view mode...\r
101 >> >\r
102 >> > Documentation of pop-to-buffer says:\r
103 >> >\r
104 >> > "Select buffer BUFFER-OR-NAME in some window, preferably a different one."\r
105 >> >\r
106 >> > What if pop-up-windows's value is nil -- the content of current window\r
107 >> > is replaced with this view stuff -- and when exiting view mode, the\r
108 >> > window will be deleted ? What happens with emacs 24 in this case ?\r
109 >> \r
110 >> Hi \r
111 >> \r
112 >> You are quite right there are problems here under emacs 23: if you\r
113 >> already have a split window when the error occurs in one part the error\r
114 >> is displayed in the other window and then on exit that (previously\r
115 >> existing) window is closed.\r
116 >> \r
117 >> What do people think should happen on an error? I, personally, don't\r
118 >> like taking over an existing window, and Jamie liked some of the errors\r
119 >> (eg non-fatal `locked database' tagging errors) to be shown in the\r
120 >> mini-buffer.\r
121 >> \r
122 >> I also think it is going to be difficult to get this right: emacs 23 and\r
123 >> 24 are different and there are also some user configuration variable\r
124 >> that affect what happens.\r
125 >\r
126 > How about showing all errors in the minibuffer (which could simply\r
127 > mean calling (error ...) and letting the Emacs top-level show it in\r
128 > the mini-buffer)?  We could log the verbose error details (like\r
129 > stdout) to some other buffer that we don't automatically show, but\r
130 > instead simply reference from the minibuffer message.  This would be\r
131 > more in line with how Emacs typically handles errors, and would make\r
132 > the details available to the user without flooding them with the\r
133 > details.\r
134 \r
135 Hi \r
136 \r
137 That sounds great. In an ideal world we could behave slightly\r
138 differently for fatal errors but the common errors are likely to be\r
139 transient (locked database errors) so getting these right (which this\r
140 would do) seems the important step.\r
141 \r
142 My view is that we should push a fix like the above for 0.15. What do\r
143 other people think?\r
144 \r
145 \r
146 Best wishes\r
147 \r
148 Mark\r
149 \r