community/pipermail-archives/sup-devel/2010-09.txt (34506B) - raw
1 From adam@lazur.org Thu Sep 2 16:49:24 2010
2 From: adam@lazur.org (adam lazur)
3 Date: Thu, 2 Sep 2010 13:49:24 -0700
4 Subject: [sup-devel] [PATCH] wrap quoted text according to wrap preferences
5 Message-ID: <1283460564-18287-1-git-send-email-adam@lazur.org>
6
7 From: adam lazur <laz at facebook.com>
8
9 Wrap expanded sections of quoted text at a column boundary, just like
10 sup already does for unquoted text. I split the existing wrapper code
11 into a utility function.
12 ---
13 lib/sup/modes/thread-view-mode.rb | 27 ++++++++++++++++-----------
14 1 files changed, 16 insertions(+), 11 deletions(-)
15
16 diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb
17 index 088529b..f648f8b 100644
18 --- a/lib/sup/modes/thread-view-mode.rb
19 +++ b/lib/sup/modes/thread-view-mode.rb
20 @@ -841,6 +841,19 @@ private
21 p.longname + (ContactManager.is_aliased_contact?(p) ? " (#{ContactManager.alias_for p})" : "")
22 end
23
24 + def maybe_wrap_text lines
25 + if @wrap
26 + config_width = $config[:wrap_width]
27 + if config_width and config_width != 0
28 + width = [config_width, buffer.content_width].min
29 + else
30 + width = buffer.content_width
31 + end
32 + lines = lines.map { |l| l.chomp.wrap width }.flatten
33 + end
34 + return lines
35 + end
36 +
37 ## todo: check arguments on this overly complex function
38 def chunk_to_lines chunk, state, start, depth, parent=nil, color=nil, star_color=nil
39 prefix = " " * INDENT_SPACES * depth
40 @@ -856,23 +869,15 @@ private
41 else
42 raise "Bad chunk: #{chunk.inspect}" unless chunk.respond_to?(:inlineable?) ## debugging
43 if chunk.inlineable?
44 - lines = chunk.lines
45 - if @wrap
46 - config_width = $config[:wrap_width]
47 - if config_width and config_width != 0
48 - width = [config_width, buffer.content_width].min
49 - else
50 - width = buffer.content_width
51 - end
52 - lines = lines.map { |l| l.chomp.wrap width }.flatten
53 - end
54 + lines = maybe_wrap_text(chunk.lines)
55 lines.map { |line| [[chunk.color, "#{prefix}#{line}"]] }
56 elsif chunk.expandable?
57 case state
58 when :closed
59 [[[chunk.patina_color, "#{prefix}+ #{chunk.patina_text}"]]]
60 when :open
61 - [[[chunk.patina_color, "#{prefix}- #{chunk.patina_text}"]]] + chunk.lines.map { |line| [[chunk.color, "#{prefix}#{line}"]] }
62 + lines = maybe_wrap_text(chunk.lines)
63 + [[[chunk.patina_color, "#{prefix}- #{chunk.patina_text}"]]] + lines.map { |line| [[chunk.color, "#{prefix}#{line}"]] }
64 end
65 else
66 [[[chunk.patina_color, "#{prefix}x #{chunk.patina_text}"]]]
67 --
68 1.7.2.1
69
70
71 From viroteck@viroteck.net Sat Sep 4 06:40:18 2010
72 From: viroteck@viroteck.net (Robin Burchell)
73 Date: Sat, 04 Sep 2010 20:40:18 +1000
74 Subject: [sup-devel] [PATCH] wrap quoted text according to wrap
75 preferences
76 In-Reply-To: <1283460564-18287-1-git-send-email-adam@lazur.org>
77 References: <1283460564-18287-1-git-send-email-adam@lazur.org>
78 Message-ID: <1283596689-sup-5333@virgin>
79
80 Hi Adam,
81
82 Excerpts from adam lazur's message of Fri Sep 03 06:49:24 +1000 2010:
83 > From: adam lazur <laz at facebook.com>
84 >
85 > Wrap expanded sections of quoted text at a column boundary, just like
86 > sup already does for unquoted text. I split the existing wrapper code
87 > into a utility function.
88
89 Thanks for this. Fixes an annoyance that I really didn't like. I've applied it
90 to my tree at http://github.com/rburchell/sup/ and so far, so good.
91
92 I'll let you know if I see any breakage.
93
94 --
95 Robin Burchell
96 http://rburchell.com
97
98 From eg@gaute.vetsj.com Thu Sep 9 08:02:17 2010
99 From: eg@gaute.vetsj.com (Gaute Hope)
100 Date: Thu, 09 Sep 2010 14:02:17 +0200
101 Subject: [sup-devel] [PATCH] utf-8 script encoding
102 In-Reply-To: <1266066673-sup-5419@mithink>
103 References: <1262533823-sup-5348@dolk>
104 <1262534836-29113-1-git-send-email-rlane@club.cc.cmu.edu>
105 <1262535218-sup-9718@dolk> <1264250655-sup-3062@masanjin.net>
106 <1266066673-sup-5419@mithink>
107 Message-ID: <1284033605-sup-442@dolk>
108
109 Excerpts from Michael Hamann's message of 2010-02-13 14:51:53 +0100:
110 > Hi,
111 >
112 > Excerpts from William Morgan's message of 2010-01-23 13:44:39 +0100:
113 > > Reformatted excerpts from Gaute Hope's message of 2010-01-03:
114 > > > No. Tab completion fails, and sending fails, I can add names with
115 > > > UTF-8 chars to the recipient list, but it fails with the last attached
116 > > > exception. This is the same behaviour as earlier.
117 > >
118 > > That's weird, I would've expected this to help. What's the alternative,
119 > > adding "u" to the end of every regexp?
120 >
121 > Has there been any progress on this subject? This is imho a quite annoying bug
122 > as it makes me regularly recover mails from the buffer of screen when having
123 > written a reply to a message with a subject containing utf-8 chars without
124 > noticing that.
125 >
126 > Sorry if this should have been fixed already, I'm currently using git next and
127 > there the problem still exists.
128 >
129
130 I put target.force_encoding 'UTF-8' on the tab completion of contacts
131 and labels and that seems to have fixed the issue 36 on Ruby 1.9. See
132 attached patch; or:
133 http://gitorious.org/sup/gautehs-mainline/commit/c78e53f13b493afe2ce13c8f312068fe042cd126
134
135 - gaute
136 -------------- next part --------------
137 A non-text attachment was scrubbed...
138 Name: 0001-Force-UTF-8-on-label-and-contact-completion.patch
139 Type: application/octet-stream
140 Size: 1448 bytes
141 Desc: not available
142 URL: <http://rubyforge.org/pipermail/sup-devel/attachments/20100909/fc45a122/attachment.obj>
143
144 From ezyang@MIT.EDU Thu Sep 9 12:55:25 2010
145 From: ezyang@MIT.EDU (Edward Z. Yang)
146 Date: Thu, 09 Sep 2010 12:55:25 -0400
147 Subject: [sup-devel] [PATCH] Return nothing between if end index is not
148 found.
149 In-Reply-To: <1282085130-sup-6401@midna.zekjur.net>
150 References: <1279475566-sup-7173@ezyang> <1279579814-sup-4745@midna.zekjur.net>
151 <1279656544-sup-4931@midna.zekjur.net> <1281915009-sup-2620@ezyang>
152 <1281921538-sup-8727@midna.zekjur.net> <1281922808-sup-4140@ezyang>
153 <1281979317-sup-3846@midna.zekjur.net> <1281979589-sup-7759@ezyang>
154 <1282085130-sup-6401@midna.zekjur.net>
155 Message-ID: <1284051078-sup-224@ezyang>
156
157 Excerpts from Michael Stapelberg's message of Tue Aug 17 18:46:32 -0400 2010:
158 > Interesting. I gzipped it (to make sure it does not get touched in any way on
159 > its way to you) and attached it to this mail.
160
161 I finally got around to looking at your message, and as expected, it appears
162 that there is no trailing END PGP MESSAGE block, which is why my patch breaks
163 your behavior (it claims there is no valid PGP block.)
164
165 Regardless of what the PGP standard says, I suppose it's good practice
166 to be liberal in what we accept. So the correct change might be to
167 keep the existing semantics of between (documenting carefully what happens
168 if the ending line is not present) and then fixing the code that relies
169 on the bogus invariant.
170
171 This also resolves Kevin Riggle?s issue.
172
173 Cheers,
174 Edward
175
176 From kevinr@free-dissociation.com Thu Sep 9 15:08:45 2010
177 From: kevinr@free-dissociation.com (Kevin Riggle)
178 Date: Thu, 09 Sep 2010 15:08:45 -0400
179 Subject: [sup-devel] [PATCH] Return nothing between if end index is not
180 found.
181 In-Reply-To: <1282085130-sup-6401@midna.zekjur.net>
182 References: <1279475566-sup-7173@ezyang> <1279579814-sup-4745@midna.zekjur.net>
183 <1279656544-sup-4931@midna.zekjur.net> <1281915009-sup-2620@ezyang>
184 <1281921538-sup-8727@midna.zekjur.net> <1281922808-sup-4140@ezyang>
185 <1281979317-sup-3846@midna.zekjur.net> <1281979589-sup-7759@ezyang>
186 <1282085130-sup-6401@midna.zekjur.net>
187 Message-ID: <1284059161-sup-3369@black-opal.free-dissociation.com>
188
189 Excerpts from Michael Stapelberg's message of Tue Aug 17 18:46:32 -0400 2010:
190 > Hi Edward,
191 >
192 > Excerpts from Edward Z. Yang's message of 2010-08-16 21:55:32 +0200:
193 > > Fascinatingly enough, I cannot find it in either my inbox or my spam filter. (Dun dun dun.)
194 > > Maybe you should send it as an attachment.
195 > Interesting. I gzipped it (to make sure it does not get touched in any way on
196 > its way to you) and attached it to this mail.
197 >
198 These days GMail, at least, will look inside your gzipped attachments and will
199 block attachments containing binaries. Now, if you'd PGP-encrypted it.....
200
201 - Kevin
202 --
203 Kevin Riggle (kevinr at free-dissociation.com)
204 http://free-dissociation.com
205
206 From michael@content-space.de Sat Sep 4 17:51:46 2010
207 From: michael@content-space.de (Michael Hamann)
208 Date: Sat, 4 Sep 2010 23:51:46 +0200
209 Subject: [sup-devel] [PATCH] Fixed inline gpg crash when the end marker is
210 missing
211 In-Reply-To: <AANLkTimw-xi2XCdn3R3QHoDFFv-4cD7GxCoHWxbta-0r@mail.gmail.com>
212 References: <AANLkTimw-xi2XCdn3R3QHoDFFv-4cD7GxCoHWxbta-0r@mail.gmail.com>
213 Message-ID: <1283637106-18801-1-git-send-email-michael@content-space.de>
214
215 lines.between() does not check if the end marker actually exists, but
216 later it is assumed the marker exists. This change introduces a check
217 for the end marker and doesn't decrypt messages in which the end marker
218 is missing. This is a fix for
219 http://rubyforge.org/pipermail/sup-talk/2010-August/004209.html
220 ---
221 lib/sup/message.rb | 3 ++-
222 1 files changed, 2 insertions(+), 1 deletions(-)
223
224 diff --git a/lib/sup/message.rb b/lib/sup/message.rb
225 index 9f488af..69669bd 100644
226 --- a/lib/sup/message.rb
227 +++ b/lib/sup/message.rb
228 @@ -559,7 +559,8 @@ private
229 end
230
231 gpg = lines.between(GPG_START, GPG_END)
232 - if !gpg.empty?
233 + # between does not check if GPG_END actually exists
234 + if !gpg.empty? && !lines.index(GPG_END).nil?
235 msg = RMail::Message.new
236 msg.body = gpg.join("\n")
237
238 --
239 1.7.2.2
240
241
242 From ezyang@MIT.EDU Sat Sep 11 12:42:50 2010
243 From: ezyang@MIT.EDU (Edward Z. Yang)
244 Date: Sat, 11 Sep 2010 12:42:50 -0400
245 Subject: [sup-devel] [PATCH] Fixed inline gpg crash when the end marker
246 is missing
247 In-Reply-To: <1283637106-18801-1-git-send-email-michael@content-space.de>
248 References: <AANLkTimw-xi2XCdn3R3QHoDFFv-4cD7GxCoHWxbta-0r@mail.gmail.com>
249 <1283637106-18801-1-git-send-email-michael@content-space.de>
250 Message-ID: <1284223201-sup-8199@ezyang>
251
252 Excerpts from Michael Hamann's message of Sat Sep 04 17:51:46 -0400 2010:
253 > lines.between() does not check if the end marker actually exists, but
254 > later it is assumed the marker exists. This change introduces a check
255 > for the end marker and doesn't decrypt messages in which the end marker
256 > is missing. This is a fix for
257 > http://rubyforge.org/pipermail/sup-talk/2010-August/004209.html
258
259 Hello Michael,
260
261 It may be desirable to assume an implicit end marker at the end
262 of a message if it does not exist, to deal with certain malformed
263 PGP messages that were also complained about on this list.
264
265 Cheers,
266 Edward
267
268 From gaudenz@soziologie.ch Wed Sep 15 13:56:26 2010
269 From: gaudenz@soziologie.ch (Gaudenz Steinlin)
270 Date: Wed, 15 Sep 2010 19:56:26 +0200
271 Subject: [sup-devel] [PATCH] prefer To and Cc adresses of accounts on reply
272 Message-ID: <1284573363-sup-9875@meteor.durcheinandertal.local>
273
274 If a message was sent (To or Cc header) to an address which corresponds
275 to an account prefer this account over the account corresponding to the
276 address in recipient_email.
277
278 This solves the problem that the wrong reply from address is chosen on
279 mails which are sent to an account which is forwarded to another account.
280 ---
281 lib/sup/modes/reply-mode.rb | 15 ++++++---------
282 1 files changed, 6 insertions(+), 9 deletions(-)
283
284 diff --git a/lib/sup/modes/reply-mode.rb b/lib/sup/modes/reply-mode.rb
285 index bbac922..d80f35b 100644
286 --- a/lib/sup/modes/reply-mode.rb
287 +++ b/lib/sup/modes/reply-mode.rb
288 @@ -65,18 +65,15 @@ EOS
289 ## if we have a value from a hook, use it.
290 from = if hook_reply_from
291 hook_reply_from
292 - ## otherwise, if the original email had an envelope-to header, try and use
293 - ## it, and look up the corresponding name form the list of accounts.
294 - ##
295 + ## otherwise, try and find an account somewhere in the list of to's
296 + ## and cc's and look up the corresponding name form the list of accounts.
297 + ## if this does not succeed use the recipient_email (=envelope-to) instead.
298 ## this is for the case where mail is received from a mailing lists (so the
299 ## To: is the list id itself). if the user subscribes via a particular
300 ## alias, we want to use that alias in the reply.
301 - elsif @m.recipient_email && (a = AccountManager.account_for(@m.recipient_email))
302 - Person.new a.name, @m.recipient_email
303 - ## otherwise, try and find an account somewhere in the list of to's
304 - ## and cc's.
305 - elsif(b = (@m.to + @m.cc).find { |p| AccountManager.is_account? p })
306 - b
307 + elsif(b = (@m.to.collect {|t| t.email} + @m.cc.collect {|c| c.email} + [@m.recipient_email] ).find { |p| AccountManager.is_account_email? p })
308 + a = AccountManager.account_for(b)
309 + Person.new a.name, b
310 ## if all else fails, use the default
311 else
312 AccountManager.default_account
313 --
314 Ever tried. Ever failed. No matter.
315 Try again. Fail again. Fail better.
316 ~ Samuel Beckett ~
317 -------------- next part --------------
318 A non-text attachment was scrubbed...
319 Name: signature.asc
320 Type: application/pgp-signature
321 Size: 828 bytes
322 Desc: not available
323 URL: <http://rubyforge.org/pipermail/sup-devel/attachments/20100915/bb96e0bd/attachment.bin>
324
325 From eg@gaute.vetsj.com Fri Sep 17 06:54:00 2010
326 From: eg@gaute.vetsj.com (Gaute Hope)
327 Date: Fri, 17 Sep 2010 12:54:00 +0200
328 Subject: [sup-devel] [PATCH] utf-8 script encoding
329 In-Reply-To: <1284033605-sup-442@dolk>
330 References: <1262533823-sup-5348@dolk>
331 <1262534836-29113-1-git-send-email-rlane@club.cc.cmu.edu>
332 <1262535218-sup-9718@dolk> <1264250655-sup-3062@masanjin.net>
333 <1266066673-sup-5419@mithink> <1284033605-sup-442@dolk>
334 Message-ID: <1284720809-sup-6508@dolk>
335
336 Excerpts from Gaute Hope's message of 2010-09-09 14:02:17 +0200:
337 > I put target.force_encoding 'UTF-8' on the tab completion of contacts
338 > and labels and that seems to have fixed the issue 36 on Ruby 1.9. See
339 > attached patch; or:
340 > http://gitorious.org/sup/gautehs-mainline/commit/c78e53f13b493afe2ce13c8f312068fe042cd126
341
342 Also force encoding on label search completion:
343 http://gitorious.org/~gauteh/sup/gautehs-mainline/commit/009cda0e379950726c5234a8949e636194bf13e3
344
345 There's still an error if you try to complete multiple unicode
346 recipients, probably because one of the strings are not Unicode.
347
348 - gaute
349 -------------- next part --------------
350 A non-text attachment was scrubbed...
351 Name: 0001-Also-force-encoding-on-label-search-completion.patch
352 Type: application/octet-stream
353 Size: 739 bytes
354 Desc: not available
355 URL: <http://rubyforge.org/pipermail/sup-devel/attachments/20100917/71c22c5e/attachment.obj>
356
357 From eg@gaute.vetsj.com Thu Sep 23 06:37:34 2010
358 From: eg@gaute.vetsj.com (Gaute Hope)
359 Date: Thu, 23 Sep 2010 12:37:34 +0200
360 Subject: [sup-devel] [PATCH] Update status on jump on line in
361 line-cursor-mode
362 Message-ID: <1285238213-sup-3935@dolk>
363
364 The line number isn't updated in the status field when you jump to the
365 end or beginning, or do page up or down before the next redraw is done.
366
367 Updating the status manually in set_cursor_pos.
368 ---
369 lib/sup/modes/line-cursor-mode.rb | 1 +
370 1 files changed, 1 insertions(+), 0 deletions(-)
371
372 diff --git a/lib/sup/modes/line-cursor-mode.rb b/lib/sup/modes/line-cursor-mode.rb
373 index 1bd4ed1..1cae994 100644
374 --- a/lib/sup/modes/line-cursor-mode.rb
375 +++ b/lib/sup/modes/line-cursor-mode.rb
376 @@ -66,6 +66,7 @@ protected
377 return if @curpos == p
378 @curpos = p.clamp @cursor_top, lines
379 buffer.mark_dirty
380 + set_status
381 end
382
383 ## override search behavior to be cursor-based. this is a stupid
384 --
385 1.7.3
386
387 From eg@gaute.vetsj.com Thu Sep 23 07:50:23 2010
388 From: eg@gaute.vetsj.com (Gaute Hope)
389 Date: Thu, 23 Sep 2010 13:50:23 +0200
390 Subject: [sup-devel] sup for sale
391 In-Reply-To: <1267111506-sup-1389@peer.zerties.org>
392 References: <1267109223-sup-351@masanjin.net>
393 <1267111506-sup-1389@peer.zerties.org>
394 Message-ID: <1285241702-sup-3344@dolk>
395
396 Excerpts from Christian Dietrich's message of 2010-02-25 16:32:39 +0100:
397 > Excerpts from William Morgan's message of Thu Feb 25 15:51:55 +0100 2010:
398 > > But if someone wants to take the ball and be an official maintainer, I
399 > > will give you my blessing and the power to gem push new releases. You
400 > > don't even have to maintain my current crazy branching scheme!
401 >
402 > Hi,
403 > i haven't contributed much to sup yet (except one patch, that wasn't
404 > applied) but i thinks its a really great mailer, that is it worth to
405 > be activly continued.
406 >
407 > In the last half year i made the experience that it is easier for
408 > the single programmer (pusher) if he isn't the only one who is
409 > allowed to push the upstream repository. Because there you have
410 > always the possibility to say: Hm, i don't have the time in the next
411 > 3 weeks or so, but there is somebody else, who does merging/patching
412 > and bugfixing. Perhaps it isn't that bad to give push right to a
413 > group of people, who activly developed sup in the past.
414
415 Hi,
416
417 First; thanks to both William and Rich for the great work on sup. I'm
418 using it full time now since I don't-really-know-anymore, there are
419 occasional bugs and more than a few problems with ruby 1.9 - but things
420 are starting to get along. Awesome work!
421
422 I just want to support the point of Christian Dietrich of perhaps adding
423 another maintainer/committer to be able to take some of the load when
424 Rich might be busy or gone for a while. I agree that it can be
425 de-motivating to contribute when you see the patches pile up, I imagine
426 it must be harder to go through the backlog as well. Still think Rich is
427 the man for the job thou, so he's the boss!
428
429 Best regards, Gaute
430
431 From alvherre@alvh.no-ip.org Thu Sep 23 13:46:31 2010
432 From: alvherre@alvh.no-ip.org (Alvaro Herrera)
433 Date: Thu, 23 Sep 2010 13:46:31 -0400
434 Subject: [sup-devel] sup for sale
435 In-Reply-To: <1285241702-sup-3344@dolk>
436 References: <1267109223-sup-351@masanjin.net>
437 <1267111506-sup-1389@peer.zerties.org> <1285241702-sup-3344@dolk>
438 Message-ID: <1285263695-sup-3656@alvh.no-ip.org>
439
440 Excerpts from Gaute Hope's message of jue sep 23 07:50:23 -0400 2010:
441
442 > First; thanks to both William and Rich for the great work on sup. I'm
443 > using it full time now since I don't-really-know-anymore, there are
444 > occasional bugs and more than a few problems with ruby 1.9 - but things
445 > are starting to get along. Awesome work!
446
447 Seconded!
448
449 > I just want to support the point of Christian Dietrich of perhaps adding
450 > another maintainer/committer to be able to take some of the load when
451 > Rich might be busy or gone for a while. I agree that it can be
452 > de-motivating to contribute when you see the patches pile up, I imagine
453 > it must be harder to go through the backlog as well. Still think Rich is
454 > the man for the job thou, so he's the boss!
455
456 I just want to add that it's a bit discouraging to see that the master
457 branch doesn't move a bit for a long time. So it would be very good for
458 morale of us poor users to have someone else pushing patches, even if
459 it's just the minor bugfixes that we see pop up on the mailing lists.
460
461 (I don't have a lot to offer myself in term of patches, but I do have a
462 couple of very minor fixes sitting in my private tree just because it
463 seems rather pointless to send them along right now.)
464
465 --
466 ?lvaro Herrera <alvherre at alvh.no-ip.org>
467
468 From sup-bugs@masanjin.net Wed Sep 29 08:22:48 2010
469 From: sup-bugs@masanjin.net (Sascha Silbe)
470 Date: Wed, 29 Sep 2010 12:22:48 +0000
471 Subject: [sup-devel] [issue122] editing labels in thread view mode messes up
472 labels of all messages in thread, even after undo
473 In-Reply-To: <1285762968.52.0.37349243868.issue122@masanjin.net>
474 Message-ID: <1285762968.52.0.37349243868.issue122@masanjin.net>
475
476
477 New submission from Sascha Silbe <sascha-web-masanjin.net-sup-bugs at silbe.org>:
478
479 When changing labels in thread view mode (and probably also in thread index / inbox mode), labels for _all_ messages of the thread are set to be exactly the same. Apart from not being what the user expects, it also messes up special labels like :attachment.
480 Even worse, the undo block also sets the labels of all messages to the union of the previous labels, thereby not(completely) undoing the effect.
481
482 At the very least, undo should work properly and only labels that have actually been added or removed by the user should be touched. This would preserve the state of both the special labels and any source-specific labels that were not explicitly changed by the user.
483
484 I would also expect edit_labels to only apply to the current message in thread view mode. If you disagree, please consider adding an edit_message_labels keybinding. This would especially be useful for managing "todo lists".
485
486 ----------
487 messages: 288
488 nosy: sascha_silbe
489 priority: bug
490 ruby_version: 1.8.x
491 status: unread
492 sup_version: git master (45c3433)
493 title: editing labels in thread view mode messes up labels of all messages in thread, even after undo
494
495 _________________________________________
496 Sup issue tracker <sup-bugs at masanjin.net>
497 <http://masanjin.net/sup-bugs/issue122>
498 _________________________________________
499
500 From sascha-pgp@silbe.org Wed Sep 29 10:13:00 2010
501 From: sascha-pgp@silbe.org (Sascha Silbe)
502 Date: Wed, 29 Sep 2010 16:13:00 +0200
503 Subject: [sup-devel] [PATCH] add sendmail hook
504 Message-ID: <1285769580-15705-1-git-send-email-sascha-pgp@silbe.org>
505
506 Add a hook that is run in place of the sendmail command. This allows
507 last-minute adjustments including sending a separate copy to each recipient
508 and setting the envelope sender, i.e. VERP (variable envelope return path).
509
510 Signed-off-by: Sascha Silbe <sascha-pgp at silbe.org>
511 ---
512 lib/sup/modes/edit-message-mode.rb | 25 +++++++++++++++++++++++--
513 1 files changed, 23 insertions(+), 2 deletions(-)
514
515 I've been using this for about three months now for setting the envelope
516 sender to the subscription address, allowing me to use a different address
517 in the From: header and doing crossposts even if though I use a separate
518 subscription address for each mailing list.
519
520 diff --git a/lib/sup/modes/edit-message-mode.rb b/lib/sup/modes/edit-message-mode.rb
521 index bba07b5..d80ff9b 100644
522 --- a/lib/sup/modes/edit-message-mode.rb
523 +++ b/lib/sup/modes/edit-message-mode.rb
524 @@ -58,6 +58,18 @@ Return value:
525 none
526 EOS
527
528 + HookManager.register "sendmail", <<EOS
529 +Sends the given mail. If this hook doesn't exist, the sendmail command
530 +configured for the account is used.
531 +The message will be saved after this hook is run, so any modification to it
532 +will be recorded.
533 +Variables:
534 + message: RMail::Message instance of the mail to send
535 + account: Account instance matching the From address
536 +Return value:
537 + True if mail has been sent successfully, false otherwise.
538 +EOS
539 +
540 attr_reader :status
541 attr_accessor :body, :header
542 bool_reader :edited
543 @@ -341,8 +353,17 @@ protected
544 begin
545 date = Time.now
546 m = build_message date
547 - IO.popen(acct.sendmail, "w") { |p| p.puts m }
548 - raise SendmailCommandFailed, "Couldn't execute #{acct.sendmail}" unless $? == 0
549 +
550 + if HookManager.enabled? "sendmail"
551 + if not HookManager.run "sendmail", :message => m, :account => acct
552 + warn "Sendmail hook was not successful"
553 + return false
554 + end
555 + else
556 + IO.popen(acct.sendmail, "w") { |p| p.puts m }
557 + raise SendmailCommandFailed, "Couldn't execute #{acct.sendmail}" unless $? == 0
558 + end
559 +
560 SentManager.write_sent_message(date, from_email) { |f| f.puts sanitize_body(m.to_s) }
561 BufferManager.kill_buffer buffer
562 BufferManager.flash "Message sent!"
563 --
564 1.7.1
565
566
567 From sascha-pgp@silbe.org Wed Sep 29 10:16:02 2010
568 From: sascha-pgp@silbe.org (Sascha Silbe)
569 Date: Wed, 29 Sep 2010 16:16:02 +0200
570 Subject: [sup-devel] [PATCH] fix handling of multiple label: terms in search
571 Message-ID: <1285769762-15823-1-git-send-email-sascha-pgp@silbe.org>
572
573 By default Xapian will join query terms with the same prefix with OR instead
574 of AND, so searching for multiple labels doesn't return the expected results.
575 By making use of a parameter to add_boolean_prefix (added in Xapian 1.2) we
576 can tell Xapian to use OR only for the search terms that are guaranteed to be
577 unique.
578
579 Signed-off-by: Sascha Silbe <sascha-pgp at silbe.org>
580 ---
581 lib/sup/index.rb | 74 +++++++++++++++++++++++++++---------------------------
582 1 files changed, 37 insertions(+), 37 deletions(-)
583
584 Tested on Debian Squeeze with Ruby 1.8.7.302 and Xapian 1.2.3.
585
586 diff --git a/lib/sup/index.rb b/lib/sup/index.rb
587 index 9273f18..a72bec6 100644
588 --- a/lib/sup/index.rb
589 +++ b/lib/sup/index.rb
590 @@ -419,8 +419,8 @@ EOS
591 qp.stemming_strategy = Xapian::QueryParser::STEM_SOME
592 qp.default_op = Xapian::Query::OP_AND
593 qp.add_valuerangeprocessor(Xapian::NumberValueRangeProcessor.new(DATE_VALUENO, 'date:', true))
594 - NORMAL_PREFIX.each { |k,vs| vs.each { |v| qp.add_prefix k, v } }
595 - BOOLEAN_PREFIX.each { |k,vs| vs.each { |v| qp.add_boolean_prefix k, v } }
596 + NORMAL_PREFIX.each { |k,info| info[:prefix].each { |v| qp.add_prefix k, v } }
597 + BOOLEAN_PREFIX.each { |k,info| info[:prefix].each { |v| qp.add_boolean_prefix k, v, info[:exclusive] } }
598
599 begin
600 xapian_query = qp.parse_query(subs, Xapian::QueryParser::FLAG_PHRASE|Xapian::QueryParser::FLAG_BOOLEAN|Xapian::QueryParser::FLAG_LOVEHATE|Xapian::QueryParser::FLAG_WILDCARD)
601 @@ -471,31 +471,31 @@ EOS
602
603 # Stemmed
604 NORMAL_PREFIX = {
605 - 'subject' => 'S',
606 - 'body' => 'B',
607 - 'from_name' => 'FN',
608 - 'to_name' => 'TN',
609 - 'name' => %w(FN TN),
610 - 'attachment' => 'A',
611 - 'email_text' => 'E',
612 - '' => %w(S B FN TN A E),
613 + 'subject' => {:prefix => 'S', :exclusive => false},
614 + 'body' => {:prefix => 'B', :exclusive => false},
615 + 'from_name' => {:prefix => 'FN', :exclusive => false},
616 + 'to_name' => {:prefix => 'TN', :exclusive => false},
617 + 'name' => {:prefix => %w(FN TN), :exclusive => false},
618 + 'attachment' => {:prefix => 'A', :exclusive => false},
619 + 'email_text' => {:prefix => 'E', :exclusive => false},
620 + '' => {:prefix => %w(S B FN TN A E), :exclusive => false},
621 }
622
623 # Unstemmed
624 BOOLEAN_PREFIX = {
625 - 'type' => 'K',
626 - 'from_email' => 'FE',
627 - 'to_email' => 'TE',
628 - 'email' => %w(FE TE),
629 - 'date' => 'D',
630 - 'label' => 'L',
631 - 'source_id' => 'I',
632 - 'attachment_extension' => 'O',
633 - 'msgid' => 'Q',
634 - 'id' => 'Q',
635 - 'thread' => 'H',
636 - 'ref' => 'R',
637 - 'location' => 'J',
638 + 'type' => {:prefix => 'K', :exclusive => true},
639 + 'from_email' => {:prefix => 'FE', :exclusive => false},
640 + 'to_email' => {:prefix => 'TE', :exclusive => false},
641 + 'email' => {:prefix => %w(FE TE), :exclusive => false},
642 + 'date' => {:prefix => 'D', :exclusive => true},
643 + 'label' => {:prefix => 'L', :exclusive => false},
644 + 'source_id' => {:prefix => 'I', :exclusive => true},
645 + 'attachment_extension' => {:prefix => 'O', :exclusive => false},
646 + 'msgid' => {:prefix => 'Q', :exclusive => true},
647 + 'id' => {:prefix => 'Q', :exclusive => true},
648 + 'thread' => {:prefix => 'H', :exclusive => false},
649 + 'ref' => {:prefix => 'R', :exclusive => false},
650 + 'location' => {:prefix => 'J', :exclusive => false},
651 }
652
653 PREFIX = NORMAL_PREFIX.merge BOOLEAN_PREFIX
654 @@ -661,8 +661,8 @@ EOS
655 # Person names are indexed with several prefixes
656 person_termer = lambda do |d|
657 lambda do |p|
658 - doc.index_text p.name, PREFIX["#{d}_name"] if p.name
659 - doc.index_text p.email, PREFIX['email_text']
660 + doc.index_text p.name, PREFIX["#{d}_name"][:prefix] if p.name
661 + doc.index_text p.email, PREFIX['email_text'][:prefix]
662 doc.add_term mkterm(:email, d, p.email)
663 end
664 end
665 @@ -673,9 +673,9 @@ EOS
666 # Full text search content
667 subject_text = m.indexable_subject
668 body_text = m.indexable_body
669 - doc.index_text subject_text, PREFIX['subject']
670 - doc.index_text body_text, PREFIX['body']
671 - m.attachments.each { |a| doc.index_text a, PREFIX['attachment'] }
672 + doc.index_text subject_text, PREFIX['subject'][:prefix]
673 + doc.index_text body_text, PREFIX['body'][:prefix]
674 + m.attachments.each { |a| doc.index_text a, PREFIX['attachment'][:prefix] }
675
676 # Miscellaneous terms
677 doc.add_term mkterm(:date, m.date) if m.date
678 @@ -753,25 +753,25 @@ EOS
679 def mkterm type, *args
680 case type
681 when :label
682 - PREFIX['label'] + args[0].to_s.downcase
683 + PREFIX['label'][:prefix] + args[0].to_s.downcase
684 when :type
685 - PREFIX['type'] + args[0].to_s.downcase
686 + PREFIX['type'][:prefix] + args[0].to_s.downcase
687 when :date
688 - PREFIX['date'] + args[0].getutc.strftime("%Y%m%d%H%M%S")
689 + PREFIX['date'][:prefix] + args[0].getutc.strftime("%Y%m%d%H%M%S")
690 when :email
691 case args[0]
692 - when :from then PREFIX['from_email']
693 - when :to then PREFIX['to_email']
694 + when :from then PREFIX['from_email'][:prefix]
695 + when :to then PREFIX['to_email'][:prefix]
696 else raise "Invalid email term type #{args[0]}"
697 end + args[1].to_s.downcase
698 when :source_id
699 - PREFIX['source_id'] + args[0].to_s.downcase
700 + PREFIX['source_id'][:prefix] + args[0].to_s.downcase
701 when :location
702 - PREFIX['location'] + [args[0]].pack('n') + args[1].to_s
703 + PREFIX['location'][:prefix] + [args[0]].pack('n') + args[1].to_s
704 when :attachment_extension
705 - PREFIX['attachment_extension'] + args[0].to_s.downcase
706 + PREFIX['attachment_extension'][:prefix] + args[0].to_s.downcase
707 when :msgid, :ref, :thread
708 - PREFIX[type.to_s] + args[0][0...(MAX_TERM_LENGTH-1)]
709 + PREFIX[type.to_s][:prefix] + args[0][0...(MAX_TERM_LENGTH-1)]
710 else
711 raise "Invalid term type #{type}"
712 end
713 --
714 1.7.1
715
716
717 From sascha-pgp@silbe.org Wed Sep 29 10:16:15 2010
718 From: sascha-pgp@silbe.org (Sascha Silbe)
719 Date: Wed, 29 Sep 2010 16:16:15 +0200
720 Subject: [sup-devel] [PATCH] fix searching for non-lowercase labels
721 Message-ID: <1285769775-15914-1-git-send-email-sascha-pgp@silbe.org>
722
723 Case is preserved when marshalling labels (stored as document data), but label
724 terms are stored lowercase. build_xapian_query uses mkterm and thus already
725 converts labels to lowercase when searching. parse_query accepts a Xapian
726 query string from the user and needs to explicitly convert labels to
727 lowercase, which it now does.
728
729 Signed-off-by: Sascha Silbe <sascha-pgp at silbe.org>
730 ---
731 lib/sup/index.rb | 6 ++++++
732 1 files changed, 6 insertions(+), 0 deletions(-)
733
734 diff --git a/lib/sup/index.rb b/lib/sup/index.rb
735 index a72bec6..f90d0d9 100644
736 --- a/lib/sup/index.rb
737 +++ b/lib/sup/index.rb
738 @@ -346,6 +346,12 @@ EOS
739 end
740 end
741
742 + ## labels are stored lower-case in the index
743 + subs = subs.gsub(/\blabel:(\S+)\b/) do
744 + label = $1
745 + "label:#{label.downcase}"
746 + end
747 +
748 ## if we see a label:deleted or a label:spam term anywhere in the query
749 ## string, we set the extra load_spam or load_deleted options to true.
750 ## bizarre? well, because the query allows arbitrary parenthesized boolean
751 --
752 1.7.1
753
754
755 From ezyang@MIT.EDU Wed Sep 29 11:27:14 2010
756 From: ezyang@MIT.EDU (Edward Z. Yang)
757 Date: Wed, 29 Sep 2010 11:27:14 -0400
758 Subject: [sup-devel] [PATCH] fix handling of multiple label: terms in
759 search
760 In-Reply-To: <1285769762-15823-1-git-send-email-sascha-pgp@silbe.org>
761 References: <1285769762-15823-1-git-send-email-sascha-pgp@silbe.org>
762 Message-ID: <1285774021-sup-2553@ezyang>
763
764 Excerpts from Sascha Silbe's message of Wed Sep 29 10:16:02 -0400 2010:
765 > By default Xapian will join query terms with the same prefix with OR instead
766 > of AND, so searching for multiple labels doesn't return the expected results.
767 > By making use of a parameter to add_boolean_prefix (added in Xapian 1.2) we
768 > can tell Xapian to use OR only for the search terms that are guaranteed to be
769 > unique.
770
771 This is great, I'd love to see this go into mainline.
772
773 Cheers,
774 Edward
775
776 From bwalton@artsci.utoronto.ca Wed Sep 29 20:56:53 2010
777 From: bwalton@artsci.utoronto.ca (Ben Walton)
778 Date: Wed, 29 Sep 2010 20:56:53 -0400
779 Subject: [sup-devel] [PATCH] add sendmail hook
780 In-Reply-To: <1285769580-15705-1-git-send-email-sascha-pgp@silbe.org>
781 References: <1285769580-15705-1-git-send-email-sascha-pgp@silbe.org>
782 Message-ID: <1285808187-sup-7819@pinkfloyd.chass.utoronto.ca>
783
784 Excerpts from Sascha Silbe's message of Wed Sep 29 10:13:00 -0400 2010:
785
786 > Add a hook that is run in place of the sendmail command. This allows
787 > last-minute adjustments including sending a separate copy to each
788 > recipient and setting the envelope sender, i.e. VERP (variable
789 > envelope return path).
790
791 +1 for this. The patch looks sane although I didn't actually test it.
792 -Ben
793
794 Thanks
795 -Ben
796 --
797 Ben Walton
798 Systems Programmer - CHASS
799 University of Toronto
800 C:416.407.5610 | W:416.978.4302
801
802
803 From ezyang@MIT.EDU Thu Sep 30 15:19:38 2010
804 From: ezyang@MIT.EDU (Edward Z. Yang)
805 Date: Thu, 30 Sep 2010 15:19:38 -0400
806 Subject: [sup-devel] Exception
807 Message-ID: <1285874266-sup-5868@ezyang>
808
809 I got the following exception
810
811 /home/ezyang/Dev/sup/lib/sup/index.rb:537:in `find_docid'
812 /home/ezyang/Dev/sup/lib/sup/index.rb:542:in `find_doc'
813 /home/ezyang/Dev/sup/lib/sup/index.rb:552:in `get_entry'
814 /home/ezyang/Dev/sup/lib/sup/index.rb:195:in `build_message'
815 /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
816 /home/ezyang/Dev/sup/lib/sup/index.rb:561:in `synchronize'
817 /home/ezyang/Dev/sup/lib/sup/index.rb:195:in `build_message'
818 /home/ezyang/Dev/sup/lib/sup/index.rb:150
819 /home/ezyang/Dev/sup/lib/sup/index.rb:230:in `call'
820 /home/ezyang/Dev/sup/lib/sup/index.rb:230:in `load_contacts'
821 /home/ezyang/Dev/sup/lib/sup/index.rb:150:in `each_id_by_date'
822 /home/ezyang/Dev/sup/lib/sup/index.rb:245:in `each_id'
823 /home/ezyang/Dev/sup/lib/sup/index.rb:245:in `each'
824 /home/ezyang/Dev/sup/lib/sup/index.rb:245:in `each_id'
825 /home/ezyang/Dev/sup/lib/sup/index.rb:150:in `each_id_by_date'
826 /home/ezyang/Dev/sup/lib/sup/index.rb:228:in `load_contacts'
827 /home/ezyang/Dev/sup/lib/sup/util.rb:596:in `send'
828 /home/ezyang/Dev/sup/lib/sup/util.rb:596:in `method_missing'
829 /home/ezyang/Dev/sup/lib/sup/buffer.rb:548:in `ask_for_contacts'
830 /home/ezyang/Dev/sup/lib/sup/util.rb:596:in `send'
831 /home/ezyang/Dev/sup/lib/sup/util.rb:596:in `method_missing'
832 /home/ezyang/Dev/sup/lib/sup/modes/compose-mode.rb:25:in `spawn_nicely'
833 /home/ezyang/Dev/sup/bin/sup:311
834
835 Caused by this failed assertion:
836
837 def find_docid id
838 docids = term_docids(mkterm(:msgid,id))
839 fail unless docids.size <= 1
840 docids.first
841 end
842
843 So I guess my index is corrupted in some weird way (probably I managed
844 to create two mails with the same docid). I've worked around it by commenting
845 out the assert, but any idea how to fix my index?
846
847 Edward
848