[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
sup-talk Digest, Vol 30, Issue 1
Send sup-talk mailing list submissions to
sup-talk@rubyforge.org
To subscribe or unsubscribe via the World Wide Web, visit
http://rubyforge.org/mailman/listinfo/sup-talk
or, via email, send a message with subject or body 'help' to
sup-talk-request@rubyforge.org
You can reach the person managing the list at
sup-talk-owner@rubyforge.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of sup-talk digest..."
Today's Topics:
1. Re: Saving status of merged threads with '#' on next branch
(William Morgan)
2. Re: Sup and Cygwin (Mark Alexander)
3. Re: Sup and Cygwin (William Morgan)
4. Re: Read only mode for sup (Nicolas Pouillard)
5. Re: brief master update (Nicolas Pouillard)
6. Re: brief master update (William Morgan)
7. Re: Read only mode for sup (William Morgan)
8. Display size of message or attachments? (Lee Hinman)
9. Re: Display size of message or attachments? (William Morgan)
10. Re: Display size of message or attachments? (Lee Hinman)
11. Suggestion for '.' keybinding (Lee Hinman)
12. Re: Display size of message or attachments? (William Morgan)
13. Sup with Microsoft Exchange 2007 (Bryan Richardson)
14. sup crashes when starting, here is the exception-log
(Sean Escriva)
15. Re: Display size of message or attachments? (Iain)
16. Re: Saving status of merged threads with '#' on next branch
(Bjorn Michelsen)
17. Re: Lost Maildir Messages (Iain)
18. Re: Saving status of merged threads with '#' on next branch
(William Morgan)
19. Re: Lost Maildir Messages (Mark Alexander)
20. Re: Saving status of merged threads with '#' on next branch
(Bjorn Michelsen)
21. Re: Suggestion for '.' keybinding (Nicolas Pouillard)
22. Possible problem with maildir ID generation (Mark Alexander)
23. Two questions (Reid Thompson)
24. Re: Sup with Microsoft Exchange 2007 (Bryan Richardson)
25. Re: Sup with Microsoft Exchange 2007 (Mark Alexander)
26. Re: Sup with Microsoft Exchange 2007 (Bryan Richardson)
27. Re: Sup with Microsoft Exchange 2007 (William Morgan)
28. Re: Two questions (William Morgan)
29. Re: Two questions (Reid Thompson)
30. Re: Saving status of merged threads with '#' on next branch
(William Morgan)
31. Re: Sup with Microsoft Exchange 2007 (Bryan Richardson)
32. Re: Sup with Microsoft Exchange 2007 (Andrew Pimlott)
33. Re: Possible problem with maildir ID generation (William Morgan)
34. Re: Sup with Microsoft Exchange 2007 (William Morgan)
35. Re: Two questions (William Morgan)
36. Re: Sup with Microsoft Exchange 2007 (Bryan Richardson)
37. Re: Sup with Microsoft Exchange 2007 (Bryan Richardson)
38. Re: Sup with Microsoft Exchange 2007 (Bryan Richardson)
39. Re: Sup with Microsoft Exchange 2007 (Ben Walton)
40. Re: Possible problem with maildir ID generation (Mark Alexander)
41. [PATCH] Bug fixes and speed improvements for maildir
handling. (Mark Alexander)
42. Re: [PATCH] Bug fixes and speed improvements for maildir
handling. (Mark Alexander)
43. Re: Two questions (Reid Thompson)
44. IMAP folder/label integration and playing better with changed
sources? (Saku Ytti)
45. Re: sup crashes when starting, here is the exception-log
(William Morgan)
46. Re: Suggestion for '.' keybinding (William Morgan)
47. Re: Two questions (William Morgan)
48. First time user of sup; some questions (Edward Z. Yang)
49. Re: First time user of sup; some questions (Edward Z. Yang)
50. Re: First time user of sup; some questions (William Morgan)
51. Re: First time user of sup; some questions (Edward Z. Yang)
52. GSoC Project of Interest (Jon Dugan)
53. mime-view hook (Jon Dugan)
54. Re: mime-view hook (William Morgan)
55. Re: GSoC Project of Interest (William Morgan)
56. Re: mime-view hook (Andrew Pimlott)
57. Re: mime-view hook (Jon Dugan)
58. Re: mime-view hook (Andrew Pimlott)
59. Exception (Edward Z. Yang)
60. message add speedup (William Morgan)
61. scary exception (John Bent)
62. Re: scary exception (William Morgan)
63. Re: scary exception (John Bent)
64. redo ideas (Mike S)
65. Re: scary exception (William Morgan)
66. Re: IMAP folder/label integration and playing better with
changed sources? (William Morgan)
67. Re: redo ideas (Nicolas Pouillard)
68. UTF-8 message sending patch (Helge Titlestad)
69. New to Sup and some imap sync questions (Christopher Bertels)
70. Re: Possible problem with maildir ID generation (Marc Hartstein)
71. Inconsistent inbox after restart (Steve Goldman)
72. Re: Possible problem with maildir ID generation (Mark Alexander)
73. Re: Inconsistent inbox after restart (Nicolas Pouillard)
74. Re: Inconsistent inbox after restart (Tyberius Prime)
75. Re: Inconsistent inbox after restart (Tyberius Prime)
76. Re: New to Sup and some imap sync questions (Edward Z. Yang)
77. possible mbox "initial From" fix (William Morgan)
78. Re: New to Sup and some imap sync questions (William Morgan)
79. Re: Inconsistent inbox after restart (William Morgan)
80. Re: redo ideas (William Morgan)
81. Re: New to Sup and some imap sync questions (Edward Z. Yang)
82. Re: New to Sup and some imap sync questions (William Morgan)
83. Re: New to Sup and some imap sync questions (Christopher Bertels)
84. Re: New to Sup and some imap sync questions (William Morgan)
85. Re: Possible problem with maildir ID generation (William Morgan)
86. Re: UTF-8 message sending patch (William Morgan)
87. Re: Possible problem with maildir ID generation (William Morgan)
88. Re: Sup with Microsoft Exchange 2007 (William Morgan)
89. Re: Possible problem with maildir ID generation (Marc Hartstein)
90. Re: Possible problem with maildir ID generation (Marc Hartstein)
91. Re: possible mbox "initial From" fix (Bart Schaefer)
92. Re: Inconsistent inbox after restart (Tyberius Prime)
93. Re: Inconsistent inbox after restart (Steve Goldman)
94. Re: Inconsistent inbox after restart (Ben Walton)
95. Re: Inconsistent inbox after restart (William Morgan)
96. Re: Inconsistent inbox after restart (William Morgan)
97. Re: Sup with Microsoft Exchange 2007 (Ben Walton)
98. Re: Inconsistent inbox after restart (Steve Goldman)
99. [PATCH] Keymap: make new + (apply to tagged) behaviour nicer
(Ben Walton)
100. [PATCH] Keymap: make new + (apply to tagged) behaviour nicer
(Ben Walton)
101. Re: Inconsistent inbox after restart (Steve Goldman)
102. Re: Sup with Microsoft Exchange 2007 (William Morgan)
103. Re: Inconsistent inbox after restart (William Morgan)
104. Re: Sup with Microsoft Exchange 2007 (Ben Walton)
105. Re: Inconsistent inbox after restart (Steve Goldman)
106. Re: [PATCH] Keymap: make new + (apply to tagged) behaviour
nicer (William Morgan)
107. Re: [PATCH] Bug fixes and speed improvements for maildir
handling. (William Morgan)
108. Re: possible mbox "initial From" fix (William Morgan)
109. [PATCH] Keymap: improve behaviour of apply to tagged in
thread index (Ben Walton)
110. Re: [PATCH] Keymap: improve behaviour of apply to tagged in
thread index (William Morgan)
111. Re: Possible problem with maildir ID generation (William Morgan)
112. Re: Sup with Microsoft Exchange 2007 (William Morgan)
113. Re: Possible problem with maildir ID generation (Marc Hartstein)
114. Re: Possible problem with maildir ID generation (Mark Alexander)
115. sent source (Ben Walton)
116. flexible sent (wip) (Ben Walton)
117. IMAP questions (n00b) :) (Filip Stokkeland)
118. /usr/bin/run-mailcap (Filip Stokkeland)
119. Re: /usr/bin/run-mailcap (Marc Hartstein)
120. Re: /usr/bin/run-mailcap (William Morgan)
121. Re: sent source (William Morgan)
122. Re: IMAP questions (n00b) :) (William Morgan)
123. Re: /usr/bin/run-mailcap (Mark Alexander)
124. Re: /usr/bin/run-mailcap (Ben Walton)
125. Re: sent source (Ben Walton)
126. flexible sent source (update) (Ben Walton)
127. sup-sync dies; memory limit? (Andrew Pimlott)
128. Re: sent source (Ben Walton)
129. Re: sent source (William Morgan)
130. Re: sup-sync dies; memory limit? (Andrew Pimlott)
131. Re: sup-sync dies; memory limit? (William Morgan)
132. Re: sup-sync dies; memory limit? (Andrew Pimlott)
133. Re: sup-sync dies; memory limit? (William Morgan)
134. sup crash when doing search (Damon Conway)
135. inconsistencies and new user confusion (Andrew Pimlott)
136. Re: inconsistencies and new user confusion (Marc Hartstein)
137. Re: inconsistencies and new user confusion (Edward Z. Yang)
138. Re: sup crash when doing search (Marcus Williams)
139. Re: sup crash when doing search (Marcus Williams)
140. [PATCH] limit option parser nil check (Marcus Williams)
141. [PATCH] Chronic context fix (Marcus Williams)
142. Re: sup crash when doing search (Marcus Williams)
143. Notification tools (Henri Ducrocq)
144. Re: inconsistencies and new user confusion (Andrew Pimlott)
145. Strange problem in before-edit hook (Marcus Williams)
146. Re: flexible sent source (update) (William Morgan)
147. Re: flexible sent source (update) (Ben Walton)
148. Re: Notification tools (William Morgan)
149. Re: flexible sent source (update) (William Morgan)
150. "interning empty string" from sup-sync (Marc Hartstein)
151. Re: "interning empty string" from sup-sync (William Morgan)
152. Re: "interning empty string" from sup-sync (Marc Hartstein)
153. Re: Notification tools (Henri Ducrocq)
154. Re: Notification tools (Marc Hartstein)
155. Re: Notification tools (William Morgan)
156. Re: Notification tools (Marc Hartstein)
157. Re: Notification tools (Marcus Williams)
158. Re: Notification tools (Nicolas Pouillard)
159. Re: Notification tools (Marc Hartstein)
160. gmail login (Maurice McCarthy)
161. Re: gmail login (Ben Walton)
162. Re: Notification tools (David Guibert)
163. Re: Notification tools (Henri Ducrocq)
164. [PATCH] chmod a+x bin/* (Kirill Smelkov)
165. Re: [PATCH] chmod a+x bin/* (Ben Walton)
166. Re: Notification tools (Henri Ducrocq)
167. merge activity report (William Morgan)
168. Re: [PATCH] chmod a+x bin/* (William Morgan)
169. Re: [PATCH] Chronic context fix (William Morgan)
170. Re: merge activity report (Ben Walton)
171. Re: merge activity report (William Morgan)
172. Re: [PATCH] limit option parser nil check (William Morgan)
173. Re: Notification tools (William Morgan)
174. Re: Notification tools (William Morgan)
175. Re: inconsistencies and new user confusion (William Morgan)
176. Re: inconsistencies and new user confusion (William Morgan)
177. Re: Notification tools (Marc Hartstein)
178. Re: Notification tools (Henri Ducrocq)
179. Strange random changing of default colors (Mark Alexander)
180. Re: Strange random changing of default colors (Marc Hartstein)
181. Re: Strange random changing of default colors (Mark Alexander)
182. Re: Strange random changing of default colors (William Morgan)
183. Handling window resizing (Henri Ducrocq)
184. Re: Handling window resizing (Henri Ducrocq)
185. Re: inconsistencies and new user confusion (Andrew Pimlott)
186. Re: Handling window resizing (William Morgan)
187. Re: inconsistencies and new user confusion (William Morgan)
188. mailing list alias (John Bent)
189. Re: Strange random changing of default colors (Mark Alexander)
190. [PATCH] Use terminal width instead of hardcoded 80 as the
wrap length. (Mark Alexander)
191. [PATCH] Put labels before subject in thread index view.
(Mark Alexander)
192. Re: [PATCH] Put labels before subject in thread index view.
(Ben Walton)
193. Re: [PATCH] Use terminal width instead of hardcoded 80 as
the wrap length. (Ben Walton)
194. Re: [PATCH] Use terminal width instead of hardcoded 80 as
the wrap length. (Michael Stipicevic)
195. Re: [PATCH] Put labels before subject in thread index view.
(Nicolas Pouillard)
196. Multiple email accounts (Edward Z. Yang)
197. Re: Multiple email accounts (Iain)
198. Re: [PATCH] Use terminal width instead of hardcoded 80 as
the wrap length. (Ben Walton)
199. Re: [PATCH] Put labels before subject in thread index view.
(Marc Hartstein)
200. Re: scary exception (John Bent)
201. Re: [PATCH] Put labels before subject in thread index view.
(Henri Ducrocq)
202. Getting gpg to work (Micah Anderson)
203. Re: Multiple email accounts (Edward Z. Yang)
204. [PATCH] New hook: after-save (Henri Ducrocq)
205. Re: mailing list alias (William Morgan)
206. Re: [PATCH] Use terminal width instead of hardcoded 80 as
the wrap length. (William Morgan)
207. Re: scary exception (William Morgan)
208. Re: [PATCH] Use terminal width instead of hardcoded 80 as
the wrap length. (Ben Walton)
209. Re: [PATCH] Put labels before subject in thread index view.
(William Morgan)
210. Re: [PATCH] Use terminal width instead of hardcoded 80 as
the wrap length. (Mark Alexander)
211. Re: Multiple email accounts (William Morgan)
212. Arg, gmail (Guillaume Quintard)
213. Re: Getting gpg to work (William Morgan)
214. Re: Arg, gmail (William Morgan)
215. Re: Arg, gmail (Iain)
216. Re: Arg, gmail (Guillaume Quintard)
217. Re: Arg, gmail (Iain)
218. Re: Arg, gmail (Nicolas Pouillard)
219. Re: Arg, gmail (Mark Alexander)
220. Re: [PATCH] Use terminal width instead of hardcoded 80 as
the wrap length. (Nicolas Pouillard)
221. Re: Arg, gmail (Guillaume Quintard)
222. Re: Multiple email accounts (Marcus Williams)
223. sup bombs out attempting to access ssh+mbox (Sean Escriva)
224. oops, previous sup exception log (Sean Escriva)
225. Re: [PATCH] New hook: after-save (William Morgan)
226. Re: UTF-8 message sending patch (William Morgan)
227. Re: merge activity report (William Morgan)
228. pending 0.8 release (William Morgan)
229. Re: merge activity report (Ben Walton)
230. Re: merge activity report (William Morgan)
231. [PATCH] Use rake/packagegemtask (Ingmar Vanhassel)
232. Re: [PATCH] Use rake/packagegemtask (Ingmar Vanhassel)
233. utf patch needs work, i think (Ben Walton)
234. Re: utf patch needs work, i think (Ben Walton)
235. Re: Getting gpg to work (Micah Anderson)
236. [PATCH] Prettier printing of enclosed messages (Israel Herraiz)
237. Re: [PATCH] Fixing a couple of warnings (was Prettier
printing of enclosed messages) (Israel Herraiz)
238. [PATCH] Prettier printing of enclosed messages (Israel Herraiz)
239. Re: Getting gpg to work (William Morgan)
240. Re: utf patch needs work, i think (William Morgan)
241. Re: [PATCH] Use rake/packagegemtask (William Morgan)
242. [RFC] Bounce messages (Ben Walton)
243. (no subject) (Ben Walton)
244. Re: (no subject) (Ben Walton)
245. Re: (no subject) (Ben Walton)
246. Attempt at reply-from hook (Edward Z. Yang)
247. Need help with OfflineIMAP integration and Iconv errors
(Dominic LoBue)
248. Re: utf patch needs work, i think (William Morgan)
249. [PATCH] Handle nil charset on attachments. (Mark Alexander)
250. Re: [PATCH] Handle nil charset on attachments. (William Morgan)
251. Re: Attempt at reply-from hook (Ingmar Vanhassel)
252. Re: Attempt at reply-from hook (Edward Z. Yang)
253. Re: Attempt at reply-from hook (Ben Walton)
254. Sup is hanging (Edward Z. Yang)
255. Re: Sup is hanging (William Morgan)
256. Re: Sup is hanging (Edward Z. Yang)
257. Re: Sup is hanging (Edward Z. Yang)
258. Re: Sup is hanging (Edward Z. Yang)
259. Re: Sup is hanging (William Morgan)
260. Re: Sup is hanging (Edward Z. Yang)
261. Re: Sup is hangingy (Edward Z. Yang)
262. Re: Sup is hangingy (Edward Z. Yang)
263. Re: Sup is hangingyy (Edward Z. Yang)
264. Re: (no subject) (Ross Macduff)
265. Re: Sup is hanging (William Morgan)
266. Re: Sup is hangingy (William Morgan)
267. Re: Sup is hangingy (William Morgan)
268. Re: Need help with OfflineIMAP integration and Iconv errors
(William Morgan)
269. [PATCH] Add V to view a raw message (headers and body).
(Ben Walton)
270. Re: Sup is hanging (William Morgan)
271. Toggle expand/collapse of a message in threadview
(Christopher Bertels)
272. Re: Toggle expand/collapse of a message in threadview
(William Morgan)
273. Re: Sup is hanging (Edward Z. Yang)
274. Re: Attempt at reply-from hook (Edward Z. Yang)
275. Re: [PATCH] Add V to view a raw message (headers and body).
(Nicolas Pouillard)
276. Re: Toggle expand/collapse of a message in threadview
(Christopher Bertels)
277. Re: Toggle expand/collapse of a message in threadview
(Christopher Bertels)
278. Re: Toggle expand/collapse of a message in threadview
(Christopher Bertels)
279. Re: [PATCH] Add V to view a raw message (headers and body).
(Ben Walton)
280. sup crash while attempting to load next email after deleting
previous (Dominic LoBue)
281. Re: Sup is hanging (William Morgan)
282. Re: Attempt at reply-from hook (William Morgan)
283. Re: [PATCH] Add V to view a raw message (headers and body).
(William Morgan)
284. Re: Toggle expand/collapse of a message in threadview
(William Morgan)
285. Re: [PATCH] Prettier printing of enclosed messages
(William Morgan)
286. Re: [RFC] Bounce messages (William Morgan)
287. Re: [RFC] Bounce messages (Ben Walton)
288. Re: Sup is hanging (Marc Hartstein)
289. [ANN] Sup 0.8 released (William Morgan)
290. Re: Sup is hanging (Edward Z. Yang)
291. Re: Attempt at reply-from hook (Edward Z. Yang)
292. Re: Sup is hanging (Edward Z. Yang)
293. Sup annoyances (Edward Z. Yang)
294. Re: Sup annoyances (Edward Z. Yang)
295. Re: [RFC] Bounce messages (Nicolas Pouillard)
296. Re: [RFC] Bounce messages (Ben Walton)
297. Re: [RFC] Bounce messages (Nicolas Pouillard)
298. Re: [RFC] Bounce messages (Helge Titlestad)
299. Re: Sup is hanging (Marc Hartstein)
300. Re: Sup annoyances (Marc Hartstein)
301. Re: Sup is hanging (Marc Hartstein)
302. Re: Sup annoyances (Edward Z. Yang)
303. Re: sup/gpg (Ben Walton)
304. Re: [PATCH] Use terminal width instead of hardcoded 80 as
the wrap length. (Ingmar Vanhassel)
305. exception with undomanager (Ben Walton)
306. Re: [PATCH] Use terminal width instead of hardcoded 80 as
the wrap length. (Marc Hartstein)
307. crash with .8 on save ($) (David L.Kaplan)
308. (no subject) (Ben Walton)
309. [PATCH 1/2] Add message bouncing capability (Ben Walton)
310. [PATCH 2/2] Bounce Message Hook (Ben Walton)
311. Fwd: [REQUEST] reply-to-list (Andrei Thorp)
312. Re: Fwd: [REQUEST] reply-to-list (Ben Walton)
313. Can't seem to send mail (Joe W?lfel)
314. Re: Can't seem to send mail (Andrei Thorp)
315. Re: Can't seem to send mail (Ben Walton)
316. Re: exception with undomanager (William Morgan)
317. Re: sup/gpg (William Morgan)
318. Re: sup/gpg (Marc Hartstein)
319. Re: Sup annoyances (William Morgan)
320. Re: Sup is hanging (William Morgan)
321. Re: Can't seem to send mail (Joe W?lfel)
322. Re: exception with undomanager (Edward Z. Yang)
323. Re: sup/gpg (William Morgan)
324. Re: Can't seem to send mail (Andrei Thorp)
325. Re: Can't seem to send mail (Ben Walton)
326. Re: exception with undomanager (Ben Walton)
327. Re: exception with undomanager (William Morgan)
328. Re: exception with undomanager (Edward Z. Yang)
329. Re: exception with undomanager (Ben Walton)
330. Re: Can't seem to send mail (Joe W?lfel)
331. Re: Can't seem to send mail (Andrei Thorp)
332. Re: Attempt at reply-from hook (William Morgan)
333. Re: Attempt at reply-from hook (Edward Z. Yang)
334. Re: Attempt at reply-from hook (Marc Hartstein)
335. Re: Sup annoyances (Edward Z. Yang)
336. Re: Sup annoyances (William Morgan)
337. Re: Attempt at reply-from hook (Edward Z. Yang)
338. Gmail Labels Sidebar (Andrei Thorp)
339. Re: Gmail Labels Sidebar (Ben Walton)
340. Re: Sup annoyances (Edward Z. Yang)
341. Re: Gmail Labels Sidebar (Edward Z. Yang)
342. Re: Sup annoyances (Edward Z. Yang)
343. Re: Gmail Labels Sidebar (Ben Walton)
344. Re: Sup annoyances (Edward Z. Yang)
345. Re: Sup annoyances (Edward Z. Yang)
346. Re: Sup annoyances (Edward Z. Yang)
347. Re: Attempt at reply-from hook (Marc Hartstein)
348. Re: Attempt at reply-from hook (Edward Z. Yang)
349. display_length issue with special-characters on non-UTF8
terminal (Tarko Tikan)
350. Re: Gmail Labels Sidebar (Andrei Thorp)
351. Re: Gmail Labels Sidebar (Andrei Thorp)
352. Re: Gmail Labels Sidebar (Marcus Williams)
353. Re: Gmail Labels Sidebar (Marcus Williams)
354. Re: Gmail Labels Sidebar (Marcus Williams)
355. Fwd: Gmail Labels Sidebar (Andrei Thorp)
356. Re: Attempt at reply-from hook (William Morgan)
357. Re: Sup annoyances (William Morgan)
358. Re: Sup annoyances (William Morgan)
359. Re: Sup annoyances (William Morgan)
360. Re: Sup annoyances (William Morgan)
361. lockmanager (Ben Walton)
362. [PATCH] before-search hook (Edward Z. Yang)
363. sup -c while sup is running? (Marc Hartstein)
364. IMAP alternative for Sup? (Joe W?lfel)
365. Re: IMAP alternative for Sup? (Edward Z. Yang)
366. IMAP alternative works well with sup? (Joe W?lfel)
367. sup and ncursesw (J?rg-Hendrik Bach)
368. Re: [PATCH] before-search hook (Edward Z. Yang)
369. Re: Sup annoyances (Edward Z. Yang)
370. Re: Sup annoyances (Edward Z. Yang)
371. Re: Attempt at reply-from hook (Edward Z. Yang)
372. Sup locking up (Marcus Williams)
373. Re: Sup locking up (Ben Walton)
374. Re: Crash after sending a message (Fabio Riga)
375. [BUG?] label-list-mode doesn't update (Andrei Thorp)
376. Re: Sup locking up (Marcus Williams)
377. Re: Sup locking up (Ben Walton)
378. Re: Sup locking up (Andrei Thorp)
379. Re: Sup locking up (Marcus Williams)
380. Re: (no subject) (Ben Walton)
381. Crash after sending a message (Fabio Riga)
382. Re: (no subject) (William Morgan)
383. Re: Sup locking up (Edward Z. Yang)
384. Re: (no subject) (Ben Walton)
385. Re: IMAP alternative for Sup? (Joe W?lfel)
386. Re: IMAP alternative for Sup? (Edward Z. Yang)
387. Re: IMAP alternative for Sup? (Ben Walton)
388. Re: (no subject) (William Morgan)
389. Re: Gmail Labels Sidebar (William Morgan)
390. Re: Gmail Labels Sidebar (Andrei Thorp)
391. Re: Gmail Labels Sidebar (William Morgan)
392. Re: Gmail Labels Sidebar (William Morgan)
393. Re: display_length issue with special-characters on non-UTF8
terminal (William Morgan)
394. Re: [PATCH] Use terminal width instead of hardcoded 80 as
the wrap length. (William Morgan)
395. [PATCH] fixes for ruby1.9 (Rich Lane)
396. Re: sup -c while sup is running? (William Morgan)
397. Re: sup and ncursesw (William Morgan)
398. Re: Gmail Labels Sidebar (Marcus Williams)
399. [PATCH] Minimalist view (Marcus Williams)
400. Transitioning to OfflineIMAP (Nicholas Bergson-Shilcock)
401. Re: Transitioning to OfflineIMAP (William Morgan)
402. Re: display_length issue with special-characters on non-UTF8
terminal (Tarko Tikan)
403. Re: sup and ncursesw (J?rg-Hendrik Bach)
404. Sup won't save state (Arvid Picciani)
405. Re: Sup won't save state (Marc Hartstein)
406. Re: [PATCH] Minimalist view (Ben Walton)
407. Re: [PATCH] Minimalist view (Marcus Williams)
408. Re: Sup won't save state (Arvid Picciani)
409. Wrong messages in thread (Arvid Picciani)
410. Re: Wrong messages in thread (Edward Z. Yang)
411. Re: Sup won't save state (Andrei Thorp)
412. Re: Wrong messages in thread (Nicolas Pouillard)
413. Re: Wrong messages in thread (William Morgan)
414. Re: Sup won't save state (William Morgan)
415. Re: Sup won't save state (William Morgan)
416. Re: [PATCH] Minimalist view (William Morgan)
417. Re: [PATCH] Minimalist view (Ben Walton)
418. Re: sup and ncursesw (William Morgan)
419. Re: display_length issue with special-characters on non-UTF8
terminal (William Morgan)
420. Re: Sup won't save state (Andrei Thorp)
421. Re: [PATCH] fixes for ruby1.9 (William Morgan)
422. Re: Crash after sending a message (William Morgan)
423. Re: lockmanager (William Morgan)
424. Re: lockmanager (Ben Walton)
425. Re: [PATCH] before-search hook (William Morgan)
426. Re: lockmanager (William Morgan)
427. [BUG] Sup Overload (Andrei Thorp)
428. [BUG] Can't handle spaces in paths (Andrei Thorp)
429. Re: [BUG] Can't handle spaces in paths (Guillaume Quintard)
430. Re: [BUG] Can't handle spaces in paths (Andrei Thorp)
431. Re: Crash after sending a message (Guillaume Quintard)
432. Re: Crash after sending a message (William Morgan)
433. Re: [BUG] Can't handle spaces in paths (William Morgan)
434. Yet Another Offlineimap Thread (YAOT) (Andrei Thorp)
435. Re: Crash after sending a message (Guillaume Quintard)
436. [BUG] Sup Overload (Andrei Thorp)
437. Re: Crash after sending a message (William Morgan)
438. Re: Crash after sending a message (Guillaume Quintard)
439. Re: Crash after sending a message (Ben Walton)
440. Re: Crash after sending a message (Guillaume Quintard)
441. [PATCH] Alternative View (Marcus Williams)
442. Re: [PATCH] Minimalist view (Marcus Williams)
443. Re: Crash after sending a message (Ben Walton)
444. [PATCH] index: cleanup interface (Rich Lane)
445. [PATCH] index: consistent naming (Rich Lane)
446. Re: Yet Another Offlineimap Thread (YAOT) (Andrei Thorp)
447. Re: Yet Another Offlineimap Thread (YAOT) (Ingmar Vanhassel)
448. Fwd: Yet Another Offlineimap Thread (YAOT) (Andrei Thorp)
449. Re: display_length issue with special-characters on non-UTF8
terminal (William Morgan)
450. Re: sup and ncursesw (William Morgan)
451. Re: Yet Another Offlineimap Thread (YAOT) (Andrei Thorp)
452. Re: Yet Another Offlineimap Thread (YAOT) (Andrei Thorp)
453. Re: display_length issue with special-characters on non-UTF8
terminal (Nicolas Pouillard)
454. Character encoding when displaying quoted-printable messages
(Jim Cheetham)
455. Re: Crash after sending a message (Fabio Riga)
456. Re: sup and ncursesw (J?rg-Hendrik Bach)
457. invalid source error (Mariano Mara)
458. Re: invalid source error (Mariano Mara)
459. Carriage return (Guillaume Quintard)
460. Delete single message in thread-view? (Christopher Bertels)
461. Re: Carriage return (Andrei Thorp)
462. [PATCH] Hack that fixes "undefined method multipart?"
exception. (Joe W?lfel)
463. [PATCH 0/18] Xapian-based index (Rich Lane)
464. [PATCH 01/18] remove load_entry_for_id call in
sup-recover-sources (Rich Lane)
465. [PATCH 02/18] remove load_entry_for_id call in
DraftManager.discard (Rich Lane)
466. [PATCH 03/18] remove ferret entry from poll/sync interface
(Rich Lane)
467. [PATCH 04/18] index: remove unused method load_entry_for_id
(Rich Lane)
468. [PATCH 05/18] switch DraftManager to use
Message.build_from_source (Rich Lane)
469. [PATCH 07/18] move source-related methods to SourceManager
(Rich Lane)
470. [PATCH 06/18] index: move has_any_from_source_with_label? to
sup-sync-back (Rich Lane)
471. [PATCH 08/18] index: remove unused method fresh_thread_id
(Rich Lane)
472. [PATCH 10/18] index: make wrap_subj methods private (Rich Lane)
473. [PATCH 11/18] index: move Ferret-specific code to
ferret_index.rb (Rich Lane)
474. [PATCH 12/18] remove last external uses of ferret docid
(Rich Lane)
475. [PATCH 09/18] index: revert overeager opts->query rename in
each_message_in_thread_for (Rich Lane)
476. [PATCH 14/18] index: choose index implementation with config
entry or environment variable (Rich Lane)
477. [PATCH 13/18] add Message.indexable_{body, chunks, subject}
(Rich Lane)
478. [PATCH 15/18] index: add xapian implementation (Rich Lane)
479. [PATCH 17/18] add limit argument to
author_names_and_newness_for_thread (Rich Lane)
480. [PATCH 16/18] fix String#ord monkeypatch (Rich Lane)
481. [PATCH 18/18] dont using SavingHash#[] for membership test
(Rich Lane)
482. Re: [PATCH 18/18] dont using SavingHash#[] for membership
test (Andrei Thorp)
483. Re: [PATCH 0/18] Xapian-based index (William Morgan)
484. Re: [PATCH 0/18] Xapian-based index (William Morgan)
485. Re: [PATCH 0/18] Xapian-based index (Olly Betts)
486. Re: [PATCH 0/18] Xapian-based index (William Morgan)
487. Re: [PATCH] before-search hook (Edward Z. Yang)
488. Re: Transitioning to OfflineIMAP (Nicholas Bergson-Shilcock)
489. Re: Character encoding when displaying quoted-printable
messages (Jim Cheetham)
490. ncurses-ruby-1.2.3 + ncursesw hack breaks search
(Ingmar Vanhassel)
491. Sup crash when adding CC to forwarded message (Helge Titlestad)
492. sent_source - singular or per-account? (Jim Cheetham)
493. Re: ncurses-ruby-1.2.3 + ncursesw hack breaks search
(William Morgan)
494. Re: ncurses-ruby-1.2.3 + ncursesw hack breaks search
(Jörg-Hendrik Bach)
495. Sup on Ruby-1.9 (Ingmar Vanhassel)
496. Re: Sup on Ruby-1.9 (William Morgan)
497. Re: Sup crash when adding CC to forwarded message
(William Morgan)
498. Re: Delete single message in thread-view? (William Morgan)
499. Re: Sup crash when adding CC to forwarded message
(Helge Titlestad)
500. Re: Sup crash when adding CC to forwarded message
(William Morgan)
501. Re: Sup on Ruby-1.9 (William Morgan)
502. Re: sent_source - singular or per-account? (Ben Walton)
503. Reconnect command (Andrea Fazzi)
504. Re: sent_source - singular or per-account? (Jim Cheetham)
505. Re: sent_source - singular or per-account? (Ben Walton)
506. Re: sent_source - singular or per-account? (Jim Cheetham)
507. Re: sent_source - singular or per-account? (Ben Walton)
508. Sup doesn't respect Reply-To header (Edward Z. Yang)
509. colour customisation (J?rg-Hendrik Bach)
510. Re: colour customisation (Andrei Thorp)
511. Re: sup (William Morgan)
512. Re: colour customisation (William Morgan)
513. Re: colour customisation (J?rg-Hendrik Bach)
514. Re: colour customisation (Andrei Thorp)
515. sup 0.8.1 crash (Jonathan Lassoff)
516. Backups ? (Marc Weber)
517. Re: Backups ? (wagnerdm@seas.upenn.edu)
518. Re: Backups ? (Ben Walton)
519. Re: Backups ? (Ingmar Vanhassel)
520. Exception Log (Iain)
521. [PATCH] Use /etc/mailname if present to determine the
hostname for Message-Id (Adeodato Sim?)
522. sup opens multiple connections to the same imap-server
(Michael Stapelberg)
523. Using sup on multiple computers? (Michael Stapelberg)
524. Re: Using sup on multiple computers? (Edward Z. Yang)
525. Re: Using sup on multiple computers? (Jonathan Lassoff)
526. Re: Using sup on multiple computers? (Michael Stapelberg)
527. Re: Using sup on multiple computers? (Andrei Thorp)
528. [PATCH] mime-decode hook: provide a "charset" variable with
the attachment charset (Adeodato Sim?)
529. Validating GPG keys in parallel and in background
(Michael Stapelberg)
530. [PATCH] Unbreak "bounce-command" hook (was referencing an
nonexistent variable) (Adeodato Sim?)
531. Re: sup opens multiple connections to the same imap-server
(Ben Walton)
532. Re: [PATCH] Unbreak "bounce-command" hook (was referencing
an nonexistent variable) (Ben Walton)
533. Re: sup opens multiple connections to the same imap-server
(Michael Stapelberg)
534. Adding/saving multiple attachments? (Michael Stapelberg)
535. Invalid character on import (Nico Schottelius)
536. Slow import of messages (Nico Schottelius)
537. Re: Slow import of messages (Michael Stapelberg)
538. Re: Invalid character on import (Nicolas Pouillard)
539. Re: Slow import of messages (Jim Cheetham)
540. problems with Maildir and IMAP offline (Luis Ca?as D?az)
541. Re: problems with Maildir and IMAP offline (Andrei Thorp)
542. Re: problems with Maildir and IMAP offline (Andrei Thorp)
543. Re: problems with Maildir and IMAP offline (Tim Gray)
544. Re: problems with Maildir and IMAP offline (Ben Walton)
545. Re: problems with Maildir and IMAP offline (Andrei Thorp)
546. Re: problems with Maildir and IMAP offline (Tim Gray)
547. Re: problems with Maildir and IMAP offline (Andrei Thorp)
548. Re: problems with Maildir and IMAP offline (Tim Gray)
549. Re: problems with Maildir and IMAP offline (Tim Gray)
550. Re: problems with Maildir and IMAP offline (Israel Herraiz)
551. Re: Using sup on multiple computers? (John Bent)
552. Re: Using sup on multiple computers? (Ben Walton)
553. Re: Using sup on multiple computers? (Michael Stapelberg)
554. Re: [PATCH 0/18] Xapian-based index (Richard Heycock)
555. trying out sup ... (lee)
556. [PATCH] GSSAPI support for net/imap.rb and sup
(Michael Stapelberg)
557. Choose "From:" address based on message content? (Steve Goldman)
558. Re: Choose "From:" address based on message content?
(Steve Goldman)
559. Re: [PATCH] mime-decode hook: provide a "charset" variable
with the attachment charset (Adeodato Sim?)
560. Re: [PATCH 0/18] Xapian-based index (Adeodato Sim?)
561. [RFC] Fix parsing of encrypted messages that contain further
multipart elements (Adeodato Sim?)
562. [PATCH] Fix parsing of encrypted messages that contain
further multipart elements (Adeodato Sim?)
563. Exception (Marc Weber)
564. [PATCH] xapian: initialize sources in sup-dump (Rich Lane)
565. [PATCH] xapian: fix mk_addrs args in build_message (Rich Lane)
566. Re: [PATCH 0/18] Xapian-based index (Rich Lane)
567. Re: [PATCH 0/18] Xapian-based index (Adeodato Sim?)
568. Reply calculation (Edward Z. Yang)
569. Re: Reply calculation (Edward Z. Yang)
570. Re: Reply calculation (Edward Z. Yang)
571. Re: Reply calculation (Edward Z. Yang)
572. [PATCH] xapian: dont exclude spam/etc in some internal
searches (Rich Lane)
573. Re: [PATCH 0/18] Xapian-based index (Rich Lane)
574. Re: [PATCH 0/18] Xapian-based index (Ingmar Vanhassel)
575. Re: [PATCH 0/18] Xapian-based index (William Morgan)
576. Re: [PATCH 0/18] Xapian-based index (William Morgan)
577. xapian merged into next (William Morgan)
578. Re: [PATCH] xapian: dont exclude spam/etc in some internal
searches (William Morgan)
579. Re: [PATCH] xapian: fix mk_addrs args in build_message
(William Morgan)
580. Re: [PATCH] xapian: initialize sources in sup-dump
(William Morgan)
581. Re: [PATCH] Unbreak "bounce-command" hook (was referencing
an nonexistent variable) (William Morgan)
582. Re: xapian merged into next (Guillaume Quintard)
583. Re: [PATCH] Unbreak "bounce-command" hook (was referencing
an nonexistent variable) (Ben Walton)
584. Re: xapian merged into next (William Morgan)
585. Re: [PATCH] Unbreak "bounce-command" hook (was referencing
an nonexistent variable) (William Morgan)
586. Re: [PATCH] Unbreak "bounce-command" hook (was referencing
an nonexistent variable) (Ben Walton)
587. Re: [PATCH] Unbreak "bounce-command" hook (was referencing
an nonexistent variable) (William Morgan)
588. Re: xapian merged into next (Guillaume Quintard)
589. Re: Exception (William Morgan)
590. Re: xapian merged into next (William Morgan)
591. Re: [PATCH] Unbreak "bounce-command" hook (was referencing
an nonexistent variable) (William Morgan)
592. Re: xapian merged into next (Guillaume Quintard)
593. Re: Reply calculation (William Morgan)
594. Re: xapian merged into next (William Morgan)
595. Re: [PATCH] mime-decode hook: provide a "charset" variable
with the attachment charset (William Morgan)
596. Re: Choose "From:" address based on message content?
(William Morgan)
597. Re: Choose "From:" address based on message content?
(William Morgan)
598. Re: Exception (Marc Weber)
599. Re: [PATCH 0/18] Xapian-based index (Ingmar Vanhassel)
600. Re: [PATCH 0/18] Xapian-based index (Rich Lane)
601. Re: Reply calculation (Edward Z. Yang)
602. Re: xapian merged into next (Guillaume Quintard)
603. Odd key bug (Edward Z. Yang)
604. Re: sup 0.8.1 crash (William Morgan)
605. Re: [PATCH] Use /etc/mailname if present to determine the
hostname for Message-Id (William Morgan)
606. Re: Validating GPG keys in parallel and in background
(William Morgan)
607. Re: Adding/saving multiple attachments? (William Morgan)
608. Re: Invalid character on import (William Morgan)
609. Re: [PATCH] GSSAPI support for net/imap.rb and sup
(William Morgan)
610. Re: Odd key bug (William Morgan)
611. Re: xapian merged into next (William Morgan)
612. Odd bug with lazy-loaded messages (Edward Z. Yang)
613. [PATCH] Make logging less chatty (Edward Z. Yang)
614. Re: [PATCH] before-search hook (Edward Z. Yang)
615. Re: Odd key bug (Alex Vandiver)
616. xapian question (William Morgan)
617. Re: [PATCH] Make logging less chatty (Ben Walton)
618. Re: Odd key bug (Ben Walton)
619. Re: Odd key bug (Edward Z. Yang)
620. Re: Odd key bug (Edward Z. Yang)
621. Re: Odd key bug (Tarko Tikan)
622. Re: Odd key bug (Edward Z. Yang)
623. Re: [PATCH] before-search hook (William Morgan)
624. Re: xapian merged into next (Guillaume Quintard)
625. Re: Odd key bug (Andrew Pimlott)
626. Re: xapian merged into next (Richard Heycock)
627. [PATCH 1/2] xapian: fix MAX_DATE (Rich Lane)
628. [PATCH 2/2] xapian: fix issue with empty ferret query (Rich Lane)
629. Re: xapian merged into next (Rich Lane)
630. [PATCH] explicitly load messages in testcase (Rich Lane)
631. Re: [PATCH 0/18] Xapian-based index (Olly Betts)
632. Re: trying out sup ... (William Morgan)
633. Re: [PATCH 0/18] Xapian-based index (William Morgan)
634. Re: [PATCH] explicitly load messages in testcase (William Morgan)
635. Re: xapian merged into next (William Morgan)
636. Re: Odd key bug (William Morgan)
637. Re: [PATCH] Make logging less chatty (William Morgan)
638. Re: Odd key bug (Ben Walton)
639. Re: [PATCH] explicitly load messages in testcase (Rich Lane)
640. Re: Reply calculation (William Morgan)
641. Re: xapian question (Rich Lane)
642. Re: [PATCH] explicitly load messages in testcase (William Morgan)
643. Re: [PATCH 0/18] Xapian-based index (Olly Betts)
644. Re: [PATCH 0/18] Xapian-based index (William Morgan)
645. Re: [PATCH] Make logging less chatty (Mark Alexander)
646. Re: Reply calculation (Edward Z. Yang)
647. error with Sup while sending mails (paro 462)
648. [PATCH] handle malformed multiplart messages (Kornilios Kourtis)
649. Re: error with Sup while sending mails (William Morgan)
650. Re: xapian question (William Morgan)
651. Re: Slow import of messages (William Morgan)
652. Handling big mailing lists (Ilpo Nyyss?nen )
653. Re: error with Sup while sending mails (Marc Weber)
654. Re: Handling big mailing lists (Marc Weber)
655. Re: Handling big mailing lists (William Morgan)
656. Re: Handling big mailing lists (Ilpo Nyyss?nen )
657. Re: [PATCH] mime-decode hook: provide a "charset" variable
with the attachment charset (Adeodato Sim?)
658. [PATCH] HookContext::method_missing(): allow locals to be
nil (Adeodato Sim?)
659. sup on opensolaris (Tomas Carnecky)
660. Smooth Paging (Andrei Thorp)
661. Sup Resource Usage (Andrei Thorp)
662. Re: Smooth Paging (Edward Z. Yang)
663. Re: Sup Resource Usage (William Morgan)
664. Re: Smooth Paging (William Morgan)
665. Re: Smooth Paging (Edward Z. Yang)
666. Re: sup on opensolaris (William Morgan)
667. Re: Smooth Paging (William Morgan)
668. Re: Sup Resource Usage (Andrei Thorp)
669. Re: Smooth Paging (Andrei Thorp)
670. Re: Smooth Paging (Andrei Thorp)
671. Re: [PATCH 0/18] Xapian-based index (Rich Lane)
672. Re: sup on opensolaris (Ben Walton)
673. Re: xapian question (Rich Lane)
674. Re: Smooth Paging (Christopher Bertels)
675. Fwd: xapian merged into next (Guillaume Quintard)
676. Re: Fwd: xapian merged into next (Rich Lane)
677. Re: Fwd: xapian merged into next (Guillaume Quintard)
678. Re: Smooth Paging (vasudeva)
679. [PATCH] xapian: drop excessively long terms (Rich Lane)
680. Re: Fwd: xapian merged into next (Rich Lane)
681. Re: Fwd: xapian merged into next (Guillaume Quintard)
682. Re: Smooth Paging (Christopher Bertels)
683. sup crashing after sending mail (Igor Brkic)
684. [PATCH] run-mailcap fix (Beno?t PIERRE)
685. Stack overflow in regexp matcher (Mark Drayton)
686. Re: Odd bug with lazy-loaded messages (William Morgan)
687. Re: Handling big mailing lists (William Morgan)
688. Re: xapian question (William Morgan)
689. Re: sup on opensolaris (Tomas Carnecky)
690. Re: [PATCH] xapian: drop excessively long terms (William Morgan)
691. sup ignoring SIGTERM? (Adeodato Sim?)
692. Re: [PATCH] xapian: drop excessively long terms (Edward Z. Yang)
693. Re: sup crashing after sending mail (William Morgan)
694. Re: [PATCH] xapian: drop excessively long terms (Rich Lane)
695. Re: [PATCH] xapian: drop excessively long terms (William Morgan)
696. Re: [PATCH] xapian: drop excessively long terms
(Nicolas Pouillard)
697. Re: [PATCH] xapian: drop excessively long terms (Rich Lane)
698. Re: [PATCH] xapian: drop excessively long terms
(Nicolas Pouillard)
699. Re: [PATCH] xapian: drop excessively long terms (Rich Lane)
700. Re: sup ignoring SIGTERM? (William Morgan)
701. Re: sup ignoring SIGTERM? (Nicolas Pouillard)
702. Re: sup ignoring SIGTERM? (Ben Walton)
703. Re: sup ignoring SIGTERM? (William Morgan)
704. Re: sup ignoring SIGTERM? (Edward Z. Yang)
705. Re: sup crashing after sending mail (Igor Brkic)
706. Re: sup crashing after sending mail (William Morgan)
707. Re: sup crashing after sending mail (Igor Brkic)
708. Re: sup crashing after sending mail (Igor Brkic)
709. Re: sup crashing after sending mail (William Morgan)
710. Re: sup ignoring SIGTERM? (William Morgan)
711. Re: sup ignoring SIGTERM? (Nicolas Pouillard)
712. Re: sup ignoring SIGTERM? (Adeodato Sim?)
713. Re: sup ignoring SIGTERM? (Ben Walton)
714. Re: sup ignoring SIGTERM? (William Morgan)
715. Re: sup ignoring SIGTERM? (Adeodato Sim?)
716. [PATCH] move xapian index loading into load_index (Rich Lane)
717. Re: sup ignoring SIGTERM? (Rich Lane)
718. Re: Odd bug with lazy-loaded messages (Edward Z. Yang)
719. Re: sup ignoring SIGTERM? (Adeodato Sim?)
720. Re: Odd bug with lazy-loaded messages (Edward Z. Yang)
721. Starring messages in a hook (Jason Stewart)
722. Re: Starring messages in a hook (Ian Smith)
723. some internal api refactors (William Morgan)
724. Re: [PATCH] move xapian index loading into load_index
(William Morgan)
725. Re: Stack overflow in regexp matcher (William Morgan)
726. Re: [PATCH] run-mailcap fix (William Morgan)
727. [PATCH run-mailcap 1/2] Don't redirect stderr to /dev/null
when calling run-mailcap. (Beno?t PIERRE)
728. [PATCH run-mailcap 2/2] Use BufferManager.shell_out to call
run-mailcap instead of system. (Beno?t PIERRE)
729. Re: some internal api refactors (Rich Lane)
730. Re: Stack overflow in regexp matcher (Mark Drayton)
731. Re: [PATCH 0/18] Xapian-based index (Ingmar Vanhassel)
732. Re: [PATCH 0/18] Xapian-based index (Nicolas Pouillard)
733. Sup crashing (Taru Karttunen)
734. Re: [PATCH 0/18] Xapian-based index (Rich Lane)
735. Poll delay and states not really saved (Guillaume Quintard)
736. Re: Poll delay and states not really saved (Ingmar Vanhassel)
737. Re: Poll delay and states not really saved (Guillaume Quintard)
738. Re: [PATCH run-mailcap 2/2] Use BufferManager.shell_out to
call run-mailcap instead of system. (William Morgan)
739. Re: Sup crashing (William Morgan)
740. Re: [PATCH run-mailcap 2/2] Use BufferManager.shell_out to
call run-mailcap instead of system. (Beno?t PIERRE)
741. [PATCH] Restore keypad mode after we force ncurses to
refresh the whole screen. (Beno?t PIERRE)
742. Introduction, thanks, and a tiny patch (Carl Worth)
743. Introduction, thanks, and a small patch (Carl Worth)
744. [PATCH] maildir: Allow ', ' in the unique-name portion of a
maildir filename. (Carl Worth)
745. Re: Introduction, thanks, and a small patch (Igor Brkic)
746. Re: Introduction, thanks, and a small patch (Marc Weber)
747. Re: Introduction, thanks, and a small patch (Carl Worth)
748. Re: Introduction, thanks, and a small patch (Carl Worth)
749. [PATCH 1/2] move all GDBM data into Xapian (Rich Lane)
750. [PATCH 2/2] xapian index format versioning (Rich Lane)
751. [PATCH] skip system buffers when rolling (Rich Lane)
752. [PATCH] add 'I' keybinding to raise Inbox buffer (Rich Lane)
753. Re: [PATCH 2/2] xapian index format versioning (Adeodato Sim?)
754. [PATCH 2/2] xapian index format versioning (Rich Lane)
755. Re: Introduction, thanks, and a small patch (William Morgan)
756. Re: Introduction, thanks, and a small patch (William Morgan)
757. Re: Stack overflow in regexp matcher (William Morgan)
758. Re: some internal api refactors (William Morgan)
759. Re: [PATCH] Restore keypad mode after we force ncurses to
refresh the whole screen. (William Morgan)
760. [PATCH] Add an after-add-message hook (Kevin Riggle)
761. Re: some internal api refactors (Rich Lane)
762. Re: Introduction, thanks, and a small patch (Igor Brkic)
763. [PATCH] index log (Rich Lane)
764. [PATCH 1/5] console mode (Rich Lane)
765. [PATCH 3/5] console: index internals accessor (Rich Lane)
766. [PATCH 2/5] console: add/remove labels (Rich Lane)
767. [PATCH 4/5] console: reload (Rich Lane)
768. [PATCH 5/5] console: clear_hooks (Rich Lane)
769. [PATCH] cache results of Person.from_address (Rich Lane)
770. Re: Sup crashing (Taru Karttunen)
771. Re: [PATCH] cache results of Person.from_address (Andrei Thorp)
772. Re: Sup crashing (William Morgan)
773. Re: [PATCH 2/2] xapian index format versioning (Adeodato Sim?)
774. Re: some internal api refactors (William Morgan)
775. logging and internal API changes in next (William Morgan)
776. ncurses hack (Edward Z. Yang)
777. Re: logging and internal API changes in next (Andrei Thorp)
778. Re: ncurses hack (William Morgan)
779. Re: ncurses hack (Dusan)
780. xapian rpms (Ben Walton)
781. Re: [PATCH] maildir: Allow ', ' in the unique-name portion
of a maildir filename. (William Morgan)
782. crash when sup-syncing to xapian (Ben Walton)
783. Re: [PATCH] skip system buffers when rolling (William Morgan)
784. Re: [PATCH] add 'I' keybinding to raise Inbox buffer
(William Morgan)
785. Re: [PATCH] maildir: Allow ', ' in the unique-name portion
of a maildir filename. (Carl Worth)
786. Re: [PATCH] maildir: Allow ', ' in the unique-name portion
of a maildir filename. (William Morgan)
787. Re: [PATCH] Add an after-add-message hook (William Morgan)
788. Re: crash when sup-syncing to xapian (Beno?t PIERRE)
789. Re: ncurses hack (Beno?t PIERRE)
790. [PATCH] Fix a thread merging bug introduced by refactoring
in 59f8fc2 (Alex Vandiver)
791. Re: [PATCH 1/5] console mode (William Morgan)
792. Re: crash when sup-syncing to xapian (Rich Lane)
793. Re: ncurses hack (Dusan)
794. Re: ncurses hack (Beno?t PIERRE)
795. Re: ncurses hack (Dusan)
796. Re: crash when sup-syncing to xapian (Beno?t PIERRE)
797. Re: ncurses hack (Dusan)
798. Re: ncurses hack (J?rg-Hendrik Bach)
799. Re: crash when sup-syncing to xapian (Rich Lane)
800. Re: crash when sup-syncing to xapian (Beno?t PIERRE)
801. What's your sup workflow (and a spew of ideas) (Carl Worth)
802. Crash w/ current 'next' (Mike Kelly)
803. Re: What's your sup workflow (and a spew of ideas) (Carl Worth)
804. Re: What's your sup workflow (and a spew of ideas) (Andrei Thorp)
805. Re: What's your sup workflow (and a spew of ideas) (Carl Worth)
806. Re: What's your sup workflow (and a spew of ideas) (Rich Lane)
807. Re: [PATCH] Add an after-add-message hook (Kevin Riggle)
808. Re: crash when sup-syncing to xapian (Ben Walton)
809. Exception trying to run git source (Carl Worth)
810. Re: What's your sup workflow (and a spew of ideas) (Carl Worth)
811. Re: Exception trying to run git source (Ben Walton)
812. Re: What's your sup workflow (and a spew of ideas) (Rich Lane)
813. Re: What's your sup workflow (and a spew of ideas) (Andrei Thorp)
814. Re: Exception trying to run git source (Ben Walton)
815. Re: Exception trying to run git source (William Morgan)
816. Re: Exception trying to run git source (Carl Worth)
817. Re: Exception trying to run git source (Ben Walton)
818. Re: Exception trying to run git source (Carl Worth)
819. Re: Exception trying to run git source (Ben Walton)
820. Re: crash when sup-syncing to xapian (William Morgan)
821. Re: Exception trying to run git source (William Morgan)
822. Re: Crash w/ current 'next' (William Morgan)
823. Re: [PATCH] Add an after-add-message hook (William Morgan)
824. Re: Exception trying to run git source (Carl Worth)
825. Re: Exception trying to run git source (William Morgan)
826. [PATCH] fix garbaged text in textfield when using ncursesw
(Beno?t PIERRE)
827. Re: [PATCH] mime-decode hook: provide a "charset" variable
with the attachment charset (Adeodato Sim?)
828. Re: Exception trying to run git source (Carl Worth)
829. In next: thread-view-mode labelling No method join for Set
(Wirt Wolff)
830. Re: What's your sup workflow (and a spew of ideas) (Carl Worth)
831. Re: In next: thread-view-mode labelling No method join for
Set (Carl Worth)
832. Re: In next: thread-view-mode labelling No method join for
Set (Ben Walton)
833. Re: In next: thread-view-mode labelling No method join for
Set (Carl Worth)
834. [PATCH] Make SUP_LOG_LEVEL self-documenting. (Carl Worth)
835. [PATCH] Be less overzealous in moving text to the left
column (Carl Worth)
836. On making kill-thread easier (Carl Worth)
837. Re: On making kill-thread easier (Andrei Thorp)
838. Re: On making kill-thread easier (Chris Wilson)
839. Re: On making kill-thread easier (Andrei Thorp)
840. Re: On making kill-thread easier (Ben Walton)
841. Re: On making kill-thread easier (Carl Worth)
842. Re: On making kill-thread easier (Carl Worth)
843. Re: On making kill-thread easier (Ben Walton)
844. Re: On making kill-thread easier (Carl Worth)
845. Re: In next: thread-view-mode labelling No method join for
Set (Ben Walton)
846. Re: On making kill-thread easier (Carl Worth)
847. [PATCH] Add an after-add-message hook (Kevin Riggle)
848. Re: [PATCH] Add an after-add-message hook (Kevin Riggle)
849. 'next' crash: wrong id called on nil (thread.rb:264:in
`thread_for') (Carl Worth)
850. Re: On making kill-thread easier (Chris Wilson)
851. Re: On making kill-thread easier (Edward Z. Yang)
852. Re: On making kill-thread easier (Ben Walton)
853. Crashing ssh + sup, bad combo (Guillaume Quintard)
854. Re: Crashing ssh + sup, bad combo (Mark Alexander)
855. Re: Crashing ssh + sup, bad combo (Guillaume Quintard)
856. Re: Crashing ssh + sup, bad combo (Rich Lane)
857. Sup crashed at launch (Contzen Laurent)
858. Bug: Log printing with encoding problems (Ulrik Sverdrup)
859. Bug: Quits on unbound(?) keys (Ulrik Sverdrup)
860. Re: [PATCH] index log (William Morgan)
861. Re: [PATCH] cache results of Person.from_address (William Morgan)
862. Re: [PATCH] cache results of Person.from_address (William Morgan)
863. Re: [PATCH 2/2] xapian index format versioning (William Morgan)
864. Re: [PATCH] Fix a thread merging bug introduced by
refactoring in 59f8fc2 (William Morgan)
865. Re: [PATCH] fix garbaged text in textfield when using
ncursesw (William Morgan)
866. sup crash (Carlos Franke)
867. Re: Sup crashed at launch (William Morgan)
868. Re: sup crash (William Morgan)
869. Re: Sup crashed at launch (William Morgan)
870. Re: [PATCH] mime-decode hook: provide a "charset" variable
with the attachment charset (William Morgan)
871. [PATCH] add Message#load_from_index! shortcut (Rich Lane)
872. Re: [PATCH] cache results of Person.from_address (Rich Lane)
873. [PATCH] add xapian-specific hack to quickly create a Person
(Rich Lane)
874. Re: Bug: Quits on unbound(?) keys (Ingmar Vanhassel)
875. Re: [PATCH] mime-decode hook: provide a "charset" variable
with the attachment charset (Adeodato Sim?)
876. Re: Exception trying to run git source (William Morgan)
877. Re: [PATCH] Make SUP_LOG_LEVEL self-documenting. (William Morgan)
878. How to edit attachments in reply? (Chris Wilson)
879. Re: [PATCH] mime-decode hook: provide a "charset" variable
with the attachment charset (William Morgan)
880. Re: [PATCH] Be less overzealous in moving text to the left
column (William Morgan)
881. [PATCH] sup-sync: restore state on messages that dont
already exist (Rich Lane)
882. [PATCH 1/2] preemptively load messages when scrolling (Rich Lane)
883. [PATCH 2/2] ui responsiveness tweaks (Rich Lane)
884. [PATCH] reply all keybindings (Rich Lane)
885. Re: [PATCH] index log (Nicolas Pouillard)
886. Re: [PATCH 2/2] xapian index format versioning
(Nicolas Pouillard)
887. Re: In next: thread-view-mode labelling No method join for
Set (William Morgan)
888. Encrypted password in configuration file (Lars Kotthoff)
889. Re: Bug: Quits on unbound(?) keys (William Morgan)
890. Re: [PATCH] Add an after-add-message hook (William Morgan)
891. Re: 'next' crash: wrong id called on nil (thread.rb:264:in
`thread_for') (William Morgan)
892. Re: Crashing ssh + sup, bad combo (William Morgan)
893. Re: Bug: Log printing with encoding problems (William Morgan)
894. Re: [PATCH] add Message#load_from_index! shortcut
(William Morgan)
895. Re: [PATCH] add xapian-specific hack to quickly create a
Person (William Morgan)
896. Re: How to edit attachments in reply? (William Morgan)
897. Re: [PATCH 2/2] xapian index format versioning (Rich Lane)
898. Re: In next: thread-view-mode labelling No method join for
Set (Nicolas Pouillard)
899. [PATCH] Add UTF-8 encoding string for ArchLinux systems
(Israel Herraiz)
900. [PATCH] Identify list messages by list-id if list-post is
not present (Israel Herraiz)
901. lots of branches merged down to master (William Morgan)
902. Re: [PATCH] add xapian-specific hack to quickly create a
Person (Rich Lane)
903. Re: 'next' crash: wrong id called on nil (thread.rb:264:in
`thread_for') (Carl Worth)
904. Re: [PATCH 2/2] ui responsiveness tweaks (Carl Worth)
905. Re: Exception trying to run git source (Carl Worth)
906. Re: [PATCH] Make SUP_LOG_LEVEL self-documenting. (Carl Worth)
907. Re: [PATCH] Be less overzealous in moving text to the left
column (Carl Worth)
908. On making inbox-mode and search-results-mode more similar
(Carl Worth)
909. [PATCH] Add 'a' and 'd' keybindings to thread-view-mode to
archive/delete current thread (Carl Worth)
910. Should '/' trigger the loading of more messages? (Carl Worth)
911. Re: On making inbox-mode and search-results-mode more
similar (Carl Worth)
912. Re: Should '/' trigger the loading of more messages?
(Ingmar Vanhassel)
913. Re: [PATCH 2/2] ui responsiveness tweaks (Ingmar Vanhassel)
914. Re: On making inbox-mode and search-results-mode more
similar (Rich Lane)
915. Re: Should '/' trigger the loading of more messages?
(Marcus Williams)
916. Re: Should '/' trigger the loading of more messages? (Carl Worth)
917. Nobody told me (Guillaume Quintard)
918. Ignore killed messages in U screen (Edward Z. Yang)
919. Re: Ignore killed messages in U screen (Ben Walton)
920. Re: Ignore killed messages in U screen (Edward Z. Yang)
921. sent and draft sources (Joe Shaw)
922. Re: sent and draft sources (Ben Walton)
923. Re: sent and draft sources (Joe Shaw)
924. sup crashed: NoMethodError (Sean Escriva)
925. Re: sent and draft sources (Adeodato Sim?)
926. Re: sent and draft sources (Ben Walton)
927. Re: sent and draft sources (Ben Walton)
928. Re: Encrypted password in configuration file (Jim Cheetham)
929. Re: Encrypted password in configuration file (Jim Cheetham)
930. Re: Encrypted password in configuration file (Jim Cheetham)
931. an error occurred in Sup (Stan Heckman)
932. Re: Encrypted password in configuration file (Lars Kotthoff)
933. Re: Encrypted password in configuration file (William Morgan)
934. Re: sent and draft sources (William Morgan)
935. Re: sent and draft sources (William Morgan)
936. Re: Nobody told me (William Morgan)
937. Re: an error occurred in Sup (William Morgan)
938. Re: sup crashed: NoMethodError (William Morgan)
939. Re: Nobody told me (Guillaume Quintard)
940. Re: sup crashed: NoMethodError (Sean Escriva)
941. Re: Encrypted password in configuration file (Mike Kelly)
942. Crash while syncing (Nicolas Pouillard)
943. Re: Crash while syncing (Nicolas Pouillard)
944. Re: Crash while syncing (Rich Lane)
945. Re: Crash while syncing (Nicolas Pouillard)
946. Re: Crash while syncing (Rich Lane)
947. Re: Crash while syncing (Nicolas Pouillard)
948. exception while importing to xapian (Ben Walton)
949. Re: Crash while syncing (Rich Lane)
950. Re: exception while importing to xapian (Blake Burkhart)
951. Re: exception while importing to xapian (Ben Walton)
952. [PATCH] remove use of Object#tap (Rich Lane)
953. Re: [PATCH] remove use of Object#tap (Blake Burkhart)
954. Re: exception while importing to xapian (Rich Lane)
955. Re: [PATCH] remove use of Object#tap (Blake Burkhart)
956. Re: [PATCH] remove use of Object#tap (Ben Walton)
957. [PATCH] sup-sync: restore state on messages that dont
already exist (Rich Lane)
958. Re: [PATCH] remove use of Object#tap (Rich Lane)
959. Re: [PATCH] sup-sync: restore state on messages that dont
already exist (Blake Burkhart)
960. Re: [PATCH] index log (Rich Lane)
961. Re: [PATCH] index log (Ben Walton)
962. Re: [PATCH] sup-sync: restore state on messages that dont
already exist (William Morgan)
963. Re: [PATCH] reply all keybindings (William Morgan)
964. Re: [PATCH] Add UTF-8 encoding string for ArchLinux systems
(William Morgan)
965. Re: [PATCH] Identify list messages by list-id if list-post
is not present (William Morgan)
966. Re: [PATCH] Make SUP_LOG_LEVEL self-documenting. (William Morgan)
967. Re: [PATCH] remove use of Object#tap (William Morgan)
968. Re: [PATCH 0/18] Xapian-based index (Ingmar Vanhassel)
969. Re: [PATCH] Identify list messages by list-id if list-post
is not present (Israel Herraiz)
970. Re: [PATCH] add xapian-specific hack to quickly create a
Person (William Morgan)
971. Re: [PATCH 2/2] ui responsiveness tweaks (Rich Lane)
972. Re: Nobody told me (William Morgan)
973. Re: [PATCH] Add an after-add-message hook (William Morgan)
974. Trouble loading dump into Xapian index (Marc Weber)
975. Dynamic list of maildir folders as sources (Amit Kucheria)
976. Re: Trouble loading dump into Xapian index (William Morgan)
977. Re: Dynamic list of maildir folders as sources (William Morgan)
978. Re: Trouble loading dump into Xapian index (Marc Weber)
979. [PATCH] decrypt returns 3 elem array if gpg is unavailable
(Matt Zulak)
980. Re: Trouble loading dump into Xapian index (Rich Lane)
981. Re: [PATCH 0/18] Xapian-based index (Rich Lane)
982. Re: [PATCH] Be less overzealous in moving text to the left
column (William Morgan)
983. Re: sup crashed: NoMethodError (William Morgan)
984. Re: Trouble loading dump into Xapian index (William Morgan)
985. Re: Trouble loading dump into Xapian index (Marc Weber)
986. Re: [PATCH 2/2] ui responsiveness tweaks (William Morgan)
987. Re: [PATCH] Add 'a' and 'd' keybindings to thread-view-mode
to archive/delete current thread (William Morgan)
988. Re: On making inbox-mode and search-results-mode more
similar (William Morgan)
989. Re: Trouble loading dump into Xapian index (Rich Lane)
990. Re: On making inbox-mode and search-results-mode more
similar (William Morgan)
991. Re: On making inbox-mode and search-results-mode more
similar (William Morgan)
992. Re: On making inbox-mode and search-results-mode more
similar (Rich Lane)
993. Re: [PATCH] Add 'a' and 'd' keybindings to thread-view-mode
to archive/delete current thread (Mark Alexander)
994. Re: Ignore killed messages in U screen (William Morgan)
995. Re: On making inbox-mode and search-results-mode more
similar (William Morgan)
996. Re: Ignore killed messages in U screen (Edward Z. Yang)
997. Re: [PATCH] Add 'a' and 'd' keybindings to thread-view-mode
to archive/delete current thread (Nicholas Bergson-Shilcock)
998. Re: Ignore killed messages in U screen (William Morgan)
999. Re: Ignore killed messages in U screen (Edward Z. Yang)
1000. Re: Ignore killed messages in U screen (Ben Walton)
1001. Re: Ignore killed messages in U screen (Rich Lane)
1002. Re: Ignore killed messages in U screen (Carl Worth)
1003. Can't add source when tracking next (Richard Sandilands)
1004. more xapian/label woes (Ben Walton)
1005. Re: [PATCH] Identify list messages by list-id if list-post
is not present (William Morgan)
1006. Re: [PATCH] decrypt returns 3 elem array if gpg is
unavailable (William Morgan)
1007. Re: Ignore killed messages in U screen (William Morgan)
1008. Re: Ignore killed messages in U screen (Carl Worth)
1009. Re: Can't add source when tracking next (William Morgan)
1010. Re: more xapian/label woes (William Morgan)
1011. Re: [PATCH] handle malformed multiplart messages
(William Morgan)
1012. Re: Trouble loading dump into Xapian index (Marc Weber)
1013. Re: Trouble loading dump into Xapian index (Rich Lane)
1014. Re: Trouble loading dump into Xapian index (William Morgan)
1015. a few questions on mail handling with sup (Sean Escriva)
1016. Re: more xapian/label woes (Ben Walton)
1017. Re: a few questions on mail handling with sup (Ben Walton)
1018. new exception (Ben Walton)
1019. Re: new exception (Rich Lane)
1020. Re: new exception (Ben Walton)
1021. Re: new exception (Rich Lane)
1022. Re: new exception (Ben Walton)
1023. sources.yaml labels (Ben Walton)
1024. Sent messages and Sent label (Richard Sandilands)
1025. Change color of 'highlight' indicator in inbox view?
(Richard Sandilands)
1026. Sent messages and Sent label (Richard Sandilands)
1027. Re: Change color of 'highlight' indicator in inbox view?
(William Morgan)
1028. Re: sources.yaml labels (William Morgan)
1029. Re: sources.yaml labels (Ben Walton)
1030. Re: Sent messages and Sent label (William Morgan)
1031. Re: sources.yaml labels (Ben Walton)
1032. Re: sources.yaml labels (Ingmar Vanhassel)
1033. Re: sources.yaml labels (William Morgan)
1034. Re: sources.yaml labels (Ben Walton)
1035. Re: sources.yaml labels (Ben Walton)
1036. Re: new exception (Rich Lane)
1037. Re: new exception (Ben Walton)
1038. [PATCH] small sent labels fixup (Ben Walton)
1039. Re: [PATCH] Add 'a' and 'd' keybindings to thread-view-mode
to archive/delete current thread (Nicolas Pouillard)
1040. [PATCH] sort labels in the dump (Michael Hamann)
1041. Re: [PATCH] sort labels in the dump (Nicolas Pouillard)
1042. ArgumentError from thread: poll after loading inbox
(Richard Sandilands)
1043. sup-sync and xapian memory usage (Andrew Pimlott)
1044. Re: sup-sync and xapian memory usage (Ben Walton)
1045. Re: sup-sync and xapian memory usage (Rich Lane)
1046. Re: sup-sync and xapian memory usage (Ben Walton)
1047. Re: sup-sync and xapian memory usage (Rich Lane)
1048. Re: sup-sync and xapian memory usage (Andrew Pimlott)
1049. Can't add a local maildir source (infoarts@gmail.com)
1050. lbdb module for sup (Gaute Hope)
1051. Re: [PATCH] Identify list messages by list-id if list-post
is not present (Israel Herraiz)
1052. Re: [PATCH] Identify list messages by list-id if list-post
is not present (William Morgan)
1053. Re: [PATCH] Identify list messages by list-id if list-post
is not present (Israel Herraiz)
1054. Re: sup-sync and xapian memory usage (William Morgan)
1055. Re: sup-sync and xapian memory usage (William Morgan)
1056. Re: sup-sync and xapian memory usage (Ben Walton)
1057. Re: sup-sync and xapian memory usage (Richard Heycock)
1058. Re: sup-sync and xapian memory usage (Nicolas Pouillard)
1059. Re: [PATCH] Add 'a' and 'd' keybindings to thread-view-mode
to archive/delete current thread (Wirt Wolff)
1060. Re: [PATCH] small sent labels fixup (William Morgan)
1061. master branch merge report (William Morgan)
1062. Re: master branch merge report (Nicolas Pouillard)
1063. Re: master branch merge report (William Morgan)
1064. Re: [PATCH] Add 'a' and 'd' keybindings to thread-view-mode
to archive/delete current thread (William Morgan)
1065. Re: [PATCH] Add 'a' and 'd' keybindings to thread-view-mode
to archive/delete current thread (Carl Worth)
1066. Re: master branch merge report (Nicolas Pouillard)
1067. Re: [PATCH] Add 'a' and 'd' keybindings to thread-view-mode
to archive/delete current thread (Nicolas Pouillard)
1068. Re: ArgumentError from thread: poll after loading inbox
(William Morgan)
1069. Re: lbdb module for sup (William Morgan)
1070. Re: Can't add a local maildir source (William Morgan)
1071. Re: Change color of 'highlight' indicator in inbox view?
(Carl Worth)
1072. Re: ArgumentError from thread: poll after loading inbox
(Richard Sandilands)
1073. Re: a few questions on mail handling with sup (Sean Escriva)
1074. Re: sup-sync and xapian memory usage (Rich Lane)
1075. Exception when trying to open console view (Gaute Hope)
1076. updated before-poll hook for offlineimap (Gaute Hope)
1077. U (unread) search is off (Ben Walton)
1078. Re: Exception when trying to open console view (William Morgan)
1079. Re: ArgumentError from thread: poll after loading inbox
(William Morgan)
1080. Re: Change color of 'highlight' indicator in inbox view?
(William Morgan)
1081. Re: [PATCH] Add 'a' and 'd' keybindings to thread-view-mode
to archive/delete current thread (William Morgan)
1082. Re: [PATCH] sort labels in the dump (William Morgan)
1083. Thoughts on simplifying thread-view-mode keybindings
(Carl Worth)
1084. How hard would a universal undo be? (Carl Worth)
1085. Re: updated before-poll hook for offlineimap (Gaute Hope)
1086. Re: U (unread) search is off (Ingmar Vanhassel)
1087. Re: U (unread) search is off (William Morgan)
1088. GPG: Sending mail to people without a trust-path
(Michael Stapelberg)
1089. Re: U (unread) search is off (Ben Walton)
1090. Re: U (unread) search is off (Ingmar Vanhassel)
1091. Re: How hard would a universal undo be? (William Morgan)
1092. Re: updated before-poll hook for offlineimap (William Morgan)
1093. Re: How hard would a universal undo be? (Marc Weber)
1094. Re: GPG: Sending mail to people without a trust-path
(William Morgan)
1095. Re: U (unread) search is off (Rich Lane)
1096. Re: U (unread) search is off (Rich Lane)
1097. Re: U (unread) search is off (Ben Walton)
1098. Re: How hard would a universal undo be? (Rich Lane)
1099. Re: How hard would a universal undo be? (Nicolas Pouillard)
1100. Crash while scrolling (Ben Gamari)
1101. Re: How hard would a universal undo be? (Rich Lane)
1102. Re: How hard would a universal undo be? (Nicolas Pouillard)
1103. Re: Crash while scrolling (William Morgan)
1104. Re: U (unread) search is off (William Morgan)
1105. Re: [PATCH] Fix parsing of encrypted messages that contain
further multipart elements (William Morgan)
1106. Case-sensitivity of Content-Type: more RubyMail stupidity?
(Kevin Riggle)
1107. Hello and thanks (Bo Borgerson)
1108. [PATCH] Handle added messages in label-list-mode (Bo Borgerson)
1109. [PATCH] Add command for polling unusual sources (Bo Borgerson)
1110. Re: Crash while scrolling (Ben Gamari)
1111. [PATCH] xapian: do less work for update_message_state
(Rich Lane)
1112. Re: How hard would a universal undo be? (Rich Lane)
1113. Re: [PATCH] mime-decode hook: provide a "charset" variable
with the attachment charset (Adeodato Sim?)
1114. Re: U (unread) search is off (Rich Lane)
1115. Re: How hard would a universal undo be? (Nicolas Pouillard)
1116. Re: U (unread) search is off (Olly Betts)
1117. Sup and Ruby 1.9.1 - deadlock? (Michael Hamann)
1118. Re: Sup and Ruby 1.9.1 - deadlock? (Sean Escriva)
1119. Fixing header for encrypted messages (might be an old
issue) (Christopher Bertels)
1120. Re: Sup and Ruby 1.9.1 - deadlock? (Rich Lane)
1121. Re: Sup and Ruby 1.9.1 - deadlock? (Dusan)
1122. Re: Fixing header for encrypted messages (might be an old
issue) (Adeodato Sim?)
1123. Re: Crash while scrolling (Ben Gamari)
1124. Re: Fixing header for encrypted messages (might be an old
issue) (Christopher Bertels)
1125. [PATCH] Fix message_to_chunks for the m.body == nil case.
(Carl Worth)
1126. Hello, and before-add-message hook for applying labels per
CDB (William Erik Baxter)
1127. [PATCH] Add hooks to sort and format label-list-mode
display. (William Erik Baxter)
1128. Trouble implementing UTF-8 ncurses fix (Richard Sandilands)
1129. Bug: Converting the index to xapian fails with a message
with very old date (Michael Stapelberg)
1130. Bug: Opening PGP encrypted mails fails with latest revision
(Michael Stapelberg)
1131. Problem with lbdb and extra contacts hook (Ali Polatel)
1132. Re: Problem with lbdb and extra contacts hook (Ali Polatel)
1133. Bug: Messages using inline GPG are not decrypted
(Michael Stapelberg)
1134. Re: Bug: Messages using inline GPG are not decrypted
(Michael Stapelberg)
1135. Exception while marking mail as read (David Pflug)
1136. Re: Bug: Opening PGP encrypted mails fails with latest
revision (Michael Stapelberg)
1137. Re: Bug: Messages using inline GPG are not decrypted
(Michael Stapelberg)
1138. Bug: Killed threads coming up again (Michael Stapelberg)
1139. [PATCH] Fix uninitialized @name member in person.rb.
(Carl Worth)
1140. [PATCH] Allow thread index view to sort oldest first
(Carl Worth)
1141. Re: Problem with lbdb and extra contacts hook (William Morgan)
1142. Re: Trouble implementing UTF-8 ncurses fix (William Morgan)
1143. Re: Bug: Converting the index to xapian fails with a
message with very old date (William Morgan)
1144. Re: Hello, and before-add-message hook for applying labels
per CDB (William Morgan)
1145. Re: Crash while scrolling (William Morgan)
1146. Re: Fixing header for encrypted messages (might be an old
issue) (William Morgan)
1147. Re: Sup and Ruby 1.9.1 - deadlock? (William Morgan)
1148. Re: Fixing header for encrypted messages (might be an old
issue) (William Morgan)
1149. Re: Hello and thanks (William Morgan)
1150. Re: [PATCH] Fix uninitialized @name member in person.rb.
(William Morgan)
1151. Re: Bug: Killed threads coming up again (William Morgan)
1152. Re: Bug: Killed threads coming up again (Michael Stapelberg)
1153. Re: Bug: Messages using inline GPG are not decrypted
(William Morgan)
1154. Re: Bug: Opening PGP encrypted mails fails with latest
revision (William Morgan)
1155. Hook, again (Guillaume Quintard)
1156. Re: [PATCH] Fix message_to_chunks for the m.body == nil
case. (William Morgan)
1157. Re: [PATCH] mime-decode hook: provide a "charset" variable
with the attachment charset (William Morgan)
1158. Re: Case-sensitivity of Content-Type: more RubyMail
stupidity? (William Morgan)
1159. sup 0.9 pre-release checkin (William Morgan)
1160. Re: Bug: Messages using inline GPG are not decrypted
(Michael Stapelberg)
1161. Re: Case-sensitivity of Content-Type: more RubyMail
stupidity? (Kevin Riggle)
1162. Re: Bug: Messages using inline GPG are not decrypted
(Ben Walton)
1163. Re: Bug: Converting the index to xapian fails with a
message with very old date (Michael Stapelberg)
1164. Re: Bug: Messages using inline GPG are not decrypted
(Michael Stapelberg)
1165. Re: Hook, again (William Morgan)
1166. Re: Bug: Messages using inline GPG are not decrypted
(William Morgan)
1167. Re: Case-sensitivity of Content-Type: more RubyMail
stupidity? (William Morgan)
1168. Re: Case-sensitivity of Content-Type: more RubyMail
stupidity? (Kevin Riggle)
1169. Re: Fixing header for encrypted messages (might be an old
issue) (Adeodato Sim?)
1170. Why inbox-mode instead of default search? (William Erik Baxter)
1171. Re: Why inbox-mode instead of default search? (William Morgan)
1172. Re: Why inbox-mode instead of default search?
(William Erik Baxter)
1173. Re: Crash while scrolling (Ben Gamari)
1174. [PATCH] Add new :crypto_default configuration option.
(Carl Worth)
1175. [BUG] [PATCH] Encrypted messages without signature generate
an exception (Michael Stapelberg)
1176. Feature Request: Collecting Lines in Index Mode
(Christian Dietrich)
1177. Re: Why inbox-mode instead of default search? (William Morgan)
1178. Re: Why inbox-mode instead of default search? (Carl Worth)
1179. Re: Why inbox-mode instead of default search? (Rich Lane)
1180. Re: Why inbox-mode instead of default search? (William Morgan)
1181. Re: Feature Request: Collecting Lines in Index Mode
(William Morgan)
1182. Re: sup 0.9 pre-release checkin (William Morgan)
1183. Re: sup 0.9 pre-release checkin (Michael Stapelberg)
1184. Re: Why inbox-mode instead of default search? (Carl Worth)
1185. Re: sup 0.9 pre-release checkin (William Morgan)
1186. Re: [PATCH] xapian: do less work for update_message_state
(William Morgan)
1187. Re: sup 0.9 pre-release checkin (Michael Stapelberg)
1188. Re: Ignore killed messages in U screen (William Morgan)
1189. [PATCH] Save all attachments to a folder (Michael Stapelberg)
1190. Re: [PATCH] Save all attachments to a folder (Edward Z. Yang)
1191. Re: [PATCH] xapian: do less work for update_message_state
(Rich Lane)
1192. [PATCH] When providing a wildcard as file for an
attachment, correctly expand it (Michael Stapelberg)
1193. Re: [PATCH] Save all attachments to a folder (Kevin Riggle)
1194. Re: Crash while scrolling (William Morgan)
1195. [PATCH] more inline GPG madness (Michael Stapelberg)
1196. i18n? (Christopher Bertels)
1197. Re: Ignore killed messages in U screen (Nicolas Pouillard)
1198. Re: Ignore killed messages in U screen (William Morgan)
1199. Re: Crash while scrolling (William Morgan)
1200. Re: [PATCH] xapian: do less work for update_message_state
(William Morgan)
1201. Re: Bug: Converting the index to xapian fails with a
message with very old date (William Morgan)
1202. Re: Ignore killed messages in U screen (Nicolas Pouillard)
1203. Bug: store_message writes invalid From lines with locales
set (Gregor Hoffleit)
1204. Re: Bug: store_message writes invalid From lines with
locales set (William Morgan)
1205. Re: i18n? (William Morgan)
1206. Re: [PATCH] Handle added messages in label-list-mode
(William Morgan)
1207. Re: [PATCH] Add command for polling unusual sources
(William Morgan)
1208. Re: [PATCH] Add hooks to sort and format label-list-mode
display. (William Morgan)
1209. Re: [PATCH] xapian: do less work for update_message_state
(Rich Lane)
1210. Re: [PATCH] Allow thread index view to sort oldest first
(William Morgan)
1211. Re: [PATCH] Add new :crypto_default configuration option.
(William Morgan)
1212. Re: [PATCH] When providing a wildcard as file for an
attachment, correctly expand it (William Morgan)
1213. Re: Ignore killed messages in U screen (Carl Worth)
1214. Re: [PATCH] more inline GPG madness (Michael Stapelberg)
1215. Re: [PATCH] Add new :crypto_default configuration option.
(Carl Worth)
1216. Re: [PATCH] Add hooks to sort and format label-list-mode
display. (William Erik Baxter)
1217. Re: [PATCH] Save all attachments to a folder (William Morgan)
1218. Bugfix for custom-search (Edward Z. Yang)
1219. Re: [PATCH] Allow thread index view to sort oldest first
(Carl Worth)
1220. Re: Crash while scrolling (Ben Gamari)
1221. Configurable poll time (Edward Z. Yang)
1222. Re: i18n? (Christopher Bertels)
1223. Re: i18n? (Christopher Bertels)
1224. Re: Configurable poll time (William Morgan)
1225. Re: i18n? (William Morgan)
1226. Re: Crash while scrolling (William Morgan)
1227. Re: i18n? (Christopher Bertels)
1228. Writing time-sensitive portions of sup in C (Carl Worth)
1229. [ANN] Sup 0.9 released (William Morgan)
1230. Re: i18n? (Rich Lane)
1231. Crash while loading thread index buffer (Ben Gamari)
1232. Re: Crash while scrolling (Ben Gamari)
1233. Re: i18n? (Christopher Bertels)
1234. Re: [PATCH] xapian: do less work for update_message_state
(Olly Betts)
1235. Re: Bug: store_message writes invalid From lines with
locales set (Gregor Hoffleit)
1236. Re: i18n? (Christopher Bertels)
1237. Re: Bug: Converting the index to xapian fails with a
message with very old date (Rich Lane)
1238. Re: Feature Request: Collecting Lines in Index Mode
(Christian Dietrich)
1239. Bug: Xapian exception after having polled (gauteh)
1240. labels-before-subject and ask_for_contacts config knobs
(Tarko Tikan)
1241. [PATCH] don't downcase a nil content-type (Rich Lane)
1242. Re: Bug: Xapian exception after having polled (Rich Lane)
1243. Crash, bad index, and ensuing misery (Guillaume Quintard)
1244. Re: Crash, bad index, and ensuing misery (Rich Lane)
1245. next search in buffer view.. (Marc Weber)
1246. Re: Crash, bad index, and ensuing misery (Guillaume Quintard)
1247. Re: Crash, bad index, and ensuing misery (Rich Lane)
1248. Re: Crash, bad index, and ensuing misery (Guillaume Quintard)
1249. Re: Crash, bad index, and ensuing misery (Rich Lane)
1250. Re: Bug: Xapian exception after having polled (Gaute Hope)
1251. Simple E-Mail Delaying (Nicolas Pouillard)
1252. Re: labels-before-subject and ask_for_contacts config knobs
(Marcus Williams)
1253. Re: Simple E-Mail Delaying (Steve Goldman)
1254. Re: Simple E-Mail Delaying (William Baxter)
1255. Re: [PATCH] Handle added messages in label-list-mode
(Bo Borgerson)
1256. Re: Bug: Xapian exception after having polled (Rich Lane)
1257. Re: Bug: Xapian exception after having polled (Gaute Hope)
1258. Re: Bug: Xapian exception after having polled (Rich Lane)
1259. Re: Bug: Xapian exception after having polled (Gaute Hope)
1260. Re: Crash while scrolling (Guillaume Quintard)
1261. Re: next search in buffer view.. (Marc Weber)
1262. Re: Simple E-Mail Delaying (Nicolas Pouillard)
1263. Re: Simple E-Mail Delaying (Nicolas Pouillard)
1264. Re: i18n? (Christopher Bertels)
1265. Re: Bug: Xapian exception after having polled (Gaute Hope)
1266. Re: Simple E-Mail Delaying (Nicolas Pouillard)
1267. Re: Bug: Xapian exception after having polled
(Guillaume Quintard)
1268. Re: Crash, bad index, and ensuing misery (Olly Betts)
1269. Re: Crash, bad index, and ensuing misery (Guillaume Quintard)
1270. Re: Bug: Xapian exception after having polled (Gaute Hope)
1271. Re: Bug: Xapian exception after having polled (William Morgan)
1272. Re: i18n? (William Morgan)
1273. Re: Crash while in thread-view-mode (Ben Gamari)
1274. Crash while in thread-view-mode (Ben Gamari)
1275. Re: Crash while in thread-view-mode (Ben Gamari)
1276. Re: next search in buffer view.. (William Morgan)
1277. Re: Crash while in thread-view-mode (Mark Alexander)
1278. Re: Ignore killed messages in U screen (William Morgan)
1279. Re: [PATCH] Add new :crypto_default configuration option.
(William Morgan)
1280. Re: On making inbox-mode and search-results-mode more
similar (William Morgan)
1281. Re: i18n? (Christopher Bertels)
1282. Re: i18n? (Christopher Bertels)
1283. Re: Bugfix for custom-search (Edward Z. Yang)
1284. curses exception (Dan Falcone)
1285. Re: curses exception (Dan Falcone)
1286. Re: Crash while in thread-view-mode (Rich Lane)
1287. Re: Crash while in thread-view-mode (Guillaume Quintard)
1288. Re: Crash while in thread-view-mode (Guillaume Quintard)
1289. [PATCH] Attachment filenames: RFC2184 and extension
guessing (Gregor Hoffleit)
1290. Fwd: Re: Crash while in thread-view-mode (Ben Gamari)
1291. Re: Crash while in thread-view-mode (Ben Gamari)
1292. Re: Feature Request: Collecting Lines in Index Mode
(Christian Dietrich)
1293. Re: Feature Request: Collecting Lines in Index Mode
(Christopher Bertels)
1294. Re: Feature Request: Collecting Lines in Index Mode
(Christopher Bertels)
1295. Re: Feature Request: Collecting Lines in Index Mode
(Christian Dietrich)
1296. Ruby 1.9 status? (Nicolas Pouillard)
1297. Re: Feature Request: Collecting Lines in Index Mode
(Christopher Bertels)
1298. Re: Feature Request: Collecting Lines in Index Mode (Gaute Hope)
1299. Re: Feature Request: Collecting Lines in Index Mode
(Beno?t PIERRE)
1300. Re: Feature Request: Collecting Lines in Index Mode (Gaute Hope)
1301. Re: Feature Request: Collecting Lines in Index Mode
(Beno?t PIERRE)
1302. Re: Feature Request: Collecting Lines in Index Mode
(Christian Dietrich)
1303. Re: Feature Request: Collecting Lines in Index Mode
(Christian Dietrich)
1304. Re: Feature Request: Collecting Lines in Index Mode (Gaute Hope)
1305. Re: Feature Request: Collecting Lines in Index Mode
(Christian Dietrich)
1306. Re: Feature Request: Collecting Lines in Index Mode (Gaute Hope)
1307. Re: Feature Request: Collecting Lines in Index Mode (Gaute Hope)
1308. Re: Feature Request: Collecting Lines in Index Mode
(Christian Dietrich)
1309. Re: Feature Request: Collecting Lines in Index Mode (Gaute Hope)
1310. [PATCH] moved deriving the cmd for bouncing to Account and
fixed a bug in it (Tero Tilus)
1311. pinentry-curses messes up sup (Sven Schober)
1312. show labels of polled messages (Christopher Bertels)
1313. Exception in thread-view-mode (Kevin Riggle)
1314. Re: pinentry-curses messes up sup (William Morgan)
1315. Re: Fwd: Re: Crash while in thread-view-mode (William Morgan)
1316. Re: curses exception (William Morgan)
1317. Re: Crash while scrolling (William Morgan)
1318. Re: Fwd: Re: Crash while in thread-view-mode (Ben Gamari)
1319. Re: Feature Request: Collecting Lines in Index Mode
(Christian Dietrich)
1320. Re: Ruby 1.9 status? (William Morgan)
1321. Re: [PATCH] Allow thread index view to sort oldest first
(William Morgan)
1322. Re: [PATCH] Add hooks to sort and format label-list-mode
display. (William Morgan)
1323. Re: [PATCH] don't downcase a nil content-type (William Morgan)
1324. Re: labels-before-subject and ask_for_contacts config knobs
(William Morgan)
1325. Re: labels-before-subject and ask_for_contacts config knobs
(William Morgan)
1326. Re: [PATCH] Handle added messages in label-list-mode
(William Morgan)
1327. Re: Bugfix for custom-search (William Morgan)
1328. Re: [PATCH] more inline GPG madness (William Morgan)
1329. Re: curses exception (Dan Falcone)
1330. Re: labels-before-subject and ask_for_contacts config knobs
(Marcus Williams)
1331. Re: Feature Request: Collecting Lines in Index Mode
(Christian Dietrich)
1332. Oddities of marking spam (Tero Tilus)
1333. Xapian: Term too long (Tero Tilus)
1334. Re: [PATCH] Allow thread index view to sort oldest first
(Carl Worth)
1335. RMail chokes on broken headers (Tero Tilus)
1336. Re: pinentry-curses messes up sup (Sven Schober)
1337. IMAP and recursion (Tero Tilus)
1338. Re: Fwd: Re: Crash while in thread-view-mode (Ben Gamari)
1339. Re: [PATCH] Allow thread index view to sort oldest first
(Olly Betts)
1340. Sup finds ghost messages (Tero Tilus)
1341. Wrapping long lines (Tero Tilus)
1342. About faking message IDs (Michael Stapelberg)
1343. Re: Crash while in thread-view-mode (William Morgan)
1344. Re: curses exception (William Morgan)
1345. Re: Oddities of marking spam (William Morgan)
1346. Re: Xapian: Term too long (William Morgan)
1347. Re: RMail chokes on broken headers (William Morgan)
1348. Re: Sup finds ghost messages (William Morgan)
1349. Re: Crash while in thread-view-mode (Guillaume Quintard)
1350. Re: About faking message IDs (William Morgan)
1351. before-edit hook and accessing the original sender
(Michael Stapelberg)
1352. Re: About faking message IDs (Michael Stapelberg)
1353. Re: curses exception (Dan Falcone)
1354. Re: Crash while in thread-view-mode (Ben Gamari)
1355. Re: Crash while in thread-view-mode (William Morgan)
1356. Re: curses exception (William Morgan)
1357. Re: About faking message IDs (William Morgan)
1358. Re: before-edit hook and accessing the original sender
(William Morgan)
1359. Indexing messages without ruby (Carl Worth)
1360. Re: About faking message IDs (Nicolas Pouillard)
1361. Re: About faking message IDs (Carl Worth)
1362. Re: [PATCH] more inline GPG madness (Michael Stapelberg)
----------------------------------------------------------------------
Message: 1
Date: Thu, 09 Apr 2009 11:02:08 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Saving status of merged threads with '#' on
next branch
Message-ID: <1239299963-sup-5933@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from =?UNKNOWN?Q?Bj=C3=B8rn?= Michelsen's message of 2009-04-08:
> I'm a bit lost as to where I should begin troubleshooting, so I'm
> wondering if someone else have had the same problem?
It's a known problem. I'm not sure why it isn't saved. If you want to
start investigating, ThreadSet#join_threads in lib/sup/threads.rb is the
joining code. Maybe the call to Message#add_ref is wrong somehow.
I'm also curious about your From: line, which is RFC2047-encoded but
with the "UNKNOWN" charset. What produces that? Surely not Sup!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 2
Date: Thu, 9 Apr 2009 11:37:40 -0700
From: Mark Alexander <marka@pobox.com>
To: Vikram Kumar <vikrambkumar@gmail.com>
Cc: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Sup and Cygwin
Message-ID:
<a412e2a70904091137x3e62dedcn3a498d22a7ac887d@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Apr 9, 2009 at 10:34 AM, Vikram Kumar <vikrambkumar@gmail.com> wrote:
> P.S - I couldn't find a way to search the message list archives.
Try the archive here:
http://www.nabble.com/SUP-Talk-f27890.html
------------------------------
Message: 3
Date: Thu, 09 Apr 2009 12:11:33 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup and Cygwin
Message-ID: <1239304198-sup-9672@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Vikram Kumar's message of 2009-04-09:
> Has anybody tried it before?
>
> $ sup
> /usr/lib/ruby/1.8/dl/import.rb:29:in `initialize': No such file or directory
> (RuntimeError)
Oh, that's a bug. I think you should be able to get around it by
changing the 'libc.so.6' on this line:
> from /usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup.rb:17
to 'cygwin1.dll'.
I'd be interested to know if that works. If so I'll fix it in git.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 4
Date: Fri, 10 Apr 2009 10:36:16 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Read only mode for sup
Message-ID: <1239352575-sup-724@ausone.inria.fr>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Thu Apr 09 19:30:09 +0200 2009:
> Reformatted excerpts from William Morgan's message of 2009-04-08:
> > One easy thing to comes to mind would be to have buffer-list-mode
> > (which is what you get when you hit B) sort the buffer list by last
> > access. Remap that to something like ";" and you have one-handed
> > buffer- switching with minimal keystrokes.
>
> Ok, I've done this on branch 'better-buffer-list', which I've merged
> into next. Pull and see how you guys like it. Summary:
>
> 1. 'b' rolls the buffer forward as usual.
> 2. 'B' now rolls the buffer backwards like in the olden days.
> 3. ';' pulls up the buffer list, which is now sorted by access time,
> colorized to show "system" vs non-"system" buffers, and has little
> stars for buffers with unsaved content.
> 4. '+' is now the apply-to-tagged command.
>
> Sorry for changing so many keymappings, but I really wanted ';' so that,
> with 'j' and 'k', you can swap buffers really quickly with just one
> hand. Since that freed up B, I figured I'd reenable the old behavior,
> and '+' kinda makes sense for apply-to-tagged anyways.
>
> Nicolas, I had to revert your "Buffer switching, 'bn' for the next one
> and 'bp' for the previous" change in next. I hope you're not offended! :)
I'm not offended, I just wanted to tend to more scalable bindings, where
a meaningful letter is kept to be the leading one for more advanced bindings
on a particular topic.
Moreover optimizing bindings for QUERTY keymap does not make sense for other
people... Personally I use and prefer DVORAK.
--
Nicolas Pouillard
------------------------------
Message: 5
Date: Fri, 10 Apr 2009 10:40:00 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk mailing list <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] brief master update
Message-ID: <1239352712-sup-3931@ausone.inria.fr>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Thu Apr 09 19:53:32 +0200 2009:
> I've merged these branches into master:
> - dont-canonicalize-email-addresses
> - multi-remove-labels
> - merge-labels
> - encoding-misspellings
> - background-save
>
> I'd like to do a little more work on undo, and fix the From problem, and
> then we can start thinking about an 0.8 release!
Great!
Just a small administrative question... Do we consider branches merged into
master as dead. That is making a new one if we want to improve again on this
topic?
--
Nicolas Pouillard
------------------------------
Message: 6
Date: Fri, 10 Apr 2009 05:23:02 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk mailing list <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] brief master update
Message-ID: <1239365949-sup-627@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Nicolas Pouillard's message of 2009-04-10:
> Just a small administrative question... Do we consider branches merged
> into master as dead. That is making a new one if we want to improve
> again on this topic?
Yes... I don't see a real point in adding more commits to the branch and
remerging once it's in master. I'm happy to apply trivial changes
directly to master, and anything non-trivial I prefer to test out in
next first.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 7
Date: Fri, 10 Apr 2009 05:24:15 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Read only mode for sup
Message-ID: <1239366212-sup-2213@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Nicolas Pouillard's message of 2009-04-10:
> Moreover optimizing bindings for QUERTY keymap does not make sense for
> other people... Personally I use and prefer DVORAK.
Uh oh. Well, time to get working on that configurable keymap patch...
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 8
Date: Fri, 10 Apr 2009 13:04:58 -0600
From: Lee Hinman <lee@writequit.org>
To: "Sup-talk@rubyforge.org" <sup-talk@rubyforge.org>
Subject: [sup-talk] Display size of message or attachments?
Message-ID: <1239390142-sup-9102@black>
Content-Type: text/plain; charset=UTF-8
Hey Sup'ers
Is there a way to display the total size of the message in your inbox?
(Including attachments). I wasn't able to find a way (other than saving
everything and doing it manually).
On the same note, is there a way I can see how big an attachment is on an
email? I know it shows up when sending email, but not on a retrieved email.
Thanks,
Lee
------------------------------
Message: 9
Date: Mon, 13 Apr 2009 07:56:08 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Display size of message or attachments?
Message-ID: <1239634495-sup-2172@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Lee Hinman's message of 2009-04-10:
> Is there a way to display the total size of the message in your inbox?
> (Including attachments). I wasn't able to find a way (other than
> saving everything and doing it manually).
This wouldn't be too hard but I'm not sure what the right UI would be.
Suggestions, anyone?
> On the same note, is there a way I can see how big an attachment is on
> an email? I know it shows up when sending email, but not on a
> retrieved email.
I've added this in git.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 10
Date: Mon, 13 Apr 2009 09:23:23 -0600
From: Lee Hinman <lee@writequit.org>
To: "Sup-talk@rubyforge.org" <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Display size of message or attachments?
Message-ID: <1239636103-sup-6606@black>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Mon Apr 13 08:56:08 -0600 2009:
> Reformatted excerpts from Lee Hinman's message of 2009-04-10:
> > Is there a way to display the total size of the message in your inbox?
> > (Including attachments). I wasn't able to find a way (other than
> > saving everything and doing it manually).
>
> This wouldn't be too hard but I'm not sure what the right UI would be.
> Suggestions, anyone?
How about this?:
8:56am [213k] me,William (2) >[sup-talk] Display size of message or attachments? +list +sup This wouldn't b...
> > On the same note, is there a way I can see how big an attachment is on
> > an email? I know it shows up when sending email, but not on a
> > retrieved email.
>
> I've added this in git.
Thanks!
- Lee
------------------------------
Message: 11
Date: Mon, 13 Apr 2009 10:00:56 -0600
From: Lee Hinman <lee@writequit.org>
To: "Sup-talk@rubyforge.org" <sup-talk@rubyforge.org>
Subject: [sup-talk] Suggestion for '.' keybinding
Message-ID: <1239638279-sup-6990@black>
Content-Type: text/plain; charset=UTF-8
Sup,
Since Sup already emulates vi-bindings, I was wondering if it'd be possible to
have '.' bound to "do-it-again". So if I added a label to a mail, then wanted
to apply it to a different mail, I could go to the mail and use '.' to apply
whatever the last change was. (I know I could tag all the messages ahead of
time and label them all at once, but sometimes I want to do it a different
way).
Is this possible with Sup right now? Does it store what the last action was?
(it might for the undo patch, I haven't looked at it)
- Lee
------------------------------
Message: 12
Date: Mon, 13 Apr 2009 16:19:34 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Display size of message or attachments?
Message-ID: <1239664684-sup-2594@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Lee Hinman's message of 2009-04-13:
> 8:56am [213k] me,William (2) >[sup-talk] Display size of message or
> attachments? +list +sup This wouldn't b...
What does the 213k refer to? The first message in this thread? The
newest message? All messages together? If you want per-message sizes,
it's going to have to go somewhere in thread-view-mode, methinks...
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 13
Date: Tue, 14 Apr 2009 06:59:13 -0600
From: Bryan Richardson <btricha@gmail.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] Sup with Microsoft Exchange 2007
Message-ID:
<3f81a4240904140559ubd286a5x2f026d6b875dd091@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hello all,
Has anyone had success using Sup with Microsoft Exchange 2007? I'm able to
download email no problem, and I'm also able to send email through my
exchange server. However, my problem lies in the fact that when I send an
email from Sup, it doesn't show up in the Sent Items folder of my exchange
account. I'm not that familiar with IMAP, but I'm guessing this is maybe
due to the fact that I haven't subscribed to the Sent Items folder in Sup.
In response to this, another hurdle I'm trying to get over is how to even
tell what folders are available on my exchange account for subscribing to.
Is there a way to use Sup to query for available folders?
Thanks in advance!
--
Bryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090414/3e816222/attachment-1350.html>
------------------------------
Message: 14
Date: Tue, 14 Apr 2009 09:53:15 -0700
From: Sean Escriva <sean.escriva@gmail.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] sup crashes when starting, here is the
exception-log
Message-ID: <20090414165314.GA19668@gmail.com>
Content-Type: text/plain; charset="us-ascii"
Sup-config worked flawlessly, sup-sync bombed out with the attached
sup-exception and trying to start sup generates the attached
exception-log
installed sw/gem verisons:
ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux]
ferret (0.11.6)
ncurses (0.9.1)
rmail (1.0.0)
highline (1.5.0)
net-ssh (2.0.11)
trollop (1.13)
lockfile (1.4.3)
mime-types (1.16)
Any help is appreciated, thanks
-------------- next part --------------
--- NoMethodError from thread: call #connect on mbox+ssh://optimus//var/mail/seane
undefined method `synchronize' for nil:NilClass
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/mbox/ssh-file.rb:181:in `unsafe_connect'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/mbox/ssh-file.rb:192:in `do_remote'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/mbox/ssh-file.rb:117:in `connect'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/mbox/ssh-loader.rb:37:in `connect'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/mbox/ssh-loader.rb:61:in `safely'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/mbox/ssh-loader.rb:37:in `connect'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/util.rb:538:in `send'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/util.rb:538:in `__pass'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/util.rb:525:in `method_missing'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/bin/sup:168
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup.rb:85:in `reporting_thread'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup.rb:83:in `initialize'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup.rb:83:in `new'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup.rb:83:in `reporting_thread'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/bin/sup:166
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/bin/sup:164:in `each'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/bin/sup:164
/usr/bin/sup:19:in `load'
/usr/bin/sup:19
--- NoMethodError from thread: call #connect on mbox+ssh://astrotrain//var/mail/webframp
undefined method `synchronize' for nil:NilClass
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/mbox/ssh-file.rb:181:in `unsafe_connect'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/mbox/ssh-file.rb:192:in `do_remote'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/mbox/ssh-file.rb:117:in `connect'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/mbox/ssh-loader.rb:37:in `connect'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/mbox/ssh-loader.rb:61:in `safely'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/mbox/ssh-loader.rb:37:in `connect'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/util.rb:538:in `send'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/util.rb:538:in `__pass'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/util.rb:525:in `method_missing'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/bin/sup:168
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup.rb:85:in `reporting_thread'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup.rb:83:in `initialize'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup.rb:83:in `new'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup.rb:83:in `reporting_thread'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/bin/sup:166
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/bin/sup:164:in `each'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/bin/sup:164
/usr/bin/sup:19:in `load'
/usr/bin/sup:19
-------------- next part --------------
[Tue Apr 14 09:34:16 -0700 2009] using character set encoding "UTF-8"
[Tue Apr 14 09:34:16 -0700 2009] crypto: detected gpg binary in /usr/bin/gpg
[Tue Apr 14 09:34:16 -0700 2009] locking /home/webframp/.sup/lock...
[Tue Apr 14 09:34:16 -0700 2009] loading index...
[Tue Apr 14 09:34:16 -0700 2009] loaded index of 0 messages
Scanning mbox+ssh://optimus//var/mail/seane...
[Tue Apr 14 09:34:16 -0700 2009] Opening SSH connection to optimus for /var/mail/seane...
[Tue Apr 14 09:34:16 -0700 2009] Checking for /var/mail/seane...
[Tue Apr 14 09:34:16 -0700 2009] unlocking /home/webframp/.sup/lock...
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/mbox/ssh-file.rb:181:in `unsafe_connect': undefined method `synchronize' for nil:NilClass (NoMethodError)
from /home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/mbox/ssh-file.rb:192:in `do_remote'
from /home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/mbox/ssh-file.rb:130:in `size'
from /home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/mbox/ssh-loader.rb:50:in `end_offset'
from /home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/mbox/ssh-loader.rb:61:in `safely'
from /home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/mbox/ssh-loader.rb:50:in `end_offset'
from /home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/source.rb:85:in `done?'
from /home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/util.rb:538:in `send'
from /home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/util.rb:538:in `__pass'
from /home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/util.rb:525:in `method_missing'
from /home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/poll.rb:139:in `add_messages_from'
from /home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/util.rb:499:in `send'
from /home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/util.rb:499:in `method_missing'
from /home/webframp/.gem/ruby/1.8/gems/sup-0.7/bin/sup-sync:136
from /home/webframp/.gem/ruby/1.8/gems/sup-0.7/bin/sup-sync:131:in `each'
from /home/webframp/.gem/ruby/1.8/gems/sup-0.7/bin/sup-sync:131
from /usr/bin/sup-sync:19:in `load'
from /usr/bin/sup-sync:19
------------------------------
Message: 15
Date: Wed, 15 Apr 2009 00:52:13 +0100
From: Iain <rhomunuq+ml_sup@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Display size of message or attachments?
Message-ID: <49E521AD.9070507@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Long time reader; first time poster. Massive thanks to everyone who's
worked on sup (in particular to William). I'm dabbling in sup again now
with the release of 0.7, which hasn't crashed on me at all so far, hooray!
> What does the 213k refer to? The first message in this thread? The
> newest message? All messages together? If you want per-message sizes,
> it's going to have to go somewhere in thread-view-mode, methinks...
Sounds like a potentially neat feature. I'd suggest:
- When viewing lists of threads (inbox-mode, search-results-mode,
etc), the combined size of all messages together in the thread.
- When viewing a particular thread (thread-view-mode), showing
individually for each message.
Alternatively (or in addition?), perhaps even better would be the
ability to do searches like size:>200k, which would show all messages
(or all threads?) over 200k in size.
This would be useful for people like me who prune excessively large
attachments from disk occasionally. (Which at present is a little
fiddly, involving messing with the Maildir-stored messages then
sup-sync'ing, but that's another story...)
Cheers,
~Iain
------------------------------
Message: 16
Date: Wed, 15 Apr 2009 17:58:03 +0200
From: Bjorn Michelsen <bm@bjornmichelsen.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Saving status of merged threads with '#' on
next branch
Message-ID: <1239810733-sup-5572@snowstorm>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of to. april 09 20:02:08 +0200 2009:
> > I'm a bit lost as to where I should begin troubleshooting, so I'm
> > wondering if someone else have had the same problem?
>
> It's a known problem. I'm not sure why it isn't saved. If you want to
> start investigating, ThreadSet#join_threads in lib/sup/threads.rb is the
> joining code. Maybe the call to Message#add_ref is wrong somehow.
Thanks for clearing that up, as well as the additional information
regarding where to start looking.
> I'm also curious about your From: line, which is RFC2047-encoded but
> with the "UNKNOWN" charset. What produces that? Surely not Sup!
I haven't replied earlier because I've been trying to figure out what
causes the strange From: address.
locale outputs the following:
LANG=nb_NO.UTF-8
LC_CTYPE=nb_NO.UTF-8
LC_NUMERIC="nb_NO.UTF-8"
LC_TIME="nb_NO.UTF-8"
LC_COLLATE="nb_NO.UTF-8"
LC_MONETARY="nb_NO.UTF-8"
LC_MESSAGES=en_US.UTF-8
LC_PAPER="nb_NO.UTF-8"
LC_NAME="nb_NO.UTF-8"
LC_ADDRESS="nb_NO.UTF-8"
LC_TELEPHONE="nb_NO.UTF-8"
LC_MEASUREMENT="nb_NO.UTF-8"
LC_IDENTIFICATION="nb_NO.UTF-8"
LC_ALL=
And Vim is saying that all files related to sup is encoded as utf8.
So, at the moment I don't know why this is happening. Maybe someone
using special characters can let me in on their secret?
--
Mvh.
Bj?rn Michelsen
MOB: +47 934 55 474
------------------------------
Message: 17
Date: Wed, 15 Apr 2009 18:29:15 +0100
From: Iain <rhomunuq+ml_sup@gmail.com>
To: sup-talk mailing list <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Lost Maildir Messages
Message-ID: <49E6196B.504@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Hm, that would be bad. The right way to debug this is to wait for it to
> happen again (!) and examine the contents of the poll-mode and log-mode
> buffers, which should describe what Sup thinks it was doing at the time.
I've noticed what seems to be the same problem.
I've been using getmail (no procmail or fetchmail), to grab messages
into Maildir folders. Occasionally, messages don't show up in Sup. They
appear only when I do a manual sup-sync --changed.
I discovered by accident (by impatiently trying to read an email that I
knew was being delivered by getmail into Sup) that I can reliably
replicate the problem, or at least a similar problem. It seems to occur
when Sup polls the Maildir at the same time as getmail is retrieving the
message.
I can replicate the problem by pressing P repeatedly in Sup to manually
poll for messages, while getmail is in the process of retrieving. (It
takes about 4 seconds for getmail to go from initialising a retrieval to
dropping the mail in the Maildir, so there is a big window for when I
press P, and I can replicate the problem reliably.) Every time, Sup
doesn't retrieve the new messages.
The log-mode buffer doesn't show anything relevant in my
artifically-produced replication of the problem, because it doesn't log
when you manually poll.
The poll-mode buffer for the source in question displays the exact same
message on every poll of the source (before getmail runs, during the
getmail run, after the getmail run) when repeatedly polling before and
during the getmail run:
Loading from maildir:///home/user/Mail/address@example.com/...
Found message at 12398138490002177 with labels {mylabel}
-- the timestamp never changes.
If I had to guess, I'd say that it looks like the shortcut taken
(looking at the mtime of the directory to see if scanning for a new
Maildir message is required) has a race condition. A weird race
condition, because I've verified (ls -l --time-style=+%s) that the "new"
and "tmp" folders are indeed having their timestamps updated when the
mail drops in (they are).
This might explain the infrequent lost messages: when not hitting P
repeatedly, this race condition is unlikely to occur, only happening
when the Sup poll occurs within the few seconds window during which
getmail is working and working with a new message to deliver.
~Iain
------------------------------
Message: 18
Date: Wed, 15 Apr 2009 10:33:24 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Saving status of merged threads with '#' on
next branch
Message-ID: <1239816596-sup-2531@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Bjorn Michelsen's message of 2009-04-15:
> I haven't replied earlier because I've been trying to figure out what
> causes the strange From: address.
Is the weird encoding also present in the files in ~/.sup/sent.mbox? If
so, it's could be Rubymail... AFAICT, Rubymail doesn't do anything with
rfc2047, but I could have missed it.
If not, are you using some funky sendmail?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 19
Date: Wed, 15 Apr 2009 13:04:47 -0700
From: Mark Alexander <marka@pobox.com>
To: Iain <rhomunuq+ml_sup@gmail.com>
Cc: sup-talk mailing list <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Lost Maildir Messages
Message-ID:
<a412e2a70904151304n28e9add1tafe5a815259a1b8c@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Wed, Apr 15, 2009 at 10:29 AM, Iain <rhomunuq+ml_sup@gmail.com> wrote:
> I discovered by accident (by impatiently trying to read an email that I knew
> was being delivered by getmail into Sup) that I can reliably replicate the
> problem, or at least a similar problem. It seems to occur when Sup polls the
> Maildir at the same time as getmail is retrieving the message.
I thought this might be the problem with my lost messages. So I
changed my setup so that I don't have fetchmail running as a daemon
when sup is running. Instead, I have sup running fetchmail whenever
it polls. But I'm still getting lost messages, maybe 5 per day (out
of hundreds of message). So there may be two problems here.
I've started writing some debugging code to see if I can track down
these lost messages. Attached is a little program that parses a
procmail log file, and checks to see if each message mentioned in the
log also appears in the ferret index. It's got some ugly hacks for my
particular setup (e.g., the checks for the "vd" and "rd" directories,
which I need to ignore in my case, and the hardcoded Maildir
directory path). But maybe it'll prove useful to
others who are using procmail.
I invoke this script from the sup source directory using:
ruby -I lib procmail.rb /home/marka/Maildir/procmail.log
I have this in my ~/.procmailrc to enable logging:
LOGFILE=/home/marka/Maildir/procmail.log
-------------- next part --------------
A non-text attachment was scrubbed...
Name: procmail.rb
Type: application/octet-stream
Size: 1156 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090415/e1b15a73/attachment-0001.obj>
------------------------------
Message: 20
Date: Thu, 16 Apr 2009 11:53:31 +0200
From: Bjorn Michelsen <bm@bjornmichelsen.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Saving status of merged threads with '#' on
next branch
Message-ID: <1239875483-sup-5697@snowstorm>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of on. april 15 19:33:24 +0200 2009:
> > I haven't replied earlier because I've been trying to figure out what
> > causes the strange From: address.
>
> Is the weird encoding also present in the files in ~/.sup/sent.mbox? If
> so, it's could be Rubymail... AFAICT, Rubymail doesn't do anything with
> rfc2047, but I could have missed it.
No, everything is encoded correctly in ~/.sup/sent.mbox
> If not, are you using some funky sendmail?
I'm using sSMTP at the moment. Maybe it has something to do with the
following bug
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=341952#10 ?
--
Mvh.
Bj?rn Michelsen
MOB: +47 934 55 474
------------------------------
Message: 21
Date: Thu, 16 Apr 2009 21:47:31 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: Lee Hinman <lee@writequit.org>
Cc: "Sup-talk@rubyforge.org" <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Suggestion for '.' keybinding
Message-ID: <1239911250-sup-9394@ausone>
Content-Type: text/plain; charset=UTF-8
Excerpts from Lee Hinman's message of Mon Apr 13 18:00:56 +0200 2009:
> Sup,
> Since Sup already emulates vi-bindings, I was wondering if it'd be possible to
> have '.' bound to "do-it-again". So if I added a label to a mail, then wanted
> to apply it to a different mail, I could go to the mail and use '.' to apply
> whatever the last change was. (I know I could tag all the messages ahead of
> time and label them all at once, but sometimes I want to do it a different
> way).
>
> Is this possible with Sup right now? Does it store what the last action was?
> (it might for the undo patch, I haven't looked at it)
I greatly support this idea!
--
Nicolas Pouillard
------------------------------
Message: 22
Date: Thu, 16 Apr 2009 15:05:59 -0700
From: Mark Alexander <marka@pobox.com>
To: sup-talk mailing list <sup-talk@rubyforge.org>
Subject: [sup-talk] Possible problem with maildir ID generation
Message-ID:
<a412e2a70904161505l3e1fdfc9l987013130b3f5ddd@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
I've been studying maildir.rb (and adding some debug code) while
trying to figure out my lost message problem. I think there may be a
problem with the way the internal message IDs are generated. The
make_id method glues together the file timestamp and size. But I
think this could lead to an out-of-order problem in the @ids array.
Consider two messages that arrive in the same second, but the second
message is smaller than the first. Because the message size makes up
the low seven (decimal) digits of the ID, the second message, even
though it arrived later, will have an ID that is less than the first
message.
Then suppose that sup polls the maildir directory after the first
message arrives, but before the second message arrives, and sets the
cur_offset to the ID of the first message. Then, the next time it
polls, it will see the second message, but because its ID is less than
that of the first message, it will appear before the first in the @ids
array after it is sorted. So then the each method will skip the
second message, because cur_offset (the ID of the first message) will
be found in @ids after it.
Does this scenario make sense? I have seen what appears to be one
instance of this happening, though I'm still watching closely and
adding more debugging code to make sure that it explains all of the
lost messages.
------------------------------
Message: 23
Date: Fri, 17 Apr 2009 15:41:12 -0400
From: Reid Thompson <reid.thompson@ateb.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] Two questions
Message-ID: <1239997272.5948.104.camel@localhost>
Content-Type: text/plain
>From the readme:
Note that Sup never changes the contents of any mailboxes; it only
indexes in to them. So it shouldn't ever corrupt your mail. The flip
side is that if you change a mailbox (e.g. delete messages, or, in
the case of mbox files, read an unread message) then Sup will be
unable to load messages from that source and will ask you to run
sup-sync --changed.
So, in order to actually manage my email, I have to utilize a different email client to delete unwanted mail - essentially doing the same work twice, or am I missing something?
Could sup-sync --changed be incorporated into sup, and triggered automatically by sup itself?
------------------------------
Message: 24
Date: Mon, 20 Apr 2009 15:52:24 -0600
From: Bryan Richardson <btricha@gmail.com>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Sup with Microsoft Exchange 2007
Message-ID:
<3f81a4240904201452u78abe68bj2a4b9863b850e8a@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
BUMP!!!
So... no one uses Sup with Microsoft Exchange?! :(
--
Bryan
On 4/14/09, Bryan Richardson <btricha@gmail.com> wrote:
> Hello all,
>
> Has anyone had success using Sup with Microsoft Exchange 2007? I'm able to
> download email no problem, and I'm also able to send email through my
> exchange server. However, my problem lies in the fact that when I send an
> email from Sup, it doesn't show up in the Sent Items folder of my exchange
> account. I'm not that familiar with IMAP, but I'm guessing this is maybe
> due to the fact that I haven't subscribed to the Sent Items folder in Sup.
> In response to this, another hurdle I'm trying to get over is how to even
> tell what folders are available on my exchange account for subscribing to.
> Is there a way to use Sup to query for available folders?
>
> Thanks in advance!
>
> --
> Bryan
>
------------------------------
Message: 25
Date: Mon, 20 Apr 2009 15:54:57 -0700
From: Mark Alexander <marka@pobox.com>
To: Bryan Richardson <btricha@gmail.com>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup with Microsoft Exchange 2007
Message-ID: <1240267632-sup-2023@r50p>
Content-Type: text/plain; charset=UTF-8
Excerpts from Bryan Richardson's message of Mon Apr 20 14:52:24 -0700 2009:
> So... no one uses Sup with Microsoft Exchange?! :(
Unfortunately, we use Exchange at work. But I hide that unpleasant
fact from myself by using fetchmail and postfix on a Linux box. I
have never used Outlook or the web interface that Exchange provides.
Instead, I've always used mutt -- and more recently, sup. So I have
no idea if I'm having the same problem you are. Sorry!
------------------------------
Message: 26
Date: Mon, 20 Apr 2009 17:38:01 -0600
From: Bryan Richardson <btricha@gmail.com>
To: Mark Alexander <marka@pobox.com>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup with Microsoft Exchange 2007
Message-ID:
<3f81a4240904201638v94a7dbdpce0d865cd83d8873@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I guess my main question is this:
Is it possible to specify where my sent mail gets saved? I'd like to be
able to specify that it gets saved in one of my IMAP folders ('Sent Items'
in my Microsoft Exchange account). This way, if for some reason I do ever
have to access my mail via Microsoft Exchange Web Access, I'll still have
access to all my sent emails.
On Mon, Apr 20, 2009 at 4:54 PM, Mark Alexander <marka@pobox.com> wrote:
> Excerpts from Bryan Richardson's message of Mon Apr 20 14:52:24 -0700 2009:
> > So... no one uses Sup with Microsoft Exchange?! :(
>
> Unfortunately, we use Exchange at work. But I hide that unpleasant
> fact from myself by using fetchmail and postfix on a Linux box. I
> have never used Outlook or the web interface that Exchange provides.
> Instead, I've always used mutt -- and more recently, sup. So I have
> no idea if I'm having the same problem you are. Sorry!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090420/d51dfe3f/attachment-0001.html>
------------------------------
Message: 27
Date: Tue, 21 Apr 2009 06:02:35 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup with Microsoft Exchange 2007
Message-ID: <1240318807-sup-3080@entry>
Content-Type: text/plain; charset=UTF-8
Hi Bryan,
Reformatted excerpts from Bryan Richardson's message of 2009-04-20:
> Is it possible to specify where my sent mail gets saved? I'd like to
> be able to specify that it gets saved in one of my IMAP folders ('Sent
> Items' in my Microsoft Exchange account). This way, if for some
> reason I do ever have to access my mail via Microsoft Exchange Web
> Access, I'll still have access to all my sent emails.
This is currently not possible with Sup, which as a rule doesn't play
nicely with other mail clients. It wouldn't be terribly hard to add if
you were so inclined (we have an IMAP library in there already) and I'd
be happy to point you in the right direction, but it's not on my
near-term list of things to do.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 28
Date: Tue, 21 Apr 2009 06:06:24 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Two questions
Message-ID: <1240318974-sup-6743@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Reid Thompson's message of 2009-04-17:
> So, in order to actually manage my email, I have to utilize a
> different email client to delete unwanted mail - essentially doing the
> same work twice, or am I missing something?
For the two special cases of "physically" removing messages marked as
deleted or spam, you can use sup-sync-back, which is a batch operation
operating on an entire mail source at a time. Currently it only applies
to mbox sources and can't be run while Sup is also running.
> Could sup-sync --changed be incorporated into sup, and triggered
> automatically by sup itself?
You could certainly do that via Sup's hook mechanism, but it's a very
slow operation (it has to scan over the entire mailbox).
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 29
Date: Tue, 21 Apr 2009 09:13:54 -0400
From: Reid Thompson <reid.thompson@ateb.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Two questions
Message-ID: <1240319634.11793.11.camel@localhost>
Content-Type: text/plain
On Tue, 2009-04-21 at 06:06 -0700, William Morgan wrote:
> Reformatted excerpts from Reid Thompson's message of 2009-04-17:
> > So, in order to actually manage my email, I have to utilize a
> > different email client to delete unwanted mail - essentially doing the
> > same work twice, or am I missing something?
>
> For the two special cases of "physically" removing messages marked as
> deleted or spam, you can use sup-sync-back, which is a batch operation
> operating on an entire mail source at a time. Currently it only applies
> to mbox sources and can't be run while Sup is also running.
>
> > Could sup-sync --changed be incorporated into sup, and triggered
> > automatically by sup itself?
>
> You could certainly do that via Sup's hook mechanism, but it's a very
> slow operation (it has to scan over the entire mailbox).
OK -- so to 'manage' an imap store, i'd need to setup a mechanism to
fetch all the email to a local store, deleting from the imap store, and
then do something like schedule an overnight run of sup-sync-back,
------------------------------
Message: 30
Date: Tue, 21 Apr 2009 06:28:41 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Saving status of merged threads with '#' on
next branch
Message-ID: <1240320083-sup-2514@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Bjorn Michelsen's message of 2009-04-16:
> No, everything is encoded correctly in ~/.sup/sent.mbox
Then this is almost definitely your MTA, not Sup. But you could also try
sending a message to yourself with another MUA and see what happens.
(Probably what will happen is that the MUA will RFC2047-encode your
headers, and sSMTP will see that and leave them alone, and this problem
will be hidden. So the right answer is really for Sup to RFC2047-encode
headers in outgoing email.)
> I'm using sSMTP at the moment. Maybe it has something to do with the
> following bug
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=341952#10 ?
The problem could be someone trying to fix that bug (which is basically
"we should add RFC2047 support"). Somehow it's not picking up your
locale settings.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 31
Date: Tue, 21 Apr 2009 07:42:42 -0600
From: Bryan Richardson <btricha@gmail.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup with Microsoft Exchange 2007
Message-ID:
<3f81a4240904210642o9c74049o27e164e317d0842e@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi William,
First off, I want to say 'Thank You' for creating such a great application
here. Text-based is the way to go! :)
As for saving sent mail in an IMAP folder, I did find a patch that I was
able to use to provide me with this functionality.
One question I do have though is why my sent messages get saved to my 'Sent
Mail' folder on my GMail account automatically (without the patch I
mentioned above) when I use Sup with GMail...
As a side note, does Sup have any sort of plugin architecture? I'm thinking
of maybe developing a text-based calendar app in Ruby at some point... :)
--
Thanks!
Bryan
On Tue, Apr 21, 2009 at 7:02 AM, William Morgan <wmorgan-sup@masanjin.net>wrote:
> Hi Bryan,
>
> Reformatted excerpts from Bryan Richardson's message of 2009-04-20:
> > Is it possible to specify where my sent mail gets saved? I'd like to
> > be able to specify that it gets saved in one of my IMAP folders ('Sent
> > Items' in my Microsoft Exchange account). This way, if for some
> > reason I do ever have to access my mail via Microsoft Exchange Web
> > Access, I'll still have access to all my sent emails.
>
> This is currently not possible with Sup, which as a rule doesn't play
> nicely with other mail clients. It wouldn't be terribly hard to add if
> you were so inclined (we have an IMAP library in there already) and I'd
> be happy to point you in the right direction, but it's not on my
> near-term list of things to do.
> --
> William <wmorgan-sup@masanjin.net>
> _______________________________________________
> sup-talk mailing list
> sup-talk@rubyforge.org
> http://rubyforge.org/mailman/listinfo/sup-talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090421/1e4467d1/attachment-0001.html>
------------------------------
Message: 32
Date: Tue, 21 Apr 2009 06:48:39 -0700
From: Andrew Pimlott <andrew@pimlott.net>
To: Bryan Richardson <btricha@gmail.com>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup with Microsoft Exchange 2007
Message-ID: <20090421134839.GY11701@pimlott.net>
Content-Type: text/plain; charset=us-ascii
On Tue, Apr 21, 2009 at 07:42:42AM -0600, Bryan Richardson wrote:
> One question I do have though is why my sent messages get saved to my 'Sent
> Mail' folder on my GMail account automatically (without the patch I
> mentioned above) when I use Sup with GMail...
GMail's SMTP server does this.
Andrew
------------------------------
Message: 33
Date: Tue, 21 Apr 2009 07:00:30 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Possible problem with maildir ID generation
Message-ID: <1240320547-sup-6957@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Mark Alexander's message of 2009-04-16:
> Consider two messages that arrive in the same second, but the second
> message is smaller than the first. Because the message size makes up
> the low seven (decimal) digits of the ID, the second message, even
> though it arrived later, will have an ID that is less than the first
> message.
I think you could be right. Using the size as part of the ID was
supposed to differentiate messages with the same timestamp, but it would
result in exactly the behavior you describe when polling.
I think there's a much simpler scheme we can use that will also fix
this. I'll post a patch soon and we can see if it addresses the
problem.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 34
Date: Tue, 21 Apr 2009 07:13:48 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup with Microsoft Exchange 2007
Message-ID: <1240323082-sup-1515@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Bryan Richardson's message of 2009-04-21:
> First off, I want to say 'Thank You' for creating such a great
> application here. Text-based is the way to go! :)
Glad you like it!
> As for saving sent mail in an IMAP folder, I did find a patch that I
> was able to use to provide me with this functionality.
Interesting. Would you mind reposting it here, if you get a chance?
> One question I do have though is why my sent messages get saved to my
> 'Sent Mail' folder on my GMail account automatically (without the
> patch I mentioned above) when I use Sup with GMail...
As someone else pointed out, this is because GMail's MTA is clever.
> As a side note, does Sup have any sort of plugin architecture? I'm
> thinking of maybe developing a text-based calendar app in Ruby at some
> point... :)
It doesn't have plugins per se. It has a pretty good hook system, but
that's probably not useful to you. What are you interested in using? The
ncurses interface? The full-text search index?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 35
Date: Tue, 21 Apr 2009 07:26:20 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Two questions
Message-ID: <1240323252-sup-1276@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Reid Thompson's message of 2009-04-21:
> OK -- so to 'manage' an imap store, i'd need to setup a mechanism to
> fetch all the email to a local store, deleting from the imap store,
> and then do something like schedule an overnight run of sup-sync-back,
There are a couple issues at play. First, if you're serious about Sup
with IMAP, many people have gone the route of mirroring their IMAP
folders locally using something like offlineimap. The Ruby IMAP
libraries, and possibly IMAP itself, is otherwise too slow for how Sup
likes to treat its mailstores.
But that's not strictly necessary.
Second, if you're serious about deleting email from your IMAP server (as
opposed to just letting it stay there forever, since storage is cheap
and the too-fleeting moments of your precious mortality are not), you'll
need to periodically run sup-sync-back with the appropriate flags.
This all stems from design decisions around Sup's target environment,
which is that you have too much email to scan every message except in an
offline manner. I have 229k emails in my inbox. Sup's the only client
I know of that can scale to that. (Besides GMail of course.)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 36
Date: Tue, 21 Apr 2009 08:28:11 -0600
From: Bryan Richardson <btricha@gmail.com>
To: Andrew Pimlott <andrew@pimlott.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup with Microsoft Exchange 2007
Message-ID:
<3f81a4240904210728j6b9e05a8x61f9aab6ebf3614c@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Ah, I see. Thanks Andrew. If only Microsoft could be as smart as Google...
:)
On Tue, Apr 21, 2009 at 7:48 AM, Andrew Pimlott <andrew@pimlott.net> wrote:
> On Tue, Apr 21, 2009 at 07:42:42AM -0600, Bryan Richardson wrote:
> > One question I do have though is why my sent messages get saved to my
> 'Sent
> > Mail' folder on my GMail account automatically (without the patch I
> > mentioned above) when I use Sup with GMail...
>
> GMail's SMTP server does this.
>
> Andrew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090421/161a4c33/attachment-0001.html>
------------------------------
Message: 37
Date: Tue, 21 Apr 2009 08:29:23 -0600
From: Bryan Richardson <btricha@gmail.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup with Microsoft Exchange 2007
Message-ID:
<3f81a4240904210729h74ac436bn9e1140cf7021c5ad@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Yeah, I'll find the patch and post it here.
As for the calendaring app, I figured having it integrated with Sup might be
kinda cool. The search index might help too. :)
On Tue, Apr 21, 2009 at 8:13 AM, William Morgan <wmorgan-sup@masanjin.net>wrote:
> Reformatted excerpts from Bryan Richardson's message of 2009-04-21:
> > First off, I want to say 'Thank You' for creating such a great
> > application here. Text-based is the way to go! :)
>
> Glad you like it!
>
> > As for saving sent mail in an IMAP folder, I did find a patch that I
> > was able to use to provide me with this functionality.
>
> Interesting. Would you mind reposting it here, if you get a chance?
>
> > One question I do have though is why my sent messages get saved to my
> > 'Sent Mail' folder on my GMail account automatically (without the
> > patch I mentioned above) when I use Sup with GMail...
>
> As someone else pointed out, this is because GMail's MTA is clever.
>
> > As a side note, does Sup have any sort of plugin architecture? I'm
> > thinking of maybe developing a text-based calendar app in Ruby at some
> > point... :)
>
> It doesn't have plugins per se. It has a pretty good hook system, but
> that's probably not useful to you. What are you interested in using? The
> ncurses interface? The full-text search index?
> --
> William <wmorgan-sup@masanjin.net>
> _______________________________________________
> sup-talk mailing list
> sup-talk@rubyforge.org
> http://rubyforge.org/mailman/listinfo/sup-talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090421/13efa4bf/attachment-0001.html>
------------------------------
Message: 38
Date: Tue, 21 Apr 2009 08:32:02 -0600
From: Bryan Richardson <btricha@gmail.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup with Microsoft Exchange 2007
Message-ID:
<3f81a4240904210732k11366cf7naec562af54ecabac@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
The patch for what the author (Ben Walton) calls 'Flexible Sent Source' can
be found at the following URL. It would be nice to have this integrated
into the official Sup source code... :)
http://www.nabble.com/-PATCH--flexible-sent-source-td16960901.html#a16960901
One more question: I noticed when I use Sup with my Exchange account that it
marks all my messages on the Exchange server as read when it syncs. Is this
normal?
On Tue, Apr 21, 2009 at 8:29 AM, Bryan Richardson <btricha@gmail.com> wrote:
> Yeah, I'll find the patch and post it here.
>
> As for the calendaring app, I figured having it integrated with Sup might
> be kinda cool. The search index might help too. :)
>
>
> On Tue, Apr 21, 2009 at 8:13 AM, William Morgan <wmorgan-sup@masanjin.net>wrote:
>
>> Reformatted excerpts from Bryan Richardson's message of 2009-04-21:
>> > First off, I want to say 'Thank You' for creating such a great
>> > application here. Text-based is the way to go! :)
>>
>> Glad you like it!
>>
>> > As for saving sent mail in an IMAP folder, I did find a patch that I
>> > was able to use to provide me with this functionality.
>>
>> Interesting. Would you mind reposting it here, if you get a chance?
>>
>> > One question I do have though is why my sent messages get saved to my
>> > 'Sent Mail' folder on my GMail account automatically (without the
>> > patch I mentioned above) when I use Sup with GMail...
>>
>> As someone else pointed out, this is because GMail's MTA is clever.
>>
>> > As a side note, does Sup have any sort of plugin architecture? I'm
>> > thinking of maybe developing a text-based calendar app in Ruby at some
>> > point... :)
>>
>> It doesn't have plugins per se. It has a pretty good hook system, but
>> that's probably not useful to you. What are you interested in using? The
>> ncurses interface? The full-text search index?
>> --
>> William <wmorgan-sup@masanjin.net>
>> _______________________________________________
>> sup-talk mailing list
>> sup-talk@rubyforge.org
>> http://rubyforge.org/mailman/listinfo/sup-talk
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090421/0f64130f/attachment-0001.html>
------------------------------
Message: 39
Date: Tue, 21 Apr 2009 10:37:25 -0400
From: Ben Walton <bdwalton@gmail.com>
To: Bryan Richardson <btricha@gmail.com>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup with Microsoft Exchange 2007
Message-ID:
<f96e0240904210737q71765989of31447a8de20fa62@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
I abandoned that patch for my own use after a while. [I moved my .sup
to local storage from nfs and now use the mbox sent folder.] I still
like the idea, but that patch would need much work before it became
integration worthy. If there is sufficient interest, I'd invest the
time.
William, what requirements would need to be met from your side to see
this added?
Thanks
-Ben
On Tue, Apr 21, 2009 at 10:32 AM, Bryan Richardson <btricha@gmail.com> wrote:
> The patch for what the author (Ben Walton) calls 'Flexible Sent Source' can
> be found at the following URL.? It would be nice to have this integrated
> into the official Sup source code... :)
>
> http://www.nabble.com/-PATCH--flexible-sent-source-td16960901.html#a16960901
>
> One more question: I noticed when I use Sup with my Exchange account that it
> marks all my messages on the Exchange server as read when it syncs.? Is this
> normal?
>
> On Tue, Apr 21, 2009 at 8:29 AM, Bryan Richardson <btricha@gmail.com> wrote:
>>
>> Yeah, I'll find the patch and post it here.
>>
>> As for the calendaring app, I figured having it integrated with Sup might
>> be kinda cool.? The search index might help too. :)
>>
>> On Tue, Apr 21, 2009 at 8:13 AM, William Morgan <wmorgan-sup@masanjin.net>
>> wrote:
>>>
>>> Reformatted excerpts from Bryan Richardson's message of 2009-04-21:
>>> > First off, I want to say 'Thank You' for creating such a great
>>> > application here. ?Text-based is the way to go! :)
>>>
>>> Glad you like it!
>>>
>>> > As for saving sent mail in an IMAP folder, I did find a patch that I
>>> > was able to use to provide me with this functionality.
>>>
>>> Interesting. Would you mind reposting it here, if you get a chance?
>>>
>>> > One question I do have though is why my sent messages get saved to my
>>> > 'Sent Mail' folder on my GMail account automatically (without the
>>> > patch I mentioned above) when I use Sup with GMail...
>>>
>>> As someone else pointed out, this is because GMail's MTA is clever.
>>>
>>> > As a side note, does Sup have any sort of plugin architecture? ?I'm
>>> > thinking of maybe developing a text-based calendar app in Ruby at some
>>> > point... :)
>>>
>>> It doesn't have plugins per se. It has a pretty good hook system, but
>>> that's probably not useful to you. What are you interested in using? The
>>> ncurses interface? The full-text search index?
>>> --
>>> William <wmorgan-sup@masanjin.net>
>>> _______________________________________________
>>> sup-talk mailing list
>>> sup-talk@rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/sup-talk
>>
>
>
> _______________________________________________
> sup-talk mailing list
> sup-talk@rubyforge.org
> http://rubyforge.org/mailman/listinfo/sup-talk
>
>
--
---------------------------------------------------------------------------------------------------------------------------
Ben Walton <bdwalton@gmail.com>
"With or without religion, good people can behave well and bad people
can do evil; but for good people to do evil?that takes religion. "
-Steven Weinberg
---------------------------------------------------------------------------------------------------------------------------
------------------------------
Message: 40
Date: Tue, 21 Apr 2009 08:33:17 -0700
From: Mark Alexander <marka@pobox.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Possible problem with maildir ID generation
Message-ID:
<a412e2a70904210833r48c78a8ah5c19779cd8b99b53@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Apr 21, 2009 at 7:00 AM, William Morgan
<wmorgan-sup@masanjin.net> wrote:
> I think you could be right. Using the size as part of the ID was
> supposed to differentiate messages with the same timestamp, but it would
> result in exactly the behavior you describe when polling.
>
> I think there's a much simpler scheme we can use that will also fix
> this. I'll post a patch soon and we can see if it addresses the
> problem.
I'd be very interested in this patch.
In the meantime, I made some minor changes to maildir.rb, without
changing the ID scheme. One problem was every time a maildir was
polled, the most recent message (i.e., the one at cur_offset) would be
treated as a new message again. I also changed last_offset to return
an ID that would be one second later than the last message seen.
These changes seem to have mostly fixed the lost message problem I was
having, though I'm not exactly sure why. I've only had one lost
message over the last couple of days, instead of the expected 10 or
20. I can't explain this one lost message, but I think it must be due
to a different problem, unrelated to maildir handling. I was able to
get sup to see this message again by doing a 'touch' on both the
message itself and the containing maildir.
I doubt that my changes would fix the race condition I described
earlier, but I've avoided this problem by not running fetchmail
in the background while sup is running.
I'll send out my patch in a separate email.
------------------------------
Message: 41
Date: Tue, 21 Apr 2009 08:43:44 -0700
From: Mark Alexander <marka@pobox.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] [PATCH] Bug fixes and speed improvements for
maildir handling.
Message-ID:
<a412e2a70904210843p6410e83dyabccb3dec5c9fd0a@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
---
lib/sup/maildir.rb | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/lib/sup/maildir.rb b/lib/sup/maildir.rb
index 3d584f7..d74279a 100644
--- a/lib/sup/maildir.rb
+++ b/lib/sup/maildir.rb
@@ -10,6 +10,7 @@ module Redwood
class Maildir < Source
SCAN_INTERVAL = 30 # seconds
+ TIME_SCALE = 10000000
## remind me never to use inheritance again.
yaml_properties :uri, :cur_offset, :usual, :archived, :id, :labels, :mtimes
@@ -123,8 +124,11 @@ class Maildir < Source
return unless start_offset
start = @ids.index(cur_offset || start_offset) or raise
OutOfSyncSourceError, "Unknown message id #{cur_offset ||
start_offset}." # couldn't find the most recent email
+ if cur_offset
+ start += 1
+ end
- start.upto(@ids.length - 1) do |i|
+ (start...@ids.length).each do |i|
id = @ids[i]
self.cur_offset = id
yield id, @labels + (seen?(id) ? [] : [:unread]) +
(trashed?(id) ? [:deleted] : []) + (flagged?(id) ? [:starred] : [])
@@ -138,7 +142,7 @@ class Maildir < Source
def end_offset
scan_mailbox :rescan => true
- @ids.last + 1
+ ((@ids.last / TIME_SCALE) + 1) * TIME_SCALE
end
def pct_done; 100.0 * (@ids.index(cur_offset) || 0).to_f /
(@ids.length - 1).to_f; end
@@ -164,7 +168,7 @@ private
#makes a noticeable difference on nfs.
stat = File.stat(fn)
# use 7 digits for the size. why 7? seems nice.
- sprintf("%d%07d", stat.mtime, stat.size % 10000000).to_i
+ (stat.mtime.to_i * TIME_SCALE) + (stat.size % TIME_SCALE)
end
def with_file_for id
--
1.6.1.28.gc32f76
------------------------------
Message: 42
Date: Tue, 21 Apr 2009 08:52:30 -0700
From: Mark Alexander <marka@pobox.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Bug fixes and speed improvements for
maildir handling.
Message-ID:
<a412e2a70904210852u1318bd16r6f99341a0604b6cf@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Arrggh. Gmail wrapped the lines in the patch, and I'm
at work behind a firewall so I can't use sup or mutt
to send the patch. So I've put it in an attachment
to this email. Sorry about that!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Bug-fixes-and-speed-improvements-for-maildir-handlin.patch
Type: application/octet-stream
Size: 1853 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090421/1acebf65/attachment-0001.obj>
------------------------------
Message: 43
Date: Tue, 21 Apr 2009 12:15:59 -0400
From: Reid Thompson <reid.thompson@ateb.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Two questions
Message-ID: <1240330559.11793.52.camel@localhost>
Content-Type: text/plain
On Tue, 2009-04-21 at 07:26 -0700, William Morgan wrote:
> Reformatted excerpts from Reid Thompson's message of 2009-04-21:
> > OK -- so to 'manage' an imap store, i'd need to setup a mechanism to
> > fetch all the email to a local store, deleting from the imap store,
> > and then do something like schedule an overnight run of sup-sync-back,
>
> There are a couple issues at play. First, if you're serious about Sup
> with IMAP, many people have gone the route of mirroring their IMAP
> folders locally using something like offlineimap. The Ruby IMAP
> libraries, and possibly IMAP itself, is otherwise too slow for how Sup
> likes to treat its mailstores.
>
> But that's not strictly necessary.
>
> Second, if you're serious about deleting email from your IMAP server (as
> opposed to just letting it stay there forever, since storage is cheap
> and the too-fleeting moments of your precious mortality are not), you'll
> need to periodically run sup-sync-back with the appropriate flags.
>
> This all stems from design decisions around Sup's target environment,
> which is that you have too much email to scan every message except in an
> offline manner. I have 229k emails in my inbox. Sup's the only client
> I know of that can scale to that. (Besides GMail of course.)
for 'fun', i setup a fastmail.fm account, to which i'm using rss2email
to push a number of feeds to. I setup offlineimap to pull these feeds
down for sup, so that I could 'manage' the imap store via sup.
Why is it expecting mbox format?
rthompso@raker ~/.sup $ sup-sync-back -d maildir:~/.fastmaildotfm/INBOX
[Tue Apr 21 12:10:07 -0400 2009] using character set encoding "UTF-8"
[Tue Apr 21 12:10:08 -0400 2009] crypto: detected gpg binary
in /usr/bin/gpg
[Tue Apr 21 12:10:08 -0400 2009] locking /home/rthompso/.sup/lock...
[Tue Apr 21 12:10:08 -0400 2009] loading index...
[Tue Apr 21 12:10:08 -0400 2009] loaded index of 920 messages
Error: maildir:~/.fastmaildotfm/INBOX is not an mbox source.
[Tue Apr 21 12:10:08 -0400 2009] unlocking /home/rthompso/.sup/lock...
offlineimap is populating ~/.fastmaildotfm/INBOX
rthompso@raker ~/.sup $ cat sources.yaml
---
....
- !masanjin.net,2006-10-01/Redwood/Maildir
uri: maildir:~/.fastmaildotfm/INBOX
cur_offset: 12403255620003971
usual: true
archived: false
id: 4
labels:
- rssmail
mtimes:
cur: 2009-04-21 11:47:05 -04:00
new: 2009-04-21 11:47:08 -04:00
- !masanjin.net,2006-10-01/Redwood/SentLoader
cur_offset: 19809
- !masanjin.net,2006-10-01/Redwood/DraftLoader
cur_offset: 0
rthompso@raker ~ $ find .fastmaildotfm/
.fastmaildotfm/
.fastmaildotfm/INBOX.Trash
.fastmaildotfm/INBOX.Trash/cur
.fastmaildotfm/INBOX.Trash/new
.fastmaildotfm/INBOX.Trash/tmp
.fastmaildotfm/INBOX.Sent Items
.fastmaildotfm/INBOX.Sent Items/cur
.fastmaildotfm/INBOX.Sent Items/new
.fastmaildotfm/INBOX.Sent Items/tmp
.fastmaildotfm/INBOX
.fastmaildotfm/INBOX/cur
.fastmaildotfm/INBOX/cur/1240328825_0.15391.raker,U=1,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,S
.fastmaildotfm/INBOX/new
.fastmaildotfm/INBOX/new/1240328827_7.15391.raker,U=29,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
.fastmaildotfm/INBOX/new/1240328825_5.15391.raker,U=6,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
.fastmaildotfm/INBOX/new/1240328827_6.15391.raker,U=28,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
.fastmaildotfm/INBOX/new/1240328826_0.15391.raker,U=8,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
.fastmaildotfm/INBOX/new/1240328827_5.15391.raker,U=27,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
.fastmaildotfm/INBOX/new/1240328826_9.15391.raker,U=17,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
.fastmaildotfm/INBOX/new/1240328827_4.15391.raker,U=26,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
.fastmaildotfm/INBOX/new/1240328826_8.15391.raker,U=16,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
.fastmaildotfm/INBOX/new/1240328825_6.15391.raker,U=7,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
.fastmaildotfm/INBOX/new/1240328827_3.15391.raker,U=25,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
.fastmaildotfm/INBOX/new/1240328826_7.15391.raker,U=15,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
.fastmaildotfm/INBOX/new/1240328827_2.15391.raker,U=24,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
.fastmaildotfm/INBOX/new/1240328826_1.15391.raker,U=9,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
.fastmaildotfm/INBOX/new/1240328826_6.15391.raker,U=14,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
.fastmaildotfm/INBOX/new/1240328827_1.15391.raker,U=23,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
.fastmaildotfm/INBOX/new/1240328826_13.15391.raker,U=21,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
.fastmaildotfm/INBOX/new/1240328826_5.15391.raker,U=13,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
.fastmaildotfm/INBOX/new/1240328825_1.15391.raker,U=2,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
.fastmaildotfm/INBOX/new/1240328827_0.15391.raker,U=22,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
.fastmaildotfm/INBOX/new/1240328826_12.15391.raker,U=20,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
.fastmaildotfm/INBOX/new/1240328826_4.15391.raker,U=12,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
.fastmaildotfm/INBOX/new/1240328826_3.15391.raker,U=11,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
.fastmaildotfm/INBOX/new/1240328826_2.15391.raker,U=10,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
.fastmaildotfm/INBOX/new/1240328825_2.15391.raker,U=3,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
.fastmaildotfm/INBOX/new/1240328826_11.15391.raker,U=19,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
.fastmaildotfm/INBOX/new/1240328828_0.15391.raker,U=32,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
.fastmaildotfm/INBOX/new/1240328826_10.15391.raker,U=18,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
.fastmaildotfm/INBOX/new/1240328825_3.15391.raker,U=4,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
.fastmaildotfm/INBOX/new/1240328827_9.15391.raker,U=31,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
.fastmaildotfm/INBOX/new/1240328825_4.15391.raker,U=5,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
.fastmaildotfm/INBOX/new/1240328827_8.15391.raker,U=30,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
.fastmaildotfm/INBOX/tmp
.fastmaildotfm/INBOX.Drafts
.fastmaildotfm/INBOX.Drafts/cur
.fastmaildotfm/INBOX.Drafts/new
.fastmaildotfm/INBOX.Drafts/tmp
------------------------------
Message: 44
Date: Wed, 22 Apr 2009 00:29:56 -0700 (PDT)
From: Saku Ytti <saku@ytti.fi>
To: sup-talk@rubyforge.org
Subject: [sup-talk] IMAP folder/label integration and playing better
with changed sources?
Message-ID:
<0c334e4c-0480-4def-b64a-b4996431f5c9@x3g2000yqa.googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
First, thank you for sup-mail. I thought I just wanted mutt with
indexed searches, but turns out the stuff copied
from gmail are brilliant and the novel(?) idea of buffers really makes
things simpler.
Problem for me is, I want to use also mobile phone email client and
webmail, so I'm kinda stuck with mutt. Is it likely that this could be
addressed in future?
And for the actual subject related matter, could it be possible to
store labels as folders optionally? This would
play along really well for those who use gmail, as you would
essentially get synchronised labeling between
sup and webclient.
Thanks again.
------------------------------
Message: 45
Date: Wed, 22 Apr 2009 08:02:15 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup crashes when starting, here is the
exception-log
Message-ID: <1240412232-sup-8540@entry>
Content-Type: text/plain; charset=UTF-8
Hi Sean,
Reformatted excerpts from Sean Escriva's message of 2009-04-14:
> --- NoMethodError from thread: call #connect on
> mbox+ssh://optimus//var/mail/seane
> undefined method `synchronize' for nil:NilClass
> /home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/mbox/ssh-file.rb:181:in
Sorry to report this, but the mbox-ssh stuff hasn't been working for a
while and fixing it is pretty low priority at the moment. You're welcome
to investigate, of course, or you might consider another source type.
(mbox+ssh was never was quite fast enough IMO anyways.)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 46
Date: Wed, 22 Apr 2009 08:07:22 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Suggestion for '.' keybinding
Message-ID: <1240412747-sup-2285@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Lee Hinman's message of 2009-04-13:
> Is this possible with Sup right now? Does it store what the last
> action was? (it might for the undo patch, I haven't looked at it)
It's not possible right now, but the undo patch does something similar
to this. The best approach might be to extend UndoManager to be able to
redo as well as undo.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 47
Date: Wed, 22 Apr 2009 08:12:40 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Two questions
Message-ID: <1240412894-sup-3091@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Reid Thompson's message of 2009-04-21:
> Why is it expecting mbox format?
Sorry, I gave you kind of a crappy answer above. sup-sync-back currently
only works on mbox files, though not for any reason other than no one's
gotten around to extending it yet. Deleting files from a Maildir is
significantly easier than removing them from an mbox, so the bar's not
very high on this one.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 48
Date: Wed, 22 Apr 2009 11:56:30 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] First time user of sup; some questions
Message-ID: <1240415555-sup-5859@javelin>
Content-Type: text/plain; charset=UTF-8
Hello all,
I recently switched over to Sup, and I have a favorable first impression.
However, I have a few questions:
1. How do I get date searches to work? I've tried the strings on the
wiki, namely before:, on:, after: and during:, and they consistently
return no results. I'm using sup v0.7.
2. I'd like to archive all of my email older than two weeks (in an
attempt to keep my inbox "as clean as possible"). How might I
go about doing this?
3. I am currently running sup client-side, but it seems to me that,
given its index-centric operation nature, and the fact that this
index does not get propagated back to the mailserver, it would
be more appropriate to run this on a server (this also seems to
jive with the recent "Sup as a Service" postings). Should I toss
sup on a remote machine I have SSH access to, and if I do, how might
I migrate the index I already have?
Cheers,
Edward
--
------------------------------
Message: 49
Date: Wed, 22 Apr 2009 16:40:06 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] First time user of sup; some questions
Message-ID: <1240432739-sup-2328@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from Edward Z. Yang's message of Wed Apr 22 11:56:30 -0400 2009:
> 2. I'd like to archive all of my email older than two weeks (in an
> attempt to keep my inbox "as clean as possible"). How might I
> go about doing this?
Ended up fixing this by !!, T, t (for messages I didn't want to remove), and then ;a
Kind of took a while, since I had 5000+ conversations in my inbox.
Cheers,
Edward
--
------------------------------
Message: 50
Date: Wed, 22 Apr 2009 15:26:43 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] First time user of sup; some questions
Message-ID: <1240439191-sup-6622@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Edward Z. Yang's message of 2009-04-22:
> 1. How do I get date searches to work? I've tried the strings on the
> wiki, namely before:, on:, after: and during:, and they consistently
> return no results. I'm using sup v0.7.
Do you have the chronic gem installed? It's an optional gem but the date
search stuff requires it.
> 2. I'd like to archive all of my email older than two weeks (in an
> attempt to keep my inbox "as clean as possible"). How might I go about
> doing this?
Check out sup-tweak-labels for a way to do this offline (which is really
what you want). With chronic installed, you should be able to pass the
date range query and have it remove the inbox label from all matching
messages. You might want to limit the query a bit so that you don't do
this to every message in your index, over and over. Something like
"+before(two weeks ago) +after(15 days ago)" maybe.
> 3. I am currently running sup client-side, but it seems to me that,
> given its index-centric operation nature, and the fact that this
> index does not get propagated back to the mailserver, it would
> be more appropriate to run this on a server (this also seems to
> jive with the recent "Sup as a Service" postings). Should I toss
> sup on a remote machine I have SSH access to, and if I do, how might
> I migrate the index I already have?
Until Sup the Service is ready (and believe it or not, I have actually
been working on it recently), running it on a globally-accessible server
is what I do. You should be able to simply copy your .sup directory
over. (Although if you're migrating from Windows to a Linux box, I'm
not entirely certain that will work... I'd be interested to hear if it
does.)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 51
Date: Wed, 22 Apr 2009 19:21:11 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] First time user of sup; some questions
Message-ID: <1240442350-sup-9277@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Wed Apr 22 18:26:43 -0400 2009:
> Do you have the chronic gem installed? It's an optional gem but the date
> search stuff requires it.
Nope. Installing the chronic gem fixed things. I've updated the wiki
article accordingly.
> Check out sup-tweak-labels for a way to do this offline (which is really
> what you want). With chronic installed, you should be able to pass the
> date range query and have it remove the inbox label from all matching
> messages. You might want to limit the query a bit so that you don't do
> this to every message in your index, over and over. Something like
> "+before(two weeks ago) +after(15 days ago)" maybe.
Since I'm pretty good about archiving email when it's no longer relevant,
this is not strictly necessary, but it's good to know the existence
of sup-tweak-labels.
> Until Sup the Service is ready (and believe it or not, I have actually
> been working on it recently), running it on a globally-accessible server
> is what I do. You should be able to simply copy your .sup directory
> over. (Although if you're migrating from Windows to a Linux box, I'm
> not entirely certain that will work... I'd be interested to hear if it
> does.)
Excellent. I'm running on Ubuntu Linux and am thinking of setting up
a little bit of replication framework to make my index accessible
on multiple machines.
Cheers,
Edward
------------------------------
Message: 52
Date: Wed, 22 Apr 2009 18:35:00 -0700
From: Jon Dugan <jdugan@es.net>
To: sup talk <sup-talk@rubyforge.org>
Subject: [sup-talk] GSoC Project of Interest
Message-ID: <1240449619-sup-9301@junction.es.net>
Content-Type: text/plain; charset=UTF-8
There's an GSoC project that may be of interest to folks on this list. It's
aim is to add Gmail/sup like features to the Plan 9 mail system called upas.
This might end up creating something an awful lot like Sup the Service Not
identical for sure, but there is at least some overlap in terms of aims and
ideas.
Most services on Plan 9 are implemented as synthetic file systems. The
synthetic filesystem that represents email on Plan 9 is known as upas. upas
provides a filesytem view of mail boxes regardless of their backend storage
medium (eg, POP, IMAP, etc) which provides a nice clean separation between the
code that you use to do useful things to your mail and the code that deals
with the mail store itself.
To quote the man page:
The mailbox itself becomes a directory under /mail/fs. Each message in the
mailbox becomes a numbered directory in the mailbox directory, and each
attachment becomes a numbered directory in the message directory. Since an
attachment may itself be a mail message, this structure can recurse ad
nauseam.
Each message and attachment directory contains the files:
body the message minus the RFC822 style headers
cc the address(es) from the CC: header
date the date in the message, or if none, the time of delivery
digest an SHA1 digest of the message contents
subject the contents of the subject line
.
. etc
.
Here's the manpage for upas:
http://plan9.bell-labs.com/magic/man2html/4/upasfs
The GSoC project:
http://socghop.appspot.com/student_project/show/google/gsoc2009/plan9/t124024225207
There's a ton of interesting and powerful stuff in Plan 9.
I'm hoping this will provide some useful ideas for Sup the Service.
Jon
--
Jon M. Dugan <jdugan@es.net> | GTalk: jdugan.esnet
ESnet Network Engineering Group | http://www.es.net/
Lawrence Berkeley National Laboratory | http://www.lbl.gov/
------------------------------
Message: 53
Date: Wed, 22 Apr 2009 18:11:40 -0700
From: Jon Dugan <jdugan@es.net>
To: "Sup-talk@rubyforge.org" <sup-talk@rubyforge.org>
Subject: [sup-talk] mime-view hook
Message-ID: <1240448213-sup-1757@junction.es.net>
Content-Type: text/plain; charset=UTF-8
I'm running the mainline sup from git.
I have a mime-view.rb hook like this:
case content_type
when "text/html"
Redwood::log("w3m: " + '/opt/local/bin/w3m -dump -T ' + content_type + ' ' + filename)
IO.popen('-') {|f| f ? f.read : exec('/opt/local/bin/w3m', '-dump', '-T', content_type, filename)}
else
Redwood::log("dumbplumb: " + filename)
system '/Users/jdugan/projects/dumbplumb/dumbplumb', filename
end
It's supposed to render HTML in the SUP window and hand everything else off to
dumbplumb. It does hand everything else off to dumbplub, however it doesn't
do what I expect for the HTML attachments.
Whatever gets returned from the hook should be displayed, right?
I am a Ruby noob so maybe it's my Ruby that's bad. (Although I've got a lot
of experience with Python, Perl, etc...)
If I send the output of the IO.popen to Redwood::log I see what I'd expect in
the log buffer, so I have confidence in the part that is using w3m to render
the HTML.
Why didn't I use backticks (`) instead of the calls to system and exec?
To sidestep shell quoting issues. I started with backticks but attachments
with spaces and other shell meta characters were problematic.
Thanks for any suggestions,
Jon
PS: dumbplumb may be of interest. Here's the README:
dumbplumb is a simple mechanism for displaying files from remote systems
locally. it is a brain dead hack that implements something which is something
like the Plan 9 plumber but not really.
Eventually it may be reworked to actually use the plan9 port plumber, but for
now it's just dumb.
dumbplumbd listens on port 9937 on your local system for requests. dumbplumb
sends requests to dumbplumbd. ssh port forwarding is used to proxy the two
together, eg:
ssh -R 9937:localhost:9937 remotehost
You can find dumbplumb at http://bitbucket.org/jdugan/dumbplumb/
--
Jon M. Dugan <jdugan@es.net> | GTalk: jdugan.esnet
ESnet Network Engineering Group | http://www.es.net/
Lawrence Berkeley National Laboratory | http://www.lbl.gov/
------------------------------
Message: 54
Date: Thu, 23 Apr 2009 05:47:59 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] mime-view hook
Message-ID: <1240489722-sup-3696@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Jon Dugan's message of 2009-04-22:
> It's supposed to render HTML in the SUP window and hand everything
> else off to dumbplumb. It does hand everything else off to dumbplub,
> however it doesn't do what I expect for the HTML attachments.
>
> Whatever gets returned from the hook should be displayed, right?
Not exactly. There are two MIME hooks, and you'll need them both for
what you're trying to do: mime-decode, for turning an attachment into
text (displayed directly in Sup), and mime-view, for launching
third-party applications to view an attachment. I've updated the docs on
these two in git to make their relationship a little more clear, but in
summary: mime-decode should return a string, or nil if uncovertable, and
mime-view should return true if the application was successful, and
false otherwise.
Note that by default Sup calls run-mailcap to view attachments it can't
convert to text, so you can make the dumbplumb behavior global by
changing your mailcap instead. (If you desire that.)
> dumbplumb is a simple mechanism for displaying files from remote
> systems locally. it is a brain dead hack that implements something
> which is something like the Plan 9 plumber but not really.
That's awesome. Very useful for Sup.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 55
Date: Thu, 23 Apr 2009 05:52:56 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] GSoC Project of Interest
Message-ID: <1240490917-sup-3402@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Jon Dugan's message of 2009-04-22:
> Most services on Plan 9 are implemented as synthetic file systems.
> The synthetic filesystem that represents email on Plan 9 is known as
> upas. upas provides a filesytem view of mail boxes regardless of
> their backend storage medium (eg, POP, IMAP, etc) which provides a
> nice clean separation between the code that you use to do useful
> things to your mail and the code that deals with the mail store
> itself.
Very interesting and that's a great abstraction. Definitely lots of
overlap with STS. I suspect the primary differences will be that STS
uses fielded, full-text search as its primary access mechanism, and
there's no notion of any kind of filesystem-like mailbox or directory
hierarchy.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 56
Date: Thu, 23 Apr 2009 10:53:36 -0700
From: Andrew Pimlott <andrew@pimlott.net>
To: Jon Dugan <jdugan@es.net>
Cc: "Sup-talk@rubyforge.org" <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] mime-view hook
Message-ID: <20090423175336.GX11701@pimlott.net>
Content-Type: text/plain; charset=us-ascii
On Wed, Apr 22, 2009 at 06:11:40PM -0700, Jon Dugan wrote:
> dumbplumbd listens on port 9937 on your local system for requests. dumbplumb
> sends requests to dumbplumbd. ssh port forwarding is used to proxy the two
> together, eg:
>
> ssh -R 9937:localhost:9937 remotehost
You probably realize this, but... A well-known port doesn't work for
this, because you need one plumber per display session. So the SSH
forwarding needs to use the right plumber on this end and establish a
corresponding session on the other end.
The obvious model for this is SSH agent forwarding. You'd have a
PLUMBER_SOCK variable containing the path to a unix socket, and ssh
would create a unix socket on the other end, forward it there, and set a
new PLUMBER_SOCK variable. The obstacle is, the SSH developers haven't
shown any interest in making the SSH agent forward mechanism availble to
others. See for example
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=294148
If you don't do this, you'll have plumbers stepping on each other, or
you'll have to manage ports manually.
Andrew
------------------------------
Message: 57
Date: Thu, 23 Apr 2009 11:14:48 -0700
From: Jon Dugan <jdugan@es.net>
To: Andrew Pimlott <andrew@pimlott.net>
Cc: "Sup-talk@rubyforge.org" <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] mime-view hook
Message-ID: <1240509574-sup-3576@junction.es.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from Andrew Pimlott's message of Thu Apr 23 10:53:36 -0700 2009:
> On Wed, Apr 22, 2009 at 06:11:40PM -0700, Jon Dugan wrote:
> > dumbplumbd listens on port 9937 on your local system for requests. dumbplumb
> > sends requests to dumbplumbd. ssh port forwarding is used to proxy the two
> > together, eg:
> >
> > ssh -R 9937:localhost:9937 remotehost
>
> You probably realize this, but... A well-known port doesn't work for
> this, because you need one plumber per display session. So the SSH
> forwarding needs to use the right plumber on this end and establish a
> corresponding session on the other end.
That is definitely and issue and I should probably add that to the README.
However in practice it doesn't seem to be a problem for me, I only forward the
port for the first connection to my sup box. When I leave a display I log out
of the sup box thus freeing the well known port for the next display I sit at.
(Or if I forget I can log in and kill that ssh process by hand.) However, this
whole fiasco is part of the reason I call it dumb.
There is also a significant security issue which is anyone on the sup box can
send a dumbplumb request if they know what port to talk to. In my case this
is a fairly minor risk as I am the only person who uses my sup box. This too
is part of the reason I call it dumb.
> The obvious model for this is SSH agent forwarding. You'd have a
> PLUMBER_SOCK variable containing the path to a unix socket, and ssh
> would create a unix socket on the other end, forward it there, and set a
> new PLUMBER_SOCK variable. The obstacle is, the SSH developers haven't
> shown any interest in making the SSH agent forward mechanism availble to
> others. See for example
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=294148
>
> If you don't do this, you'll have plumbers stepping on each other, or
> you'll have to manage ports manually.
I've wanted this kind of forwarding for a long, long time. I was unaware of
the patch listed there. I'll have to take a look. This would be especially
cool if it was forwardable like the agent socket, since sometimes I have to
ssh through intermediate boxes. (But see my ssh-gw script for a cute trick
for getting around this: http://bitbucket.org/jdugan/ssh-gw/).
The unix socket forwarding would make the whole thing much, much cleaner.
One hack to work around the port collision problem is to enable environment
variable forwarding (see SendEnv in ssh_config(5)) and use that to dynamically
choose a port per session. This could be used to forward unix domain sockets
by combining this with something like socat. This, however, starts to become
a huge tangle of duct tape and bailing wire... Also SendEnv has some security
implications.
In short I'd love something less dumb, but for now this scratches an itch.
Jon
--
Jon M. Dugan <jdugan@es.net> | GTalk: jdugan.esnet
ESnet Network Engineering Group | http://www.es.net/
Lawrence Berkeley National Laboratory | http://www.lbl.gov/
------------------------------
Message: 58
Date: Thu, 23 Apr 2009 15:59:13 -0700
From: Andrew Pimlott <andrew@pimlott.net>
To: Jon Dugan <jdugan@es.net>
Cc: "Sup-talk@rubyforge.org" <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] mime-view hook
Message-ID: <20090423225913.GY11701@pimlott.net>
Content-Type: text/plain; charset=us-ascii
On Thu, Apr 23, 2009 at 11:14:48AM -0700, Jon Dugan wrote:
> I've wanted this kind of forwarding for a long, long time. I was unaware of
> the patch listed there. I'll have to take a look. This would be especially
> cool if it was forwardable like the agent socket, since sometimes I have to
> ssh through intermediate boxes. (But see my ssh-gw script for a cute trick
> for getting around this: http://bitbucket.org/jdugan/ssh-gw/).
>
> The unix socket forwarding would make the whole thing much, much cleaner.
It's sad that this hasn't been picked up. I looked into it a while
back, and I can't remember exactly what the impediment is. It would be
an extension to the SecSH protocol, and nobody on the ssh side seems to
get the need for it (baffling to me, given ssh-agent). Even the code
that exists (AFAICT) only connects explicitly-named ports on either end.
> One hack to work around the port collision problem is to enable environment
> variable forwarding (see SendEnv in ssh_config(5)) and use that to dynamically
> choose a port per session.
Even then, you're manually managing the ports: You have to assign a
port number to every session you use; if others use the same machines
(which is unthinkable in the first place for lack of access control),
everyone's numbers have to be unique. That's just dumb--but you know
that. :-)
> In short I'd love something less dumb, but for now this scratches an itch.
Credit to you for writing it. As soon as I saw it, I knew the plumber
was the right thing, but when I ran into the forwarding problem, I gave
up. I'm glad you didn't!
Andrew
------------------------------
Message: 59
Date: Sat, 25 Apr 2009 20:47:23 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: "Sup-talk@rubyforge.org" <sup-talk@rubyforge.org>
Subject: [sup-talk] Exception
Message-ID: <1240706801-sup-2126@javelin>
Content-Type: text/plain; charset=UTF-8
Hello,
sup gets an uncaught exception if you x out a buffer window while it is
loading messages:
----------------------------------------------------------------
I'm very sorry. It seems that an error occurred in Sup. Please
accept my sincere apologies. If you don't mind, please send the
contents of ~/.sup/exception-log.txt and a brief report of the
circumstances to sup-talk at rubyforge dot orgs so that I might
address this problem. Thank you!
Sincerely,
William
----------------------------------------------------------------
--- ArgumentError from thread: load messages for thread-view-mode
buffer not on stack: #<Redwood::Buffer:0xb6586518>: "New message in forum"
/usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup/buffer.rb:395:in `kill_buffer'
/usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup/buffer.rb:386:in `kill_buffer_safely'
/usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup/util.rb:499:in `send'
/usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup/util.rb:499:in `method_missing'
/usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup/modes/thread-view-mode.rb:452:in `dispatch'
/usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup/modes/thread-index-mode.rb:114:in `call'
/usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup/modes/thread-index-mode.rb:114:in `select'
/usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup.rb:85:in `reporting_thread'
/usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup.rb:83:in `initialize'
/usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup.rb:83:in `new'
/usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup.rb:83:in `reporting_thread'
/usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup/modes/thread-index-mode.rb:94:in `select'
/usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup/modes/thread-index-mode.rb:144:in `launch_another_thread'
/usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup/modes/thread-index-mode.rb:126:in `launch_next_thread_after'
/usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup/modes/thread-view-mode.rb:457:in `dispatch'
/usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup/modes/thread-view-mode.rb:429:in `delete_and_then'
/usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup/modes/thread-view-mode.rb:404:in `delete_and_next'
/usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup/mode.rb:49:in `send'
/usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup/mode.rb:49:in `handle_input'
/usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup/buffer.rb:240:in `handle_input'
/usr/lib/ruby/gems/1.8/gems/sup-0.7/bin/sup:207
/var/lib/gems/1.8/bin/sup:19:in `load'
/var/lib/gems/1.8/bin/sup:19
Cheers,
Edward
------------------------------
Message: 60
Date: Sun, 26 Apr 2009 17:07:36 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk mailing list <sup-talk@rubyforge.org>
Subject: [sup-talk] message add speedup
Message-ID: <1240790767-sup-9896@entry>
Content-Type: text/plain; charset=UTF-8
I've merged a branch 'scanning-speedup' into next that doubles the speed
of adding messages to the index. There was a lot of time wasted in
parsing the email headers, which I fixed, and I tweaked a couple other
things. Various other operations that load data from the message source,
like viewing a message thread, should now be slightly faster.
I'm able to index around 70 messages/s on my home computer, which is
still slow, but hey, twice as fast as 35. Time is split about 50/50
between scanning/parsing and Ferret index writing. Sadly, Ruby has a
GIL, so I don't think threading these two operations will buy very much.
(Though there might be complicated ways of getting around that.)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 61
Date: Sun, 26 Apr 2009 21:28:27 -0600
From: John Bent <johnbent@lanl.gov>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] scary exception
Message-ID: <1240802707-sup-2069@tangerine.lanl.gov>
Content-Type: text/plain; charset=US-ASCII
On Friday, sup stopped loading and crashed with an exception, I also
couldn't run sup-sync. At first I was a little scared, but then I
remembered that sup doesn't actually modify mail data so that I could
revert to pine, and then I got very, very scared.
I though I would have to do weird things at a ruby prompt but I just
waited two days and now it works again. Somewhat strange since I tried
about five times on Friday. Oh well, I'm running sup in screen so I'll
just never quit again. :)
Here's the error message in case there's something obvious to someone
else:
tangerine:~/mail>sup-sync
[Fri Apr 24 16:43:10 -0600 2009] using character set encoding "US-ASCII"
[Fri Apr 24 16:43:11 -0600 2009] crypto: no gpg binary detected
[Fri Apr 24 16:43:11 -0600 2009] locking /Users/johnbent/.sup/lock...
[Fri Apr 24 16:43:11 -0600 2009] loading index...
[Fri Apr 24 16:43:11 -0600 2009] loaded index of 79908 messages
Scanning mbox:/Users/johnbent/mail/mbox...
[Fri Apr 24 16:43:11 -0600 2009] unlocking /Users/johnbent/.sup/lock...
/opt/local/lib/ruby/gems/1.8/gems/ferret-0.11.6/lib/ferret/index.rb:768:in
`search': IO Error occured at <except.c>:93 in xraise (IOError)
Error occured in fs_store.c:284 - fsi_read_i
couldn't read 1024 chars from : <Unknown error: 0>
from
/opt/local/lib/ruby/gems/1.8/gems/ferret-0.11.6/lib/ferret/index.rb:768:in
`do_search'
from
/opt/local/lib/ruby/gems/1.8/gems/ferret-0.11.6/lib/ferret/index.rb:339:in
`search'
from /opt/local/lib/ruby/1.8/monitor.rb:242:in `synchronize'
from
/opt/local/lib/ruby/gems/1.8/gems/ferret-0.11.6/lib/ferret/index.rb:338:in
`search'
from
/opt/local/lib/ruby/gems/1.8/gems/sup-999/lib/sup/index.rb:422:in
`load_entry_for_id'
from /opt/local/lib/ruby/1.8/monitor.rb:242:in `synchronize'
from
/opt/local/lib/ruby/gems/1.8/gems/sup-999/lib/sup/index.rb:421:in
`load_entry_for_id'
from
/opt/local/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:499:in `send'
... 10 levels...
from /opt/local/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:131:in
`each'
from /opt/local/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:131
from /opt/local/bin/sup-sync:16:in `load'
from /opt/local/bin/sup-sync:16
Thanks,
JOHn
------------------------------
Message: 62
Date: Mon, 27 Apr 2009 10:25:19 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] scary exception
Message-ID: <1240852818-sup-1006@entry>
Content-Type: text/plain; charset=UTF-8
Hi John,
Reformatted excerpts from John Bent's message of 2009-04-26:
> /opt/local/lib/ruby/gems/1.8/gems/ferret-0.11.6/lib/ferret/index.rb:768:in
> `search': IO Error occured at <except.c>:93 in xraise (IOError)
> Error occured in fs_store.c:284 - fsi_read_i
> couldn't read 1024 chars from : <Unknown error: 0>
It appears that you're running off a gem generated directly from the git
repo. How recently did you do that? This Ferret error is something I
though we had kicked quite a while ago, so if you are running from a
recent git, I'll be worried.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 63
Date: Mon, 27 Apr 2009 11:34:54 -0600
From: John Bent <johnbent@lanl.gov>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] scary exception
Message-ID: <1240853542-sup-4778@tangerine.lanl.gov>
Content-Type: text/plain; charset=US-ASCII
Excerpts from William Morgan's message of Mon Apr 27 11:25:19 -0600 2009:
> Hi John,
>
> Reformatted excerpts from John Bent's message of 2009-04-26:
> > /opt/local/lib/ruby/gems/1.8/gems/ferret-0.11.6/lib/ferret/index.rb:768:in
> > `search': IO Error occured at <except.c>:93 in xraise (IOError)
> > Error occured in fs_store.c:284 - fsi_read_i
> > couldn't read 1024 chars from : <Unknown error: 0>
>
> It appears that you're running off a gem generated directly from the git
> repo. How recently did you do that? This Ferret error is something I
> though we had kicked quite a while ago, so if you are running from a
> recent git, I'll be worried.
>
I'm sorry. I don't remember. The timestamp on my sup executable says
Jan 13 2009. I'll try to upgrade and see if I ever see this again.
John
------------------------------
Message: 64
Date: Mon, 27 Apr 2009 8:43:46 -0400
From: Mike S <stipim@rpi.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] redo ideas
Message-ID: <200904271244.n3RCi1VO027803@smtp6.server.rpi.edu>
Content-Type: text/plain
I'm graduating in a few weeks, so I'll have some free time I can dedicate
to sup again.
Recently redo functionality was suggested, I believe this was meant to be
a solution for something, but I have been thinking about it for a while.
I'd like to register Ctrl-R to keep with the vim bindings.
Redo is fairly straightforward from the UndoManager side; it simply has
to push and pop from one list to another when undoing/redoing. The qualm
I have is with the code generating the undo hooks.
Right now, code is written in duplicate. Something like toggle_starred
has to perform three things:
* toggle the star on the message
* generate a lambda to unstar the message (effectively duplicating
toggle_starred)
* register the lambda with UndoManager
There are two obvious ways to implement redo that I think are ugly, and
one slightly clever one that might be better. If you know some Ruby magic
that resolves this, please let me know!
Ugly method 1: write code in triplicate. When you call an action, it does
4 things:
* actually perform the action
* create a lambda undoing that action
* create a lambda redoing the action
* registering undo and redo
Ugly method 2: write code in duplicate, register a redo and call redo
This saves duplication of code, but it seems unnecessarily complex.
* create undo lambda
* create redo lambda
* register undo and redo, but 'queue up' redo
* UndoManager.redo
Slightly clever method: have primitives return their own undo/redo. This
can be seen in toggle_starred where actually_toggle_starred returns its
inverse. This shifts the complexity down and keeps higher level code clean.
Any thoughts?
- Mike
--
Mike Stipicevic
RPI EE/CSYS '09
stipim@rpi.edu
mstipicevic@ieee.org
------------------------------
Message: 65
Date: Mon, 27 Apr 2009 10:46:43 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] scary exception
Message-ID: <1240854270-sup-8870@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from John Bent's message of 2009-04-27:
> I'm sorry. I don't remember. The timestamp on my sup executable says
> Jan 13 2009. I'll try to upgrade and see if I ever see this again.
Yeah, I think it was around March that things got merged in. Try it with
the latest & greatest and see if it happens again.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 66
Date: Mon, 27 Apr 2009 11:18:27 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] IMAP folder/label integration and playing
better with changed sources?
Message-ID: <1240856180-sup-6270@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Saku Ytti's message of 2009-04-22:
> Problem for me is, I want to use also mobile phone email client and
> webmail, so I'm kinda stuck with mutt. Is it likely that this could be
> addressed in future?
One thing I'd like to do with Sup the Service would be to provide an
IMAP server interface to it. Then you could use with standard IMAP
clients. But that's probably a ways off.
> And for the actual subject related matter, could it be possible to
> store labels as folders optionally? This would play along really well
> for those who use gmail, as you would essentially get synchronised
> labeling between sup and webclient.
Sounds like a good idea but a lot of work...
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 67
Date: Mon, 27 Apr 2009 21:47:00 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: Mike S <stipim@rpi.edu>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] redo ideas
Message-ID: <1240861270-sup-8603@ausone.local>
Content-Type: text/plain; charset=UTF-8
Excerpts from Mike S's message of Mon Apr 27 14:43:46 +0200 2009:
> I'm graduating in a few weeks, so I'll have some free time I can dedicate
> to sup again.
>
> Recently redo functionality was suggested, I believe this was meant to be
> a solution for something, but I have been thinking about it for a while.
> I'd like to register Ctrl-R to keep with the vim bindings.
Just some thoughts about this... I was more thinking about the repeat feature
of Vi/Vim (the '.' command) than the redo one.
Two other ways of doing the undo/redo:
1/ Save the actions using a data type that we can inverse.
Example in Ruby syntax
a = Action.add_labels(:foo, :bar)
a.apply # actually do the job
a.invert # equals to Action.remove_labels(:foo, :bar)
2/ Save the state (has to be defined) at each action.
This solution would be limited to actions where the state is manageable.
Best regards,
--
Nicolas Pouillard
------------------------------
Message: 68
Date: Mon, 27 Apr 2009 22:00:44 +0200
From: Helge Titlestad <helgedt@tihlde.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] UTF-8 message sending patch
Message-ID: <1240861799-sup-787@colargol.tihlde.org>
Content-Type: text/plain; charset="utf-8"
Hi,
I just installed sup and noticed that it didn't play extremely well
with utf-8 out of the box.
http://sup.rubyforge.org/wiki/wiki.pl?UTF8 together with the String
hack from http://www.nabble.com/UTF-8-woes-td21598658.html#a21598658
fixed the viewing parts (I think), but it's still unacceptable to
send raw utf-8 in email headers.
So I fixed it with another little hack (to edit-message-mode.rb),
which sets Content-Transfer-Encoding to 8-bit and more importantly
tries to convert any utf-8 headers to quoted printable.
I think the patch (attached) fixes my problems, but it's probably far
from complete. It doesn't detect non-utf8-but-still-illegal-strings,
it assumes every header except Subject is an address, and so on.
Any feedback is welcome. (:
--
alge
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sup-utf8-message-sending.patch
Type: application/octet-stream
Size: 1904 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090427/6cae2b53/attachment-0001.obj>
------------------------------
Message: 69
Date: Tue, 28 Apr 2009 19:49:04 +0200
From: Christopher Bertels <mailinglist@flasht.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] New to Sup and some imap sync questions
Message-ID: <1240940037-sup-2915@bakkdoor-ubuntu>
Content-Type: text/plain; charset=UTF-8
Hi!
I'm new to using Sup and I really like it.
I know that it works a little different than most mail clients I've used before.
I'be been using Thunderbird but I#ve always missed a way to view my mails in one big inbox with multiple accounts.
Fortunately, Sup does this just the way I want it to. And since I like Ruby as well, it's definately another plus to be able to customize it with Ruby.
I do have one question though:
Are there any plans on making it sync changes back to the imap server somehow? I'm used to having different mail clients on different machines dealing with
the same accounts on several imap servers. I'm so used to having all the changes happening on the server itself, that it's something I'm really missing with Sup.
Just wondering if this is ever planned? Since now, even if I have Sup installed on my different machines, I still need to sync all the settings when I change something (e.g. adding a hook-script or something else). Or is there an easy way to sync my Sup settings etc?
I'm new to it, but it seems very promising...
Thanks for any help and keep up the good work!
Christopher.
------------------------------
Message: 70
Date: Tue, 28 Apr 2009 15:18:22 -0400
From: Marc Hartstein <marc.hartstein@alum.vassar.edu>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Possible problem with maildir ID generation
Message-ID: <20090428191822.GB10581@cabinet.hsd1.ma.comcast.net>
Content-Type: text/plain; charset="us-ascii"
On Tue, Apr 21, 2009 at 07:00:30AM -0700, William Morgan wrote:
> Reformatted excerpts from Mark Alexander's message of 2009-04-16:
> > Consider two messages that arrive in the same second, but the second
> > message is smaller than the first. Because the message size makes up
> > the low seven (decimal) digits of the ID, the second message, even
> > though it arrived later, will have an ID that is less than the first
> > message.
>
> I think you could be right. Using the size as part of the ID was
> supposed to differentiate messages with the same timestamp, but it would
> result in exactly the behavior you describe when polling.
Isn't part of the maildir scheme that the filenames are guaranteed to be
unique? It's been a while since I looked at this part of the sup
source, but would it be possible to simply use the filename as the ID
when working with maildir, rather than generating a new ID? Or is there
an additional constraint (like ordering?) that needs to be satisfied and
isn't by maildir?
I switched back to mutt a few months ago because a couple of details of
sup were driving me nuts, partly to do with maildir handling and to a
crash I was having, but there are a lot of UI features of sup I find
myself really missing, and I'm considering coming back again. I'm
hoping switching back and forth a few times will help inform what I
*want* in an MUA . . . if, as I currently suspect, turning sup into what
I want will be easier than turning mutt into what I want, that could
result in my contributing a bunch more patches down the road.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090428/75736a92/attachment-0001.bin>
------------------------------
Message: 71
Date: Tue, 28 Apr 2009 15:19:26 -0400
From: Steve Goldman <sgoldman@tower-research.com>
To: Sup Talk List <sup-talk@rubyforge.org>
Subject: [sup-talk] Inconsistent inbox after restart
Message-ID: <1240945125-sup-8484@sgoldmanlinux.tower-research.com>
Content-Type: text/plain; charset=UTF-8
This only started happening after I upgraded to the latest version...
Oftentimes when I quit sup and then restart, my inbox looks different.
Messages that I had previously archived are back in the inbox. Has
anyone else seen this? I'm losing sleep over it.
Thanks.
--
Steve Goldman
sgoldman@tower-research.com
T: 212.219.6014
F: 212.219.6007
Tower Research Capital, LLC
377 Broadway, 11th Fl.
New York, NY 10013
------------------------------
Message: 72
Date: Tue, 28 Apr 2009 19:29:46 -0400
From: Mark Alexander <marka@pobox.com>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Possible problem with maildir ID generation
Message-ID:
<a412e2a70904281629n6171bbb6i4c6330e375f8c6ad@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Apr 28, 2009 at 3:18 PM, Marc Hartstein
<marc.hartstein@alum.vassar.edu> wrote:
> Isn't part of the maildir scheme that the filenames are guaranteed to be
> unique? ?It's been a while since I looked at this part of the sup
> source, but would it be possible to simply use the filename as the ID
> when working with maildir, rather than generating a new ID? ?Or is there
> an additional constraint (like ordering?) that needs to be satisfied and
> isn't by maildir?
Maildir filenames are unique, but they would need to be ordered
by time, since sup depends on that ordering (look in maildir.rb for
where it uses sort). I'm not sure if mail delivery programs
(I use procmail) guarantee that the filenames are ordered that way.
I will say that the patch I sent out for maildir.rb has made
my life a lot happier, but it's still not ideal because of
the race condition I mentioned.
William was talking about using some other scheme to generate IDs.
We should see what he has to say about this.
------------------------------
Message: 73
Date: Wed, 29 Apr 2009 10:40:13 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: Steve Goldman <sgoldman@tower-research.com>
Cc: Sup Talk List <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Inconsistent inbox after restart
Message-ID: <1240994294-sup-8386@ausone.inria.fr>
Content-Type: text/plain; charset=UTF-8
Excerpts from Steve Goldman's message of Tue Apr 28 21:19:26 +0200 2009:
> This only started happening after I upgraded to the latest version...
>
> Oftentimes when I quit sup and then restart, my inbox looks different.
> Messages that I had previously archived are back in the inbox. Has
> anyone else seen this? I'm losing sleep over it.
From time to time I also encounter this issue: previously archived emails
come back to the inbox.
--
Nicolas Pouillard
------------------------------
Message: 74
Date: Wed, 29 Apr 2009 10:37:08 +0200
From: Tyberius Prime <tyberius_prime@coonabibba.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Inconsistent inbox after restart
Message-ID: <1240994200-sup-9656@h984274.serverkompetenz.net>
Content-Type: text/plain; charset=UTF-8
I should add, the read status is being kept for me.
Excerpts from Nicolas Pouillard's message of Wed Apr 29 10:40:13 +0200 2009:
> Excerpts from Steve Goldman's message of Tue Apr 28 21:19:26 +0200 2009:
> > This only started happening after I upgraded to the latest version...
> >
> > Oftentimes when I quit sup and then restart, my inbox looks different.
> > Messages that I had previously archived are back in the inbox. Has
> > anyone else seen this? I'm losing sleep over it.
>
> From time to time I also encounter this issue: previously archived emails
> come back to the inbox.
>
------------------------------
Message: 75
Date: Wed, 29 Apr 2009 10:17:23 +0200
From: Tyberius Prime <tyberius_prime@coonabibba.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Inconsistent inbox after restart
Message-ID: <1240992967-sup-2852@h984274.serverkompetenz.net>
Content-Type: text/plain; charset=UTF-8
Hi,
yes, I see the same,
haven't dug into it so far either, simply never restart sup
if I can avoid it... (yeah, great conflict strategy, but
life's short).
So long,
Tyberius Prime
Excerpts from Steve Goldman's message of Tue Apr 28 21:19:26 +0200 2009:
> This only started happening after I upgraded to the latest version...
>
> Oftentimes when I quit sup and then restart, my inbox looks different.
> Messages that I had previously archived are back in the inbox. Has
> anyone else seen this? I'm losing sleep over it.
>
> Thanks.
> --
>
> Steve Goldman
> sgoldman@tower-research.com
>
> T: 212.219.6014
> F: 212.219.6007
>
> Tower Research Capital, LLC
> 377 Broadway, 11th Fl.
> New York, NY 10013
------------------------------
Message: 76
Date: Wed, 29 Apr 2009 13:04:40 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: "Sup-talk@rubyforge.org" <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] New to Sup and some imap sync questions
Message-ID: <1241024581-sup-9014@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from Christopher Bertels's message of Tue Apr 28 13:49:04 -0400 2009:
> Just wondering if this is ever planned? Since now, even if I have Sup installed
> on my different machines, I still need to sync all the settings when I change
> something (e.g. adding a hook-script or something else). Or is there an easy
> way to sync my Sup settings etc?
Hello Christopher,
My current understanding is that William is not interested in mucking around
with IMAP any more than he has to, so unless someone steps up and submits
some patches there will not be syncing back to IMAP.
As for handling Sup on multiple machines, I think the current best practice
is "don't"; pick one machine, make it ssh'able into, and use that to handle
all of your mail.
Cheers,
Edward
------------------------------
Message: 77
Date: Wed, 29 Apr 2009 11:02:06 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk mailing list <sup-talk@rubyforge.org>
Subject: [sup-talk] possible mbox "initial From" fix
Message-ID: <1241027916-sup-7642@entry>
Content-Type: text/plain; charset=UTF-8
After a lot of toying with RubyMail, hoping I could get it to behave
well, I finally gave up and just tweaked the regexp that determines
whether a line is an mbox separator or not, and bypassed RubyMail mbox
splitting entirely. It might still be too lenient---I have it looking
for /^From \S+@\S+ /, so it's not even bothering to parse a date, etc.
I'm hoping to strike somewhat of a balance between strict and liberal.
So, please try it out and see if it solves your mbox problems.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 78
Date: Wed, 29 Apr 2009 11:09:16 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] New to Sup and some imap sync questions
Message-ID: <1241028139-sup-8070@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Edward Z. Yang's message of 2009-04-29:
> My current understanding is that William is not interested in mucking
> around with IMAP any more than he has to, so unless someone steps up
> and submits some patches there will not be syncing back to IMAP.
That's pretty much the case, but I hope it's ameliorated by the fact
that I do plan to get sup-sync-back working with Maildir ("any day
now"), and then you can use offlineimap to really sync between IMAP and
Sup.
> As for handling Sup on multiple machines, I think the current best
> practice is "don't"; pick one machine, make it ssh'able into, and use
> that to handle all of your mail.
Correct.
Recently I've been thinking about the possibility of storing one's
mbox/Maildir in git, syncing it between machines (Maildir would probably
work best for this, as mbox will generate spurious conflicts when
deleting+adding), and maintaining the Ferret index locally on each
machine. If we add a notion of an outbound message queue to Sup (i.e.
each machine knows whether it has the ability to send mail or not), and
also synchronize that and the drafts and sent folders between machines,
you could use Sup for completely offline, distributed email. Crazy?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 79
Date: Wed, 29 Apr 2009 11:10:53 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Inconsistent inbox after restart
Message-ID: <1241028590-sup-8155@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Steve Goldman's message of 2009-04-28:
> Oftentimes when I quit sup and then restart, my inbox looks different.
> Messages that I had previously archived are back in the inbox. Has
> anyone else seen this? I'm losing sleep over it.
I see it periodically too (I think I also see read messages turned
unread again) and have been trying to find a pattern---is it email
that's autosaved when I quit Sup, etc.?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 80
Date: Wed, 29 Apr 2009 11:22:41 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] redo ideas
Message-ID: <1241028879-sup-6375@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Mike S's message of 2009-04-27:
> I'm graduating in a few weeks, so I'll have some free time I can
> dedicate to sup again.
Congrats! Great!
> I'd like to register Ctrl-R to keep with the vim bindings.
Sure.
> Ugly method 2: write code in duplicate, register a redo and call redo
> This saves duplication of code, but it seems unnecessarily complex.
>
> * create undo lambda
> * create redo lambda
> * register undo and redo, but 'queue up' redo
> * UndoManager.redo
Redo is actually a slightly different operation from do. Do has to ask
for user input (what label do you want to apply?), redo just reuses it.
Maybe that's not such a big deal though; do/redo can just check to see
if it already has the value from the user, and ask if not.
> Slightly clever method: have primitives return their own undo/redo.
> This can be seen in toggle_starred where actually_toggle_starred
> returns its inverse. This shifts the complexity down and keeps higher
> level code clean.
That sounds eminently reasonable to me.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 81
Date: Wed, 29 Apr 2009 14:38:13 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: "Sup-talk@rubyforge.org" <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] New to Sup and some imap sync questions
Message-ID: <1241030207-sup-8690@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Wed Apr 29 14:09:16 -0400 2009:
> Recently I've been thinking about the possibility of storing one's
> mbox/Maildir in git, syncing it between machines (Maildir would probably
> work best for this, as mbox will generate spurious conflicts when
> deleting+adding), and maintaining the Ferret index locally on each
> machine. If we add a notion of an outbound message queue to Sup (i.e.
> each machine knows whether it has the ability to send mail or not), and
> also synchronize that and the drafts and sent folders between machines,
> you could use Sup for completely offline, distributed email. Crazy?
I was under the impression that the interesting stuff (e.g. tags) was
stored in the index, so you would have to sync that too?
Cheers,
Edward
------------------------------
Message: 82
Date: Wed, 29 Apr 2009 13:16:30 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] New to Sup and some imap sync questions
Message-ID: <1241036141-sup-3541@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Edward Z. Yang's message of 2009-04-29:
> I was under the impression that the interesting stuff (e.g. tags) was
> stored in the index, so you would have to sync that too?
That would have to be update to include all new messages every time you
synced. And the flags would have to be synced too. Not a trivial
undertaking, but within the realm of possibility.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 83
Date: Wed, 29 Apr 2009 22:48:35 +0200
From: Christopher Bertels <mailinglist@flasht.de>
To: "Sup-talk@rubyforge.org" <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] New to Sup and some imap sync questions
Message-ID: <1241037842-sup-8569@bakkdoor-ubuntu>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Mi Apr 29 20:09:16 +0200 2009:
> Recently I've been thinking about the possibility of storing one's
> mbox/Maildir in git, syncing it between machines (Maildir would probably
> work best for this, as mbox will generate spurious conflicts when
> deleting+adding), and maintaining the Ferret index locally on each
> machine. If we add a notion of an outbound message queue to Sup (i.e.
> each machine knows whether it has the ability to send mail or not), and
> also synchronize that and the drafts and sent folders between machines,
> you could use Sup for completely offline, distributed email. Crazy?
Actually, that's something I've thought about as well. Seems kinda crazy, but since I don't switch between
machines too often (mainly laptop & desktop machine - maybe switching once a day) this could be an optoin.
Or I'll use my server and ssh into it to view my mail.
Anyhow, I guess I'll stick with Sup - I just like it too much already ;)
Christopher.
------------------------------
Message: 84
Date: Wed, 29 Apr 2009 13:58:01 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] New to Sup and some imap sync questions
Message-ID: <1241038425-sup-3748@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from William Morgan's message of 2009-04-29:
> That would have to be update to include all new messages every time
> you synced. And the flags would have to be synced too. Not a trivial
> undertaking, but within the realm of possibility.
That wasn't very clear. Let me try again. The Ferret index (a scary
binary thing) would not be synced. Individual sources would be synced,
along with some version of the message flags (probably as a
newline-separated text file, to allow conflict resolution (!)), and then
the index would be updated on the local machine to reflect those
changes.
Kinda tantamount to rsyncing your .sup directory and all your sources
across different machines, but a little more refined.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 85
Date: Wed, 29 Apr 2009 15:31:52 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Possible problem with maildir ID generation
Message-ID: <1241038730-sup-2939@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Mark Alexander's message of 2009-04-28:
> Maildir filenames are unique, but they would need to be ordered by
> time, since sup depends on that ordering (look in maildir.rb for where
> it uses sort). I'm not sure if mail delivery programs (I use
> procmail) guarantee that the filenames are ordered that way.
That's correct; the name is not sufficient as ids because Sup needs a
single pointer into the Maildir as a marker for what it has already
processed, so we have to use something ordinal. But it can't just be
any old ordinal, it has to be something that corresponds with the way
messages are written to the Maildir, in order to be able to divide newer
messages from older ones.
A timestamp is the obvious choice, but messages can have the same
timestamp, so then what do you do? The current approach is to sort by
another arbitrary field (in this cae, message size), which gives a
unique ordering, but doesn't match up
(All this rigamarole about ordinals and blah blah blah is necessary
because I don't want Sup to rescan the entire Maildir unless absolutely
necessary. One day I'll convert my mbox to a Maildir with 250k files in
it, and a rescan will kill me, especially at Ruby speed.)
> I will say that the patch I sent out for maildir.rb has made my life a
> lot happier, but it's still not ideal because of the race condition I
> mentioned.
>
> William was talking about using some other scheme to generate IDs. We
> should see what he has to say about this.
Well I haven't quite started on it yet, but my plan is to:
a) Sort files by timestamp, and then by something else (maybe name), and
use the position in that array instead of the timestamp. This doesn't
solve anything, but it will make the ids prettier, and removes the
hideous "%7d" thing.
b) When polling, if the current "offset" is N, return all messages that
have a timestamp >= the Nth message. So this will mean that we'll
rescan messages on occasion, but we shouldn't miss any.
Any obvious flaws?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 86
Date: Wed, 29 Apr 2009 15:38:23 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] UTF-8 message sending patch
Message-ID: <1241044621-sup-9157@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Helge Titlestad's message of 2009-04-27:
> I think the patch (attached) fixes my problems, but it's probably far
> from complete. It doesn't detect non-utf8-but-still-illegal-strings,
> it assumes every header except Subject is an address, and so on.
Thanks! Good timing on this; it was near the top of my todo list.
I will probably edit this a bit and merge it in as part of a bigger
utf-8 fixing branch.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 87
Date: Wed, 29 Apr 2009 15:39:31 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Possible problem with maildir ID generation
Message-ID: <1241044743-sup-2889@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from William Morgan's message of 2009-04-29:
> A timestamp is the obvious choice, but messages can have the same
> timestamp, so then what do you do? The current approach is to sort by
> another arbitrary field (in this cae, message size), which gives a
> unique ordering, but doesn't match up
Sigh.
Doesn't match up with that procmail, or whatever MUA, is giving us.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 88
Date: Wed, 29 Apr 2009 15:45:29 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup with Microsoft Exchange 2007
Message-ID: <1241045035-sup-1534@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Walton's message of 2009-04-21:
> William, what requirements would need to be met from your side to see
> this added?
As far as I'm concerned, if it works, I'll add it. I'd love to have this
functionality in Sup, and it is frequently requested.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 89
Date: Wed, 29 Apr 2009 19:38:20 -0400
From: Marc Hartstein <marc.hartstein@alum.vassar.edu>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Possible problem with maildir ID generation
Message-ID: <20090429233820.GA14143@cabinet.hsd1.ma.comcast.net>
Content-Type: text/plain; charset="us-ascii"
On Wed, Apr 29, 2009 at 03:31:52PM -0700, William Morgan wrote:
> (All this rigamarole about ordinals and blah blah blah is necessary
> because I don't want Sup to rescan the entire Maildir unless absolutely
> necessary. One day I'll convert my mbox to a Maildir with 250k files in
> it, and a rescan will kill me, especially at Ruby speed.)
How are we defining 'rescan' here? I can think of a couple of possible
meanings, and I'm not sure where you are:
1. Open every file in the maildir and read from it, every poll.
2. Visit every filename in the maildir to consider whether it is a new
file, every poll.
3. Something else I'm not thinking of this instant.
If 1, would it suffice to preserve a list of which messages you've
already added to the index? (Comparing against the database, which would
contain the filenames for all the messages.)
If 2:
> a) Sort files by timestamp, and then by something else (maybe name), and
Doesn't this effectively require visiting every filename in the maildir?
I suspect I'm not entirely clear on what we're optimizing for, or I'm
missing something about the relative costs of operations.
...
I have just checked into maildir...I thought I remembered something from
the last time I looked at it: maildir filenames are of the form
'time.pid.host:info', and are supposedly unique. If the desired name is
already taken, the MDA sleeps for 2s then tries again. [see man maildir]
So the only way you're going to get a timestamp collision (on the
filename timestamp, perhaps not on the actual ctime) is if you have
multiple processes delivering mail simultaneously, or if you're
synchronizing mail delivered on multiple hosts. In the case of the
latter, a timestamp-based heuristic for finding new messages isn't going
to work.
Would it suffice to keep track of the filename of the most recent
message added for each maildir source, and check everything with a time
portion of the filename equal to or greater than that message for
whether it needs to be added? [although see above about whether that
gains anything]
It seems you're "supposed" to move things from new/ to cur/ after you've
indexed them to solve exactly this problem, but I know this clashes with
the sup design philosophy.
Having looked into this more closely, I'm starting to seriously
reconsider whether maildir is really what I want to be using for storing
my mail. There are some weird timing issues.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090429/1e38e394/attachment-0001.bin>
------------------------------
Message: 90
Date: Wed, 29 Apr 2009 19:44:40 -0400
From: Marc Hartstein <marc.hartstein@alum.vassar.edu>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Possible problem with maildir ID generation
Message-ID: <20090429234440.GB14143@cabinet.hsd1.ma.comcast.net>
Content-Type: text/plain; charset="us-ascii"
On Wed, Apr 29, 2009 at 07:38:20PM -0400, Marc Hartstein wrote:
>
> I have just checked into maildir...I thought I remembered something from
> the last time I looked at it: maildir filenames are of the form
> 'time.pid.host:info', and are supposedly unique. If the desired name is
> already taken, the MDA sleeps for 2s then tries again. [see man maildir]
Please ignore this part...a minute's further research suggests that this
should probably not be relied upon...certainly the pid section is no
longer necessarily a pid, and it might be naive to trust that the time
is really a time, or indeed that there's any structure to the stuff
before the (possible) colon.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090429/fa36c670/attachment-0001.bin>
------------------------------
Message: 91
Date: Wed, 29 Apr 2009 17:51:15 -0700
From: Bart Schaefer <barton.schaefer@gmail.com>
To: sup-talk mailing list <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] possible mbox "initial From" fix
Message-ID:
<6bb609560904291751n3cc62f46g6a4edcba1f97d6f7@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Apr 29, 2009 at 11:02 AM, William Morgan
<wmorgan-sup@masanjin.net> wrote:
> After a lot of toying with RubyMail, hoping I could get it to behave
> well, I finally gave up and just tweaked the regexp that determines
> whether a line is an mbox separator or not, and bypassed RubyMail mbox
> splitting entirely. It might still be too lenient---I have it looking
> for /^From \S+@\S+ /, so it's not even bothering to parse a date, etc.
> I'm hoping to strike somewhat of a balance between strict and liberal.
Offering a geezer perspective on this, as one of the primary
programmers on an old Unix mail reader that originally didn't
understand any kind of folder *except* mbox ... the "match separator"
method that worked best for us back in the early '90s went like this:
(1) Check for "From " at start of line; if not found, return "not a separator".
(2) Skip 5 characters, then skip any whitespace.
(3) Remember this location.
(4) Skip everything that is NOT whitespace, ignoring syntax for now.
(5) Skip any whitespace.
(6) Attempt to parse a date string in any of a variety of formats.
(6a) If successful, return "is a separator"
(6b) If unsuccessful, rewind to the location saved at (3)
(7) Attempt to parse an email address in full RFC822 (now 5322)
syntax, including comments, phrases, etc; if unsuccessful, return "not
a separator"
(8) Skip any whitespace following the parsed email address
(9) Attempt again to parse a date; if successful, return "is a separator"
(10) Return "not a separator"
We found that in most cases this failed at (1) or succeeded very
quickly at (6a). Only obscure cases proceed to (7), but if you're
dealing with anything like old USENET news archives or folders written
by '80s-era mail clients you need either step (4) or step (7) to get
past the cruft.
Note that the key is finding "From ... DATE" rather than "From ADDRESS
..." if you really want to distinguish message separators from stuff
people type in a message body. I'm not sure you can do this with a
regular expression.
If you want details on the variety of date formats that we recognized,
let me know ...
------------------------------
Message: 92
Date: Thu, 30 Apr 2009 09:11:29 +0200
From: Tyberius Prime <tyberius_prime@coonabibba.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Inconsistent inbox after restart
Message-ID: <1241075456-sup-909@h984274.serverkompetenz.net>
Content-Type: text/plain; charset=UTF-8
For me it seems to be messages that have been saved 'hours' ago by pressing $.
Excerpts from William Morgan's message of Wed Apr 29 20:10:53 +0200 2009:
> Reformatted excerpts from Steve Goldman's message of 2009-04-28:
> > Oftentimes when I quit sup and then restart, my inbox looks different.
> > Messages that I had previously archived are back in the inbox. Has
> > anyone else seen this? I'm losing sleep over it.
>
> I see it periodically too (I think I also see read messages turned
> unread again) and have been trying to find a pattern---is it email
> that's autosaved when I quit Sup, etc.?
------------------------------
Message: 93
Date: Thu, 30 Apr 2009 08:51:42 -0400
From: Steve Goldman <sgoldman@tower-research.com>
To: Sup Talk List <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Inconsistent inbox after restart
Message-ID: <1241095872-sup-9569@sgoldmanlinux.tower-research.com>
Content-Type: text/plain; charset=UTF-8
Excerpts from Tyberius Prime's message of Thu Apr 30 03:11:29 -0400 2009:
> For me it seems to be messages that have been saved 'hours' ago by pressing $.
>
> Excerpts from William Morgan's message of Wed Apr 29 20:10:53 +0200 2009:
> > Reformatted excerpts from Steve Goldman's message of 2009-04-28:
> > > Oftentimes when I quit sup and then restart, my inbox looks different.
> > > Messages that I had previously archived are back in the inbox. Has
> > > anyone else seen this? I'm losing sleep over it.
> >
> > I see it periodically too (I think I also see read messages turned
> > unread again) and have been trying to find a pattern---is it email
> > that's autosaved when I quit Sup, etc.?
I have confirmed that 0.7 is fine, but master is not. So we just have
to track down which commit(s) in between broke it...
--
Steve Goldman
sgoldman@tower-research.com
T: 212.219.6014
F: 212.219.6007
Tower Research Capital, LLC
377 Broadway, 11th Fl.
New York, NY 10013
------------------------------
Message: 94
Date: Thu, 30 Apr 2009 09:10:20 -0400
From: Ben Walton <bdwalton@gmail.com>
To: Steve Goldman <sgoldman@tower-research.com>
Cc: Sup Talk List <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Inconsistent inbox after restart
Message-ID:
<f96e0240904300610n741d83aq95dd0c4b10876243@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
On Thu, Apr 30, 2009 at 8:51 AM, Steve Goldman
<sgoldman@tower-research.com> wrote:
> Excerpts from Tyberius Prime's message of Thu Apr 30 03:11:29 -0400 2009:
>> For me it seems to be messages that have been saved 'hours' ago by pressing $.
>
> I have confirmed that 0.7 is fine, but master is not. ?So we just have
> to track down which commit(s) in between broke it...
git-bisect to the rescue? Anyone experiencing this and comfortable
with git that wants to track down where the problem was introduced?
It may take a little while, unless the problem can be recreated at
will, but the bisect tool is awesome for situations like this.
-Ben
--
---------------------------------------------------------------------------------------------------------------------------
Ben Walton <bdwalton@gmail.com>
"With or without religion, good people can behave well and bad people
can do evil; but for good people to do evil?that takes religion. "
-Steven Weinberg
---------------------------------------------------------------------------------------------------------------------------
------------------------------
Message: 95
Date: Thu, 30 Apr 2009 06:19:20 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Inconsistent inbox after restart
Message-ID: <1241097437-sup-8272@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Steve Goldman's message of 2009-04-30:
> I have confirmed that 0.7 is fine, but master is not. So we just have
> to track down which commit(s) in between broke it...
Ok, now we're onto something! As an educated guess, I've published a
branch revert-background-save, which is identical to master except that
the commits on the background-save branch have been reverted. Can you
try that branch please?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 96
Date: Thu, 30 Apr 2009 06:36:22 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Inconsistent inbox after restart
Message-ID: <1241098531-sup-1508@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Walton's message of 2009-04-30:
> git-bisect to the rescue? Anyone experiencing this and comfortable
> with git that wants to track down where the problem was introduced?
> It may take a little while, unless the problem can be recreated at
> will, but the bisect tool is awesome for situations like this.
If the educated guesses fall through, then we'll punish Steve for his
insulin by making him binary search through all commits since 0.7.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 97
Date: Thu, 30 Apr 2009 10:07:57 -0400
From: Ben Walton <bdwalton@gmail.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup with Microsoft Exchange 2007
Message-ID:
<f96e0240904300707k4d629f33hc660a9792545257e@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
On Wed, Apr 29, 2009 at 6:45 PM, William Morgan
<wmorgan-sup@masanjin.net> wrote:
> As far as I'm concerned, if it works, I'll add it. I'd love to have this
> functionality in Sup, and it is frequently requested.
Ok. I started cleaning up the original patch last night. I think it
was decent for the most part. The bad parts were the integration into
sup-config. I'll have something ready in a day or two, hopefully.
Since I'm back into mucking with this bit, are you open to having the
maildir scanning code move messages from new/ to cur/? This could
help with the unique id vs directory scanning issue.
-Ben
> --
> William <wmorgan-sup@masanjin.net>
> _______________________________________________
> sup-talk mailing list
> sup-talk@rubyforge.org
> http://rubyforge.org/mailman/listinfo/sup-talk
>
--
---------------------------------------------------------------------------------------------------------------------------
Ben Walton <bdwalton@gmail.com>
"With or without religion, good people can behave well and bad people
can do evil; but for good people to do evil?that takes religion. "
-Steven Weinberg
---------------------------------------------------------------------------------------------------------------------------
------------------------------
Message: 98
Date: Thu, 30 Apr 2009 10:23:25 -0400
From: Steve Goldman <sgoldman@tower-research.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Inconsistent inbox after restart
Message-ID: <1241101364-sup-9621@sgoldmanlinux.tower-research.com>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Thu Apr 30 09:36:22 -0400 2009:
> Reformatted excerpts from Ben Walton's message of 2009-04-30:
> > git-bisect to the rescue? Anyone experiencing this and comfortable
> > with git that wants to track down where the problem was introduced?
> > It may take a little while, unless the problem can be recreated at
> > will, but the bisect tool is awesome for situations like this.
>
> If the educated guesses fall through, then we'll punish Steve for his
> insulin by making him binary search through all commits since 0.7.
Bad news. This new branch is also buggy.
Time to apply the force of brute.
--
Steve Goldman
sgoldman@tower-research.com
T: 212.219.6014
F: 212.219.6007
Tower Research Capital, LLC
377 Broadway, 11th Fl.
New York, NY 10013
------------------------------
Message: 99
Date: Fri, 1 May 2009 12:54:47 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH] Keymap: make new + (apply to tagged)
behaviour nicer
Message-ID:
<1241196888-16400-1-git-send-email-bwalton@artsci.utoronto.ca>
Ok, so I updated to the next branch to work on updating/polishing the
flexible sent source patch and the new + key for apply to tagged
behaviour is driving me nuts. I had a lot of muscle memory built up
around the semi-colon, so it's a tough adjustment for me. I'm willing
to make it, of course, since I think the overall reasoning is sound.
That being said, mapping = to do the same thing as + will save having
to hold shift to access this.
I hope this is ok. Patch to follow.
Thanks
-Ben
------------------------------
Message: 100
Date: Fri, 1 May 2009 12:54:48 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk@rubyforge.org
Cc: Ben Walton <bwalton@artsci.utoronto.ca>
Subject: [sup-talk] [PATCH] Keymap: make new + (apply to tagged)
behaviour nicer
Message-ID:
<1241196888-16400-2-git-send-email-bwalton@artsci.utoronto.ca>
Make = a synonym for + in the thread index mode so that shift isn't
required to apply an action to all tagged messages.
---
lib/sup/modes/thread-index-mode.rb | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb
index 7b87bf6..b44dc18 100644
--- a/lib/sup/modes/thread-index-mode.rb
+++ b/lib/sup/modes/thread-index-mode.rb
@@ -42,7 +42,7 @@ EOS
k.add :toggle_tagged, "Tag/untag selected thread", 't'
k.add :toggle_tagged_all, "Tag/untag all threads", 'T'
k.add :tag_matching, "Tag matching threads", 'g'
- k.add :apply_to_tagged, "Apply next command to all tagged threads", '+'
+ k.add :apply_to_tagged, "Apply next command to all tagged threads", '+', '='
k.add :join_threads, "Force tagged threads to be joined into the same thread", '#'
k.add :undo, "Undo the previous action", 'u'
end
--
1.6.2.1
------------------------------
Message: 101
Date: Fri, 01 May 2009 16:23:53 -0400
From: Steve Goldman <sgoldman@tower-research.com>
To: Sup Talk List <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Inconsistent inbox after restart
Message-ID: <1241209146-sup-3561@sgoldmanlinux.tower-research.com>
Content-Type: text/plain; charset=UTF-8
I have found the offensive commit...
Whoever was working on this, can you take a look and figure out where
the bug is?
(And for all you perl bashers out there, given this ridiculous line
of ruby, you officially can't talk any more shit.)
063ec996a24b13b5dc9a59e21aa42ba629ab510a
--- a/lib/sup/poll.rb
+++ b/lib/sup/poll.rb
@@ -97,7 +97,7 @@ EOS
numi = 0
add_messages_from source do |m, offset, entry|
## always preserve the labels on disk.
- m.labels = entry[:label].split(/\s+/).map { |x| x.intern } if entry
+ m.labels = ((m.labels - [:unread, :inbox]) + entry[:label].split(/\s+/).map { |x| x.intern }).uniq if entry
yield "Found message at #{offset} with labels {#{m.labels * ', '}}"
unless entry
num += 1
--
Steve Goldman
sgoldman@tower-research.com
T: 212.219.6014
F: 212.219.6007
Tower Research Capital, LLC
377 Broadway, 11th Fl.
New York, NY 10013
------------------------------
Message: 102
Date: Mon, 04 May 2009 05:59:49 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup with Microsoft Exchange 2007
Message-ID: <1241441484-sup-8964@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Walton's message of 2009-04-30:
> Since I'm back into mucking with this bit, are you open to having the
> maildir scanning code move messages from new/ to cur/? This could
> help with the unique id vs directory scanning issue.
Would it really help? I'd be willing if so, but I don't see how. Maybe
I'm missing something.
I've avoided moving new/ to cur/ because I didn't see any benefit to
Sup, and it conflicts with the hands-off philosophy, so it just seemed
like one more thing we could screw up. But if there is a real reason to
do it, I'd probably be willing.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 103
Date: Mon, 04 May 2009 06:32:04 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Inconsistent inbox after restart
Message-ID: <1241443759-sup-9889@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Steve Goldman's message of 2009-05-01:
> I have found the offensive commit...
Interesting. I think I see the problem. Were all the messages that
magically reappeared in your inbox messages that were sent to mailing
lists, or otherwise messages that somehow appeared twice in your inbox?
> (And for all you perl bashers out there, given this ridiculous line
> of ruby, you officially can't talk any more shit.)
No one here has bashed Perl. Personally I prefer bashing Python (when
I'm not too busy bashing Java (when I'm not too busy bashing C++)), and
credit Perl for much of what I like about Ruby.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 104
Date: Mon, 4 May 2009 09:41:17 -0400
From: Ben Walton <bdwalton@gmail.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup with Microsoft Exchange 2007
Message-ID:
<f96e0240905040641y5e2a5efetfacee48b8e4260d2@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
On Mon, May 4, 2009 at 8:59 AM, William Morgan <wmorgan-sup@masanjin.net> wrote:
> Reformatted excerpts from Ben Walton's message of 2009-04-30:
>> Since I'm back into mucking with this bit, are you open to having the
>> maildir scanning code move messages from new/ to cur/? This could
>> help with the unique id vs directory scanning issue.
>
> Would it really help? I'd be willing if so, but I don't see how. Maybe
> I'm missing something.
Scan both folders (cur/, new/) on startup or sup-sync. After that,
scan only new. Since mail is moved out of new/ into cur/ after
detection, the time stamp stuff could be dropped since it would be
redundant anyway. I think I'd confused myself about the id generation
issue, so it wouldn't likely be of benefit there.
> I've avoided moving new/ to cur/ because I didn't see any benefit to
> Sup, and it conflicts with the hands-off philosophy, so it just seemed
> like one more thing we could screw up. But if there is a real reason to
> do it, I'd probably be willing.
Sup would be a better Maildir citizen, since this is the intended way
to access/use a maildir source.
-Ben
--
---------------------------------------------------------------------------------------------------------------------------
Ben Walton <bdwalton@gmail.com>
"With or without religion, good people can behave well and bad people
can do evil; but for good people to do evil?that takes religion. "
-Steven Weinberg
---------------------------------------------------------------------------------------------------------------------------
------------------------------
Message: 105
Date: Mon, 04 May 2009 09:46:35 -0400
From: Steve Goldman <sgoldman@tower-research.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Inconsistent inbox after restart
Message-ID: <1241444694-sup-9120@sgoldmanlinux.tower-research.com>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Mon May 04 09:32:04 -0400 2009:
> Reformatted excerpts from Steve Goldman's message of 2009-05-01:
> > I have found the offensive commit...
>
> Interesting. I think I see the problem. Were all the messages that
> magically reappeared in your inbox messages that were sent to mailing
> lists, or otherwise messages that somehow appeared twice in your inbox?
Most of the messages I archive come from lists, so this is possible.
The lists I'm on are smart enough to not deliver messages twice, most
of the time.
> > (And for all you perl bashers out there, given this ridiculous line
> > of ruby, you officially can't talk any more shit.)
>
> No one here has bashed Perl. Personally I prefer bashing Python (when
> I'm not too busy bashing Java (when I'm not too busy bashing C++)), and
> credit Perl for much of what I like about Ruby.
Live and let live!!
--
Steve Goldman
sgoldman@tower-research.com
T: 212.219.6014
F: 212.219.6007
Tower Research Capital, LLC
377 Broadway, 11th Fl.
New York, NY 10013
------------------------------
Message: 106
Date: Mon, 04 May 2009 07:24:15 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Keymap: make new + (apply to tagged)
behaviour nicer
Message-ID: <1241446972-sup-1257@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Walton's message of 2009-05-01:
> Make = a synonym for + in the thread index mode so that shift isn't
> required to apply an action to all tagged messages.
Good idea. Can you make this change against the better-buffer-list
branch instead of next? It's not applying as is.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 107
Date: Mon, 04 May 2009 07:28:43 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Bug fixes and speed improvements for
maildir handling.
Message-ID: <1241447258-sup-9435@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Mark Alexander's message of 2009-04-21:
> ---
> lib/sup/maildir.rb | 10 +++++++---
> 1 files changed, 7 insertions(+), 3 deletions(-)
I think I'm going to drop this patch, as the Maildir code is going to
get changed in other ways very shortly.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 108
Date: Mon, 04 May 2009 07:35:20 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] possible mbox "initial From" fix
Message-ID: <1241447393-sup-7632@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Bart Schaefer's message of 2009-04-29:
> We found that in most cases this failed at (1) or succeeded very
> quickly at (6a). Only obscure cases proceed to (7), but if you're
> dealing with anything like old USENET news archives or folders written
> by '80s-era mail clients you need either step (4) or step (7) to get
> past the cruft.
>
> Note that the key is finding "From ... DATE" rather than "From ADDRESS
> ..." if you really want to distinguish message separators from stuff
> people type in a message body. I'm not sure you can do this with a
> regular expression.
Thanks! This is really helpful. I am a little worried about the current
fix, since there's no real requirement that an email address have an @
sign in it for local users, and that will result in false negatives,
and there's a non-trivial potential for false positives.
If we went this route (which wouldn't require a big changeset), I may
punt on parsing the date myself and just rely on Time.parse. Speed
shouldn't really be affected (except in weird pathological cases) since
the date parsing will be a second step. I like it.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 109
Date: Mon, 4 May 2009 10:44:11 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk@rubyforge.org
Cc: Ben Walton <bwalton@artsci.utoronto.ca>
Subject: [sup-talk] [PATCH] Keymap: improve behaviour of apply to
tagged in thread index
Message-ID:
<1241448251-21371-1-git-send-email-bwalton@artsci.utoronto.ca>
Make = a synonym for + in the thread index mode so that shift isn't
required to apply an action to all tagged messages.
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
---
This is the requeste resend against better-buffer-list.
-Ben
lib/sup/modes/thread-index-mode.rb | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb
index 0bce0de..a45175d 100644
--- a/lib/sup/modes/thread-index-mode.rb
+++ b/lib/sup/modes/thread-index-mode.rb
@@ -42,7 +42,7 @@ EOS
k.add :toggle_tagged, "Tag/untag selected thread", 't'
k.add :toggle_tagged_all, "Tag/untag all threads", 'T'
k.add :tag_matching, "Tag matching threads", 'g'
- k.add :apply_to_tagged, "Apply next command to all tagged threads", '+'
+ k.add :apply_to_tagged, "Apply next command to all tagged threads", '+', '='
k.add :join_threads, "Force tagged threads to be joined into the same thread", '#'
end
--
1.6.2.1
------------------------------
Message: 110
Date: Mon, 04 May 2009 07:48:23 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Keymap: improve behaviour of apply to
tagged in thread index
Message-ID: <1241448496-sup-8476@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Walton's message of 2009-05-04:
> Make = a synonym for + in the thread index mode so that shift isn't
> required to apply an action to all tagged messages.
Applied, thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 111
Date: Mon, 04 May 2009 09:10:23 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Possible problem with maildir ID generation
Message-ID: <1241451919-sup-8970@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Marc Hartstein's message of 2009-04-29:
> On Wed, Apr 29, 2009 at 03:31:52PM -0700, William Morgan wrote:
> > (All this rigamarole about ordinals and blah blah blah is necessary
> > because I don't want Sup to rescan the entire Maildir unless absolutely
> > necessary. One day I'll convert my mbox to a Maildir with 250k files in
> > it, and a rescan will kill me, especially at Ruby speed.)
>
> How are we defining 'rescan' here? I can think of a couple of possible
> meanings, and I'm not sure where you are:
>
> 1. Open every file in the maildir and read from it, every poll.
> 2. Visit every filename in the maildir to consider whether it is a new
> file, every poll.
> 3. Something else I'm not thinking of this instant.
You're probably confused because what I said was wrong. Here's what I
should have said:
Rescanning the entire directory to check for new mail is unavoidable in
Maildir. What I *do* have some control over, i.e. can try to optimize,
is the following operation: given a file in the directory, does it
represent a new message? One way to do this would be to maintain a set
of all filenames representing read messages, and to check for existence
within the set, for every file. Sup doesn't do this; instead it defines
an ordering on filenames, such that newer filenames are "larger" than
older filenames under that ordering, and maintains a threshold
representing the dividing point between new and old. The idea being that
performing that comparison is quick, and that storing the set of read
messages is also quick.
(And again, I care about the case where you have 500k messages, and so
doing set existence is painful. Although perhaps Bloom filters are the
solution... that would be interesting!)
> So the only way you're going to get a timestamp collision (on the
> filename timestamp, perhaps not on the actual ctime) is if you have
> multiple processes delivering mail simultaneously, or if you're
> synchronizing mail delivered on multiple hosts. In the case of the
> latter, a timestamp-based heuristic for finding new messages isn't
> going to work.
I think the collisions we are seeing are due to timestamp granularity.
A little research suggests that e.g. ext2fs ctimes are 1-second
granular. It seems quite easy to get more than one email per second.
> Would it suffice to keep track of the filename of the most recent
> message added for each maildir source, and check everything with a
> time portion of the filename equal to or greater than that message for
> whether it needs to be added? [although see above about whether that
> gains anything]
Yes, I think that's the solution. Basically switch from > to >= when
comparing timestamps, and realize that you're going to get some dupes.
> Having looked into this more closely, I'm starting to seriously
> reconsider whether maildir is really what I want to be using for storing
> my mail. There are some weird timing issues.
Well, mbox has the advantage of being nice and linear so this problem
goes away, but is horribly broken in other ways (c.f. the recent thread
about the "From problem"). IMAP is a ridiculous PITA to deal with (at
least as a client), so you're kinda screwed in every direction here. If
anything, Maildir is less broken than the other alternatives.
Plus Maildir works really well with git. :)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 112
Date: Mon, 04 May 2009 09:22:45 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup with Microsoft Exchange 2007
Message-ID: <1241453755-sup-6000@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Walton's message of 2009-05-04:
> Scan both folders (cur/, new/) on startup or sup-sync. After that,
> scan only new. Since mail is moved out of new/ into cur/ after
> detection, the time stamp stuff could be dropped since it would be
> redundant anyway.
Crap, I think you're right. Polling will be trivial and no more messing
around with timestamps.
In fact I don't even have to scan cur/ on startup; I can just assume
it's unchanged. If you screw with the Maildir via another MUA you have
to run sup-sync --changed, just like with every other source.
For this to work, the "offset" for each message will have to be its
filename. I wonder how many implicit assumptions that will violate.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 113
Date: Mon, 4 May 2009 12:52:24 -0400
From: Marc Hartstein <marc.hartstein@alum.vassar.edu>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Possible problem with maildir ID generation
Message-ID: <20090504165224.GA15815@cabinet.hsd1.ma.comcast.net>
Content-Type: text/plain; charset="us-ascii"
On Mon, May 04, 2009 at 09:10:23AM -0700, William Morgan wrote:
> Rescanning the entire directory to check for new mail is unavoidable in
> Maildir. What I *do* have some control over, i.e. can try to optimize,
> is the following operation: given a file in the directory, does it
> represent a new message? One way to do this would be to maintain a set
> of all filenames representing read messages, and to check for existence
> within the set, for every file. Sup doesn't do this; instead it defines
> an ordering on filenames, such that newer filenames are "larger" than
> older filenames under that ordering, and maintains a threshold
> representing the dividing point between new and old. The idea being that
> performing that comparison is quick, and that storing the set of read
> messages is also quick.
Ok. We're on the same page, then.
It seems to me that comparing a filename to a stored 'threshold' file
name is about the same speed as checking a hash for existence of a key,
and that a hash is also similar in speed for writes...the main thing you
lose is that you have to store a potentially large construct [500k * ~30
bytes] in memory for it to work.
Further, I don't know how database access speeds look (or if some subset
of them can be speed optimized), but you *already* have to store the
filename somewhere so you can go retrieve the messages when they're
accessed, no?
So I'm wondering if you're really gaining all that much from using the
thresholding heuristic over doing it the naive way, and if it's worth
the risk that messages fail to appear because they violate on of the
assumptions of the heuristic. [For instance, what if a user does
something weird like using an rsync cronjob to copy email delivered to
another host over to the host running sup: you could easily have
messages appearing older than the last-scanned timestamp.]
> I think the collisions we are seeing are due to timestamp granularity.
> A little research suggests that e.g. ext2fs ctimes are 1-second
> granular. It seems quite easy to get more than one email per second.
It does, but as I mentioned somewhere in that email, the reference
implementation of maildir (qmail) says that it will only deliver one
message per second. However, I definitely concede that relying on this
behavior would be setting things up for something to go wrong down the
line.
> Yes, I think that's the solution. Basically switch from > to >= when
> comparing timestamps, and realize that you're going to get some dupes.
I think the solution might be to move messages from new/ to cur/, as Ben
Walton suggested. As I understand it, that feature of maildir is
intended *exactly* to cover this case. I know the "don't touch
anything" philosophy, but are non-clobbering moves within a filesystem
sufficiently safe? Other MUAs know that they need to check that some
competing MUA didn't move things out of new/ when they weren't running;
we might want to remind people that maildir can be problematic if more
than one MUA is running simultaneously.
If going this route, manual polls should also rescan cur/. That way if
the user knows they may have invalidated things by running another MUA,
they can get sup to see everything.
> Well, mbox has the advantage of being nice and linear so this problem
> goes away, but is horribly broken in other ways (c.f. the recent thread
> about the "From problem"). IMAP is a ridiculous PITA to deal with (at
> least as a client), so you're kinda screwed in every direction here. If
> anything, Maildir is less broken than the other alternatives.
I was kind of hoping that in the last many years someone had come up
with something that sucks less by now. I saw reference to maildir+; I
wonder if it actually solves anything (and if it's supported by
anything). I picked maildir because I was aware mbox is flawed and have
never even considered IMAP.
> Plus Maildir works really well with git. :)
I noticed that.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090504/c85f05f3/attachment-0001.bin>
------------------------------
Message: 114
Date: Mon, 4 May 2009 13:24:10 -0400
From: Mark Alexander <marka@pobox.com>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Possible problem with maildir ID generation
Message-ID:
<a412e2a70905041024k3b2469e6v5e13d00177a23550@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Mon, May 4, 2009 at 12:52 PM, Marc Hartstein
<marc.hartstein@alum.vassar.edu> wrote:
> On Mon, May 04, 2009 at 09:10:23AM -0700, William Morgan wrote:
>> I think the collisions we are seeing are due to timestamp granularity.
>> A little research suggests that e.g. ext2fs ctimes are 1-second
>> granular. It seems quite easy to get more than one email per second.
>
> It does, but as I mentioned somewhere in that email, the reference
> implementation of maildir (qmail) says that it will only deliver one
> message per second. ?However, I definitely concede that relying on this
> behavior would be setting things up for something to go wrong down the
> line.
Just a data point: in my setup (postfix+procmail) I'm seeing multiple messages
being delivered to the same maildir in the same second. That was what
motivated my patch.
------------------------------
Message: 115
Date: Wed, 6 May 2009 20:02:26 -0400
From: Ben Walton <bdwalton@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] sent source
Message-ID:
<f96e0240905061702m43899549p5ea53b5b6c478b02@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Hi All,
I wanted to poll for thoughts on how to handle a generic mbox as the
sent source. My concern is how to deal with file locking...this is
one of the nastier aspects of mbox files.
The cop-out approach is to allow the user to select any mbox source
configured as the outbox and admonish them not to use it for incoming
mail too...that puts us in the same place as ~/.sup/sent.mbox is now.
Doing this does open sup to user error though and the potential for
trashed mboxes.
The next option is to play with locks, but that's not straight forward
at all. Dovecot, as an example, allows a configuration knob for the
admin to set the order in which the different mechanisms are used.
This works as long as all of the mbox consumers use the same sequence.
There is still lots of room for error here (NFS, etc).
Option 3 is to simply limit the mbox sent source to the SentLoader
class which means that 'regular' mbox files available to the user
can't be a destination for sent mail.
None of these solutions is perfect, and all suck compared to their
maildir or imap counterparts (I'm not even going to bother with
ssh+mbox). What do other 'suppers' think about this?
Thanks
-Ben
--
---------------------------------------------------------------------------------------------------------------------------
Ben Walton <bdwalton@gmail.com>
"With or without religion, good people can behave well and bad people
can do evil; but for good people to do evil?that takes religion. "
-Steven Weinberg
---------------------------------------------------------------------------------------------------------------------------
------------------------------
Message: 116
Date: Wed, 6 May 2009 23:11:09 -0400
From: Ben Walton <bdwalton@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] flexible sent (wip)
Message-ID:
<f96e0240905062011o51cf195bm24eb83ca60ef58d9@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Hi All,
For those interested in the ability to store mail in places other than
the sent.mbox file in the $SUP_BASE directory, you can see my work in
progress by checking out the bw/flexible_sent branch available from:
git://code.chass.utoronto.ca/bwalton-sup.git
This code is branched from a very recent next on WIlliam's mainline.
The present state of the code is working in my tests (I've played with
IMAP and Maildir, but mbox is also a possibility if you're brave...see
my previous message). I haven't added the sup-config part yet, so
you're still required to add a
:sent_source: <some valid source uri>
line to your config.yaml to enable it.
You can setup a testing area (eg separate ferret index, config, etc)
by running sup with SUP_BASE=/some/alternate/.sup/dir if you want to
get a feel for it without touching your working setup.
Comments and feedback are welcome.
Thanks
-Ben
--
---------------------------------------------------------------------------------------------------------------------------
Ben Walton <bdwalton@gmail.com>
"With or without religion, good people can behave well and bad people
can do evil; but for good people to do evil?that takes religion. "
-Steven Weinberg
---------------------------------------------------------------------------------------------------------------------------
------------------------------
Message: 117
Date: Thu, 7 May 2009 12:38:47 +0200
From: Filip Stokkeland <flips@luminated.net>
To: sup-talk@rubyforge.org
Subject: [sup-talk] IMAP questions (n00b) :)
Message-ID:
<24cc29320905070338u1e23c6d3sa78c20dd0da60b19@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi! I just discovered and started testing Sup. And it looks great!
I tried browsing through some of the mailing list archives, and I
found postings saying Sup does not sync back to IMAP(S). So I take it
then, that when I mark mail as read or as spam, nothing happens on the
IMAP server, but only in the local Sup index?
And another thing. I have my main work email today sorted on the
server, using Sieve, so I get new email sorted into 40 different IMAP
folders. In Sup, can I get it to automatically fetch from all
subscribed IMAP folders?
Or maybe I should rather fetch all this email into my own local server
using fetchmail or something and then either put it all in one big
inbox or multiple mboxes locally and then add this as source?
Best regards
--
Filip
------------------------------
Message: 118
Date: Thu, 7 May 2009 13:58:02 +0200
From: Filip Stokkeland <flips@luminated.net>
To: sup-talk@rubyforge.org
Subject: [sup-talk] /usr/bin/run-mailcap
Message-ID:
<24cc29320905070458g7b970ea4rbfcc469d6afc3a3d@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
In Sup, installed on a RHEL 5.1 with EPEL, using gems, when I select
f.ex. html attachments, I just get an error that view doesn't work and
I get the plain text. A quick grep in the code reveals this:
lib/sup/message-chunks.rb: cmd = "/usr/bin/run-mailcap
--action=view '#{@content_type}:#{path}' 2>/dev/null"
I can't find run-mailcap on this RedHat installation. "yum
whatprovides" didn't help and the mailcap package had no such file
installed:
# rpm -ql mailcap
/etc/mailcap
/etc/mime.types
/usr/share/man/man4/mailcap.4.gz
Maybe run-mailcap a Debian/Ubuntu thing? (I'll be back on my regular
ubuntu installation soon enough anyway, just using a lab machine right
now.) In Mutt I don't believe I did anything except use my default
.mailcap ...
Cheers.
--
Filip
------------------------------
Message: 119
Date: Thu, 7 May 2009 09:06:32 -0400
From: Marc Hartstein <marc.hartstein@alum.vassar.edu>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] /usr/bin/run-mailcap
Message-ID: <20090507130632.GA18726@cabinet.hsd1.ma.comcast.net>
Content-Type: text/plain; charset="us-ascii"
On Thu, May 07, 2009 at 01:58:02PM +0200, Filip Stokkeland wrote:
> Maybe run-mailcap a Debian/Ubuntu thing? (I'll be back on my regular
> ubuntu installation soon enough anyway, just using a lab machine right
> now.) In Mutt I don't believe I did anything except use my default
> .mailcap ...
Here on Gentoo I seem to have it provided by app-misc/run-mailcap, which
lists as its homepage
http://packages.debian.org/unstable/net/mime-support
Perhaps you can install the Debian package directly?
It appears I happened to have it as a dependency of my window manager;
is this dependency listed anywhere in the install documentation/on the
wiki?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090507/bfebf553/attachment-0001.bin>
------------------------------
Message: 120
Date: Thu, 07 May 2009 06:07:32 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] /usr/bin/run-mailcap
Message-ID: <1241701545-sup-3821@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Filip Stokkeland's message of 2009-05-07:
> Maybe run-mailcap a Debian/Ubuntu thing? (I'll be back on my regular
> ubuntu installation soon enough anyway, just using a lab machine right
> now.) In Mutt I don't believe I did anything except use my default
> .mailcap ...
It could very well be a Debianism. Is there a good alternative for
RedHat, or does Sup have to start manually parsing ~/.mailcap,
/etc/mailcap/, etc?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 121
Date: Thu, 07 May 2009 06:23:33 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sent source
Message-ID: <1241702060-sup-3211@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Walton's message of 2009-05-06:
> The next option is to play with locks, but that's not straight forward
> at all.
This is my favorite option, because sup-sync-back also has to do mbox
locking, so I don't think we can avoid the issue in general.
> Dovecot, as an example, allows a configuration knob for the admin to
> set the order in which the different mechanisms are used. This works
> as long as all of the mbox consumers use the same sequence. There is
> still lots of room for error here (NFS, etc).
Currently sup-sync-back just says, "hey, you can use this program
/usr/bin/dotlockfile if you have it" and pushes the details of locking
to that. I think that's at least a vaguely reasonable approach. Ideally
it would be more configurable, would fall back to other locking
programs, etc., but I think it's significantly better than not doing any
locking at all.
(Eventually these two mbox writers should share the same locking code,
but don't feel obligated to refactor as part of your patch if it's
already getting too hairy.)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 122
Date: Thu, 07 May 2009 06:12:31 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] IMAP questions (n00b) :)
Message-ID: <1241701676-sup-657@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Filip Stokkeland's message of 2009-05-07:
> Hi! I just discovered and started testing Sup. And it looks great!
Thanks!
> I tried browsing through some of the mailing list archives, and I
> found postings saying Sup does not sync back to IMAP(S). So I take it
> then, that when I mark mail as read or as spam, nothing happens on the
> IMAP server, but only in the local Sup index?
That's correct. I'm not opposed to pushing those flags back to the IMAP
server in principle, at least in batch mode (there's a tool that does
that now for mbox, and I'm working on Maildir), but writing that code
pretty low on my personal priority queue at the moment.
> And another thing. I have my main work email today sorted on the
> server, using Sieve, so I get new email sorted into 40 different IMAP
> folders. In Sup, can I get it to automatically fetch from all
> subscribed IMAP folders?
There's not a good automatic way of doing this. If you can generate the
list of folders, then you can run sup-add on each one.
> Or maybe I should rather fetch all this email into my own local server
> using fetchmail or something and then either put it all in one big
> inbox or multiple mboxes locally and then add this as source?
Current best practice for IMAP is to sync it locally with a program like
offlineimap. That also speeds things up, e.g. when you open a thread
with 100 messages, Sup wants to download them all at once, and IMAP is
much slower than Maildir for that.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 123
Date: Thu, 7 May 2009 11:29:30 -0400
From: Mark Alexander <marka@pobox.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] /usr/bin/run-mailcap
Message-ID:
<a412e2a70905070829w2725cf8dw7ab3c24158bd1bfc@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, May 7, 2009 at 9:07 AM, William Morgan <wmorgan-sup@masanjin.net> wrote:
> Reformatted excerpts from Filip Stokkeland's message of 2009-05-07:
>> Maybe run-mailcap a Debian/Ubuntu thing? ?(I'll be back on my regular
>> ubuntu installation soon enough anyway, just using a lab machine right
>> now.) In Mutt I don't believe I did anything except use my default
>> .mailcap ...
>
> It could very well be a Debianism. Is there a good alternative for
> RedHat, or does Sup have to start manually parsing ~/.mailcap,
> /etc/mailcap/, etc?
For my Fedora 4 system, I found the run-mailcap script somewhere
(I forget where now, but I probably used Google to find it), and manually
installed it in /usr/bin.
------------------------------
Message: 124
Date: Thu, 07 May 2009 09:21:21 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] /usr/bin/run-mailcap
Message-ID: <1241702388-sup-6440@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Thu May 07 09:07:32 -0400 2009:
> It could very well be a Debianism. Is there a good alternative for
> RedHat, or does Sup have to start manually parsing ~/.mailcap,
> /etc/mailcap/, etc?
I just copied the script onto my box (rhel5.3) and it works fine.
Maybe a config knob for those that can't stick it in /usr/bin (or a
less hardcoded way of calling it to allow for $PATH).
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090507/5bc6dee1/attachment-0001.bin>
------------------------------
Message: 125
Date: Thu, 07 May 2009 17:57:22 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sent source
Message-ID: <1241733359-sup-131@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Thu May 07 09:23:33 -0400 2009:
> Reformatted excerpts from Ben Walton's message of 2009-05-06:
> > The next option is to play with locks, but that's not straight forward
> > at all.
>
> This is my favorite option, because sup-sync-back also has to do mbox
> locking, so I don't think we can avoid the issue in general.
Ok. This is the direction I'll go. This will be the most difficult
part of the whole thing.
> Currently sup-sync-back just says, "hey, you can use this program
> /usr/bin/dotlockfile if you have it" and pushes the details of locking
> to that. I think that's at least a vaguely reasonable approach. Ideally
> it would be more configurable, would fall back to other locking
> programs, etc., but I think it's significantly better than not doing any
> locking at all.
Wouldn't it be nicer to handle this internally?
> (Eventually these two mbox writers should share the same locking code,
> but don't feel obligated to refactor as part of your patch if it's
> already getting too hairy.)
Ok.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090507/9dcc7d13/attachment-0001.bin>
------------------------------
Message: 126
Date: Thu, 07 May 2009 18:01:16 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: Sup Mailing List <sup-talk@rubyforge.org>
Subject: [sup-talk] flexible sent source (update)
Message-ID: <1241733502-sup-26@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Hi All,
I've pushed a few new changes to the bw/flexible_sent branch at
git://code.chass.utoronto.ca/bwalton-sup.git. It is now possible to
use sup-config to choose which (valid) mail source to store messages
in and I tweaked how the special sent label is applied.
I'd appreciate it if those interested in the topic played with this
branch. William, I'd also appreciate any feedback you have on it at
this point. (Do you mind pulling my branch, or would you prefer a
git-send-email stack of patches?)
I still need to tackle mbox locking...
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090507/b2a65479/attachment-0001.bin>
------------------------------
Message: 127
Date: Fri, 8 May 2009 09:42:26 -0700
From: Andrew Pimlott <andrew@pimlott.net>
To: sup-talk@rubyforge.org
Subject: [sup-talk] sup-sync dies; memory limit?
Message-ID: <20090508164226.GA28854@pimlott.net>
Content-Type: text/plain; charset=us-ascii
I have been running sup-sync on a new mailbox, and it tends to get
partway through and then die, but not in the same place each time.
Twice, the error has been like
/var/lib/gems/1.8/gems/sup-0.7/lib/sup/crypto.rb:162:in ``': Cannot allocate memory - /usr/bin/gpg --quiet --batch --no-verbose --logger-fd 1 --use-agent --verify /tmp/28751-0-redwood.signature /tmp/28751-0-redwood.payload 2> /dev/null (Errno::ENOMEM)
followed by a backtrace. Another time, it was just
zsh: killed /var/lib/gems/1.8/bin/sup-sync --all-sources
I monitored the sup-sync process the last time. It's memory use grew
slowly, and the process died at around 64M of virtual memory. I don't
have any memory limits set. Is it possible that sup-sync or ruby uses
some itself? Any other ideas?
Andrew
------------------------------
Message: 128
Date: Fri, 08 May 2009 22:10:55 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sent source
Message-ID: <1241834800-sup-1443@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Thu May 07 09:23:33 -0400 2009:
> Currently sup-sync-back just says, "hey, you can use this program
> /usr/bin/dotlockfile if you have it" and pushes the details of locking
> to that. I think that's at least a vaguely reasonable approach. Ideally
> it would be more configurable, would fall back to other locking
> programs, etc., but I think it's significantly better than not doing any
> locking at all.
...Ok, what about implementing the dotlockfile functionality inside a
LockManager singleton? I'm thinking about something that would accept
a list of required locks before allowing read and write. It would
then provide with_readlock(file, &block) and with_writelock(file,
&block) methods that obtain required locks and yield to the caller to
do the actual work.
> (Eventually these two mbox writers should share the same locking code,
> but don't feel obligated to refactor as part of your patch if it's
> already getting too hairy.)
sup-sync-back could make use of this LockManager too.
Thoughts?
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090508/8b72cea9/attachment-0001.bin>
------------------------------
Message: 129
Date: Sat, 09 May 2009 06:01:04 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sent source
Message-ID: <1241873892-sup-9543@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Walton's message of 2009-05-08:
> ...Ok, what about implementing the dotlockfile functionality inside a
> LockManager singleton? I'm thinking about something that would accept
> a list of required locks before allowing read and write. It would
> then provide with_readlock(file, &block) and with_writelock(file,
> &block) methods that obtain required locks and yield to the caller to
> do the actual work.
That sounds good to me and is very much in the spirit of the current Sup
codebase. I'd like to also have a non-yield mechanism (e.g. #lock and
#unlock methods), similar to the interface Mutex exposes, because
sometimes it's irritating to use the block form, but that's icing on the
cake.
> sup-sync-back could make use of this LockManager too.
Yes, definitely they should all share the same code path.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 130
Date: Mon, 11 May 2009 11:26:15 -0700
From: Andrew Pimlott <andrew@pimlott.net>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] sup-sync dies; memory limit?
Message-ID: <20090511182615.GI28854@pimlott.net>
Content-Type: text/plain; charset=us-ascii
I forgot to mention, this was the latest release (0.7) installed with
gem. I just tried the current git mainline (clearing all my .sup state
first), and it got through my whole mailbox without a problem.
Andrew
On Fri, May 08, 2009 at 09:42:26AM -0700, Andrew Pimlott wrote:
> I have been running sup-sync on a new mailbox, and it tends to get
> partway through and then die, but not in the same place each time.
> Twice, the error has been like
>
> /var/lib/gems/1.8/gems/sup-0.7/lib/sup/crypto.rb:162:in ``': Cannot allocate memory - /usr/bin/gpg --quiet --batch --no-verbose --logger-fd 1 --use-agent --verify /tmp/28751-0-redwood.signature /tmp/28751-0-redwood.payload 2> /dev/null (Errno::ENOMEM)
>
> followed by a backtrace. Another time, it was just
>
> zsh: killed /var/lib/gems/1.8/bin/sup-sync --all-sources
>
> I monitored the sup-sync process the last time. It's memory use grew
> slowly, and the process died at around 64M of virtual memory. I don't
> have any memory limits set. Is it possible that sup-sync or ruby uses
> some itself? Any other ideas?
>
> Andrew
> _______________________________________________
> sup-talk mailing list
> sup-talk@rubyforge.org
> http://rubyforge.org/mailman/listinfo/sup-talk
------------------------------
Message: 131
Date: Tue, 12 May 2009 10:19:48 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup-sync dies; memory limit?
Message-ID: <1242148438-sup-9068@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Andrew Pimlott's message of 2009-05-11:
> On Fri, May 08, 2009 at 09:42:26AM -0700, Andrew Pimlott wrote:
> > I don't have any memory limits set. Is it possible that sup-sync or
> > ruby uses some itself? Any other ideas?
Very mysterious. Sup-sync doesn't do anything fancy with memory; it's a
fairly straight-forward Ruby script. Maybe one of the C extensions (like
Ferret) has a memory leak.
> I forgot to mention, this was the latest release (0.7) installed with
> gem. I just tried the current git mainline (clearing all my .sup
> state first), and it got through my whole mailbox without a problem.
Evey more mysterious. The differences between these two versions are
trivial:
diff --git a/origin/release-0.7:bin/sup-sync b/origin/master:bin/sup-sync
index ac5caf6..91710d4 100644
--- a/origin/release-0.7:bin/sup-sync
+++ b/origin/master:bin/sup-sync
@@ -143,12 +143,7 @@ begin
next if target == :changed && entry && entry[:source_id].to_i == source.id && entry[:source_info].to_i == offset
## get the state currently in the index
- index_state =
- if entry
- entry[:label].split(/\s+/).map { |x| x.intern }
- else
- nil
- end
+ index_state = entry[:label].split(/\s+/).map { |x| x.intern } if entry
## skip if we're operating on restored messages, and this one
## ain't.
@@ -163,7 +158,7 @@ begin
## assign message labels based on the operation we're performing
case op
when :asis
- m.labels = index_state if index_state
+ m.labels = ((m.labels - [:unread, :inbox]) + index_state).uniq if index_state
when :restore
## if the entry exists on disk
if restored_state[m.id]
I'm at a loss.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 132
Date: Tue, 12 May 2009 11:31:58 -0700
From: Andrew Pimlott <andrew@pimlott.net>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup-sync dies; memory limit?
Message-ID: <20090512183158.GO28854@pimlott.net>
Content-Type: text/plain; charset=us-ascii
On Tue, May 12, 2009 at 10:19:48AM -0700, William Morgan wrote:
> Reformatted excerpts from Andrew Pimlott's message of 2009-05-11:
> > On Fri, May 08, 2009 at 09:42:26AM -0700, Andrew Pimlott wrote:
> > > I don't have any memory limits set. Is it possible that sup-sync or
> > > ruby uses some itself? Any other ideas?
>
> Very mysterious.
I cannot reproduce the problem anymore, but as far as I know, nothing
changed on my system (other than the inbox I am testing with evolving
routinely). sup-sync from the 0.7 gem now runs to completion and never
uses more than ~36M virtual memory (before it got up around 60M before
crashing). It doesn't seem possible that the git copy of sup affected
the installed gem. So I'm at a complete loss too.
Andrew
------------------------------
Message: 133
Date: Tue, 12 May 2009 12:54:35 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup-sync dies; memory limit?
Message-ID: <1242158027-sup-1409@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Andrew Pimlott's message of 2009-05-12:
> It doesn't seem possible that the git copy of sup affected the
> installed gem. So I'm at a complete loss too.
Let's just pretend this never happened.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 134
Date: Tue, 12 May 2009 12:18:45 -0500
From: Damon Conway <damon.conway@alchemysystems.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] sup crash when doing search
Message-ID: <1242148324-sup-9511@case>
Content-Type: text/plain; charset=UTF-8
I installed the chronic gem with "sudo gem install chronic", and then tried a search by date.
I did "before:(1st apr)" in a global search, and sup crashed. I have included the exception log below.
My guess is that I'm missing a gem, but I'm not quite sure which one. I just installed sup yesterday
after I found it when looking around for any news on imap support in nmh so it's very likely that I've
missed something.
So far sup is quite impressive. Keep up the good work, and thanks for the mail client.
Thanks,
Damon
Some system details:
Ubuntu 9.04
Dell XPS 1210
ruby 1.8.7 (2008-08-11 patchlevel 72) [i486-linux]
gnome-terminal 2.26.0
Screen version 4.00.03jw4 (FAU) 2-May-06
--- NoMethodError from thread: main
private method `gsub' called for nil:NilClass
/var/lib/gems/1.8/gems/sup-0.7/lib/sup/index.rb:568:in `parse_user_query_string'
/var/lib/gems/1.8/gems/sup-0.7/lib/sup/util.rb:499:in `send'
/var/lib/gems/1.8/gems/sup-0.7/lib/sup/util.rb:499:in `method_missing'
/var/lib/gems/1.8/gems/sup-0.7/lib/sup/modes/search-results-mode.rb:29:in `spawn_from_query'
/var/lib/gems/1.8/gems/sup-0.7/bin/sup:239
/var/lib/gems/1.8/bin/sup:19:in `load'
/var/lib/gems/1.8/bin/sup:19
------------------------------
Message: 135
Date: Tue, 12 May 2009 16:33:03 -0700
From: Andrew Pimlott <andrew@pimlott.net>
To: sup-talk@rubyforge.org
Subject: [sup-talk] inconsistencies and new user confusion
Message-ID: <20090512233303.GU28854@pimlott.net>
Content-Type: text/plain; charset=us-ascii
I'm making my second try at switching to sup (though the first was
pretty half-assed). I'm in that state where too many things are
happening that I don't understand, so I need some clarification on how
things are supposed to work. I'm using the mainline as of a few days
ago, where the last checkin is may 4.
There seem to be serious consistency issues. For example, I applied a
label "cal" to a thread. I press "L" to list labels, and it's not
there. I sync the mailbox, unsure if this is needed. (It shouldn't be,
of course--if it is, I hope this is intended to be fixed, perhaps with
the undo work.) Now, "cal" shows up in the label list, but with a
message count less than the number I labeled. At some point down the
line, after more activity, it gets the count right.
Similarly, I have now a mailbox in which I deleted a thread of 2
messages, then added a reply to that mailbox (from outside sup). In my
inbox, I only see the reply, and the labels are "inbox". Shouldn't the
thread always "stick together"? If I switch to the "deleted" label, I
see the expected thread of three messages, but on all three the labels
are "deleted, inbox". I had another case recently in all messages in a
thread had labels "deleted, inbox", but the thread still showed up in my
inbox. Any idea what's going on?
Andrew
------------------------------
Message: 136
Date: Wed, 13 May 2009 00:23:45 -0400
From: Marc Hartstein <marc.hartstein@alum.vassar.edu>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] inconsistencies and new user confusion
Message-ID: <20090513042345.GB18461@cabinet.hsd1.ma.comcast.net>
Content-Type: text/plain; charset="us-ascii"
On Tue, May 12, 2009 at 04:33:03PM -0700, Andrew Pimlott wrote:
> I'm making my second try at switching to sup (though the first was
> pretty half-assed).
Welcome to sup!
> Similarly, I have now a mailbox in which I deleted a thread of 2
> messages, then added a reply to that mailbox (from outside sup). In my
> inbox, I only see the reply, and the labels are "inbox". Shouldn't the
> thread always "stick together"? If I switch to the "deleted" label, I
> see the expected thread of three messages, but on all three the labels
> are "deleted, inbox".
'deleted' means "don't show this to me even if there are new messages in
the thread.
You probably wanted to archive the thread rather than deleting it, which
removes the 'inbox' tag [so it no longer appears in your inbox] but
otherwise leaves it alone, so the entire thread will be shown if there
is any new mail in the thread. The [a] key will archive the currently
selected thread.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090513/cbfb0e0d/attachment-0001.bin>
------------------------------
Message: 137
Date: Wed, 13 May 2009 01:23:49 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: Sup Mailing List <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] inconsistencies and new user confusion
Message-ID: <1242192198-sup-9446@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from marc.hartstein's message of Wed May 13 00:23:45 -0400 2009:
> 'deleted' means "don't show this to me even if there are new messages in
> the thread.
I was under the impression that "killing" a thread was what did that?
Cheers,
Edward
------------------------------
Message: 138
Date: Wed, 13 May 2009 08:14:12 +0100
From: Marcus Williams <marcus-sup@bar-coded.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup crash when doing search
Message-ID: <1242198767-sup-3140@tomsk>
Content-Type: text/plain; charset=utf-8
On 12.5.2009, Damon Conway wrote:
> I did "before:(1st apr)" in a global search, and sup crashed. I have included
> the exception log below.
I can reproduce this, although this used to work. Not sure whats
happening offhand but I'll poke around and see if I can fix it.
Marcus
------------------------------
Message: 139
Date: Wed, 13 May 2009 09:50:24 +0100
From: Marcus Williams <marcus-sup@bar-coded.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup crash when doing search
Message-ID: <1242204467-sup-6823@tomsk>
Content-Type: text/plain; charset=utf-8
On 13.5.2009, I wrote:
> I can reproduce this, although this used to work. Not sure whats
> happening offhand but I'll poke around and see if I can fix it.
Ok, the crash doesnt happen in master only in next. The reason for the
crash is the new "limit" search option that doesnt check if chronic
has failed. Patch for that to follow (against next).
Theres also another bug in that Chronic should default to date
searches in the past as email is almost always dated earlier than your
current time (except spam). So theres a patch for that following as
well (against master)
Marcus
------------------------------
Message: 140
Date: Wed, 13 May 2009 10:00:31 +0100
From: Marcus Williams <marcus-sup@bar-coded.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] [PATCH] limit option parser nil check
Message-ID: <1242205071-sup-2484@tomsk>
Content-Type: text/plain; charset=utf-8
The limit search option doesnt check if the current search term is nil
(when chronic has failed for instance). This patch (against next) adds
the check.
---
lib/sup/index.rb | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/sup/index.rb b/lib/sup/index.rb
index c66a24e..4ebc966 100644
--- a/lib/sup/index.rb
+++ b/lib/sup/index.rb
@@ -584,7 +584,7 @@ protected
BufferManager.flash "Can't understand limit #{lim.inspect}!"
subs = nil
end
- end
+ end unless subs.nil?
if subs
[@qparser.parse(subs), extraopts]
--
1.5.4.1
------------------------------
Message: 141
Date: Wed, 13 May 2009 10:02:31 +0100
From: Marcus Williams <marcus-sup@bar-coded.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] [PATCH] Chronic context fix
Message-ID: <1242205240-sup-5042@tomsk>
Content-Type: text/plain; charset=utf-8
Chronic should use a context of :past for email date searches as emails
tend to be in the past. This fixes a problem when the wrong year is
guessed. To search for emails in the future you now need to be less
ambiguous (1 apr 2099 instead of 1 apr).
---
lib/sup/index.rb | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/sup/index.rb b/lib/sup/index.rb
index 235a18c..779bf02 100644
--- a/lib/sup/index.rb
+++ b/lib/sup/index.rb
@@ -506,7 +506,7 @@ protected
subs = subs.gsub(/\b(before|on|in|during|after):(\((.+?)\)\B|(\S+)\b)/) do
break if chronic_failure
field, datestr = $1, ($3 || $4)
- realdate = Chronic.parse(datestr, :guess => false, :context => :none)
+ realdate = Chronic.parse(datestr, :guess => false, :context => :past)
if realdate
case field
when "after"
--
1.5.4.1
------------------------------
Message: 142
Date: Wed, 13 May 2009 10:31:36 +0100
From: Marcus Williams <marcus-sup@bar-coded.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup crash when doing search
Message-ID: <1242207018-sup-4894@tomsk>
Content-Type: text/plain; charset=utf-8
On 13.5.2009, I wrote:
> Theres also another bug in that Chronic should default to date
> searches in the past as email is almost always dated earlier than your
> current time (except spam). So theres a patch for that following as
> well (against master)
I should also have added that chronic doesnt understand dates like
"1st apr" strangely, but it should have told you (the patches fix this
problem). "1 apr", "apr 1st" are ok I think.
Marcus
------------------------------
Message: 143
Date: Wed, 13 May 2009 12:37:04 +0100
From: Henri Ducrocq <henri.ducrocq@gmail.com>
To: Sup Mailing List <sup-talk@rubyforge.org>
Subject: [sup-talk] Notification tools
Message-ID: <1242213878-sup-4217@ptoseis>
Content-Type: text/plain; charset=UTF-8
(First of alli: Thanks William for that very gorgeous piece of software!)
I would like to use mail-notification (or an equivalent) to display the status of
my inbox in my system tray, I mean the number of unread emails.
But of course that program isn't aware of what messages have been read inside sup.
What can I do to fix this? I thought about having the after-poll hook dump all new
messages into a dummy mbox file, which would be monitored by mail-notification..
But there must be a simpler way?
------------------------------
Message: 144
Date: Wed, 13 May 2009 07:53:11 -0700
From: Andrew Pimlott <andrew@pimlott.net>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] inconsistencies and new user confusion
Message-ID: <20090513145311.GX28854@pimlott.net>
Content-Type: text/plain; charset=us-ascii
On Wed, May 13, 2009 at 12:23:45AM -0400, Marc Hartstein wrote:
> 'deleted' means "don't show this to me even if there are new messages in
> the thread.
Is this the intended behavior? Unfortunately, I'm seeing several
variations. I have a thread now, which I deleted then added a new
message to, and some but not all of the previously deleted messages are
back in my inbox. If I quit sup and restart, only the new message is in
my inbox. As I said, the labels shown in the message headers are
inconsistent as well. In this case, both the deleted messages and the
new message had the deleted label, which contradicts them showing up in
my inbox. After a quit and restart, the new message loses the deleted
label when viewed from my inbox. But if I do a label search for
deleted, the whole thread is there--and even the new message has the
deleted label.
Andrew
------------------------------
Message: 145
Date: Wed, 13 May 2009 16:28:06 +0100
From: Marcus Williams <marcus-sup@bar-coded.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Strange problem in before-edit hook
Message-ID: <1242228484-sup-2569@tomsk>
Content-Type: text/plain; charset=utf-8
The automatic setting of the from address on a reply works really well
in sup, but I've been trying to get new emails do something similar
with the hook mechanism.
I've got the before-edit hook to do set my from address by picking up
the previously used from address from a search using the sent label.
Basically this means if I send a new email to someone using a specific
from address, it picks up my last used from address as the default the
next time I send them an email. This saves having to write something
specific for every email/domain I send to.
It works really well but I get the odd crash in the hook because the
header['To'] sometimes is an array rather than the expected string.
I've got around this by doing a to_s on the header but I cant figure
out why I'd ever get an array. Anyone got any ideas?
Heres the hook:
### start of before-edit
fr = nil
emailto = ""
hdrto = header["To"].to_s
hdrto.split(' ').find() { |e| e.include?("@") }.each() do |ee|
if ee.include?("<")
emailto = ee[1..-2]
else
emailto = ee
end
end
Index.index.search_each("to:\"#{emailto}\" AND label:sent") { |id, score| m = Index.build_message(id); fr = m.from }
header["From"] = fr.full_address unless fr.nil?
header["Return-Path"] = header["From"]
### end of before-edit
------------------------------
Message: 146
Date: Wed, 13 May 2009 11:11:10 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] flexible sent source (update)
Message-ID: <1242238048-sup-6168@entry>
Content-Type: text/plain; charset=UTF-8
Hi Ben,
Reformatted excerpts from Ben Walton's message of 2009-05-07:
> I'd appreciate it if those interested in the topic played with this
> branch. William, I'd also appreciate any feedback you have on it at
> this point. (Do you mind pulling my branch, or would you prefer a
> git-send-email stack of patches?)
This branch looks great. Thanks! We're going to have to rebase it
against master before merging in, but I think that will be easier once I
merge a few other branches down from next to master.
> I still need to tackle mbox locking...
This is puntable for now, if we make it clear to the user that their
sent box shouldn't also receive mail.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 147
Date: Wed, 13 May 2009 14:50:23 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] flexible sent source (update)
Message-ID: <1242240494-sup-9505@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Wed May 13 14:11:10 -0400 2009:
> Reformatted excerpts from Ben Walton's message of 2009-05-07:
> > I'd appreciate it if those interested in the topic played with this
> > branch. William, I'd also appreciate any feedback you have on it at
> > this point. (Do you mind pulling my branch, or would you prefer a
> > git-send-email stack of patches?)
>
> This branch looks great. Thanks! We're going to have to rebase it
> against master before merging in, but I think that will be easier once I
> merge a few other branches down from next to master.
Ok. I can do that when you're ready.
> > I still need to tackle mbox locking...
>
> This is puntable for now, if we make it clear to the user that their
> sent box shouldn't also receive mail.
Well, I'm working on it (slowly) already. It shouldn't be as bad as
I'd initially thought it would be. The lockfile library should handle
the needs for the dotlocking, and I'll add some fcntl and flock
support too, so that it's "stackable" in a similar fashion to the way
dovecot works.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090513/bbdf512e/attachment-0001.bin>
------------------------------
Message: 148
Date: Wed, 13 May 2009 11:54:53 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Notification tools
Message-ID: <1242239740-sup-8633@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Henri Ducrocq's message of 2009-05-13:
> (First of alli: Thanks William for that very gorgeous piece of
> software!)
Glad you find it useful!
> I would like to use mail-notification (or an equivalent) to display
> the status of my inbox in my system tray, I mean the number of unread
> emails. But of course that program isn't aware of what messages have
> been read inside sup.
Sounds great. I'd love to have that too.
> What can I do to fix this? I thought about having the after-poll hook
> dump all new messages into a dummy mbox file, which would be monitored
> by mail-notification.. But there must be a simpler way?
Having now read the mail-notification manpage... the problem is
mail-notification. It should provide a way for other apps to signal a
notification (the whole Unix philosophy of decomposability, etc.) but it
does not.
Periodically dumping all new messages into a dummy mbox file is a
terrible idea, but I think that's your only Sup-specific option.
Patching mail-notification is a better idea, though that may not be what
you want to hear.
If you're using a recent Gnome, you have some other options. If you're
running notification-daemon (e.g. Ubuntu 9.04), you can install the
libnotify-bin package and having the after-poll hook call notify-bin on
new email. (Not quite the same.) You can also look at the
indicator-applet: libindicate also has Python bindings, so you could
install python-indicate and write a python short program to use that.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 149
Date: Wed, 13 May 2009 11:55:28 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] flexible sent source (update)
Message-ID: <1242240924-sup-7948@entry>
Content-Type: text/plain; charset=UTF-8
Oh yeah:
Reformatted excerpts from William Morgan's message of 2009-05-13:
> Reformatted excerpts from Ben Walton's message of 2009-05-07:
> > (Do you mind pulling my branch, or would you prefer a git-send-email
> > stack of patches?)
I'm perfectly happy to pull from your branch.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 150
Date: Wed, 13 May 2009 15:08:21 -0400
From: Marc Hartstein <marc.hartstein@alum.vassar.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] "interning empty string" from sup-sync
Message-ID: <20090513190821.GC18461@cabinet.hsd1.ma.comcast.net>
Content-Type: text/plain; charset="us-ascii"
I'm attempting to switch back to sup today after a few months hiatus.
As I was using mutt during the hiatus, I've moved a lot of mail from my
inbox (where sup left it for a year) to =archive (so the inbox would be
useful in mutt). So, to switch back, I'm doing a big old sup-sync.
I started with sup-sync -a --all-sources which crashed with this error. In attempting to narrow down which source was causing it, I've noticed that it's coming from a few, but not all, of them. Here's an example:
[magus@cabinet ~]$ sup-sync -a maildir:/home/magus/.maildir/inbox
/home/magus/src/sup/lib/sup/util.rb:8: warning: method redefined; discarding old gen_lock_id
/home/magus/src/sup/lib/sup/util.rb:19: warning: method redefined; discarding old dump_lock_id
[Wed May 13 15:02:05 -0400 2009] using character set encoding "utf8"
/home/magus/src/sup/lib/sup/message-chunks.rb:36: warning: method redefined; discarding old make_tmpname
/usr/lib/ruby/gems/1.8/gems/chronic-0.2.3/lib/chronic/repeaters/repeater_month_name.rb:13: warning: useless use of > in void context
/usr/lib/ruby/gems/1.8/gems/chronic-0.2.3/lib/chronic/repeaters/repeater_month_name.rb:19: warning: useless use of > in void context
/usr/lib/ruby/gems/1.8/gems/chronic-0.2.3/lib/chronic/repeaters/repeater_month_name.rb:25: warning: useless use of < in void context
/home/magus/src/sup/bin/sup-sync:11: warning: method redefined; discarding old to_s
[Wed May 13 15:02:05 -0400 2009] crypto: detected gpg binary in /usr/bin/gpg
[Wed May 13 15:02:05 -0400 2009] locking /home/magus/.sup/lock...
[Wed May 13 15:02:05 -0400 2009] loading index...
[Wed May 13 15:02:05 -0400 2009] loaded index of 26276 messages
[Wed May 13 15:02:05 -0400 2009] scanning maildir /home/magus/.maildir/inbox...
[Wed May 13 15:02:05 -0400 2009] done scanning maildir
Scanning maildir:/home/magus/.maildir/inbox...
[Wed May 13 15:02:05 -0400 2009] hook: read 'mime-decode' from /home/magus/.sup/hooks/mime-decode.rb
[Wed May 13 15:02:05 -0400 2009] hook: read 'before-add-message' from /home/magus/.sup/hooks/before-add-message.rb
[Wed May 13 15:02:05 -0400 2009] unlocking /home/magus/.sup/lock...
/home/magus/src/sup/bin/sup-sync:159:in `intern': interning empty string (ArgumentError)
from /home/magus/src/sup/bin/sup-sync:159
from /home/magus/src/sup/bin/sup-sync:159:in `map'
from /home/magus/src/sup/bin/sup-sync:159
from /home/magus/src/sup/lib/sup/poll.rb:161:in `add_messages_from'
from /home/magus/src/sup/lib/sup/maildir.rb:130:in `each'
from /home/magus/src/sup/lib/sup/maildir.rb:127:in `upto'
from /home/magus/src/sup/lib/sup/maildir.rb:127:in `each'
from /home/magus/src/sup/lib/sup/util.rb:538:in `send'
from /home/magus/src/sup/lib/sup/util.rb:538:in `__pass'
from /home/magus/src/sup/lib/sup/util.rb:525:in `method_missing'
from /home/magus/src/sup/lib/sup/poll.rb:141:in `add_messages_from'
from /home/magus/src/sup/lib/sup/util.rb:499:in `send'
from /home/magus/src/sup/lib/sup/util.rb:499:in `method_missing'
from /home/magus/src/sup/bin/sup-sync:140
from /home/magus/src/sup/bin/sup-sync:135:in `each'
from /home/magus/src/sup/bin/sup-sync:135
This individual source error seems to be the same error message I got
for all sources.
I'm attempting to sup-sync individually one source at a time to see if
the order in which they're sync'ed or something helps (perhaps it was
trying to thread a message with another message which is no longer in
the inbox due to having moved to archive?); will report back if that
seems to clear it up.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090513/29226221/attachment-0001.bin>
------------------------------
Message: 151
Date: Wed, 13 May 2009 13:55:51 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] "interning empty string" from sup-sync
Message-ID: <1242248081-sup-5132@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Marc Hartstein's message of 2009-05-13:
> /home/magus/src/sup/bin/sup-sync:159:in `intern': interning empty string
> (ArgumentError)
> from /home/magus/src/sup/bin/sup-sync:159
That's a bug. Turns out String#split doesn't exactly behave how I
thought:
$ irb
>> " a b c ".split
=> ["a", "b", "c"]
>> " a b c ".split(/\s+/)
=> ["", "a", "b", "c"]
I've fixed this in next.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 152
Date: Wed, 13 May 2009 17:24:00 -0400
From: Marc Hartstein <marc.hartstein@alum.vassar.edu>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] "interning empty string" from sup-sync
Message-ID: <20090513212400.GD18461@cabinet.hsd1.ma.comcast.net>
Content-Type: text/plain; charset="us-ascii"
On Wed, May 13, 2009 at 01:55:51PM -0700, William Morgan wrote:
> I've fixed this in next.
Great, thanks. Pulled, and running it now. If it works, I'll be back
in sup shortly. :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090513/a971d2f1/attachment-0001.bin>
------------------------------
Message: 153
Date: Thu, 14 May 2009 01:23:00 +0100
From: Henri Ducrocq <henri.ducrocq@gmail.com>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Notification tools
Message-ID:
<391beaa80905131723k4b59090bi5bd541d97d1a75f2@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Wed, May 13, 2009 at 7:54 PM, William Morgan <wmorgan-sup@masanjin.net>wrote:
> Periodically dumping all new messages into a dummy mbox file is a
> terrible idea, but I think that's your only Sup-specific option.
> Patching mail-notification is a better idea, though that may not be what
> you want to hear.
It isn't :)
> If you're using a recent Gnome, you have some other options. If you're
> running notification-daemon (e.g. Ubuntu 9.04), you can install the
> libnotify-bin package and having the after-poll hook call notify-bin on
> new email. (Not quite the same.) You can also look at the
> indicator-applet: libindicate also has Python bindings, so you could
> install python-indicate and write a python short program to use that.
I don't use Gnome or KDE (or anything really.)
Re. the notification-daemon tip, that's what I'm doing already (via a python
script of mine, I didn't know about notify-bin!), but sure it isn't the
same.
What I might do: Have after-poll dump the number of unread messages into a
file,
and display that value in my dzen status bar. It might be good enough.
Now I'll only do it if my bloody laptop stops crashing on me... I dropped it
earlier,
I have a very bad feeling about this.
Thanks for you help William,
Henri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090514/bd1c3a00/attachment-0001.html>
------------------------------
Message: 154
Date: Wed, 13 May 2009 20:35:11 -0400
From: Marc Hartstein <marc.hartstein@alum.vassar.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Notification tools
Message-ID: <1242261120-sup-2999@cabinet>
Content-Type: text/plain; charset="utf8"
Excerpts from Henri Ducrocq's message of Wed May 13 20:23:00 -0400 2009:
> What I might do: Have after-poll dump the number of unread messages
> into a file, and display that value in my dzen status bar. It might be
> good enough.
I was thinking about doing that myself, but if I'm stuck having my
status bar monitor poll something, I was wondering if it wouldn't be
easier to have it ask sup somehow rather than having some file in a
known location that has to be written to/parsed.
Has anybody done anything like this? Any code snippets?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090513/d44a1cfb/attachment-0001.bin>
------------------------------
Message: 155
Date: Wed, 13 May 2009 18:52:14 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Notification tools
Message-ID: <1242265757-sup-2754@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Marc Hartstein's message of 2009-05-13:
> Has anybody done anything like this? Any code snippets?
I really need to clean up the code so that all of Sup's special query
parsing (chronic, contact aliases, etc.) is accessible, but you can do
simple queries directly through the Ferret API with a script like:
require 'sup'
i = Redwood::Index.new
i.load
puts "total unread: " + i.ferret.search("label:unread").total_hits
puts "inbox unread: " + i.ferret.search("label:unread AND label:inbox").total_hits
That gets you the number of messages, not the number of threads. (Sup
doesn't store the latter.)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 156
Date: Thu, 14 May 2009 00:05:16 -0400
From: Marc Hartstein <marc.hartstein@alum.vassar.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Notification tools
Message-ID: <1242273707-sup-1213@cabinet>
Content-Type: text/plain; charset="utf8"
Excerpts from William Morgan's message of Wed May 13 21:52:14 -0400 2009:
> parsing (chronic, contact aliases, etc.) is accessible, but you can do
> simple queries directly through the Ferret API with a script like:
Thanks, William, that helps; I can put a quick script around that to get
the desired behavior, at least for now.
Although, I just tried this (I seem to have had to append .to_s to each
of the total_hits), and it works, but all my results are exactly 15
greater than the relevant numbers I see if I go into the label menu with
<L><Enter>. Any idea what might cause that?
----- ~/bin/sup-biff
#!/bin/bash
ruby -I '/home/magus/src/sup/lib' <<EOF
require 'sup'
i = Redwood::Index.new
i.load
puts "total unread: " + i.ferret.search("label:unread").total_hits.to_s
puts "inbox unread: " + i.ferret.search("label:unread AND label:inbox").total_hits.to_s
puts "inbox total: " + i.ferret.search("label:inbox").total_hits.to_s
EOF
-----
[magus@cabinet ~]$ sup-biff
[Wed May 13 23:57:56 -0400 2009] using character set encoding "utf8"
[Wed May 13 23:57:57 -0400 2009] loading index...
[Wed May 13 23:57:57 -0400 2009] loaded index of 26444 messages
total unread: 6121
inbox unread: 442
inbox total: 878
-----
Deleted 16 messages, 5 unread
Draft 1 message, 0 unread
Inbox 853 messages, 427 unread
Killed 0 messages, 0 unread
Sent 388 messages, 0 unread
Spam 0 messages, 0 unread
Starred 24 messages, 0 unread
Unread 6106 messages, 6106 unread
[Personal tags stripped for readability.]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090514/f10e1916/attachment-0001.bin>
------------------------------
Message: 157
Date: Thu, 14 May 2009 09:37:38 +0100
From: Marcus Williams <marcus-sup@bar-coded.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Notification tools
Message-ID: <1242290067-sup-3675@tomsk>
Content-Type: text/plain; charset=utf-8
On 14.5.2009, Marc Hartstein wrote:
> Although, I just tried this (I seem to have had to append .to_s to each
> of the total_hits), and it works, but all my results are exactly 15
> greater than the relevant numbers I see if I go into the label menu with
> <L><Enter>. Any idea what might cause that?
I think the Sup version will by default not include killed or deleted
messages so that might be whats causing it.
Marcus
------------------------------
Message: 158
Date: Thu, 14 May 2009 15:04:44 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: Henri Ducrocq <henri.ducrocq@gmail.com>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Notification tools
Message-ID: <1242305907-sup-1542@ausone.inria.fr>
Content-Type: text/plain; charset=UTF-8
Excerpts from Henri Ducrocq's message of Thu May 14 02:23:00 +0200 2009:
> On Wed, May 13, 2009 at 7:54 PM, William Morgan <wmorgan-sup@masanjin.net>wrote:
>
> > Periodically dumping all new messages into a dummy mbox file is a
> > terrible idea, but I think that's your only Sup-specific option.
> > Patching mail-notification is a better idea, though that may not be what
> > you want to hear.
>
>
> It isn't :)
>
> > If you're using a recent Gnome, you have some other options. If you're
> > running notification-daemon (e.g. Ubuntu 9.04), you can install the
> > libnotify-bin package and having the after-poll hook call notify-bin on
> > new email. (Not quite the same.) You can also look at the
> > indicator-applet: libindicate also has Python bindings, so you could
> > install python-indicate and write a python short program to use that.
>
>
> I don't use Gnome or KDE (or anything really.)
> Re. the notification-daemon tip, that's what I'm doing already (via a python
> script of mine, I didn't know about notify-bin!), but sure it isn't the
> same.
> What I might do: Have after-poll dump the number of unread messages into a
> file,
> and display that value in my dzen status bar. It might be good enough.
I'm doing something quite similar:
I have a status-bar-text hook.
$ cat ~/.sup/hooks/status-bar-text.rb
dir = ENV['HOME']+'/.sup/'
state_new = dir+'state.new'
File.open(state_new, 'w') do |f|
f.puts "SupState { sup_num_inbox_unread = #{num_inbox_unread} }"
end
File.rename(state_new, dir+'state') rescue nil
nil
Then I have tweaked my xmonad config to inject the contents of this
file in my dzen bar.
Best regards,
--
Nicolas Pouillard
------------------------------
Message: 159
Date: Thu, 14 May 2009 16:09:38 -0400
From: Marc Hartstein <marc.hartstein@alum.vassar.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Notification tools
Message-ID: <1242331711-sup-4976@cabinet>
Content-Type: text/plain; charset="utf8"
Excerpts from Marcus Williams's message of Thu May 14 04:37:38 -0400 2009:
> On 14.5.2009, Marc Hartstein wrote:
> > Although, I just tried this (I seem to have had to append .to_s to each
> > of the total_hits), and it works, but all my results are exactly 15
> > greater than the relevant numbers I see if I go into the label menu with
> > <L><Enter>. Any idea what might cause that?
>
> I think the Sup version will by default not include killed or deleted
> messages so that might be whats causing it.
Deleted Unread messages accounted for 5 of the 15, but there are no
Killed, so the remaining 10 are still a mystery.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 244 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090514/28018713/attachment-0001.bin>
------------------------------
Message: 160
Date: Fri, 15 May 2009 17:37:08 +0000
From: Maurice McCarthy <manselton@googlemail.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] gmail login
Message-ID:
<8c09a1500905151037m351adedyefdde82c244e17c0@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi I'm a noob user and not a programmer. Thanks
for your brilliant efforts. I've asked the grml
team to include sup by default. http://grml.org
They ought to love it as grml is a Debian based
installable live distro for admins and geeks.
The sup log tells me that when I log in to my
gmail account it ends up logging in using
plain text.
Fri May 15 17:20:06 +0000 2009: CRAM-MD5 authentication failed:
Net::IMAP::NoResponseError. Trying LOGIN auth...
Fri May 15 17:20:06 +0000 2009: LOGIN authentication failed:
Net::IMAP::NoResponseError. Trying plain-text LOGIN...
Fri May 15 17:20:06 +0000 2009: Successfully connected to
imaps://imap.googlemail.com:993/INBOX.
Have I got something configured wrongly or am I
really advertising my password to the world? Or
is it going through a secure tunnel anyhow?
Many Thanks in advance for your advice If
pipermail had been searchable I'd have looked
in the archives before bothering you. Sorry
for the inconvenience if this has already been
asked.
Maurice
--
Best Wishes
------------------------------
Message: 161
Date: Fri, 15 May 2009 13:57:38 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] gmail login
Message-ID: <1242409947-sup-5182@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Maurice McCarthy's message of Fri May 15 13:37:08 -0400 2009:
> The sup log tells me that when I log in to my
> gmail account it ends up logging in using
> plain text.
This is normal and just a part of a standard IMAP connection auth
sequence. Unless you've got kerberos enabled/SASL auth stuff in
place, the standard IMAP auth options are all pretty nasty (pop3 is no
better)...
> Fri May 15 17:20:06 +0000 2009: CRAM-MD5 authentication failed:
> Net::IMAP::NoResponseError. Trying LOGIN auth...
> Fri May 15 17:20:06 +0000 2009: LOGIN authentication failed:
> Net::IMAP::NoResponseError. Trying plain-text LOGIN...
> Fri May 15 17:20:06 +0000 2009: Successfully connected to
> imaps://imap.googlemail.com:993/INBOX.
You still connected via an ssl secured connection, so even using
horrible auth mechanisms like this, you're reasonably protected during
transit.
Looks good from here.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090515/3372a1e8/attachment-0001.bin>
------------------------------
Message: 162
Date: Fri, 15 May 2009 14:41:33 +0200
From: David Guibert <david.guibert@gmail.com>
To: Marc Hartstein <marc.hartstein@alum.vassar.edu>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Notification tools
Message-ID: <1242391055-sup-4644@orsine>
Content-Type: text/plain; charset=utf8
Hi,
>From Marc Hartstein:
> Excerpts from Marcus Williams's message of Thu May 14 04:37:38 -0400 2009:
> > On 14.5.2009, Marc Hartstein wrote:
> > > Although, I just tried this (I seem to have had to append .to_s to each
> > > of the total_hits), and it works, but all my results are exactly 15
> > > greater than the relevant numbers I see if I go into the label menu with
> > > <L><Enter>. Any idea what might cause that?
> >
> > I think the Sup version will by default not include killed or deleted
> > messages so that might be whats causing it.
>
> Deleted Unread messages accounted for 5 of the 15, but there are no
> Killed, so the remaining 10 are still a mystery.
Spam.
I changed sup-biff to contain:
#!/bin/bash
ruby -I '~/src/sup/lib' <<EOF
require 'sup'
i = Redwood::Index.new
i.load
puts "total spam + unread: " + i.ferret.search("label:unread").total_hits.to_s
puts "total !spam + !deleted + unread: " + i.ferret.search("!label:spam !label:deleted +label:unread").total_hits.to_s
puts "inbox unread: " + i.ferret.search("!label:spam !label:deleted +label:inbox +label:unread").total_hits.to_s
puts "inbox total: " + i.ferret.search("!label:spam !label:deleted +label:inbox").total_hits.to_s
EOF
regards.
--
David
------------------------------
Message: 163
Date: Fri, 15 May 2009 22:22:14 +0100
From: Henri Ducrocq <henri.ducrocq@gmail.com>
To: Sup Mailing List <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Notification tools
Message-ID: <1242422476-sup-9185@ptoseis>
Content-Type: text/plain; charset=UTF-8
Excerpts from Nicolas Pouillard's message of Thu May 14 14:04:44 +0100 2009:
> I have a status-bar-text hook.
...
> Then I have tweaked my xmonad config to inject the contents of this
> file in my dzen bar.
But isn't status-bar-text only triggered by keystrokes?
Anyways, I'm updating the file from after-poll.rb, it seems to work.
Henri
(oops, Nicolas you're gonna receive this email twice)
--
--
Henri
------------------------------
Message: 164
Date: Sat, 16 May 2009 19:01:14 +0400
From: Kirill Smelkov <kirr@landau.phys.spbu.ru>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH] chmod a+x bin/*
Message-ID:
<1242486074-5822-1-git-send-email-kirr@landau.phys.spbu.ru>
The files in there are all executables, and this simplifies running sup
in-tree.
---
0 files changed, 0 insertions(+), 0 deletions(-)
mode change 100644 => 100755 bin/sup
mode change 100644 => 100755 bin/sup-add
mode change 100644 => 100755 bin/sup-config
mode change 100644 => 100755 bin/sup-dump
mode change 100644 => 100755 bin/sup-recover-sources
mode change 100644 => 100755 bin/sup-sync
mode change 100644 => 100755 bin/sup-sync-back
mode change 100644 => 100755 bin/sup-tweak-labels
diff --git a/bin/sup b/bin/sup
old mode 100644
new mode 100755
diff --git a/bin/sup-add b/bin/sup-add
old mode 100644
new mode 100755
diff --git a/bin/sup-config b/bin/sup-config
old mode 100644
new mode 100755
diff --git a/bin/sup-dump b/bin/sup-dump
old mode 100644
new mode 100755
diff --git a/bin/sup-recover-sources b/bin/sup-recover-sources
old mode 100644
new mode 100755
diff --git a/bin/sup-sync b/bin/sup-sync
old mode 100644
new mode 100755
diff --git a/bin/sup-sync-back b/bin/sup-sync-back
old mode 100644
new mode 100755
diff --git a/bin/sup-tweak-labels b/bin/sup-tweak-labels
old mode 100644
new mode 100755
--
1.6.3.9.g6345d
------------------------------
Message: 165
Date: Sat, 16 May 2009 13:16:14 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] chmod a+x bin/*
Message-ID: <1242494144-sup-9441@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Kirill Smelkov's message of Sat May 16 11:01:14 -0400 2009:
> The files in there are all executables, and this simplifies running sup
> in-tree.
'
+1
I was about to do the same patch.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090516/53fcd395/attachment-0001.bin>
------------------------------
Message: 166
Date: Sun, 17 May 2009 20:23:41 +0100
From: Henri Ducrocq <henri.ducrocq@gmail.com>
To: Sup Mailing List <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Notification tools
Message-ID: <1242587689-sup-9833@ptoseis>
Content-Type: text/plain; charset=UTF-8
I'm having a related problem, but this one is totally internal to Sup:
After I read a new email, in most cases (possibly always, I can't say)
the number of unread emails isn't decremented and stays at 1.
I am talking about the number of unread messages shown on the labels
page ('L' shortcut.)
This is fixed by restarting Sup.
I'm using the gem version of Sup, do I need to switch to the development
branch?
--
Henri
------------------------------
Message: 167
Date: Mon, 18 May 2009 08:11:58 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk mailing list <sup-talk@rubyforge.org>
Subject: [sup-talk] merge activity report
Message-ID: <1242659511-sup-4534@entry>
Content-Type: text/plain; charset=UTF-8
Just a brief status report.
In next:
- I've added some refinements to the undo code on the undo-manager
branch and merged that into next. If you're working on something
related to this code, you may need to rebase.
- I've fixed the mbox "From " line detector to try and only split when a
valid date is encountered. (This is on branch various-mbox-fixes.)
This seems to work well for me, but who knows what crazy date formats
are out there. I have it logging a message whenever it finds a From
line and something that it can't parse as a date (and thus decides not
to split), so you may want to keep an eye on the log buffer if you're
using mbox. You can also add test cases to
tests/test_header_parsing.rb, in method test_from_line_splitting, if
you have a particular case you're worried about.
In master:
- I've merged a bunch of stable-seeming features down to master,
including the new buffer code, so you will have to retrain your
fingers to use '=' or '+' instead of ';', which now brings up the
buffer window.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 168
Date: Mon, 18 May 2009 08:21:40 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] chmod a+x bin/*
Message-ID: <1242660088-sup-2297@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Kirill Smelkov's message of 2009-05-16:
> The files in there are all executables, and this simplifies running sup
> in-tree.
Applied, thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 169
Date: Mon, 18 May 2009 08:22:11 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Chronic context fix
Message-ID: <1242660123-sup-512@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Marcus Williams's message of 2009-05-13:
> Chronic should use a context of :past for email date searches as
> emails tend to be in the past. This fixes a problem when the wrong
> year is guessed. To search for emails in the future you now need to be
> less ambiguous (1 apr 2099 instead of 1 apr).
Applied, thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 170
Date: Mon, 18 May 2009 13:19:46 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] merge activity report
Message-ID: <1242667096-sup-7844@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Mon May 18 11:11:58 -0400 2009:
Let me know when you'd like the flexible sent stuff rebased and
against which branch. I'm ready with that any time.
Still working on the locking stuff, which is proving quite
interesting.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090518/59f3b839/attachment-0001.bin>
------------------------------
Message: 171
Date: Mon, 18 May 2009 11:24:54 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] merge activity report
Message-ID: <1242670748-sup-7451@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Walton's message of 2009-05-18:
> Let me know when you'd like the flexible sent stuff rebased and
> against which branch. I'm ready with that any time.
Ok. It will have to be rebased against master, and probably should wait
till I've merged down the scanning-speedups and various-mbox-fixes
branches, to avoid unnecessary conflicts. (The former seems stable
enough, but the latter I've just updated and needs a little more
steeping.)
> Still working on the locking stuff, which is proving quite
> interesting.
Glad to hear it.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 172
Date: Mon, 18 May 2009 11:26:10 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] limit option parser nil check
Message-ID: <1242671123-sup-6919@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Marcus Williams's message of 2009-05-13:
> The limit search option doesnt check if the current search term is nil
> (when chronic has failed for instance). This patch (against next) adds
> the check.
I've reworked this code in the parser-user-query-fix branch, currently
merged into next, and it should no longer require this fix.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 173
Date: Mon, 18 May 2009 11:31:35 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Notification tools
Message-ID: <1242671206-sup-2630@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from William Morgan's message of 2009-05-13:
> require 'sup'
> i = Redwood::Index.new
> i.load
> puts "total unread: " + i.ferret.search("label:unread").total_hits
> puts "inbox unread: " + i.ferret.search("label:unread AND
> label:inbox").total_hits
In the parser-user-query-fix branch (merged into next), you can now use
Index.run_query, which takes a query and returns an array of doc ids.
So you can now do this:
require 'sup'
i = Redwood::Index.new
i.load
puts "total unread: " + i.run_query("label:unread").size.to_s
puts "inbox unread: " + i.run_query("label:unread AND label:inbox").size.to_s
which has the same effect as above, but now you should be able to pass
in all the fancy options you can use on the search line (from:/to: with
contacts, :limit, date options if you have chronic installed, etc).
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 174
Date: Mon, 18 May 2009 11:44:01 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Notification tools
Message-ID: <1242672174-sup-8915@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Henri Ducrocq's message of 2009-05-17:
> I'm having a related problem, but this one is totally internal to Sup:
> After I read a new email, in most cases (possibly always, I can't say)
> the number of unread emails isn't decremented and stays at 1. I am
> talking about the number of unread messages shown on the labels page
> ('L' shortcut.)
Is this still the case after you save state with "$"?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 175
Date: Mon, 18 May 2009 12:17:33 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] inconsistencies and new user confusion
Message-ID: <1242674066-sup-6463@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Andrew Pimlott's message of 2009-05-12:
> There seem to be serious consistency issues. For example, I applied a
> label "cal" to a thread. I press "L" to list labels, and it's not
> there.
Can you try this again? There was a bug with new labels, where they were
disappearing from the label list under certain conditions (though not
from the index).
Note that that list only counts messages.
> I sync the mailbox, unsure if this is needed. (It shouldn't be, of
> course--if it is, I hope this is intended to be fixed, perhaps with
> the undo work.)
Currently it is needed. It would be possible to avoid it, with some work
(Sup has an event broadcast mechanism for things like this), though I
think it will be difficult to maintain the "<label> AND unread" counts.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 176
Date: Mon, 18 May 2009 12:19:49 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] inconsistencies and new user confusion
Message-ID: <1242674270-sup-8612@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Edward Z. Yang's message of 2009-05-12:
> Excerpts from marc.hartstein's message of Wed May 13 00:23:45 -0400 2009:
> > 'deleted' means "don't show this to me even if there are new
> > messages in the thread.
>
> I was under the impression that "killing" a thread was what did that?
Deleted messages don't show up under normal searches. (You have to
explicitly add label:deleted). Killed threads show up in searches,
just not in your inbox.
Killing a thread means "I might find this conversation useful one day,
but stop bugging me about it now."
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 177
Date: Mon, 18 May 2009 15:26:49 -0400
From: Marc Hartstein <marc.hartstein@alum.vassar.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Notification tools
Message-ID: <1242674544-sup-4273@cabinet>
Content-Type: text/plain; charset="utf8"
Excerpts from William Morgan's message of Mon May 18 14:31:35 -0400 2009:
> In the parser-user-query-fix branch (merged into next), you can now use
> Index.run_query, which takes a query and returns an array of doc ids.
> ...
> which has the same effect as above, but now you should be able to pass
> in all the fancy options you can use on the search line (from:/to: with
> contacts, :limit, date options if you have chronic installed, etc).
Cool, thanks. I have a working hacky poller [for ion-statusd] based on
the previous discussion, written to accept arbitrary queries. I'll
update it to use run_query when I have a few minutes to spare the next
time I go to clean it up.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090518/3d44bcc1/attachment-0001.bin>
------------------------------
Message: 178
Date: Mon, 18 May 2009 21:03:55 +0100
From: Henri Ducrocq <henri.ducrocq@gmail.com>
To: sup-talk mailing list <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Notification tools
Message-ID: <1242676869-sup-9153@ptoseis>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Mon May 18 19:44:01 +0100 2009:
> Reformatted excerpts from Henri Ducrocq's message of 2009-05-17:
> > I'm having a related problem, but this one is totally internal to Sup:
> > After I read a new email, in most cases (possibly always, I can't say)
> > the number of unread emails isn't decremented and stays at 1. I am
> > talking about the number of unread messages shown on the labels page
> > ('L' shortcut.)
>
> Is this still the case after you save state with "$"?
Oops, I didn't know about "$"...
All is working as expected now, thanks!
--
Henri
------------------------------
Message: 179
Date: Wed, 20 May 2009 07:55:28 -0700
From: Mark Alexander <marka@pobox.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Strange random changing of default colors
Message-ID:
<a412e2a70905200755n58df4ed2k77b9a1926d876ee@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
For while now I've been running off of the next branch,
and I've been noticing strange and hard-to-reproduce
problems with sup changing the default colors. When
I start it, things are fine for a few minutes, and the default
colors (for things like the unused portion of the display
or quoted text) are fine. Then after a few minutes,
the default colors will get changed to yellow-on-black,
or black-on-red, or some other strange thing. I haven't
been able to track down exactly what causes this.
Sometimes it happens when going through my inbox;
sometimes from doing a '/' to search for a string.
The only thing I can say is that the new default colors
seem to have been picked from some line that was
being displayed by sup. For example, a few times
when an "unreceived message" line was being displayed
in a thread, and I moved the highlight over that line,
the default colors got changed to the colors of that
line (black on red in this case).
I've seen this on both Fedora Core 4 with xterm,
and OpenSUSE 10.2 with konsole. So it's possible
it's a problem with older versions of ncurses.
I'll try this on Ubuntu 8.10 at some point soon.
Has anybody else noticed this?
------------------------------
Message: 180
Date: Wed, 20 May 2009 13:26:42 -0400
From: Marc Hartstein <marc.hartstein@alum.vassar.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Strange random changing of default colors
Message-ID: <1242840017-sup-6420@cabinet>
Content-Type: text/plain; charset="utf8"
Excerpts from Mark Alexander's message of Wed May 20 10:55:28 -0400 2009:
> Has anybody else noticed this?
I'm experiencing it as well. I haven't noticed what causes it, but I've
had things go black-on-green and (I think) black-on-red.
It hasn't happened to me in the last couple of days, which suggests
either that it was fixed in my most recent pull from next, or (perhaps
more likely) that it's caused by a functionality I don't use in my
regular daily use of sup, but did use when I was doing a lot more in the
way of thread management when I was coming back to sup. [I mostly just
read, reply, compose, and archive]
I'm running Gentoo here, and keep my system fairly up-to-date. ncurses
is 5.6-r2, and I run under screen under rxvt-unicode.
Just checked, and it doesn't look like any of the packages I've updated
in the last week are relevant to this.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 244 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090520/19a05657/attachment-0001.bin>
------------------------------
Message: 181
Date: Wed, 20 May 2009 11:04:08 -0700
From: Mark Alexander <marka@pobox.com>
To: Marc Hartstein <marc.hartstein@alum.vassar.edu>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Strange random changing of default colors
Message-ID:
<a412e2a70905201104n13a078f9xf4cfcb746b918dcc@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Wed, May 20, 2009 at 10:26 AM, Marc Hartstein
<marc.hartstein@alum.vassar.edu> wrote:
> Excerpts from Mark Alexander's message of Wed May 20 10:55:28 -0400 2009:
> I'm running Gentoo here, and keep my system fairly up-to-date. ncurses
> is 5.6-r2, and I run under screen under rxvt-unicode.
I forgot to mention I'm running screen too. I'll try eliminating screen
to see if that changes anything.
------------------------------
Message: 182
Date: Wed, 20 May 2009 11:52:04 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Strange random changing of default colors
Message-ID: <1242845310-sup-6904@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Mark Alexander's message of 2009-05-20:
> For while now I've been running off of the next branch, and I've been
> noticing strange and hard-to-reproduce problems with sup changing the
> default colors.
I've fixed this in master and next. The problem was that Curses limits
you to a set number of color pairs, and I had thought that limit was 16
(the Ruby bindings don't seem to expose it), and so if you used Sup for
long enough you would eventually run out of colors and it would
helpfully replace old color definitions with new ones for you. :)
But rumors suggest that the limit is more like 64, except in archaic
cases, so I've hard-coded that instead of 16, and experimentally it
seems fine to me (even running through screen).
Let me know if you experience more color weirdness, especially on
archaic systems like Mac OS and Windows.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 183
Date: Wed, 20 May 2009 21:34:36 +0100
From: Henri Ducrocq <henri.ducrocq@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Handling window resizing
Message-ID:
<391beaa80905201334y4c1832adp161bb28d52f08e1@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I'm using a tiling window manager and my windows get resized quite
frequently. However Sup isn't detecting these events and I have to press
Control-L to redraw the screen. Is that fixed in git?
And more generally, is the git branch stable enough for production use?
Thanks,
Henri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090520/d50248e9/attachment-0001.html>
------------------------------
Message: 184
Date: Thu, 21 May 2009 02:31:16 +0100
From: Henri Ducrocq <henri.ducrocq@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Handling window resizing
Message-ID: <1242868891-sup-4321@ptoseis>
Content-Type: text/plain; charset=UTF-8
Excerpts from Henri Ducrocq's message of Wed May 20 21:34:36 +0100 2009:
> I'm using a tiling window manager and my windows get resized quite
> frequently. However Sup isn't detecting these events and I have to press
> Control-L to redraw the screen.
I tried to do it myself, first by checking for Ncurses::KEY_RESIZE in
nonblocking_getch in buffer.rb (couldn't work because of the IO.select),
then slightly less unsuccessfully by catching the WINCH event, but it
looks like the signal isn't emitted in a completely consistent manner
every time I resize the window.
Any advice William? (Of course I'm secretly hoping you're gonna fix it
yourself :)
--
Henri
------------------------------
Message: 185
Date: Thu, 21 May 2009 07:46:07 -0700
From: Andrew Pimlott <andrew@pimlott.net>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] inconsistencies and new user confusion
Message-ID: <20090521144607.GC28854@pimlott.net>
Content-Type: text/plain; charset=us-ascii
On Mon, May 18, 2009 at 12:17:33PM -0700, William Morgan wrote:
> Reformatted excerpts from Andrew Pimlott's message of 2009-05-12:
> > There seem to be serious consistency issues. For example, I applied a
> > label "cal" to a thread. I press "L" to list labels, and it's not
> > there.
>
> Can you try this again?
What branch? No change on mainline.
> > I sync the mailbox, unsure if this is needed. (It shouldn't be, of
> > course--if it is, I hope this is intended to be fixed, perhaps with
> > the undo work.)
>
> Currently it is needed. It would be possible to avoid it, with some work
> (Sup has an event broadcast mechanism for things like this), though I
> think it will be difficult to maintain the "<label> AND unread" counts.
What I'm getting at is, why not keep the index up-to-date at all times?
The only reason I see not to is so the user can say "oops" and quit
without saving. But that's what undo is for. (Or transactions.)
Andrew
------------------------------
Message: 186
Date: Thu, 21 May 2009 08:22:55 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Handling window resizing
Message-ID: <1242919028-sup-7847@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Henri Ducrocq's message of 2009-05-20:
> I tried to do it myself, first by checking for Ncurses::KEY_RESIZE in
> nonblocking_getch in buffer.rb (couldn't work because of the
> IO.select), then slightly less unsuccessfully by catching the WINCH
> event, but it looks like the signal isn't emitted in a completely
> consistent manner every time I resize the window.
>
> Any advice William?
Sadly no. There have been various attempts, by myself and others to trap
sigwinch (see e.g.
http://www.nabble.com/The-recent-patch-"redraw-screen-upon-sigwinch"-td22662878.html
which is referencing commit 9bc61b52f1a4fb3492e3799240815ed0c2a7b67f)
and to handle Ncurses::KEY_RESIZE, but something always seems screwey.
A free copy of Sup to anyone who figures this out.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 187
Date: Thu, 21 May 2009 08:24:42 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] inconsistencies and new user confusion
Message-ID: <1242919384-sup-7255@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Andrew Pimlott's message of 2009-05-21:
> What branch? No change on mainline.
Sorry, the "next" branch.
> What I'm getting at is, why not keep the index up-to-date at all
> times? The only reason I see not to is so the user can say "oops" and
> quit without saving. But that's what undo is for. (Or transactions.)
This is certainly an option in the future. We've used "$" because until
recently there hasn't been an undo, and because it gives me fond
memories of Mutt. Once undo is fleshed out a bit more, auto-syncing
could certainly be an option.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 188
Date: Thu, 21 May 2009 10:05:37 -0600
From: John Bent <johnbent@lanl.gov>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] mailing list alias
Message-ID: <1242921784-sup-7643@tangerine.lanl.gov>
Content-Type: text/plain; charset=UTF-8
I switched from pine and my life is much better. Thanks William, et al.
However, I do miss being able to create an contact alias that pine
expands to a set of email addresses:
http://www.washington.edu/doit/Lessons/Pine/create_list.html
I know there are ways to create full fledged mailing lists (through my
work or a google group or something) but sometimes this seems heavy
weight. How are other people handling this? Does sup already have
this? Is it time for me to learn ruby?
Thanks,
John
------------------------------
Message: 189
Date: Thu, 21 May 2009 09:33:12 -0700
From: Mark Alexander <marka@pobox.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Strange random changing of default colors
Message-ID: <1242923554-sup-5796@r50p>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Wed May 20 11:52:04 -0700 2009:
> I've fixed this in master and next.
Thanks! It's looking good so far, after a day of use.
------------------------------
Message: 190
Date: Sat, 23 May 2009 11:19:03 -0700
From: Mark Alexander <marka@pobox.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] [PATCH] Use terminal width instead of hardcoded 80
as the wrap length.
Message-ID: <1243102667-sup-6007@r50p>
Content-Type: text/plain; charset=UTF-8
---
lib/sup/message-chunks.rb | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/lib/sup/message-chunks.rb b/lib/sup/message-chunks.rb
index 1bf7796..a463fd4 100644
--- a/lib/sup/message-chunks.rb
+++ b/lib/sup/message-chunks.rb
@@ -41,7 +41,6 @@ end
module Redwood
module Chunk
- WRAP_LEN = 80 # wrap messages and text attachments at this width
class Attachment
HookManager.register "mime-decode", <<EOS
@@ -109,7 +108,7 @@ EOS
@lines = nil
if text
@lines = text.gsub("\r\n", "\n").gsub(/\t/, " ").gsub(/\r/, "").split("\n")
- @lines = lines.map {|l| l.chomp.wrap WRAP_LEN}.flatten
+ @lines = lines.map {|l| l.chomp.wrap Ncurses.cols}.flatten
@quotable = true
end
end
@@ -161,7 +160,7 @@ EOS
attr_reader :lines
def initialize lines
- @lines = lines.map { |l| l.chomp.wrap WRAP_LEN }.flatten # wrap
+ @lines = lines.map { |l| l.chomp.wrap Ncurses.cols }.flatten # wrap
## trim off all empty lines except one
@lines.pop while @lines.length > 1 && @lines[-1] =~ /^\s*$/ && @lines[-2] =~ /^\s*$/
--
1.5.6.3
------------------------------
Message: 191
Date: Sat, 23 May 2009 11:25:57 -0700
From: Mark Alexander <marka@pobox.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] [PATCH] Put labels before subject in thread index
view.
Message-ID: <1243102820-sup-6578@r50p>
Content-Type: text/plain; charset=UTF-8
This patch is probably controversial, and I expect it
to be rejected. But I really like the way Gmail puts
the labels before the subject, and I've duplicated that here.
It helps out at work, where subject lines tend to be very
long, pushing the labels past the right edge of the window.
---
lib/sup/modes/thread-index-mode.rb | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb
index f65d241..897dca7 100644
--- a/lib/sup/modes/thread-index-mode.rb
+++ b/lib/sup/modes/thread-index-mode.rb
@@ -843,10 +843,11 @@ protected
[subj_color, size_widget_text],
[:to_me_color, t.labels.member?(:attachment) ? "@" : " "],
[:to_me_color, dp ? ">" : (p ? '+' : " ")],
- [subj_color, t.subj + (t.subj.empty? ? "" : " ")],
] +
- (t.labels - @hidden_labels).map { |label| [:label_color, "+#{label} "] } +
- [[:snippet_color, snippet]
+ (t.labels - @hidden_labels).map { |label| [:label_color, "#{label} "] } +
+ [
+ [subj_color, t.subj + (t.subj.empty? ? "" : " ")],
+ [:snippet_color, snippet],
]
end
--
1.5.6.3
------------------------------
Message: 192
Date: Sat, 23 May 2009 15:22:28 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Put labels before subject in thread
index view.
Message-ID: <1243106464-sup-8438@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Mark Alexander's message of Sat May 23 14:25:57 -0400 2009:
>
> This patch is probably controversial, and I expect it
> to be rejected. But I really like the way Gmail puts
> the labels before the subject, and I've duplicated that here.
> It helps out at work, where subject lines tend to be very
> long, pushing the labels past the right edge of the window.
I'll give the idea a +1. I'd prefer labels first also. It would also
be more uniform when you get mail without a subject...[why yes, I do
get those from people! :(].
I didn't look at the patch itself, so this comment is purely on the
idea.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090523/df5d8b16/attachment-0001.bin>
------------------------------
Message: 193
Date: Sat, 23 May 2009 15:23:23 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Use terminal width instead of
hardcoded 80 as the wrap length.
Message-ID: <1243106591-sup-6639@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Mark Alexander's message of Sat May 23 14:19:03 -0400 2009:
+1 to this also.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090523/1c908b26/attachment-0001.bin>
------------------------------
Message: 194
Date: Sat, 23 May 2009 16:18:03 -0400
From: Michael Stipicevic <mstipicevic@ieee.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Use terminal width instead of
hardcoded 80 as the wrap length.
Message-ID:
<4c4248150905231318kab3819dw68e3a3a614241c0d@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Sat, May 23, 2009 at 2:19 PM, Mark Alexander <marka@pobox.com> wrote:
> ---
> lib/sup/message-chunks.rb | 5 ++---
> 1 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/lib/sup/message-chunks.rb b/lib/sup/message-chunks.rb
> index 1bf7796..a463fd4 100644
> --- a/lib/sup/message-chunks.rb
> +++ b/lib/sup/message-chunks.rb
> @@ -41,7 +41,6 @@ end
>
> module Redwood
> module Chunk
> - WRAP_LEN = 80 # wrap messages and text attachments at this width
>
> class Attachment
> HookManager.register "mime-decode", <<EOS
> @@ -109,7 +108,7 @@ EOS
> @lines = nil
> if text
> @lines = text.gsub("\r\n", "\n").gsub(/\t/, " ").gsub(/\r/,
> "").split("\n")
> - @lines = lines.map {|l| l.chomp.wrap WRAP_LEN}.flatten
> + @lines = lines.map {|l| l.chomp.wrap Ncurses.cols}.flatten
> @quotable = true
> end
> end
> @@ -161,7 +160,7 @@ EOS
>
> attr_reader :lines
> def initialize lines
> - @lines = lines.map { |l| l.chomp.wrap WRAP_LEN }.flatten # wrap
> + @lines = lines.map { |l| l.chomp.wrap Ncurses.cols }.flatten # wrap
>
> ## trim off all empty lines except one
> @lines.pop while @lines.length > 1 && @lines[-1] =~ /^\s*$/ &&
> @lines[-2] =~ /^\s*$/
>
>
(sorry Mark for getting this twice...)
I don't know, reading little e-mails on a widescreen monitor gets really
annoying. Forcing 80 columns keeps it easier on the eyes. Could this be put
into an option somehow?
- Mike
--
Mike Stipicevic
RPI EE/CSYS '09
mstipicevic@ieee.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090523/3c3274d3/attachment-0001.html>
------------------------------
Message: 195
Date: Sat, 23 May 2009 23:42:29 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: Ben Walton <bwalton@artsci.utoronto.ca>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Put labels before subject in thread
index view.
Message-ID: <1243114920-sup-2740@ausone.local>
Content-Type: text/plain; charset=UTF-8
Excerpts from Ben Walton's message of Sat May 23 21:22:28 +0200 2009:
> Excerpts from Mark Alexander's message of Sat May 23 14:25:57 -0400 2009:
> >
> > This patch is probably controversial, and I expect it
> > to be rejected. But I really like the way Gmail puts
> > the labels before the subject, and I've duplicated that here.
> > It helps out at work, where subject lines tend to be very
> > long, pushing the labels past the right edge of the window.
>
> I'll give the idea a +1. I'd prefer labels first also. It would also
> be more uniform when you get mail without a subject...[why yes, I do
> get those from people! :(].
>
> I didn't look at the patch itself, so this comment is purely on the
> idea.
+1 to the idea too!
--
Nicolas Pouillard
------------------------------
Message: 196
Date: Sat, 23 May 2009 19:32:32 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: Sup Mailing List <sup-talk@rubyforge.org>
Subject: [sup-talk] Multiple email accounts
Message-ID: <1243121499-sup-7569@javelin>
Content-Type: text/plain; charset=UTF-8
Hello all,
Does Sup have any built-in support for multiple sending email accounts, i.e.
using the source to determine what the "From" header should be, and swapping
SMTP servers accordingly?
Cheers,
Edward
------------------------------
Message: 197
Date: Sun, 24 May 2009 00:57:36 +0100
From: Iain <rhomunuq+ml_sup@gmail.com>
To: "Sup-talk@rubyforge.org" <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Multiple email accounts
Message-ID: <1243122989-sup-7769@leda>
Content-Type: text/plain; charset=UTF-8
> Does Sup have any built-in support for multiple sending email accounts, i.e.
> using the source to determine what the "From" header should be, and swapping
> SMTP servers accordingly?
Yes. See
<http://sup.rubyforge.org/wiki/wiki.pl?MultipleAccountsAndReply> and
<http://sup.rubyforge.org/wiki/wiki.pl?Msmtp>.
Cheers,
~Iain
------------------------------
Message: 198
Date: Sat, 23 May 2009 20:00:54 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Use terminal width instead of
hardcoded 80 as the wrap length.
Message-ID: <1243123134-sup-8032@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Michael Stipicevic's message of Sat May 23 16:18:03 -0400 2009:
> I don't know, reading little e-mails on a widescreen monitor gets really
> annoying. Forcing 80 columns keeps it easier on the eyes. Could this be put
> into an option somehow?
But if you leave sup's "we dont' force wrapping" rules alone, this
makes reading mail scroll free if your terminal is wide enough and
doesn't change the behaviour if the terminal is narrower. (Not that
I'm against making it an option either.)
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090523/6fdee8b1/attachment-0001.bin>
------------------------------
Message: 199
Date: Sat, 23 May 2009 20:42:20 -0400
From: Marc Hartstein <marc.hartstein@alum.vassar.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Put labels before subject in thread
index view.
Message-ID: <1243125562-sup-287@cabinet>
Content-Type: text/plain; charset="utf8"
This is a great idea, but can we get it configurable/delegated to a
hook? Bonus points if there's a straightforward way to be able to
switch between the two modes at runtime.
I've occasionally thought I'd want this, as I get a lot of long subject
too, but I wouldn't want multiply-tagged messages [especially with
special tags like inbox and unread] to have the tags obscure the
subject.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090523/0adca6a6/attachment-0001.bin>
------------------------------
Message: 200
Date: Sat, 23 May 2009 23:54:42 -0600
From: John Bent <johnbent@lanl.gov>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] scary exception
Message-ID: <1243143847-sup-5003@tangerine.lanl.gov>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Mon Apr 27 11:46:43 -0600 2009:
> Reformatted excerpts from John Bent's message of 2009-04-27:
> > I'm sorry. I don't remember. The timestamp on my sup executable says
> > Jan 13 2009. I'll try to upgrade and see if I ever see this again.
>
> Yeah, I think it was around March that things got merged in. Try it with
> the latest & greatest and see if it happens again.
>
Ok, I figured out what the problem was. I used to be able to stay
current with git pull; rake gem; sudo gem install pkg/sup-999.gem. But
with a new work proxy and my inability to get git to work w/ a proxy, I
switched to:
git clone http://git.gitorious.org/sup/mainline.git
Then I couldn't figure out how to make a gem in mainline or install so I
just figured out I could approximate an install by copying bin/* into my
path . . . forgot the lib. Anyway, I got the scary exception again and
looked at exception-log.txt and realized I had a mismatch with my libs.
So now I'm doing the git clone mainline thing and using ruby -l lib -w
bin/sup.
Anyway, at the risk of embarrassing myself, I wanted to get this info
out there in case some other poor schlub wanders down my same convoluted
path.
Thanks,
John
------------------------------
Message: 201
Date: Sun, 24 May 2009 13:48:41 +0100
From: Henri Ducrocq <henri.ducrocq@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Put labels before subject in thread
index view.
Message-ID: <1243169011-sup-8091@ptoseis>
Content-Type: text/plain; charset=UTF-8
Excerpts from Marc Hartstein's message of Sun May 24 01:42:20 +0100 2009:
> This is a great idea, but can we get it configurable/delegated to a
> hook? Bonus points if there's a straightforward way to be able to
> switch between the two modes at runtime.
>
> I've occasionally thought I'd want this, as I get a lot of long subject
> too, but I wouldn't want multiply-tagged messages [especially with
> special tags like inbox and unread] to have the tags obscure the
> subject.
We could have an even more configurable presentation of the messages,
with the possibility of having a multiline view, e.g. subject on the
first line, labels on the second, excerpt of the text on the 3rd...
--
Henri
------------------------------
Message: 202
Date: Sun, 24 May 2009 15:52:37 -0400
From: Micah Anderson <micah@riseup.net>
To: sup-talk@rubyforge.org
Subject: [sup-talk] Getting gpg to work
Message-ID: <87k5462s8q.fsf@pond.riseup.net>
Content-Type: text/plain; charset=us-ascii
Hi,
I've just started working with sup and am stuck with a gpg problem.
I'm getting gpg messages that aren't being decoded automatically. They
show up as attachments to a message, and the message body shows as
empty. If I go down to the attachment itself and hit enter I see down
below it saying, "Viewing multipart/encrypted attachment..." and then it
says, "Couldn't execute view command, viewing as text." I dont know what
view command it attempted to execute, but then I see the following in
the body:
--mimepart_4a195eca478b1_5b73..fdbe593a824f3
Content-Type: application/pgp-encrypted
Content-Disposition: attachment
Version: 1
--mimepart_4a195eca478b1_5b73..fdbe593a824f3
Content-Type: application/octet-stream; charset=UTF-8
Content-Disposition: inline; filename=message.asc
-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.6 (GNU/Linux)
...
-----END PGP MESSAGE-----
--mimepart_4a195eca478b1_5b73..fdbe593a824f3--
What do I need to do to get this to work?
Thanks!
Micah
------------------------------
Message: 203
Date: Mon, 25 May 2009 14:18:51 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: "Sup-talk@rubyforge.org" <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Multiple email accounts
Message-ID: <1243275433-sup-6834@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from rhomunuq+ml_sup's message of Sat May 23 19:57:36 -0400 2009:
> Yes. See
> <http://sup.rubyforge.org/wiki/wiki.pl?MultipleAccountsAndReply> and
> <http://sup.rubyforge.org/wiki/wiki.pl?Msmtp>.
Great, that's 99% of what I need. The last 1% is, can Sup auto-detect
what From line to send based on the source of the message, if the
To: header is not intact? (This is commonly the case for mailing lists.
Cheers,
Edward
------------------------------
Message: 204
Date: Tue, 26 May 2009 16:14:24 +0100
From: Henri Ducrocq <henri.ducrocq@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] [PATCH] New hook: after-save
Message-ID: <1243349962-sup-2625@ptoseis>
Content-Type: text/plain; charset=UTF-8
This hook is run when the user presses on '$' to save the state and
index.
I'm using this to update a file used by my dzen status bar to display the
number of unread emails in my inbox.
diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb
index 56dcdff..e3e70bb 100644
--- a/lib/sup/modes/thread-index-mode.rb
+++ b/lib/sup/modes/thread-index-mode.rb
@@ -20,6 +20,12 @@ Variables:
thread: The message thread being marked as spam.
EOS
+ HookManager.register "after-save", <<EOS
+Executes immediately after saving the index.
+Variables:
+num_inbox_total_unread: the total number of unread messages in the inbox
+EOS
+
register_keymap do |k|
k.add :load_threads, "Load #{LOAD_MORE_THREAD_NUM} more threads", 'M'
k.add_multi "Load all threads (! to confirm) :", '!' do |kk|
@@ -409,6 +415,7 @@ EOS
end
end
end
+ HookManager.run "after-save", :num_inbox_total_unread => lambda { Index.num_results_for :labels => [:inbox, :unread] }
end
def cleanup
--
Henri
------------------------------
Message: 205
Date: Wed, 27 May 2009 06:39:06 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] mailing list alias
Message-ID: <1243431456-sup-9767@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from John Bent's message of 2009-05-21:
> I switched from pine and my life is much better. Thanks William, et
> al.
Glad you like it!
> However, I do miss being able to create an contact alias that pine
> expands to a set of email addresses:
> http://www.washington.edu/doit/Lessons/Pine/create_list.html
Sounds like a good idea. Currently Sup has no way of doing this, but a
little modification of the contact manager would probably be all that's
required.
> Is it time for me to learn ruby?
It's always time to learn Ruby!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 206
Date: Wed, 27 May 2009 08:58:23 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Use terminal width instead of
hardcoded 80 as the wrap length.
Message-ID: <1243439667-sup-3947@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Walton's message of 2009-05-23:
> But if you leave sup's "we dont' force wrapping" rules alone, this
> makes reading mail scroll free if your terminal is wide enough and
> doesn't change the behaviour if the terminal is narrower. (Not that
> I'm against making it an option either.)
Seems like there are three main modes of operation that would be
desirable:
1. wrap at 80 chars;
2. wrap at current terminal width;
3. don't wrap.
(In all cases, existing line breaks in the message are left alone.)
Would a three-way toggle irritate anyone?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 207
Date: Wed, 27 May 2009 09:03:13 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] scary exception
Message-ID: <1243439962-sup-7477@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from John Bent's message of 2009-05-23:
> current with git pull; rake gem; sudo gem install pkg/sup-999.gem. But
> with a new work proxy and my inability to get git to work w/ a proxy, I
> switched to:
>
> git clone http://git.gitorious.org/sup/mainline.git
>
> Then I couldn't figure out how to make a gem in mainline or install
These operations should all be the same, regardless of whether you're
cloning the git:// uri or the http:// one.
> just figured out I could approximate an install by copying bin/* into my
> path . . . forgot the lib. Anyway, I got the scary exception again and
> looked at exception-log.txt and realized I had a mismatch with my libs.
> So now I'm doing the git clone mainline thing and using ruby -l lib -w
> bin/sup.
Sup does maintain different version numbers for bin/sup and lib/sup.rb,
and checks for a mismatch, but that's not useful for different versions
from git, since they all claim version "git".
Oh well, glad it works now.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 208
Date: Wed, 27 May 2009 12:05:09 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Use terminal width instead of
hardcoded 80 as the wrap length.
Message-ID: <1243440258-sup-7690@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Wed May 27 11:58:23 -0400 2009:
> Seems like there are three main modes of operation that would be
> desirable:
>
> 1. wrap at 80 chars;
> 2. wrap at current terminal width;
> 3. don't wrap.
>
> (In all cases, existing line breaks in the message are left alone.)
>
> Would a three-way toggle irritate anyone?
Yes, for the message itself, this would work just fine. I'm ok with
the toggle too.
For the header display though, the terminal width should be honoured,
I think.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090527/4914d9ff/attachment-0001.bin>
------------------------------
Message: 209
Date: Wed, 27 May 2009 09:07:08 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Put labels before subject in thread
index view.
Message-ID: <1243440237-sup-9372@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Marc Hartstein's message of 2009-05-23:
> This is a great idea, but can we get it configurable/delegated to a
> hook?
I'd be happy to add an index-model-subject-widget hook, similar to the
index-mode-size-widget hook, if someone wants to write one.
> I've occasionally thought I'd want this, as I get a lot of long
> subject too, but I wouldn't want multiply-tagged messages [especially
> with special tags like inbox and unread] to have the tags obscure the
> subject.
Unread, starred, and other system labels shouldn't be displayed in
thread-view-mode. Index will, except in inbox-mode. It might not be too
bad.
I'll apply this patch and we'll see who yells.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 210
Date: Wed, 27 May 2009 09:13:30 -0700
From: Mark Alexander <marka@pobox.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Use terminal width instead of
hardcoded 80 as the wrap length.
Message-ID:
<a412e2a70905270913x6024bb26wd76e448987b7fb26@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Wed, May 27, 2009 at 8:58 AM, William Morgan
<wmorgan-sup@masanjin.net> wrote:
> Would a three-way toggle irritate anyone?
Sounds good to me.
------------------------------
Message: 211
Date: Wed, 27 May 2009 09:22:54 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Multiple email accounts
Message-ID: <1243440902-sup-4117@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Edward Z. Yang's message of 2009-05-25:
> Great, that's 99% of what I need. The last 1% is, can Sup auto-detect
> what From line to send based on the source of the message, if the To:
> header is not intact? (This is commonly the case for mailing lists.
You can use the reply-from hook to set it automatically however you
want. Try adding something like the following (completely untested!) to
~/.sup/hooks/reply-from.rb:
case message.from.email
when /sup-talk@rubyforge.org/i
Person.from_address "Edward Z. Yang <ezy+i-love-sup@mit.edu>"
end
If the hook returns nil, Sup does the default computation.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 212
Date: Wed, 27 May 2009 18:24:07 +0200
From: Guillaume Quintard <guillaume.quintard@gmail.com>
To: "Sup-talk@rubyforge.org" <sup-talk@rubyforge.org>
Subject: [sup-talk] Arg, gmail
Message-ID:
<1e5fdab70905270924t798c4e5er3978e717b2215d48@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi all,
I'm having a *little* problem with gmail: I can't send mail with
neither msmtp nor ssmtp, I get "no route to host" with the first one
and "can't auth" with the latter, even though last year it worked (I
got too annoyed by ferrets errors I dropped sup, shame on me!). If
anyone has a (s|m)smtp+gmail config, could he please mail me in
private to help me tackle this? I don't want to flood the mlist.
By the way, two questions:
- when we'll we see an automatic option to save changes to a mail as
we quit it (.a or ,a or x to kill the buffer)?
- I can haz a width limit so I don't loose sight of my mails whenever
I sleep on the right key? (cheezburger would be good too)
in inbox-mode that's just max(arbitrary_size, terminal_width)
in thread-view-mode max(terminal_width, 80 + max_depth*indent)
anyway, awesome job, I'm always amazed that sup is the only one of it's kind.
--
Guillaume
------------------------------
Message: 213
Date: Wed, 27 May 2009 09:25:44 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Getting gpg to work
Message-ID: <1243441483-sup-2270@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Micah Anderson's message of 2009-05-24:
> I'm getting gpg messages that aren't being decoded automatically.
In the early part of Sup's log, does it mention being able to find the
gpg binary? (When in Sup, hit b until you see the log-mode buffer and
then scroll to the top.)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 214
Date: Wed, 27 May 2009 09:38:26 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Arg, gmail
Message-ID: <1243442108-sup-6538@entry>
Content-Type: text/plain; charset=UTF-8
Hi Guillaume,
Nice to hear from you again.
Reformatted excerpts from Guillaume Quintard's message of 2009-05-27:
> (I got too annoyed by ferrets errors I dropped sup, shame on me!).
I think we have fixed those in the meanwhile.
> - when we'll we see an automatic option to save changes to a mail as
> we quit it (.a or ,a or x to kill the buffer)?
You mean, so that you don't have to press '$'? When you press 'q'
everything's automatically saved. Does that help?
But now that we have undo support, removing the '$' key is an option in
the future.
> - I can haz a width limit so I don't loose sight of my mails whenever
> I sleep on the right key? (cheezburger would be good too)
> in inbox-mode that's just max(arbitrary_size, terminal_width)
> in thread-view-mode max(terminal_width, 80 + max_depth*indent)
This isn't exactly what you want, but you can press '[' to jump back to
the left side of the screen.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 215
Date: Wed, 27 May 2009 17:36:45 +0100
From: Iain <rhomunuq+ml_sup@gmail.com>
To: "Sup-talk@rubyforge.org" <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Arg, gmail
Message-ID: <1243442046-sup-3254@leda>
Content-Type: text/plain; charset=UTF-8
(Replying to the list in case of future person with the same problem.)
> I'm having a *little* problem with gmail: I can't send mail with
> neither msmtp nor ssmtp, I get "no route to host" with the first one
> and "can't auth" with the latter, even though last year it worked
Gmail uses non-standard port 587.
Partial example .msmtprc:
account whateveryouwant
auth on
host smtp.gmail.com
port 587
user yourusername@gmail.com
password yourpassword
tls on
tls_starttls on
tls_certcheck off # Insecure; better would be to add the Gmail cert to
tls_trust_file
auto_from on
------------------------------
Message: 216
Date: Wed, 27 May 2009 19:29:34 +0200
From: Guillaume Quintard <guillaume.quintard@gmail.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Arg, gmail
Message-ID:
<1e5fdab70905271029i1863ef73o7c3570069e6ed978@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Wed, May 27, 2009 at 6:38 PM, William Morgan
<wmorgan-sup@masanjin.net> wrote:
account gmail
auth on
host smtp.gmail.com
port 587
user foo@gmail.com
password bar
tls on
tls_starttls on
tls_certcheck off
tls_trust_file
auto_from on
and I get
smtp: cannot connect to smtp.gmail.com, port 587: No route to host
msmtp: could not send mail (account gmail from /home/shivan/.msmtprc)
Problem sending mail: Couldn't execute msmtp --account=gmail -t
I don't get what I'm not doing right
> I think we have fixed those in the meanwhile.
>
I heard so, that's why I'm back, and so far, so good.
> You mean, so that you don't have to press '$'? When you press 'q'
> everything's automatically saved. Does that help?
not really, I don't close sup very often. what annoys me is that if I
take care of a few mails, by using ",a", go back to inbox, and reload
the view, the mails are still there. Killing the buffer could save.
Since it's only one mail, that would go fast.
> This isn't exactly what you want, but you can press '[' to jump back to
> the left side of the screen.
nope, that's not exactly what I want :-)
--
Guillaume
------------------------------
Message: 217
Date: Wed, 27 May 2009 18:36:45 +0100
From: Iain <rhomunuq+ml_sup@gmail.com>
To: "Sup-talk@rubyforge.org" <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Arg, gmail
Message-ID: <1243445671-sup-2031@leda>
Content-Type: text/plain; charset=UTF-8
> tls_trust_file
Sorry, this was some careless copy-and-pasting on my part.
tls_trust_file was part of the commented line above, not supposed to be
on a separate line by itself.
But that's not what is causing the problem...
> smtp: cannot connect to smtp.gmail.com, port 587: No route to host
> msmtp: could not send mail (account gmail from /home/shivan/.msmtprc)
> Problem sending mail: Couldn't execute msmtp --account=gmail -t
What is the output of:
telnet smtp.gmail.com 587
?
------------------------------
Message: 218
Date: Wed, 27 May 2009 19:41:33 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: Guillaume Quintard <guillaume.quintard@gmail.com>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Arg, gmail
Message-ID: <1243446006-sup-832@ausone.local>
Content-Type: text/plain; charset=UTF-8
Excerpts from Guillaume Quintard's message of Wed May 27 19:29:34 +0200 2009:
> On Wed, May 27, 2009 at 6:38 PM, William Morgan
> <wmorgan-sup@masanjin.net> wrote:
>
> account gmail
> auth on
> host smtp.gmail.com
> port 587
> user foo@gmail.com
> password bar
> tls on
> tls_starttls on
> tls_certcheck off
> tls_trust_file
> auto_from on
>
> and I get
> smtp: cannot connect to smtp.gmail.com, port 587: No route to host
> msmtp: could not send mail (account gmail from /home/shivan/.msmtprc)
> Problem sending mail: Couldn't execute msmtp --account=gmail -t
>
> I don't get what I'm not doing right
I use this one (mostly the same except tls things and no auto_from):
defaults
tls on
account gmail
host smtp.gmail.com
port 587
auth on
user foo
password bar
tls_starttls on
tls_trust_file ............../ThawtePremiumServerCA.crt
tls_certcheck on
logfile /var/log/msmtp.log
--
Nicolas Pouillard
http://nicolaspouillard.fr
------------------------------
Message: 219
Date: Wed, 27 May 2009 10:42:54 -0700
From: Mark Alexander <marka@pobox.com>
To: Guillaume Quintard <guillaume.quintard@gmail.com>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Arg, gmail
Message-ID:
<a412e2a70905271042m1baadac1ydf02986aa7b17a2d@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Wed, May 27, 2009 at 10:29 AM, Guillaume Quintard
<guillaume.quintard@gmail.com> wrote:
> smtp: cannot connect to smtp.gmail.com, port 587: No route to host
I'm away from my home machine so can't check what I'm using there
to send to gmail (I know it's working with msmtp, though). However,
I did try the following just now from a BSD machine:
% telnet smtp.gmail.com 587
Trying 209.85.201.111...
telnet: connect to address 209.85.201.111: Connection refused
% telnet smtp.gmail.com 465
Trying 209.85.201.111...
Connected to gmail-smtp-msa.l.google.com.
Escape character is '^]'.
So you might want to try port 465.
il (account gmail from /home/shivan/.msmtprc)
> Problem sending mail: Couldn't execute msmtp --account=gmail -t
>
> I don't get what I'm not doing right
>
>> I think we have fixed those in the meanwhile.
>>
> I heard so, that's why I'm back, and so far, so good.
>
>> You mean, so that you don't have to press '$'? When you press 'q'
>> everything's automatically saved. Does that help?
>
> not really, I don't close sup very often. what annoys me is that if I
> take care of a few mails, by using ",a", go back to inbox, and reload
> the view, the mails are still there. Killing the buffer could save.
> Since it's only one mail, that would go fast.
>
>
>> This isn't exactly what you want, but you can press '[' to jump back to
>> the left side of the screen.
>
> nope, that's not exactly what I want :-)
>
> --
> Guillaume
> _______________________________________________
> sup-talk mailing list
> sup-talk@rubyforge.org
> http://rubyforge.org/mailman/listinfo/sup-talk
>
------------------------------
Message: 220
Date: Wed, 27 May 2009 19:43:11 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: Mark Alexander <marka@pobox.com>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Use terminal width instead of
hardcoded 80 as the wrap length.
Message-ID: <1243446173-sup-4694@ausone.local>
Content-Type: text/plain; charset=UTF-8
Excerpts from Mark Alexander's message of Wed May 27 18:13:30 +0200 2009:
> On Wed, May 27, 2009 at 8:58 AM, William Morgan
> <wmorgan-sup@masanjin.net> wrote:
> > Would a three-way toggle irritate anyone?
>
> Sounds good to me.
It would also fit my needs.
--
Nicolas Pouillard
http://nicolaspouillard.fr
------------------------------
Message: 221
Date: Wed, 27 May 2009 19:53:04 +0200
From: Guillaume Quintard <guillaume.quintard@gmail.com>
To: Iain <rhomunuq+ml_sup@gmail.com>
Cc: "Sup-talk@rubyforge.org" <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Arg, gmail
Message-ID:
<1e5fdab70905271053qd175badj56474d496fc0ee4a@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Wed, May 27, 2009 at 7:36 PM, Iain <rhomunuq+ml_sup@gmail.com> wrote:
> What is the output of:
> telnet smtp.gmail.com 587
I don't like that. it just keeps hanging, but on another machine,
outside of the LAN, it works perfectly fine. I should talk to the
admins I guess.
Thanks for your time guys.
--
Guillaume
------------------------------
Message: 222
Date: Wed, 27 May 2009 19:51:06 +0100
From: Marcus Williams <marcus-sup@bar-coded.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Multiple email accounts
Message-ID: <1243449836-sup-6622@tomsk>
Content-Type: text/plain; charset=utf-8
On 27.5.2009, William Morgan wrote:
> > Great, that's 99% of what I need. The last 1% is, can Sup auto-detect
> > what From line to send based on the source of the message, if the To:
> > header is not intact? (This is commonly the case for mailing lists.
>
> You can use the reply-from hook to set it automatically however you
> want. Try adding something like the following (completely untested!) to
> ~/.sup/hooks/reply-from.rb:
[snip]
Note also that you might be able to do what you want with the regexen
options in config.yaml - so for instance Sup works out that I reply to
the sup talk mail list with marcus-sup@.... It uses the envelope-to
header to figure this out I seem to remember (coupled with the regexen
settings).
So under one of my accounts I have:
:regexen:
- marcus-.*(at)mydomain.com
(where (at) is replaced with @, and mydomain.com is replaced with the
obvious).
This make sup recognise all incoming emails to my email extensions
that all begin with "marcus-" and unlike the :alternative: settings
are used by sup to figure out what address to reply with. Works well
for all the mailing lists I'm using.
The only problem is they dont get used for sending new addresses (but
I recently sent an email about how I get around that).
HTH
Marcus
------------------------------
Message: 223
Date: Wed, 27 May 2009 16:08:54 -0700
From: Sean Escriva <sean.escriva@gmail.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] sup bombs out attempting to access ssh+mbox
Message-ID: <20090527230854.GA6457@gmail.com>
Content-Type: text/plain; charset="us-ascii"
Thought I'd give sup a try for managing mail from a couple different
servers on the local network, sup-config worked nicely, but sup or
sup-sync bombs out with the attached exceptions
thanks!
-------------- next part --------------
--- NoMethodError from thread: call #connect on mbox+ssh://astrotrain//var/mail/webframp
undefined method `synchronize' for nil:NilClass
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/mbox/ssh-file.rb:181:in `unsafe_connect'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/mbox/ssh-file.rb:192:in `do_remote'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/mbox/ssh-file.rb:117:in `connect'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/mbox/ssh-loader.rb:37:in `connect'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/mbox/ssh-loader.rb:61:in `safely'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/mbox/ssh-loader.rb:37:in `connect'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/util.rb:538:in `send'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/util.rb:538:in `__pass'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/util.rb:525:in `method_missing'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/bin/sup:168
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup.rb:85:in `reporting_thread'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup.rb:83:in `initialize'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup.rb:83:in `new'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup.rb:83:in `reporting_thread'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/bin/sup:166
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/bin/sup:164:in `each'
/home/webframp/.gem/ruby/1.8/gems/sup-0.7/bin/sup:164
/usr/bin/sup:19:in `load'
/usr/bin/sup:19
------------------------------
Message: 224
Date: Wed, 27 May 2009 16:13:47 -0700
From: Sean Escriva <sean.escriva@gmail.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] oops, previous sup exception log
Message-ID: <20090527231347.GA13064@gmail.com>
Content-Type: text/plain; charset=us-ascii
just realized I hadn't seen the answer to this before, sorry for the
repost, I'll try a different source method. thanks for the previous
answer William
------------------------------
Message: 225
Date: Thu, 28 May 2009 08:07:58 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] New hook: after-save
Message-ID: <1243523190-sup-8907@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Henri Ducrocq's message of 2009-05-26:
> This hook is run when the user presses on '$' to save the state and
> index.
> I'm using this to update a file used by my dzen status bar to display the
> number of unread emails in my inbox.
I think I'd prefer to modify the current after-poll hook to an
"after-state-change-hook" (or a better name) and have it fire after
either a poll or a save happens.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 226
Date: Thu, 28 May 2009 08:11:25 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] UTF-8 message sending patch
Message-ID: <1243523439-sup-4045@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Helge Titlestad's message of 2009-04-27:
> I think the patch (attached) fixes my problems, but it's probably far
> from complete. It doesn't detect non-utf8-but-still-illegal-strings,
> it assumes every header except Subject is an address, and so on.
>
> Any feedback is welcome. (:
This has all been added in. If you get a chance, please try the current
master branch of Sup and see if it has the behavior you desire. Thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 227
Date: Thu, 28 May 2009 08:13:56 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] merge activity report
Message-ID: <1243523591-sup-5117@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Walton's message of 2009-05-18:
> Let me know when you'd like the flexible sent stuff rebased and
> against which branch. I'm ready with that any time.
Sorry for the delay on this. I've merged down everything related so a
rebase against master should be pretty easy for you. Once that's done
I will merge it into next.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 228
Date: Thu, 28 May 2009 08:18:15 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk mailing list <sup-talk@rubyforge.org>
Subject: [sup-talk] pending 0.8 release
Message-ID: <1243523649-sup-7696@entry>
Content-Type: text/plain; charset=UTF-8
Hi suppers,
I've merged down several stable-seeming feature branches onto master in
anticipation of an 0.8 release. This release will includes utf8 fixes,
faster mbox reading, preliminary undo support, and many bugfixes. If you
get a chance, please give it a try and report any problems you
encounter.
For the next next version, 0.9, I'd love to see:
- Ben Walton's flexible sent source changes
- Maildir support in sup-sync-back, if I get a chance
- undo support on more actions
- three-way toggle for message text wrapping
- and whatever else you guys feel like submitting patches for!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 229
Date: Thu, 28 May 2009 11:31:36 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] merge activity report
Message-ID: <1243524514-sup-7560@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Thu May 28 11:13:56 -0400 2009:
> Sorry for the delay on this. I've merged down everything related so a
> rebase against master should be pretty easy for you. Once that's done
> I will merge it into next.
No problem. I'd actually rebased against master last night as I'd
seen a flurry of activity on the gitorious rss feed. I did this again
just now and force-pushed my changes to
git://code.chass.utoronto.ca/bwalton-sup.git. [I note this for anyone
that may have pulled from my branch previously...rebasing isn't a nice
thing to do with published branches :) ]
It's the bw/flexible_sent branch available from that URL.
I haven't spent any time on the LockManager stuff in the last week+
though, as the NBA finals have been sapping up my evenings!
Does this rebased branch meet your needs?
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090528/d00cca51/attachment-0001.bin>
------------------------------
Message: 230
Date: Thu, 28 May 2009 09:37:11 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] merge activity report
Message-ID: <1243528605-sup-9712@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Walton's message of 2009-05-28:
> Does this rebased branch meet your needs?
Look great. Merged into next. Thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 231
Date: Thu, 28 May 2009 17:03:16 +0000
From: Ingmar Vanhassel <ingmar@exherbo.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] [PATCH] Use rake/packagegemtask
Message-ID: <20090528170316.GA4359@bach>
Content-Type: text/plain; charset=us-ascii
Sup?
Attached is a patch to use rake/packagegemtask, instead of calling gem1.8 manually.
As far as I can see gem1.8 is a debianism, so calling it directly should
probably be avoided. Thoughts?
Regards,
Ingmar
--
Exherbo KDE, X.org maintainer
------------------------------
Message: 232
Date: Thu, 28 May 2009 17:06:33 +0000
From: Ingmar Vanhassel <ingmar@exherbo.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Use rake/packagegemtask
Message-ID: <20090528170633.GA4432@bach>
Content-Type: text/plain; charset="us-ascii"
Ehm, attached right now...
--
Exherbo KDE, X.org maintainer
-------------- next part --------------
>From abb652d17097468e0b828422752065347a90f317 Mon Sep 17 00:00:00 2001
From: Richard Brown <rbrown@exherbo.org>
Date: Wed, 25 Mar 2009 16:00:50 +0000
Subject: [PATCH] Use rake/packagegemtask
Add back tarball task
---
.gitignore | 2 ++
Rakefile | 38 ++++++++++++++++++++++++++++++++------
sup.gemspec | 30 ------------------------------
3 files changed, 34 insertions(+), 36 deletions(-)
delete mode 100644 sup.gemspec
diff --git a/.gitignore b/.gitignore
index b8d3bcd..0820160 100644
--- a/.gitignore
+++ b/.gitignore
@@ -3,3 +3,5 @@
.ditz-config
# i use emacs
*~
+# i use rake package task
+pkg/
diff --git a/Rakefile b/Rakefile
index 3b1d9f4..67cd0d2 100644
--- a/Rakefile
+++ b/Rakefile
@@ -29,12 +29,38 @@ task :upload_report do |t|
sh "rsync -essh -cavz ditz wmorgan@rubyforge.org:/var/www/gforge-projects/sup/"
end
-task :gem do |t|
- sh "gem1.8 build sup.gemspec"
+$:.push "lib"
+require 'rubygems'
+require "sup-files"
+require "sup-version"
+require 'rake/gempackagetask.rb'
+
+spec = Gem::Specification.new do |s|
+ s.name = %q{sup}
+ s.version = SUP_VERSION
+ s.date = Time.now.to_s
+ s.authors = ["William Morgan"]
+ s.email = %q{wmorgan-sup@masanjin.net}
+ s.summary = %q{A console-based email client with the best features of GMail, mutt, and emacs. Features full text search, labels, tagged operations, multiple buffers, recent contacts, and more.}
+ s.homepage = %q{http://sup.rubyforge.org/}
+ s.description = %q{Sup is a console-based email client for people with a lot of email. It supports tagging, very fast full-text search, automatic contact-list management, and more. If you're the type of person who treats email as an extension of your long-term memory, Sup is for you. Sup makes it easy to: - Handle massive amounts of email. - Mix email from different sources: mbox files (even across different machines), Maildir directories, IMAP folders, POP accounts, and GMail accounts. - Instantaneously search over your entire email collection. Search over body text, or use a query language to combine search predicates in any way. - Handle multiple accounts. Replying to email sent to a particular account will use the correct SMTP server, signature, and from address. - Add custom code to handle certain types of messages or to handle certain types of text within messages. - Organize email with user-defined labels, automatically track recent contacts, and much more! T
he goal of Sup is to become the email client of choice for nerds everywhere.}
+ s.files = SUP_FILES
+ s.executables = SUP_EXECUTABLES
+
+ s.add_dependency "ferret", ">= 0.11.6"
+ s.add_dependency "ncurses", ">= 0.9.1"
+ s.add_dependency "rmail", ">= 0.17"
+ s.add_dependency "highline"
+ s.add_dependency "net-ssh"
+ s.add_dependency "trollop", ">= 1.12"
+ s.add_dependency "lockfile"
+ s.add_dependency "mime-types", "~> 1"
+ s.add_dependency "gettext"
+ s.add_dependency "fastthread"
end
-task :tarball do |t|
- require "sup-files"
- require "sup-version"
- sh "tar cfvz sup-#{SUP_VERSION}.tgz #{SUP_FILES.join(' ')}"
+Rake::GemPackageTask.new(spec) do |pkg|
+ pkg.need_tar = true
end
+
+task :tarball => ["pkg/sup-#{SUP_VERSION}.tgz"]
diff --git a/sup.gemspec b/sup.gemspec
deleted file mode 100644
index 506d8ad..0000000
--- a/sup.gemspec
+++ /dev/null
@@ -1,30 +0,0 @@
-$:.push "lib"
-
-require "sup-files"
-require "sup-version"
-
-Gem::Specification.new do |s|
- s.name = %q{sup}
- s.version = SUP_VERSION
- s.date = Time.now.to_s
- s.authors = ["William Morgan"]
- s.email = %q{wmorgan-sup@masanjin.net}
- s.summary = %q{A console-based email client with the best features of GMail, mutt, and emacs. Features full text search, labels, tagged operations, multiple buffers, recent contacts, and more.}
- s.homepage = %q{http://sup.rubyforge.org/}
- s.description = %q{Sup is a console-based email client for people with a lot of email. It supports tagging, very fast full-text search, automatic contact-list management, and more. If you're the type of person who treats email as an extension of your long-term memory, Sup is for you. Sup makes it easy to: - Handle massive amounts of email. - Mix email from different sources: mbox files (even across different machines), Maildir directories, IMAP folders, POP accounts, and GMail accounts. - Instantaneously search over your entire email collection. Search over body text, or use a query language to combine search predicates in any way. - Handle multiple accounts. Replying to email sent to a particular account will use the correct SMTP server, signature, and from address. - Add custom code to handle certain types of messages or to handle certain types of text within messages. - Organize email with user-defined labels, automatically track recent contacts, and much more! T
he goal of Sup is to become the email client of choice for nerds everywhere.}
- s.files = SUP_FILES
- s.executables = SUP_EXECUTABLES
-
- s.add_dependency "ferret", ">= 0.11.6"
- s.add_dependency "ncurses", ">= 0.9.1"
- s.add_dependency "rmail", ">= 0.17"
- s.add_dependency "highline"
- s.add_dependency "net-ssh"
- s.add_dependency "trollop", ">= 1.12"
- s.add_dependency "lockfile"
- s.add_dependency "mime-types", "~> 1"
- s.add_dependency "gettext"
- s.add_dependency "fastthread"
-
- puts s.files
-end
--
1.6.3.1
------------------------------
Message: 233
Date: Thu, 28 May 2009 15:32:42 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: Sup Mailing List <sup-talk@rubyforge.org>
Subject: [sup-talk] utf patch needs work, i think
Message-ID: <1243539136-sup-9008@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
I just found something funny with the new utf patch. The only thing I
noticed in the headers of relevance was:
To: =?utf-16be?b?/v8AfgA6ACcAJwAgMEIwijBMMGgwRjBUMFYwRDB+MFcA?=
=?utf-16be?b?MF8wAg==?= <j.chetwynd@btinternet.com>
The displayed mail can be seen here:
http://www.cquest.utoronto.ca/u/bwalton/utf-wtf.png
I'll save the message if it's of any use in debugging the problem (it
was a post to the git list). There wasn't anything in the body itself
that looked odd to my quick visual inspection.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090528/eec38321/attachment-0001.bin>
------------------------------
Message: 234
Date: Thu, 28 May 2009 19:32:56 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: Sup Mailing List <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] utf patch needs work, i think
Message-ID: <1243553511-sup-472@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Ben Walton's message of Thu May 28 15:32:42 -0400 2009:
>
> I just found something funny with the new utf patch. The only thing I
> noticed in the headers of relevance was:
>
> To: =?utf-16be?b?/v8AfgA6ACcAJwAgMEIwijBMMGgwRjBUMFYwRDB+MFcA?=
> =?utf-16be?b?MF8wAg==?= <j.chetwynd@btinternet.com>
...a followup on the list makes me wonder if this isn't actually a sup
thing, but a weird encoding 'joke' by the poster. Even if the body
display wasn't a sup bug, the name is still munged up.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090528/fc984a86/attachment-0001.bin>
------------------------------
Message: 235
Date: Fri, 29 May 2009 00:19:24 -0400
From: Micah Anderson <micah@riseup.net>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Getting gpg to work
Message-ID: <8763fkwng3.fsf@pond.riseup.net>
Content-Type: text/plain; charset=us-ascii
William Morgan <wmorgan-sup@masanjin.net> writes:
> Reformatted excerpts from Micah Anderson's message of 2009-05-24:
>> I'm getting gpg messages that aren't being decoded automatically.
>
> In the early part of Sup's log, does it mention being able to find the
> gpg binary? (When in Sup, hit b until you see the log-mode buffer and
> then scroll to the top.)
Indeed I do:
[Fri May 29 00:17:42 -0400 2009] crypto: detected gpg binary in /usr/bin/gpg
micah
------------------------------
Message: 236
Date: Fri, 29 May 2009 14:48:06 +0200
From: Israel Herraiz <israel.herraiz@gmail.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH] Prettier printing of enclosed messages
Message-ID: <4a1fdabb.0a1ad00a.399c.23fb@mx.google.com>
Hi,
this patch prints enclosed messages with only some selected headers
instead of the full headers, just as "normal" messages.
Cheers,
Israel
---
lib/sup/message-chunks.rb | 26 +++++++++++++++++++-------
lib/sup/message.rb | 17 +++++++++++++----
2 files changed, 32 insertions(+), 11 deletions(-)
diff --git a/lib/sup/message-chunks.rb b/lib/sup/message-chunks.rb
index 1bf7796..7b55c91 100644
--- a/lib/sup/message-chunks.rb
+++ b/lib/sup/message-chunks.rb
@@ -208,13 +208,25 @@ EOS
class EnclosedMessage
attr_reader :lines
- def initialize from, body
- @from = from
- @lines = body.split "\n"
- end
+ def initialize from, to, cc, date, subj
+ @from = from ? "unknown sender" : from.full_adress
+ @to = to ? "" : to.map { |p| p.full_address }.join(", ")
+ @cc = cc ? "" : cc.map { |p| p.full_address }.join(", ")
+ if date
+ @date = date.rfc822
+ else
+ @date = ""
+ end
- def from
- @from ? @from.longname : "unknown sender"
+ @subj = subj
+
+ @lines = "\nFrom: #{from}\n"
+ @lines += "To: #{to}\n"
+ if !cc.empty?
+ @lines += "Cc: #{cc}\n"
+ end
+ @lines += "Date: #{date}\n"
+ @lines += "Subject: #{subj}\n\n"
end
def inlineable?; false end
@@ -224,7 +236,7 @@ EOS
def viewable?; false end
def patina_color; :generic_notice_patina_color end
- def patina_text; "Begin enclosed message from #{from} (#{@lines.length} lines)" end
+ def patina_text; "Begin enclosed message sent on #{@date}" end
def color; :quote_color end
end
diff --git a/lib/sup/message.rb b/lib/sup/message.rb
index 6dd1f7d..72ec6c5 100644
--- a/lib/sup/message.rb
+++ b/lib/sup/message.rb
@@ -383,10 +383,19 @@ private
chunks
elsif m.header.content_type == "message/rfc822"
payload = RMail::Parser.read(m.body)
- from = payload.header.from.first
- from_person = from ? Person.from_address(from.format) : nil
- [Chunk::EnclosedMessage.new(from_person, payload.to_s)] +
- message_to_chunks(payload, encrypted)
+ from = payload.header.from.first ? payload.header.from.first.format : ""
+ to = payload.header.to.map { |p| p.format }.join(", ")
+ cc = payload.header.cc.map { |p| p.format }.join(", ")
+ subj = payload.header.subject
+ subj = subj ? Message.normalize_subj(payload.header.subject.gsub(/\s+/, " ").gsub(/\s+$/, "")) : subj
+ if Rfc2047.is_encoded? subj
+ subj = Rfc2047.decode_to $encoding, subj
+ end
+ msgdate = payload.header.date
+ from_person = from ? Person.from_address (from) : nil
+ to_people = to ? Person.from_address_list (to) : nil
+ cc_people = cc ? Person.from_address_list (cc) : nil
+ [Chunk::EnclosedMessage.new(from_person, to_people, cc_people, msgdate, subj)] + message_to_chunks(payload, encrypted)
else
filename =
## first, paw through the headers looking for a filename
--
1.6.3.1
------------------------------
Message: 237
Date: Fri, 29 May 2009 15:19:23 +0200
From: Israel Herraiz <israel.herraiz@gmail.com>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] [PATCH] Fixing a couple of warnings (was
Prettier printing of enclosed messages)
Message-ID:
<691d00b80905290619y77769363t5ca4cbd7f270cc26@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
The patch introduced a couple of warnings. They are fixed with the
attached patch.
Cheers,
Israel
---
lib/sup/message.rb | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/sup/message.rb b/lib/sup/message.rb
index 72ec6c5..422aafb 100644
--- a/lib/sup/message.rb
+++ b/lib/sup/message.rb
@@ -392,9 +392,9 @@ private
subj = Rfc2047.decode_to $encoding, subj
end
msgdate = payload.header.date
- from_person = from ? Person.from_address (from) : nil
- to_people = to ? Person.from_address_list (to) : nil
- cc_people = cc ? Person.from_address_list (cc) : nil
+ from_person = from ? Person.from_address(from) : nil
+ to_people = to ? Person.from_address_list(to) : nil
+ cc_people = cc ? Person.from_address_list(cc) : nil
[Chunk::EnclosedMessage.new(from_person, to_people, cc_people,
msgdate, subj)] + message_to_chunks(payload, encrypted)
else
filename =
--
1.6.3.1
------------------------------
Message: 238
Date: Fri, 29 May 2009 14:48:06 +0200
From: Israel Herraiz <israel.herraiz@gmail.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH] Prettier printing of enclosed messages
Message-ID: <4a1fe5cd.0a04d00a.1d89.ffffe1b2@mx.google.com>
Hi,
this patch prints enclosed messages with only some selected headers
instead of the full headers, just as "normal" messages.
Cheers,
Israel
---
lib/sup/message-chunks.rb | 26 +++++++++++++++++++-------
lib/sup/message.rb | 17 +++++++++++++----
2 files changed, 32 insertions(+), 11 deletions(-)
diff --git a/lib/sup/message-chunks.rb b/lib/sup/message-chunks.rb
index 1bf7796..7b55c91 100644
--- a/lib/sup/message-chunks.rb
+++ b/lib/sup/message-chunks.rb
@@ -208,13 +208,25 @@ EOS
class EnclosedMessage
attr_reader :lines
- def initialize from, body
- @from = from
- @lines = body.split "\n"
- end
+ def initialize from, to, cc, date, subj
+ @from = from ? "unknown sender" : from.full_adress
+ @to = to ? "" : to.map { |p| p.full_address }.join(", ")
+ @cc = cc ? "" : cc.map { |p| p.full_address }.join(", ")
+ if date
+ @date = date.rfc822
+ else
+ @date = ""
+ end
- def from
- @from ? @from.longname : "unknown sender"
+ @subj = subj
+
+ @lines = "\nFrom: #{from}\n"
+ @lines += "To: #{to}\n"
+ if !cc.empty?
+ @lines += "Cc: #{cc}\n"
+ end
+ @lines += "Date: #{date}\n"
+ @lines += "Subject: #{subj}\n\n"
end
def inlineable?; false end
@@ -224,7 +236,7 @@ EOS
def viewable?; false end
def patina_color; :generic_notice_patina_color end
- def patina_text; "Begin enclosed message from #{from} (#{@lines.length} lines)" end
+ def patina_text; "Begin enclosed message sent on #{@date}" end
def color; :quote_color end
end
diff --git a/lib/sup/message.rb b/lib/sup/message.rb
index 6dd1f7d..72ec6c5 100644
--- a/lib/sup/message.rb
+++ b/lib/sup/message.rb
@@ -383,10 +383,19 @@ private
chunks
elsif m.header.content_type == "message/rfc822"
payload = RMail::Parser.read(m.body)
- from = payload.header.from.first
- from_person = from ? Person.from_address(from.format) : nil
- [Chunk::EnclosedMessage.new(from_person, payload.to_s)] +
- message_to_chunks(payload, encrypted)
+ from = payload.header.from.first ? payload.header.from.first.format : ""
+ to = payload.header.to.map { |p| p.format }.join(", ")
+ cc = payload.header.cc.map { |p| p.format }.join(", ")
+ subj = payload.header.subject
+ subj = subj ? Message.normalize_subj(payload.header.subject.gsub(/\s+/, " ").gsub(/\s+$/, "")) : subj
+ if Rfc2047.is_encoded? subj
+ subj = Rfc2047.decode_to $encoding, subj
+ end
+ msgdate = payload.header.date
+ from_person = from ? Person.from_address (from) : nil
+ to_people = to ? Person.from_address_list (to) : nil
+ cc_people = cc ? Person.from_address_list (cc) : nil
+ [Chunk::EnclosedMessage.new(from_person, to_people, cc_people, msgdate, subj)] + message_to_chunks(payload, encrypted)
else
filename =
## first, paw through the headers looking for a filename
--
1.6.3.1
------------------------------
Message: 239
Date: Sat, 30 May 2009 17:48:13 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Getting gpg to work
Message-ID: <1243730754-sup-8672@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Micah Anderson's message of 2009-05-28:
> [Fri May 29 00:17:42 -0400 2009] crypto: detected gpg binary in /usr/bin/gpg
Any other obvious messages in the log about multipart/encrypted?
Assuming not, can you forward the email to me? I won't be able to
decrypt it, presumably, but maybe I can figure out what's going on. The
mime structure you've supplied looks fine, and Sup's gpg support is
good, so I'm curious why it's not working for you.
(Feel free to munge the headers and bodies if you desire, just don't
change the mime stuff.)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 240
Date: Sat, 30 May 2009 17:59:51 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] utf patch needs work, i think
Message-ID: <1243731497-sup-5619@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Walton's message of 2009-05-28:
> ...a followup on the list makes me wonder if this isn't actually a sup
> thing, but a weird encoding 'joke' by the poster. Even if the body
> display wasn't a sup bug, the name is still munged up.
I have the same message. I'll play around with it... I suspect there's
something like a tab or a weird character coming out of the decoding
(which appears to be some non-utf16 text claiming a utf16 big-endian
encoding) that is screwing with Ncurses.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 241
Date: Sat, 30 May 2009 18:03:40 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Use rake/packagegemtask
Message-ID: <1243731812-sup-3370@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ingmar Vanhassel's message of 2009-05-28:
> Ehm, attached right now...
Applied, thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 242
Date: Sun, 31 May 2009 20:54:08 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [RFC] Bounce messages
Message-ID:
<1243817649-7642-1-git-send-email-bwalton@artsci.utoronto.ca>
Hi All,
I spent a few hours this evening putting together the basics of (I
think) the last feature of mutt that I miss in sup: Message bouncing.
It works in it's current form, but I think it needs a little further
tweaking before it is merge ready.
Currently it's pretty dumb wrt which sendmail command it calls. It
simply calls sendmail with some sane (for my environment, anyway) args
and a list of recipients (skipping the -t flag which makes it read
recipients from headers in the input). I didn't want to implement a
second mail variable per account, although that would solve the
problem, and I didn't want to use the default sendmail command with
the -t stripped from the args (although that would also work).
The other thing that I don't like presently is the confirmation UI.
Without resorting to a whole bounce-mode, is there a better way to
handle this in the face of (potentially) multiple recipients that may
make the question stretch outside the viewable area?
I'm interested in what others think is the right solution to these
problems...and whether others besides myself miss this feature of
mutt.
Thanks
-Ben
------------------------------
Message: 243
Date: Sun, 31 May 2009 21:01:10 -0400
From: Ben Walton <bwalton@cquest.utoronto.ca>
To: sup-talk@rubyforge.org
Subject: [sup-talk] (no subject)
Message-ID: <200906010101.n5111ADJ007928@ntdws12.chass.utoronto.ca>
>From 702b2cc1e652c1f20f4280b11355cb337291df87 Mon Sep 17 00:00:00 2001
From: Ben Walton <bwalton@artsci.utoronto.ca>
Date: Sun, 31 May 2009 20:37:11 -0400
Subject: [PATCH] Add bounce message feature
By pressing ! in thread view mode, a message can be re-injected to the
mail system without any modification. The interesting/useful property
of this feature is that, because only the envelope sender changes, the
mail will show up at the new destination with the original From:
header. A use case for this is redirecting mail sent to an individual
into a ticket system such that the original sender gets the
auto-response.
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
---
lib/sup/modes/thread-view-mode.rb | 19 +++++++++++++++++++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb
index 42c6280..4737dde 100644
--- a/lib/sup/modes/thread-view-mode.rb
+++ b/lib/sup/modes/thread-view-mode.rb
@@ -41,6 +41,7 @@ EOS
# k.add :collapse_non_new_messages, "Collapse all but unread messages", 'N'
k.add :reply, "Reply to a message", 'r'
k.add :forward, "Forward a message or attachment", 'f'
+ k.add :bounce, "Bounce message to other recipient(s)", '!'
k.add :alias, "Edit alias/nickname for a person", 'i'
k.add :edit_as_new, "Edit message as new", 'D'
k.add :save_to_disk, "Save message/attachment to disk", 's'
@@ -172,6 +173,24 @@ EOS
end
end
+ def bounce
+ m = @message_lines[curpos] or return
+ to = BufferManager.ask_for_contacts(:people, "Bounce To: ") or return
+
+ if BufferManager.ask_yes_or_no "Really bounce to #{to.join(', ')}?"
+ cmd = "sendmail -oem -i #{to.map { |t| t.email}.join(' ')}"
+ begin
+ IO.popen(cmd, 'w') do |sm|
+ sm.puts m.raw_message
+ end
+ raise SendmailCommandFailed, "Couldn't execute #{cmd}" unless $? == 0
+ rescue SystemCallError, SendmailCommandFailed => e
+ Redwood::log "Problem sending mail: #{e.message}"
+ BufferManager.flash "Problem sending mail: #{e.message}"
+ end
+ end
+ end
+
include CanAliasContacts
def alias
p = @person_lines[curpos] or return
--
1.6.3
------------------------------
Message: 244
Date: Sun, 31 May 2009 21:04:45 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] (no subject)
Message-ID: <1243818192-sup-3945@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Ben Walton's message of Sun May 31 21:01:10 -0400 2009:
> >From 702b2cc1e652c1f20f4280b11355cb337291df87 Mon Sep 17 00:00:00 2001
> From: Ben Walton <bwalton@artsci.utoronto.ca>
> Date: Sun, 31 May 2009 20:37:11 -0400
> Subject: [PATCH] Add bounce message feature
...sorry for the odd way in which this arrived. The changed behaviour
in the recent git send-email threw me for a bit and I fired the cover
letter without the patch following.
Thanks.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090531/e287f32c/attachment-0001.bin>
------------------------------
Message: 245
Date: Sun, 31 May 2009 22:13:40 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] (no subject)
Message-ID: <1243822252-sup-9322@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Ben Walton's message of Sun May 31 21:01:10 -0400 2009:
> >From 702b2cc1e652c1f20f4280b11355cb337291df87 Mon Sep 17 00:00:00 2001
> From: Ben Walton <bwalton@artsci.utoronto.ca>
> Date: Sun, 31 May 2009 20:37:11 -0400
> Subject: [PATCH] Add bounce message feature
I thought I'd also clarify that in its final form, there should be a
refactor of EditMessageMode::send_message to pull out the wrapped
IO.popen into a method usable for sending a normal message and
bouncing a message.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090531/a19dd890/attachment-0001.bin>
------------------------------
Message: 246
Date: Mon, 01 Jun 2009 19:18:26 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: "Sup-talk@rubyforge.org" <sup-talk@rubyforge.org>
Subject: [sup-talk] Attempt at reply-from hook
Message-ID: <1243898254-sup-7513@javelin>
Content-Type: text/plain; charset=UTF-8
Hello,
I'm attempting to create a reply-from.rb hook that looks like this:
if message.has_label? 'twp':
Person.from_address "Edward Z. Yang <edwardzyang@thewritingpot.com>"
end
Unfortunately, it doesn't seem to work. I'm running sup v0.7.
Cheers,
Edward
------------------------------
Message: 247
Date: Mon, 1 Jun 2009 18:54:58 -0700
From: Dominic LoBue <dom.lobue@gmail.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] Need help with OfflineIMAP integration and Iconv
errors
Message-ID:
<93de24940906011854m70b8511cv139d0c7a830fc914@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hello,
Let me start off by saying that I am incredibly impressed with sup.
I'm really looking forward to being able to replace Outlook with Sup,
but I'm running into some problems that are preventing a complete
transition.
The first problem I'm having is when ferret is parsing through my
emails to build its indicies I get numerous "warning: error
(Iconv::IllegalSequence) decoding message body from X" errors, This
prevents a lot of my email from showing up at all. Iconv has this
problem from attempting to convert from Windows-1252, UTF-8, and
iso-8859-1. While I doubt its the cause of the problem, I am
downloading my email from the Exchange 2003 server at work via
OfflineIMAP.
The other major problem I'm running into is I can't figure out how to
get Sup and OfflineIMAP talking together correctly so that labels and
Seen flags are uploaded back to the Exchange server. I read that there
were no plans to support uploading meta-data back to IMAP servers, so
I was hoping that OfflineIMAP would sidestep the problem entirely. I
searched the archives but I didn't find any examples of working
configs. If anyone can point me to a working example I'd greatly
appreciate it.
I've tried both the latest official release and the latest revision
uploaded to github as of 20 minutes ago.
Any help would be greatly appreciated!
Dominic LoBue
------------------------------
Message: 248
Date: Tue, 02 Jun 2009 07:54:23 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] utf patch needs work, i think
Message-ID: <1243954348-sup-1644@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from William Morgan's message of 2009-05-30:
> I suspect there's something like a tab or a weird character coming out
> of the decoding (which appears to be some non-utf16 text claiming a
> utf16 big-endian encoding) that is screwing with Ncurses.
I've committed some changes that should remove invalid characters
for your encoding before display. I think this should help. Also
various display tweaks to account for multibyte characters. I still
see some inconsistencies but I think it's getting better.
That message renders "fine" for me now. (A bunch of nonsense Chinese
characters mixed with some boxes.) I'm using utf8 in a gnome-terminal.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 249
Date: Tue, 02 Jun 2009 09:29:13 -0700
From: Mark Alexander <marka@pobox.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] [PATCH] Handle nil charset on attachments.
Message-ID: <1243959935-sup-8233@r50p>
Content-Type: text/plain; charset=UTF-8
I updated to the latest 'next' branch of sup
this morning, and immediately ran into a crash
when viewing a message with an attachement, which
was probably sent by an Outlook user. The crash
was due to a nil charset; this patch fixes the crash.
---
lib/sup/message-chunks.rb | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/sup/message-chunks.rb b/lib/sup/message-chunks.rb
index 3f57346..41d924b 100644
--- a/lib/sup/message-chunks.rb
+++ b/lib/sup/message-chunks.rb
@@ -98,7 +98,7 @@ EOS
text =
case @content_type
when /^text\/plain\b/
- Iconv.easy_decode $encoding, encoded_content.charset, @raw_content
+ Iconv.easy_decode $encoding, encoded_content.charset || $encoding, @raw_content
else
HookManager.run "mime-decode", :content_type => content_type,
:filename => lambda { write_to_disk },
------------------------------
Message: 250
Date: Tue, 02 Jun 2009 09:46:00 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Handle nil charset on attachments.
Message-ID: <1243961075-sup-6760@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Mark Alexander's message of 2009-06-02:
> I updated to the latest 'next' branch of sup this morning, and
> immediately ran into a crash when viewing a message with an
> attachement, which was probably sent by an Outlook user. The crash
> was due to a nil charset; this patch fixes the crash.
Sloppy of me. Applied, thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 251
Date: Wed, 03 Jun 2009 00:09:16 +0200
From: Ingmar Vanhassel <ingmar.stdin@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Attempt at reply-from hook
Message-ID: <1243980495-sup-7229@cannonball>
Content-Type: text/plain; charset=UTF-8
Excerpts from Edward Z. Yang's message of Tue Jun 02 01:18:26 +0200 2009:
> Hello,
>
> I'm attempting to create a reply-from.rb hook that looks like this:
>
> if message.has_label? 'twp':
> Person.from_address "Edward Z. Yang <edwardzyang@thewritingpot.com>"
> end
if message.has_label? twp
Person.from_address "Edward Z. Yang <edwardzyang@thewritingpot.com>"
end
> Unfortunately, it doesn't seem to work. I'm running sup v0.7.
If the above doesn't work, post some relevant error output.
> Cheers,
> Edward
Regards,
Ingmar
------------------------------
Message: 252
Date: Tue, 02 Jun 2009 22:54:02 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Attempt at reply-from hook
Message-ID: <1243997614-sup-7485@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from Ingmar Vanhassel's message of Tue Jun 02 18:09:16 -0400 2009:
> If the above doesn't work, post some relevant error output.
It silently fails. Is there any Sup way of making debug messages in
hooks?
Cheers,
Edward
------------------------------
Message: 253
Date: Wed, 03 Jun 2009 07:44:24 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Attempt at reply-from hook
Message-ID: <1244029436-sup-6141@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Edward Z. Yang's message of Tue Jun 02 22:54:02 -0400 2009:
> It silently fails. Is there any Sup way of making debug messages in
> hooks?
Redwood::log "my message"
Then, look in the log buffer.
HTH.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090603/2d66ef11/attachment-0001.bin>
------------------------------
Message: 254
Date: Wed, 03 Jun 2009 13:39:40 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Sup is hanging
Message-ID: <1244050695-sup-5990@javelin>
Content-Type: text/plain; charset=UTF-8
Hey all,
Somehow, I messed something up really bad, and now, whenever Sup
attempts to poll for new messages, it hang completely, spinning the
CPU. I've let it run for an appreciable amount of time, and haven't
seen any change. I was wondering how I could fix this, or go about
debugging it. There also seems to be a single mail source at fault,
but I can't remove it without having Sup complain at me. Right now,
I'm running sup as -no.
Thanks,
Edward
------------------------------
Message: 255
Date: Wed, 03 Jun 2009 11:11:28 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup is hanging
Message-ID: <1244052318-sup-6595@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Edward Z. Yang's message of 2009-06-03:
> Somehow, I messed something up really bad, and now, whenever Sup
> attempts to poll for new messages, it hang completely, spinning the
> CPU. I've let it run for an appreciable amount of time, and haven't
> seen any change. I was wondering how I could fix this, or go about
> debugging it.
Is the curses interface hung? If not, can you see if there's activity in
the poll mode or the log mode buffers? (Hit ; if you're running from
git, or B if you're running 0.7.) It might be that you've somehow reset
the recorded offset for a very large source, so Sup is polling a lot of
stuff in the background.
If it's completely hung (which would be weird), try first disabling your
hooks (move them from ~/.sup/hooks to another directory) and see if that
helps. If not, please describe the behavior of running sup-sync.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 256
Date: Wed, 03 Jun 2009 14:21:35 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup is hanging
Message-ID: <1244053108-sup-4982@javelin>
Content-Type: text/plain; charset=UTF-8
The current working theory (based on strace'ing and lsof) is that Sup
is hanging on a select() call that doesn't have any timeout. The reason
why this is hanging is because between opening the connection and
closing it, Sup does some ridiculously slow message parsing code (that
really thrashes the CPU) and by the time it's done the server has
closed the connection (but we don't know about it). The fix would probably
be to always set a timeout, but I don't know what code needs to be fixed
for that.
Cheers,
Edward
------------------------------
Message: 257
Date: Wed, 3 Jun 2009 14:26:44 -0400 (EDT)
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup is hanging
Message-ID: <alpine.DEB.2.00.0906031425430.6338@javelin>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Wed, 3 Jun 2009, William Morgan wrote:
> Is the curses interface hung?>
Yep.
> If it's completely hung (which would be weird), try first disabling your
> hooks (move them from ~/.sup/hooks to another directory) and see if that
> helps. If not, please describe the behavior of running sup-sync.
I can try that. I've described the behavior of sup-sync in my other
email.
Cheers,
Edward
------------------------------
Message: 258
Date: Wed, 3 Jun 2009 14:45:59 -0400 (EDT)
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup is hanging
Message-ID: <alpine.DEB.2.00.0906031445190.6338@javelin>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Also, if it helps, here's the backtrace for when it's hanging on the
select:
/usr/lib/ruby/1.8/monitor.rb:102:in `stop': Interrupt
from /usr/lib/ruby/1.8/monitor.rb:102:in `wait'
from /usr/lib/ruby/1.8/net/imap.rb:972:in `get_tagged_response'
from /usr/lib/ruby/1.8/net/imap.rb:1032:in `send_command'
from /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
from /usr/lib/ruby/1.8/net/imap.rb:1017:in `send_command'
from /usr/lib/ruby/1.8/net/imap.rb:409:in `examine'
from /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
from /usr/lib/ruby/1.8/net/imap.rb:407:in `examine'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/imap.rb:145:in `unsynchronized_scan_mailbox'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/imap.rb:322:in `safely'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/imap.rb:144:in `unsynchronized_scan_mailbox'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/imap.rb:192:in `unsynchronized_start_offset'
from (eval):3:in `start_offset'
from (eval):3:in `synchronize'
from (eval):3:in `start_offset'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:544:in `send'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:544:in `__pass'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:531:in `method_missing'
from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:147
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:160:in `add_messages_from'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/imap.rb:187:in `each'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/imap.rb:175:in `upto'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/imap.rb:175:in `each'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:544:in `send'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:544:in `__pass'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:531:in `method_missing'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:141:in `add_messages_from'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:505:in `send'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:505:in `method_missing'
from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:140
from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:135:in `each'
from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:135
from /var/lib/gems/1.8/bin/sup-sync:19:in `load'
from /var/lib/gems/1.8/bin/sup-sync:19
Cheers,
Edward
------------------------------
Message: 259
Date: Wed, 03 Jun 2009 14:36:15 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup is hanging
Message-ID: <1244064889-sup-9506@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Edward Z. Yang's message of 2009-06-03:
> The current working theory (based on strace'ing and lsof) is that Sup
> is hanging on a select() call that doesn't have any timeout. The
> reason why this is hanging is because between opening the connection
> and closing it, Sup does some ridiculously slow message parsing code
> (that really thrashes the CPU) and by the time it's done the server
> has closed the connection (but we don't know about it).
That may all be true, but I'd be surprised if a) Sup didn't know that
the server had closed the connection, and b) that this would cause the
whole thing to hang.
When you don't use -n, does Sup still lock up?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 260
Date: Wed, 3 Jun 2009 17:48:56 -0400 (EDT)
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup is hanging
Message-ID: <alpine.DEB.2.00.0906031740370.22220@javelin>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Wed, 3 Jun 2009, William Morgan wrote:
> Reformatted excerpts from Edward Z. Yang's message of 2009-06-03:
>> The current working theory (based on strace'ing and lsof) is that Sup
>> is hanging on a select() call that doesn't have any timeout. The
>> reason why this is hanging is because between opening the connection
>> and closing it, Sup does some ridiculously slow message parsing code
>> (that really thrashes the CPU) and by the time it's done the server
>> has closed the connection (but we don't know about it).
>
> That may all be true, but I'd be surprised if a) Sup didn't know that
> the server had closed the connection, and
It doesn't have anything to do with Sup: the system select() call is
hanging; Sup (and Ruby for that matter) is out of the equation. This
might be IMAP server weirdness, but that shouldn't cause Sup to
freeze.
> b) that this would cause the
> whole thing to hang.
That's what I find surprising, since Sup is multithreaded. I suppose
all of the threads are blocking on the select.
Sup hangs without -n. (it always hangs after it's "done fetching IMAP
headers"). "done fetching IMAP headers" is the last message we get.
The behavior seems to be:
1. Log reports "done fetching IMAP headers"
2. Sup begins malloc'ing like crazy. sup-sync still is able to catch
signals and if you kill it you find that it's somewhere in
lib/sup/message.rb, message_to_chunks. sup doesn't respond to Ctrl+C
3. After some minutes, CPU usage dies off, but Sup doesn't unfreeze.
strace indicates that sup/sup-sync is waiting on a select(), and that
the descriptors are TCP connections to the IMAP server.
Cheers,
Edward
------------------------------
Message: 261
Date: Wed, 3 Jun 2009 18:00:06 -0400 (EDT)
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup is hangingy
Message-ID: <alpine.DEB.2.00.0906031758290.24343@javelin>
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Oh hey, I managed to kill Sup:
ezyang@javelin:~$ sup
[Wed Jun 03 17:42:43 -0400 2009] using character set encoding "UTF-8"
[Wed Jun 03 17:42:44 -0400 2009] dynamically loading setlocale() from
libc.so.6
[Wed Jun 03 17:42:44 -0400 2009] setting locale...
[Wed Jun 03 17:42:44 -0400 2009] locking /home/ezyang/.sup/lock...
[Wed Jun 03 17:42:44 -0400 2009] crypto: detected gpg binary in
/usr/bin/gpg
[Wed Jun 03 17:42:44 -0400 2009] loading index...
[Wed Jun 03 17:42:44 -0400 2009] loaded index of 20188 messages
[Wed Jun 03 17:42:44 -0400 2009] starting curses
[Wed Jun 03 17:54:47 -0400 2009] stopped cursing
[Wed Jun 03 17:54:47 -0400 2009] oh crap, an exception
[Wed Jun 03 17:54:47 -0400 2009] unlocking /home/ezyang/.sup/lock...
----------------------------------------------------------------
I'm very sorry. It seems that an error occurred in Sup. Please
accept my sincere apologies. If you don't mind, please send the
contents of ~/.sup/exception-log.txt and a brief report of the
circumstances to sup-talk at rubyforge dot orgs so that I might
address this problem. Thank you!
Sincerely,
William
----------------------------------------------------------------
--- Interrupt from thread: main
/usr/lib/ruby/gems/1.8/gems/ncurses-0.9.1/lib/ncurses.rb:71:in
`method_missing'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/buffer.rb:109:in `write'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/scroll-mode.rb:245:in
`draw_line_from_string'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/scroll-mode.rb:182:in
`draw_line'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/scroll-mode.rb:48:in
`draw'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/scroll-mode.rb:48:in
`each'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/scroll-mode.rb:48:in
`draw'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/buffer.rb:99:in `draw'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/buffer.rb:303:in
`draw_screen'
/usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup:308
/var/lib/gems/1.8/bin/sup:19:in `load'
/var/lib/gems/1.8/bin/sup:19
This seems... unrelated.
Cheers,
Edward
------------------------------
Message: 262
Date: Wed, 03 Jun 2009 21:26:01 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: "Edward Z. Yang" <ezyang@mit.edu>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup is hangingy
Message-ID: <1244078482-sup-4986@javelin>
Content-Type: text/plain; charset=UTF-8
Ok, after a bit of fiddling, I've managed to figure out that this is
two problems, not one.
The first is related to a naughty IMAP server which simply stops responding
after a certain number of seconds. Unfortunately, this is my workplace's
IMAP server, so I can't give you a test environment. Furthermore, the code
that would be appropriate to change is in Net::Imap, and thus is not
easily accessible by Sup. I've worked around this by making it an unusual
source.
The second is a large amount of CPU thrashing as Sup parses messages. This
is something we can fix, and I hope to do some more poking to help make
Sup run faster in this respect. The basic behavior is Sup repeatedly
allocates some amount of memory, reallocates it twice (quadrupling it
in size to about 4MB), deallocates, and then does it again. I'm running
ruby-prof in hopes of tickling this again. Unlike the hung IMAP server,
this eventually finishes, but it is extremely obnoxious when it happens
and blocks everything else. It commonly occurs when I open an email message.
Cheers,
Edward
------------------------------
Message: 263
Date: Wed, 3 Jun 2009 21:53:12 -0400 (EDT)
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: William Morgan <wmorgan-sup@masanjin.net>, sup-talk
<sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup is hangingyy
Message-ID: <alpine.DEB.2.00.0906032152200.6894@javelin>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Wed, 3 Jun 2009, Edward Z. Yang wrote:
> The second is a large amount of CPU thrashing as Sup parses messages. This
> is something we can fix, and I hope to do some more poking to help make
> Sup run faster in this respect. The basic behavior is Sup repeatedly
> allocates some amount of memory, reallocates it twice (quadrupling it
> in size to about 4MB), deallocates, and then does it again. I'm running
> ruby-prof in hopes of tickling this again. Unlike the hung IMAP server,
> this eventually finishes, but it is extremely obnoxious when it happens
> and blocks everything else. It commonly occurs when I open an email message.
Here we go:
http://web.mit.edu/~ezyang/Public/sup-performance.png
Look at String::=~. Definitely not acceptable.
Cheers,
Edward
------------------------------
Message: 264
Date: Wed, 3 Jun 2009 22:04:32 -0400
From: Ross Macduff <ross.macduff@gmail.com>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] (no subject)
Message-ID:
<b689a800906031904s7a0606f3m229e1c726a2a83b1@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
I merged this patch into the mainline from gitorius. Works as
expected. Definitely a nice addition.
Ross
On Sun, May 31, 2009 at 9:01 PM, Ben Walton <bwalton@cquest.utoronto.ca> wrote:
> >From 702b2cc1e652c1f20f4280b11355cb337291df87 Mon Sep 17 00:00:00 2001
> From: Ben Walton <bwalton@artsci.utoronto.ca>
> Date: Sun, 31 May 2009 20:37:11 -0400
> Subject: [PATCH] Add bounce message feature
>
> By pressing ! in thread view mode, a message can be re-injected to the
> mail system without any modification. ?The interesting/useful property
> of this feature is that, because only the envelope sender changes, the
> mail will show up at the new destination with the original From:
> header. ?A use case for this is redirecting mail sent to an individual
> into a ticket system such that the original sender gets the
> auto-response.
>
> Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
> ---
> ?lib/sup/modes/thread-view-mode.rb | ? 19 +++++++++++++++++++
> ?1 files changed, 19 insertions(+), 0 deletions(-)
>
> diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb
> index 42c6280..4737dde 100644
> --- a/lib/sup/modes/thread-view-mode.rb
> +++ b/lib/sup/modes/thread-view-mode.rb
> @@ -41,6 +41,7 @@ EOS
> ?# ? ?k.add :collapse_non_new_messages, "Collapse all but unread messages", 'N'
> ? ? k.add :reply, "Reply to a message", 'r'
> ? ? k.add :forward, "Forward a message or attachment", 'f'
> + ? ?k.add :bounce, "Bounce message to other recipient(s)", '!'
> ? ? k.add :alias, "Edit alias/nickname for a person", 'i'
> ? ? k.add :edit_as_new, "Edit message as new", 'D'
> ? ? k.add :save_to_disk, "Save message/attachment to disk", 's'
> @@ -172,6 +173,24 @@ EOS
> ? ? end
> ? end
>
> + ?def bounce
> + ? ?m = @message_lines[curpos] or return
> + ? ?to = BufferManager.ask_for_contacts(:people, "Bounce To: ") or return
> +
> + ? ?if BufferManager.ask_yes_or_no "Really bounce to #{to.join(', ')}?"
> + ? ? ?cmd = "sendmail -oem -i #{to.map { |t| t.email}.join(' ')}"
> + ? ? ?begin
> + ? ? ? ?IO.popen(cmd, 'w') do |sm|
> + ? ? ? ? ?sm.puts m.raw_message
> + ? ? ? ?end
> + ? ? ? ?raise SendmailCommandFailed, "Couldn't execute #{cmd}" unless $? == 0
> + ? ? ?rescue SystemCallError, SendmailCommandFailed => e
> + ? ? ? ?Redwood::log "Problem sending mail: #{e.message}"
> + ? ? ? ?BufferManager.flash "Problem sending mail: #{e.message}"
> + ? ? ?end
> + ? ?end
> + ?end
> +
> ? include CanAliasContacts
> ? def alias
> ? ? p = @person_lines[curpos] or return
> --
> 1.6.3
>
> _______________________________________________
> sup-talk mailing list
> sup-talk@rubyforge.org
> http://rubyforge.org/mailman/listinfo/sup-talk
>
------------------------------
Message: 265
Date: Wed, 03 Jun 2009 19:11:31 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk mailing list <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup is hanging
Message-ID: <1244081477-sup-4133@entry>
Content-Type: text/plain; charset=UTF-8
[resent to list]
Reformatted excerpts from Edward Z. Yang's message of 2009-06-03:
> That's what I find surprising, since Sup is multithreaded. I suppose
> all of the threads are blocking on the select.
It's possible... Ruby does use green threads and a GIL, so there's
always the possibility that something in C land will block all Ruby
threads, but my impression was that that was an issue mainly with
third-party libraries. I believe that Net::IMAP is pure Ruby, thus using
the core Ruby IO mechanisms, and I thought those were pretty good about
being preemptible. Curious!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 266
Date: Wed, 03 Jun 2009 19:12:25 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup is hangingy
Message-ID: <1244081540-sup-7695@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Edward Z. Yang's message of 2009-06-03:
> Oh hey, I managed to kill Sup:
>
> ezyang@javelin:~$ sup
> [Wed Jun 03 17:42:43 -0400 2009] using character set encoding "UTF-8"
> [Wed Jun 03 17:42:44 -0400 2009] dynamically loading setlocale() from
> libc.so.6
> [Wed Jun 03 17:42:44 -0400 2009] setting locale...
> [Wed Jun 03 17:42:44 -0400 2009] locking /home/ezyang/.sup/lock...
> [Wed Jun 03 17:42:44 -0400 2009] crypto: detected gpg binary in
> /usr/bin/gpg
> [Wed Jun 03 17:42:44 -0400 2009] loading index...
> [Wed Jun 03 17:42:44 -0400 2009] loaded index of 20188 messages
> [Wed Jun 03 17:42:44 -0400 2009] starting curses
> [Wed Jun 03 17:54:47 -0400 2009] stopped cursing
> [Wed Jun 03 17:54:47 -0400 2009] oh crap, an exception
> [Wed Jun 03 17:54:47 -0400 2009] unlocking /home/ezyang/.sup/lock...
> ----------------------------------------------------------------
> I'm very sorry. It seems that an error occurred in Sup. Please
> accept my sincere apologies. If you don't mind, please send the
> contents of ~/.sup/exception-log.txt and a brief report of the
> circumstances to sup-talk at rubyforge dot orgs so that I might
> address this problem. Thank you!
>
> Sincerely,
> William
> ----------------------------------------------------------------
> --- Interrupt from thread: main
>
> /usr/lib/ruby/gems/1.8/gems/ncurses-0.9.1/lib/ncurses.rb:71:in
> `method_missing'
> /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/buffer.rb:109:in `write'
> /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/scroll-mode.rb:245:in
> `draw_line_from_string'
> /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/scroll-mode.rb:182:in
> `draw_line'
> /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/scroll-mode.rb:48:in
> `draw'
> /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/scroll-mode.rb:48:in
> `each'
> /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/scroll-mode.rb:48:in
> `draw'
> /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/buffer.rb:99:in `draw'
> /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/buffer.rb:303:in
> `draw_screen'
> /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup:308
> /var/lib/gems/1.8/bin/sup:19:in `load'
> /var/lib/gems/1.8/bin/sup:19
>
> This seems... unrelated.
>
> Cheers,
> Edward
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 267
Date: Wed, 03 Jun 2009 19:13:58 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup is hangingy
Message-ID: <1244081553-sup-5115@entry>
Content-Type: text/plain; charset=UTF-8
[sorry about that last one. really not doing too well with the ol' email
today.]
Reformatted excerpts from Edward Z. Yang's message of 2009-06-03:
> --- Interrupt from thread: main
>
> /usr/lib/ruby/gems/1.8/gems/ncurses-0.9.1/lib/ncurses.rb:71:in `method_missing'
[snip]
>
> This seems... unrelated.
This looks like a ctrl-c that got caught by an ncurses thread. I agree,
seems unrelated.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 268
Date: Wed, 03 Jun 2009 20:05:07 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Need help with OfflineIMAP integration and
Iconv errors
Message-ID: <1244084554-sup-6080@entry>
Content-Type: text/plain; charset=UTF-8
Hi Dominic,
Reformatted excerpts from Dominic LoBue's message of 2009-06-01:
> Let me start off by saying that I am incredibly impressed with sup.
Great! That's nice to hear.
> The first problem I'm having is when ferret is parsing through my
> emails to build its indicies I get numerous "warning: error
> (Iconv::IllegalSequence) decoding message body from X" errors, This
> prevents a lot of my email from showing up at all.
This is just a warning when iconv gets finnicky. It shouldn't prevent
email from being indexed or from appearing.
> I read that there were no plans to support uploading meta-data back to
> IMAP servers, so I was hoping that OfflineIMAP would sidestep the
> problem entirely. I searched the archives but I didn't find any
> examples of working configs. If anyone can point me to a working
> example I'd greatly appreciate it.
Maildir doesn't help you either. Sup doesn't export its message state
back to the source for any source type, except for certain limited cases
with sup-sync-back.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 269
Date: Thu, 4 Jun 2009 12:03:10 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk@rubyforge.org
Cc: Ben Walton <bwalton@artsci.utoronto.ca>
Subject: [sup-talk] [PATCH] Add V to view a raw message (headers and
body).
Message-ID:
<1244131390-25769-1-git-send-email-bwalton@artsci.utoronto.ca>
This is an augment of the already existing view header (H) command,
but allows viewing of all mime parts in their raw form, etc.
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
---
lib/sup/modes/thread-view-mode.rb | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb
index 42c6280..8de7ab0 100644
--- a/lib/sup/modes/thread-view-mode.rb
+++ b/lib/sup/modes/thread-view-mode.rb
@@ -27,6 +27,7 @@ EOS
register_keymap do |k|
k.add :toggle_detailed_header, "Toggle detailed header", 'h'
k.add :show_header, "Show full message header", 'H'
+ k.add :show_message, "Show full message (raw form)", 'V'
k.add :activate_chunk, "Expand/collapse or activate item", :enter
k.add :expand_all_messages, "Expand/collapse all messages", 'E'
k.add :edit_draft, "Edit draft", 'e'
@@ -134,6 +135,13 @@ EOS
end
end
+ def show_message
+ m = @message_lines[curpos] or return
+ BufferManager.spawn_unless_exists("Raw message for #{m.id}") do
+ TextMode.new m.raw_message
+ end
+ end
+
def toggle_detailed_header
m = @message_lines[curpos] or return
@layout[m].state = (@layout[m].state == :detailed ? :open : :detailed)
--
1.6.3
------------------------------
Message: 270
Date: Thu, 04 Jun 2009 09:09:40 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup is hanging
Message-ID: <1244130722-sup-4496@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Edward Z. Yang's message of 2009-06-03:
> http://web.mit.edu/~ezyang/Public/sup-performance.png
>
> Look at String::=~. Definitely not acceptable.
Doing some profiling on my end, it looks like the majority of IMAP
syncing time is spent in these five methods:
Redwood::Index#load_entry_for_id (22%)
Redwood::IMAP#load_message (25%)
Redwood::Message#message_to_chunks (16.5%)
Redwood::IMAP#load_header (14%)
Redwood::Index#sync_message (13%)
Four of those are essentially wrappers around IMAP or Ferret methods.
The Sup-specific one is Message#message_to_chunks. But message_to_chunks
and its callee text_to_chunks doesn't seem to have a major culprits.
String#=~ only takes 2.3% of the CPU time, and a chunk of that is coming
from RubyMail.
Just for good measure, I "manually" measured the individual regexen in
text_to_chunks. After parsing 100 messages from an IMAP server, which
took 1m27s for me, I got:
time (s) calls
bqp = 0.00854 / 1789 = 209411.2 calls/second
n1 = 0.00218 / 313 = 143709.8 calls/second
qsp = 0.03212 / 1923 = 59873.0 calls/second
n2 = 0.00202 / 312 = 154226.4 calls/second
empty = 0.00061 / 90 = 146341.5 calls/second
sp = 0.02570 / 1927 = 74995.1 calls/second
qp = 0.03392 / 4459 = 131452.5 calls/second
The names are abbreviations for the various regexen in that method. You
can see that the cumulative time spent on any one regex is at most .034
seconds (qp, which is QUERY_PATTERN), and that the slowest one is qsp,
QUERY_START_PATTERN.
Incidentally, I can parse IMAP mailboxes at a little over 1 message/s,
and mbox files at ~50 messages/second, which also suggests that the IMAP
libraries are the biggest time sink here.
This is all with ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux]), Sup
git next.
Now that's all CPU stuff. There might be memory blowup issues. If
nothing else, Sup leaks memory over time, but fixing that involves the
getting into the hellish world of Ruby<->C land or the even more hellish
internals of MRI, so I've been loathe to start down that path.
You might be able to speed up sup-sync runs on IMAP by threading the
network access and the parsing. But the IMAP connection seems pretty
CPU-heavy so who knows.
None of this answers the original question of why all Ruby threads block
when Sup waits for a response from IMAP. Since I'm pretty sure the IMAP
libraries are all Ruby (why they're so slow!), and that core Ruby IO
should be nonblocking, this might be an interpreter bug. Are you able to
pinpoint what part of MRI is blocking?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 271
Date: Thu, 04 Jun 2009 23:28:58 +0200
From: Christopher Bertels <mailinglist@flasht.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Toggle expand/collapse of a message in threadview
Message-ID: <1244150874-sup-6554@thinkpad-ubuntu>
Content-Type: text/plain; charset=UTF-8
Hi!
I've been wondering:
Is there a way to expand/collsape the current message I'm reading when in the
middle of it?
I know I can press ENTER to toggle it when I'm hovering the message's header,
but is it possible when I'm in the middle of a message?
When reading long threads with long messages, this would really be handy, as
for now I always have to go up or toggle all messages and
work my way through a thread like that.
It would be nice if I could simply press a key to toggle the current message
I'm looking at (where the current highlighted line belongs to).
Maybe I'm blind and simply haven't found this feature? Can't find it in the
help menu.
Thanks,
Christopher.
--
================================
Christopher Bertels
http://www.adztec-independent.de
------------------------------
Message: 272
Date: Thu, 04 Jun 2009 20:38:23 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Toggle expand/collapse of a message in
threadview
Message-ID: <1244172932-sup-1101@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Christopher Bertels's message of 2009-06-04:
> Is there a way to expand/collsape the current message I'm reading when
> in the middle of it?
Good idea. I've changed this in git. Pressing enter on a text region now
collapses the message. Behavior of enter on quotes, signatures,
attachments, etc. is unchanged.
Also, collapsing a message will make the cursor jump to the next open
message. So you should be able to scan rapidly through a thread one
message at a time by hitting enter to collapse it or 'n' to leave open.
(And then 'p' and 'n' to review all open messages.)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 273
Date: Fri, 05 Jun 2009 01:08:10 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup is hanging
Message-ID: <1244177820-sup-6051@javelin>
Content-Type: text/plain; charset=UTF-8
Hi William,
I tickled the bug and took a more careful look at the message that had
triggered it, and noticed that it was an auto-generated commit message
that was really long. So one possible stop-gap would be just to detect
if a message is long and disable quoting if that was the case (a long
message would be, say, one over 100KB). There is also a possibility
that the commit message had some pathological backtracking built into
it.
Excerpts from William Morgan's message of Thu Jun 04 12:09:40 -0400 2009:
> Redwood::Index#load_entry_for_id (22%)
> Redwood::IMAP#load_message (25%)
> Redwood::Message#message_to_chunks (16.5%)
> Redwood::IMAP#load_header (14%)
> Redwood::Index#sync_message (13%)
Ok, so this isn't the same spread as when I managed to make Sup hang,
so this isn't quite the same.
> Now that's all CPU stuff. There might be memory blowup issues. If
> nothing else, Sup leaks memory over time, but fixing that involves the
> getting into the hellish world of Ruby<->C land or the even more hellish
> internals of MRI, so I've been loathe to start down that path.
Sup memory leakage has not been a problem; Sup will hang on a poll
asynchronously (as in, UI is still responsive, but I get no more
new messages) often enough that I have to quit and start sup up again.
> None of this answers the original question of why all Ruby threads block
> when Sup waits for a response from IMAP. Since I'm pretty sure the IMAP
> libraries are all Ruby (why they're so slow!), and that core Ruby IO
> should be nonblocking, this might be an interpreter bug. Are you able to
> pinpoint what part of MRI is blocking?
Not yet. I don't know Ruby threads well enough to know how to get more
fine-grained information on thread mutex/blocking interaction.
To summarize:
1. If I thrash message_to_chunks() with a very long message, I cause
sup to hang.
* If this case is only caused by long messages, implement a hueristic
to prevent quoting from happening to long messages.
* If there is something specific about the message that causes massive
back-tracking, fix the regex.
In either case, message_to_chunks() should not block the rest of the
interface (although if we fix either or the two sub-points, this
may not be a noticeable problem).
2. If an IMAP connection hangs, it occasionally causes all of Sup to
block (this is rare, and comes from a pathological IMAP server. I
think the ops administering the naughty IMAP server fixed it, so
I am no longer seeing this hang).
3. Under less pathological cases, an IMAP connection can hang, and
asynchronously blocks any further polling from taking place, resulting
in no new messages. This happens commonly for me.
Cheers,
Edward
------------------------------
Message: 274
Date: Fri, 05 Jun 2009 01:24:36 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Attempt at reply-from hook
Message-ID: <1244179379-sup-6675@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from Ben Walton's message of Wed Jun 03 07:44:24 -0400 2009:
> Redwood::log "my message"
>
> Then, look in the log buffer.
I tried probing several ways.
- The reply-from.rb hook is being called.
- The message variable does exist.
- The message.has_label? "mylabel" returns false, as the body of the if
statement never gets logged. (My contention is that the message very
clearly has that label, so wtf).
- It is difficult to get a str representation of the message
I am still stymied.
Cheers,
Edward
------------------------------
Message: 275
Date: Fri, 05 Jun 2009 09:15:02 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: Ben Walton <bwalton@artsci.utoronto.ca>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Add V to view a raw message (headers
and body).
Message-ID: <1244186006-sup-1399@ausone.inria.fr>
Content-Type: text/plain; charset=UTF-8
Excerpts from Ben Walton's message of Thu Jun 04 18:03:10 +0200 2009:
> This is an augment of the already existing view header (H) command,
> but allows viewing of all mime parts in their raw form, etc.
I usually use '|' followed by "cat" or "less" for this purpose, but maybe a
dedicated key-binding is better.
--
Nicolas Pouillard
http://nicolaspouillard.fr
------------------------------
Message: 276
Date: Fri, 05 Jun 2009 13:02:13 +0200
From: Christopher Bertels <mailinglist@flasht.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Toggle expand/collapse of a message in
threadview
Message-ID: <1244199699-sup-8610@thinkpad-ubuntu>
Content-Type: text/plain; charset=UTF-8
Oh cool!
Thanks, works great and exactly what I wanted! :)
Excerpts from William Morgan's message of Fr Jun 05 05:38:23 +0200 2009:
> Reformatted excerpts from Christopher Bertels's message of 2009-06-04:
> > Is there a way to expand/collsape the current message I'm reading when
> > in the middle of it?
>
> Good idea. I've changed this in git. Pressing enter on a text region now
> collapses the message. Behavior of enter on quotes, signatures,
> attachments, etc. is unchanged.
>
> Also, collapsing a message will make the cursor jump to the next open
> message. So you should be able to scan rapidly through a thread one
> message at a time by hitting enter to collapse it or 'n' to leave open.
> (And then 'p' and 'n' to review all open messages.)
--
================================
Christopher Bertels
http://www.adztec-independent.de
------------------------------
Message: 277
Date: Fri, 05 Jun 2009 13:09:34 +0200
From: Christopher Bertels <mailinglist@flasht.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Toggle expand/collapse of a message in
threadview
Message-ID: <1244199822-sup-1224@thinkpad-ubuntu>
Content-Type: text/plain; charset=UTF-8
Actually, now that I've been using it a little more, I think it would be nicer
that when pressing enter on a collapsed message, the cursor would stay at the
header of that expanded message instead of moving to the next message header.
Right now, it's always moving to the next message, even when expanding a collapsed
message to read it.
Excerpts from William Morgan's message of Fr Jun 05 05:38:23 +0200 2009:
> Reformatted excerpts from Christopher Bertels's message of 2009-06-04:
> > Is there a way to expand/collsape the current message I'm reading when
> > in the middle of it?
>
> Good idea. I've changed this in git. Pressing enter on a text region now
> collapses the message. Behavior of enter on quotes, signatures,
> attachments, etc. is unchanged.
>
> Also, collapsing a message will make the cursor jump to the next open
> message. So you should be able to scan rapidly through a thread one
> message at a time by hitting enter to collapse it or 'n' to leave open.
> (And then 'p' and 'n' to review all open messages.)
--
================================
Christopher Bertels
http://www.adztec-independent.de
------------------------------
Message: 278
Date: Fri, 05 Jun 2009 13:24:07 +0200
From: Christopher Bertels <mailinglist@flasht.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Toggle expand/collapse of a message in
threadview
Message-ID: <1244200965-sup-607@thinkpad-ubuntu>
Content-Type: text/plain; charset=UTF-8
Ok, wasn't so hard.
Here's the patch:
diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb
index 2b6c58b..1e014c3 100644
--- a/lib/sup/modes/thread-view-mode.rb
+++ b/lib/sup/modes/thread-view-mode.rb
@@ -234,10 +234,12 @@ EOS
## view.
def activate_chunk
chunk = @chunk_lines[curpos] or return
+ move_to_next = false
if chunk.is_a? Chunk::Text
## if the cursor is over a text region, expand/collapse the
## entire message
chunk = @message_lines[curpos]
+ move_to_next = true
end
layout = if chunk.is_a?(Message)
@layout[chunk]
@@ -253,7 +255,7 @@ EOS
end
if chunk.is_a?(Message)
jump_to_message chunk
- jump_to_next_open
+ jump_to_next_open if move_to_next
end
end
Excerpts from Christopher Bertels's message of Fr Jun 05 13:09:34 +0200 2009:
> Actually, now that I've been using it a little more, I think it would be nicer
> that when pressing enter on a collapsed message, the cursor would stay at the
> header of that expanded message instead of moving to the next message header.
> Right now, it's always moving to the next message, even when expanding a
> collapsed
> message to read it.
>
> Excerpts from William Morgan's message of Fr Jun 05 05:38:23 +0200 2009:
> > Reformatted excerpts from Christopher Bertels's message of 2009-06-04:
> > > Is there a way to expand/collsape the current message I'm reading when
> > > in the middle of it?
> >
> > Good idea. I've changed this in git. Pressing enter on a text region now
> > collapses the message. Behavior of enter on quotes, signatures,
> > attachments, etc. is unchanged.
> >
> > Also, collapsing a message will make the cursor jump to the next open
> > message. So you should be able to scan rapidly through a thread one
> > message at a time by hitting enter to collapse it or 'n' to leave open.
> > (And then 'p' and 'n' to review all open messages.)
--
================================
Christopher Bertels
http://www.adztec-independent.de
------------------------------
Message: 279
Date: Fri, 05 Jun 2009 07:30:51 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: Nicolas Pouillard <nicolas.pouillard@gmail.com>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Add V to view a raw message (headers
and body).
Message-ID: <1244201417-sup-2549@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Nicolas Pouillard's message of Fri Jun 05 03:15:02 -0400 2009:
> Excerpts from Ben Walton's message of Thu Jun 04 18:03:10 +0200 2009:
> > This is an augment of the already existing view header (H) command,
> > but allows viewing of all mime parts in their raw form, etc.
> I usually use '|' followed by "cat" or "less" for this purpose, but maybe a
> dedicated key-binding is better.
Yah, I was aiming for less typing...it's something I do often enough.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090605/0f741833/attachment-0001.bin>
------------------------------
Message: 280
Date: Fri, 5 Jun 2009 05:35:15 -0700
From: Dominic LoBue <dom.lobue@gmail.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] sup crash while attempting to load next email
after deleting previous
Message-ID:
<93de24940906050535p7178dedctc9f9f8c166acdf2e@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hello,
Sup just crashed on me. The last thing I did was do ,d to delete the
email I was viewing and move on to the next. I had deleted several
other emails previously in the exact same way with no problems.
The only thing that may matter is that I had over 1000 threads loaded
in the index view (I get a _lot_ of email at work :( ).
I'm using a git release made from the below commit:
commit a8869f951cf8ec3a4a50492290c9ca757c968f49
Author: William Morgan <wmorgan-sup@masanjin.net>
Date: Sun May 31 08:58:16 2009 -0700
yet another utf8 bugfix: fix string subsetting
... with a HORRIBLE SLOW HACK!
And here is the exception-log:
--- NoMethodError from thread: load messages for thread-view-mode
undefined method `date' for nil:NilClass
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:783:in
`text_for_thread_at'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:752:in
`regen_text'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:346:in `map_with_index'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:641:in `each_with_index'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:346:in `each'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:346:in `each_with_index'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:346:in `map_with_index'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:752:in
`regen_text'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:228:in
`update'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:202:in
`handle_deleted_update'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/update.rb:27:in `send'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/update.rb:27:in `relay'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/update.rb:27:in `each'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/update.rb:27:in `relay'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:505:in `send'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:505:in `method_missing'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-view-mode.rb:431:in
`delete_and_then'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-view-mode.rb:451:in
`dispatch'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:119:in
`call'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:119:in
`select'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:71:in `reporting_thread'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:69:in `initialize'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:69:in `new'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:69:in `reporting_thread'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:99:in
`select'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:149:in
`launch_another_thread'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:131:in
`launch_next_thread_after'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-view-mode.rb:457:in
`dispatch'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-view-mode.rb:429:in
`delete_and_then'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-view-mode.rb:404:in
`delete_and_next'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/mode.rb:50:in `send'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/mode.rb:50:in `handle_input'
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/buffer.rb:249:in `handle_input'
/usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup:238
/usr/bin/sup:19:in `load'
/usr/bin/sup:19
Dominic
------------------------------
Message: 281
Date: Fri, 05 Jun 2009 06:23:50 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup is hanging
Message-ID: <1244206531-sup-5503@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Edward Z. Yang's message of 2009-06-04:
> I tickled the bug and took a more careful look at the message that had
> triggered it
This is good stuff. I think we're getting somewhere. I was hoping to
have this this fixed by 0.8 but I think it's going to have to wait till
0.9.
> and noticed that it was an auto-generated commit message that was
> really long. So one possible stop-gap would be just to detect if a
> message is long and disable quoting if that was the case (a long
> message would be, say, one over 100KB).
Yep, I bet that's the problem.
Not parsing long messages would be fine as far as I'm concerned. Heck
even 25k might be a reasonable limit (per MIME part).
> There is also a possibility that the commit message had some
> pathological backtracking built into it.
It's possible... but I'm willing to bet that it's the sheer size. If
we're still seeing this performance on smaller messages (e.g. when you
start sending me emails carefully constructed to induce worst-case
performance in Sup's regexen) we can wrap a timeout around the whole
parse as well.
> Excerpts from William Morgan's message of Thu Jun 04 12:09:40 -0400 2009:
> > Redwood::Index#load_entry_for_id (22%)
> > Redwood::IMAP#load_message (25%)
> > Redwood::Message#message_to_chunks (16.5%)
> > Redwood::IMAP#load_header (14%)
> > Redwood::Index#sync_message (13%)
>
> Ok, so this isn't the same spread as when I managed to make Sup hang,
> so this isn't quite the same.
That makes sense.
> 1. If I thrash message_to_chunks() with a very long message, I cause
> sup to hang.
This is still weird. It only makes sense if Ruby regexen block the whole
interpreter when evaluating. I guess that might be the case if they're
they haven't taken the (what I imagine must be trivial) step of allowing
preemption during the DFA execution (or however the hell they're
implemented). I guess an experiment would show this.
> 2. If an IMAP connection hangs, it occasionally causes all of Sup to
> block (this is rare, and comes from a pathological IMAP server. I
> think the ops administering the naughty IMAP server fixed it, so
> I am no longer seeing this hang).
This is also still weird, and I wonder if it's not just problems 1 and 3
combining. If it comes back we will have to do some more investigation.
> 3. Under less pathological cases, an IMAP connection can hang, and
> asynchronously blocks any further polling from taking place, resulting
> in no new messages. This happens commonly for me.
This one we can fix. (Though it's something the IMAP libraries should've
done for us.) If we put a timeout block around that #examine call, we
should be able to reset the connection if it hangs.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 282
Date: Fri, 05 Jun 2009 06:37:02 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Attempt at reply-from hook
Message-ID: <1244208597-sup-4979@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Edward Z. Yang's message of 2009-06-04:
> The message.has_label? "mylabel" returns false, as the body of the if
> statement never gets logged. (My contention is that the message very
> clearly has that label, so wtf).
Try has_label? :mylabel. Sup represents labels as symbols instead of as
strings.
Sorry about that. The hook system is in need of much documentation.
A good environment for playing around with this stuff is to run the console:
w@drspaceman:~/devel/sup$ sh devel/console.sh
[...]
>> Index.run_query "label:potato"
=> [1000]
>> m = Index.build_message 1000
=> #<Redwood::Message:0x7f187b394ac8 [...]>
>> m.labels
=> [:inbox, :unread, :potato]
>> m.has_label? :potato
=> true
>> m.has_label? "potato"
=> false
HTH.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 283
Date: Fri, 05 Jun 2009 08:31:07 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Add V to view a raw message (headers
and body).
Message-ID: <1244215854-sup-9273@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Walton's message of 2009-06-05:
> Yah, I was aiming for less typing...it's something I do often enough.
Good enough for me. Applied directly to master. Thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 284
Date: Fri, 05 Jun 2009 08:31:31 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Toggle expand/collapse of a message in
threadview
Message-ID: <1244215876-sup-1528@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Christopher Bertels's message of 2009-06-05:
> Ok, wasn't so hard. Here's the patch:
I've applied a similar change to master. Thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 285
Date: Fri, 05 Jun 2009 08:36:55 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Prettier printing of enclosed messages
Message-ID: <1244216191-sup-6520@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Israel Herraiz's message of 2009-05-29:
> this patch prints enclosed messages with only some selected headers
> instead of the full headers, just as "normal" messages.
Branch enclosed-message-display-tweaks, merged into next. Thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 286
Date: Fri, 05 Jun 2009 09:02:17 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [RFC] Bounce messages
Message-ID: <1244217075-sup-4385@entry>
Content-Type: text/plain; charset=UTF-8
Hi Ben,
I'm definitely interested in having this feature. But it does open up
some complications because we have to be able to call the MTA in two
different modes.
But this might not be such a big deal because most MTAs have basic
sendmail compatibility. Judging from the entries on the Sup Wiki for
msmtp, ssmtp, and putmail, we should be fine just calling the account's
sendmail command without -t and with the recipient email addresses.
Reformatted excerpts from Ben Walton's message of 2009-05-31:
> The other thing that I don't like presently is the confirmation UI.
> Without resorting to a whole bounce-mode, is there a better way to
> handle this in the face of (potentially) multiple recipients that may
> make the question stretch outside the viewable area?
You could just make it say "Bounce to #{to.size} recipients?". :)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 287
Date: Fri, 05 Jun 2009 12:20:32 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [RFC] Bounce messages
Message-ID: <1244218650-sup-2427@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Fri Jun 05 12:02:17 -0400 2009:
> I'm definitely interested in having this feature. But it does open
> up
Great.
> some complications because we have to be able to call the MTA in two
> different modes.
Nothing is free! :)
> But this might not be such a big deal because most MTAs have basic
> sendmail compatibility. Judging from the entries on the Sup Wiki for
> msmtp, ssmtp, and putmail, we should be fine just calling the account's
> sendmail command without -t and with the recipient email addresses.
Ok, I'll rework the patch to call the default account's sendmail
command with any -t stripped out.
> You could just make it say "Bounce to #{to.size} recipients?". :)
That would work. Still gives a chance to back out if things don't
look right but not too heavy either.
I'll rework this tonight. I looked at refactoring against the
EditMessageMode send function the other night and that's not straight
forward since the shared code is a few classes up the object tree.
Moving the send message code higher in the tree isn't ideal, as it
doesn't really belong there...suggestions on that?
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090605/17101870/attachment-0001.bin>
------------------------------
Message: 288
Date: Fri, 05 Jun 2009 14:43:59 -0400
From: Marc Hartstein <marc.hartstein@alum.vassar.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup is hanging
Message-ID: <1244227108-sup-3123@cabinet>
Content-Type: text/plain; charset="utf8"
Excerpts from Edward Z. Yang's message of Fri Jun 05 01:08:10 -0400 2009:
> I tickled the bug and took a more careful look at the message that had
> triggered it, and noticed that it was an auto-generated commit message
> that was really long. So one possible stop-gap would be just to detect
> if a message is long and disable quoting if that was the case (a long
> message would be, say, one over 100KB). There is also a possibility
> that the commit message had some pathological backtracking built into
> it.
I think I'm experiencing a similar problem with long messages which
sometimes get generated by chrootkit. I've cleverly deleted (rather
than moving somewhere innocuous) all such messages to get sup past the
chokepoint, but I expect a new one will be generated this weekend and
I'd be happy to look at it.
I noticed that one feature of the messages was that they contained one
extremely long line. Not sure if this information will in any way help
figure out what's going on there.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090605/b15e8cd8/attachment-0001.bin>
------------------------------
Message: 289
Date: Fri, 05 Jun 2009 12:02:37 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk mailing list <sup-talk@rubyforge.org>, sup-announce
mailing list <sup-announce@rubyforge.org>
Subject: [sup-talk] [ANN] Sup 0.8 released
Message-ID: <1244228405-sup-4363@entry>
Content-Type: text/plain; charset=UTF-8
I'm pleased to announce the release of Sup 0.8.
Sup is a console-based email client for people with a lot of email.
It supports tagging, very fast full-text search, automatic contact-
list management, and more. If you're the type of person who treats
email as an extension of your long-term memory, Sup is for you.
Get it: gem install sup
Learn it: http://sup.rubyforge.org
Love it: sup-talk@rubyforge.org
Excitement in 0.8:
* Undo support on many operations. Yay!
* Mbox splitting fixes. No more "From "-line problems.
* Mail parsing speedups.
* Many utf8 and widechar fixes. Display of crazy characters should be pretty
close.
* Outgoing email with non-ASCII headers is now properly encoded.
* Email addresses are no longer permanently attached to names. This was
causing problems with automated email systems that used different names
with the same address.
* Curses background now retains the terminal default color. This also makes
Sup work better on transparent terminals.
* Improve dynamic loading of setlocale for Cygwin and BSD systems.
* Labels can now be removed from multiple tagged threads.
* Applying operations to tagged threads is now invoked with '='.
* Buffer list is betterified and is now invoked with ';'.
* Zsh autocompletion support.
* As always, many bugfixes and tweaks.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 290
Date: Fri, 05 Jun 2009 17:47:00 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup is hanging
Message-ID: <1244238388-sup-760@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from Marc Hartstein's message of Fri Jun 05 14:43:59 -0400 2009:
> I noticed that one feature of the messages was that they contained one
> extremely long line. Not sure if this information will in any way help
> figure out what's going on there.
Now that you mention it, the messages that tickle this bug on my side also
have one extremely long line. That's very interesting.
Cheers,
Edward
------------------------------
Message: 291
Date: Fri, 05 Jun 2009 20:09:13 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Attempt at reply-from hook
Message-ID: <1244246896-sup-4529@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Fri Jun 05 09:37:02 -0400 2009:
> Try has_label? :mylabel. Sup represents labels as symbols instead of as
> strings.
Great! My hook works now. This is the sort of functionality that I think
is worth generalizing and implementing as a configuration twiddle (one,
I think, that should be on by default.)
> A good environment for playing around with this stuff is to run the console:
>
> w@drspaceman:~/devel/sup$ sh devel/console.sh
> [...]
> >> Index.run_query "label:potato"
> => [1000]
> >> m = Index.build_message 1000
> => #<Redwood::Message:0x7f187b394ac8 [...]>
> >> m.labels
> => [:inbox, :unread, :potato]
> >> m.has_label? :potato
> => true
> >> m.has_label? "potato"
> => false
Nice!
Cheers,
Edward
------------------------------
Message: 292
Date: Sat, 06 Jun 2009 02:20:25 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup is hanging
Message-ID: <1244267416-sup-3720@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from Edward Z. Yang's message of Fri Jun 05 17:47:00 -0400 2009:
> Now that you mention it, the messages that tickle this bug on my side also
> have one extremely long line. That's very interesting.
Here is the culprit, laid out to bear its full shame:
/\w.*:$/
I thought this was a suspicious looking regexen; a simple test confirmed my
belief:
line = ":a" * 10000
line =~ /\w.*:$/
Ba boom ba boom ba boom. This is a textbook case of catastrophic backtracking.
I have two possible fixes, they end up being about the same time for regular
cases, but the second one is more optimal for really long strings:
First, the simple one:
diff --git a/lib/sup/message.rb b/lib/sup/message.rb
index 5993729..0ddd3af 100644
--- a/lib/sup/message.rb
+++ b/lib/sup/message.rb
@@ -26,7 +26,7 @@ class Message
QUOTE_PATTERN = /^\s{0,4}[>|\}]/
BLOCK_QUOTE_PATTERN = /^-----\s*Original Message\s*----+$/
- QUOTE_START_PATTERN = /\w.*:$/
+ QUOTE_START_PATTERN = /\w\W*:$/
SIG_PATTERN = /(^-- ?$)|(^\s*----------+\s*$)|(^\s*_________+\s*$)|(^\s*--~--~-)|(^\s*--\+\+\*\*==)/
MAX_SIG_DISTANCE = 15 # lines from the end
And the slightly more complicated one (but optimal for large n):
diff --git a/lib/sup/message.rb b/lib/sup/message.rb
index 5993729..c5481a6 100644
--- a/lib/sup/message.rb
+++ b/lib/sup/message.rb
@@ -26,7 +26,6 @@ class Message
QUOTE_PATTERN = /^\s{0,4}[>|\}]/
BLOCK_QUOTE_PATTERN = /^-----\s*Original Message\s*----+$/
- QUOTE_START_PATTERN = /\w.*:$/
SIG_PATTERN = /(^-- ?$)|(^\s*----------+\s*$)|(^\s*_________+\s*$)|(^\s*--~--~-)|
MAX_SIG_DISTANCE = 15 # lines from the end
@@ -449,7 +448,7 @@ private
when :text
newstate = nil
- if line =~ QUOTE_PATTERN || (line =~ QUOTE_START_PATTERN && nextline =~ QUO
+ if line =~ QUOTE_PATTERN || (line =~ /:$/ && line =~ /\w/ && nextline =~ QU
newstate = :quote
elsif line =~ SIG_PATTERN && (lines.length - i) < MAX_SIG_DISTANCE
newstate = :sig
There are number of micro-optimizations that could be made to message
parsing, but this will basically fix the egregious problem.
Cheers,
Edward
------------------------------
Message: 293
Date: Sat, 06 Jun 2009 02:54:01 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Sup annoyances
Message-ID: <1244270435-sup-9288@javelin>
Content-Type: text/plain; charset=UTF-8
Having just submitted my first patch, I feel entitled to gripe and
moan about certain aspects of Sup. The hope is that I'll get some
pointers on what code to look at to fix these gripes. These gripes
are independent of the hanging/other behavior in my other monster
thread. (I'd say the asynchronous polling hang is my other biggest
gripe, but that's not an issue for here).
1. Threads should be lazy-loaded (possibly in the background), with
visible messages first. If a conversation got a new message, Sup
should only take its time to load that message, and not the frickin'
24 other messages that were also incidentally there. I suspect
this will require some pretty major refactoring. As a stop-gap,
I should have the option of cancelling when I open a long thread
(right now, I think it causes sup to crash).
2. Auto-completion sucks and should be improved. I should be able
to press "c", type two letters, and then mash tab. If auto-completion
actually works, then I'll blame it on dismal contacts.txt support
(if I send mail to someone, there should be a configuration twiddle
that saves it to contacts.txt. And then remembers it the next
time I want to compose mail to them).
3. Polling and loading of threads should started, asynchronously, at
the same time. Loading of threads should not hose my CPU. Loading
of threads should do smart things, instead of doing an O(n) time warp.
It takes forever for a mail from two months ago that is still in my
inbox, because it still hasn't been addressed, to show up. This could
probably be fixed with a cache file. This isn't as big of a deal
if asynchronous polling hang and crashing is fixed.
4. Sup should prompt me whether or not I want to Reply All or Reply on
appropriate cases, like pine.
Cheers,
Edward
------------------------------
Message: 294
Date: Sat, 06 Jun 2009 02:56:11 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup annoyances
Message-ID: <1244271263-sup-3881@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from Edward Z. Yang's message of Sat Jun 06 02:54:01 -0400 2009:
> 4. Sup should prompt me whether or not I want to Reply All or Reply on
> appropriate cases, like pine.
To be clear, this should be a configuration twiddle.
I think I also have just remembered one more thing:
5. Killing a thread should kill it *now*, not "when Sup next restarts".
Cheers,
Edward
------------------------------
Message: 295
Date: Sat, 06 Jun 2009 12:16:55 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [RFC] Bounce messages
Message-ID: <1244283371-sup-2895@ausone.local>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Fri Jun 05 18:02:17 +0200 2009:
> Hi Ben,
>
> I'm definitely interested in having this feature. But it does open up
> some complications because we have to be able to call the MTA in two
> different modes.
I don't get the purpose of this, how it is different from hitting 'D' to send
again the same message?
--
Nicolas Pouillard
http://nicolaspouillard.fr
------------------------------
Message: 296
Date: Sat, 06 Jun 2009 08:44:15 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [RFC] Bounce messages
Message-ID: <1244291795-sup-1695@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Nicolas Pouillard's message of Sat Jun 06 06:16:55 -0400 2009:
> I don't get the purpose of this, how it is different from hitting 'D' to send
> again the same message?
Look at the From: header when you do that. It gets set to _your_
address. You could use D, edit the from address to that of the
original sender and then fire to achieve the same effect (although I'm
not sure how it handles attachments, etc), but that's a lot of typing
for a common action. I also believe that with D, since you're
injecting a new message with original content, that you'd lose much of
the original header info.
The idea is that when you 'bounce' the message, it's akin to you
having had a .forward in place at MTA delivery time. Redirect, not
forward.
My biggest use case for this is bouncing mail sent to me personally
asking for support into our ticket system. The original sender will
see the autoreply with the ticket id, etc because the From: header
contained their address. Colleagues using other mail clients lacking
this feature will forward mail to the ticket system which sees them
get the replies. They then have to go into the ticket and set a
proper 'requester' address for further correspondence on the ticket.
I remember when I discovered this feature in mutt how weird I thought
it was. It wasn't long before it was in common use for me though.
Does that make sense?
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090606/6730fbb2/attachment-0001.bin>
------------------------------
Message: 297
Date: Sat, 06 Jun 2009 16:36:12 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: Ben Walton <bwalton@artsci.utoronto.ca>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [RFC] Bounce messages
Message-ID: <1244298935-sup-5932@ausone.local>
Content-Type: text/plain; charset=UTF-8
Excerpts from Ben Walton's message of Sat Jun 06 14:44:15 +0200 2009:
> Excerpts from Nicolas Pouillard's message of Sat Jun 06 06:16:55 -0400 2009:
> > I don't get the purpose of this, how it is different from hitting 'D' to send
> > again the same message?
>
> Look at the From: header when you do that. It gets set to _your_
> address. You could use D, edit the from address to that of the
> original sender and then fire to achieve the same effect (although I'm
> not sure how it handles attachments, etc), but that's a lot of typing
> for a common action. I also believe that with D, since you're
> injecting a new message with original content, that you'd lose much of
> the original header info.
>
> The idea is that when you 'bounce' the message, it's akin to you
> having had a .forward in place at MTA delivery time. Redirect, not
> forward.
>
> My biggest use case for this is bouncing mail sent to me personally
> asking for support into our ticket system. The original sender will
> see the autoreply with the ticket id, etc because the From: header
> contained their address. Colleagues using other mail clients lacking
> this feature will forward mail to the ticket system which sees them
> get the replies. They then have to go into the ticket and set a
> proper 'requester' address for further correspondence on the ticket.
>
> I remember when I discovered this feature in mutt how weird I thought
> it was. It wasn't long before it was in common use for me though.
>
> Does that make sense?
It does! Thanks for the explanation.
--
Nicolas Pouillard
http://nicolaspouillard.fr
------------------------------
Message: 298
Date: Sat, 06 Jun 2009 14:03:14 +0200
From: Helge Titlestad <helgedt@tihlde.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [RFC] Bounce messages
Message-ID: <1244289688-sup-9384@colargol.tihlde.org>
Content-Type: text/plain; charset=UTF-8
Excerpts from Nicolas Pouillard's message of Sat Jun 06 12:16:55 +0200 2009:
> I don't get the purpose of this, how it is different from hitting 'D' to send
> again the same message?
One out of several differences: D doesn't include attachments.
My personal use case: I have a couple of mail accounts - this one for all my
normal private stuff, one gmail account mostly for sharing documents and so on.
If I get a mail with an attachment that I can't read in a terminal (typically
pdf) to my private account, I will bounce it to my gmail account. That
preserves the whole message, and is different from both "D" (which I use
to re-send mail) and forward (which I use to forward interesting stuff to
other people).
--
alge
------------------------------
Message: 299
Date: Sat, 06 Jun 2009 12:53:30 -0400
From: Marc Hartstein <marc.hartstein@alum.vassar.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup is hanging
Message-ID: <1244307062-sup-6010@cabinet>
Content-Type: text/plain; charset="utf8"
Excerpts from Edward Z. Yang's message of Sat Jun 06 02:20:25 -0400 2009:
> Excerpts from Edward Z. Yang's message of Fri Jun 05 17:47:00 -0400 2009:
> > Now that you mention it, the messages that tickle this bug on my side also
> > have one extremely long line. That's very interesting.
>
> Here is the culprit, laid out to bear its full shame:
>
> /\w.*:$/
Looks highly plausible to me. My 7.2M (ouch) email most of which is a single
line contains a lot of :s in that line.
I'll check if the patch works and report back in a little while.
Thanks!
Marc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090606/57226edc/attachment-0001.bin>
------------------------------
Message: 300
Date: Sat, 06 Jun 2009 13:16:39 -0400
From: Marc Hartstein <marc.hartstein@alum.vassar.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup annoyances
Message-ID: <1244308338-sup-4735@cabinet>
Content-Type: text/plain; charset="utf8"
Excerpts from Edward Z. Yang's message of Sat Jun 06 02:56:11 -0400 2009:
> Excerpts from Edward Z. Yang's message of Sat Jun 06 02:54:01 -0400 2009:
> > 4. Sup should prompt me whether or not I want to Reply All or Reply on
> > appropriate cases, like pine.
>
> To be clear, this should be a configuration twiddle.
sup gives you a menu to select whether to reply to Sender, Recipient,
List, or All. It's right up near the top of the reply-mode screen. Use
regular vertical movement keys to select the Reply to: line, then
horizontal movement to select an option.
You can improve the default selection using the reply-to hook. See `sup
--list-hooks` for documentation.
I found it a little weird getting used to (coming from mutt, where I
actually used a different reply key for each mode), but the default
behavior is generally correct, and selecting from the menu isn't too
bad.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090606/fd2b4e16/attachment-0001.bin>
------------------------------
Message: 301
Date: Sat, 06 Jun 2009 13:45:49 -0400
From: Marc Hartstein <marc.hartstein@alum.vassar.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup is hanging
Message-ID: <1244310130-sup-5040@cabinet>
Content-Type: text/plain; charset="utf8"
Excerpts from Edward Z. Yang's message of Sat Jun 06 02:20:25 -0400 2009:
> I have two possible fixes, they end up being about the same time for regular
> cases, but the second one is more optimal for really long strings:
I can report that the first patch seems to be sufficient for sup-sync to
merely take a noticeable amount of time to process my highly problematic
message. I leave it to Edward and William to decide whether the
additional optimization is worthwhile.
Thanks for fixing this!
Marc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090606/f9d537bc/attachment-0001.bin>
------------------------------
Message: 302
Date: Sat, 06 Jun 2009 14:17:29 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup annoyances
Message-ID: <1244312041-sup-9128@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from Marc Hartstein's message of Sat Jun 06 13:16:39 -0400 2009:
> sup gives you a menu to select whether to reply to Sender, Recipient,
> List, or All. It's right up near the top of the reply-mode screen. Use
> regular vertical movement keys to select the Reply to: line, then
> horizontal movement to select an option.
Yep, I know about this.
> You can improve the default selection using the reply-to hook. See `sup
> --list-hooks` for documentation.
I didn't know about that.
> I found it a little weird getting used to (coming from mutt, where I
> actually used a different reply key for each mode), but the default
> behavior is generally correct, and selecting from the menu isn't too
> bad.
The trouble is I always forget to check the To: header on my mails, and
there is a ~large class of mailing list emails that don't actually do
the right thing by default. Improving the heuristic may be an alternate
possibility.
Cheers,
Edward
------------------------------
Message: 303
Date: Sat, 06 Jun 2009 15:06:49 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: Marc Hartstein <marc.hartstein@alum.vassar.edu>
Cc: Sup Mailing List <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup/gpg
Message-ID: <1244314983-sup-482@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Marc Hartstein's message of Sat Jun 06 14:53:55 -0400 2009:
> Excerpts from Ben Walton's message of Sat Jun 06 14:45:56 -0400 2009:
> >
> > This just got stranger, which makes me think it may be a sup issue
> > still. The thread you replied twice to earlier today has one message
> > validating and the other not. See attached.
>
> Ok, that's totally bizarre.
>
> Things I can think of:
>
> Those were two different sup instances (I'd quit, created a branch, and
> applied the discussed patch in between sending the two replies)
Well, if the patch altered the behaviour, that's a possibility.
> I might well have typoed my passphrase for one of the messages and not
> the other, though I'm not sure which. I think it's slightly more likely
> that the BAD message was the one where I made a typo, though. [I then
> proceeded to enter it correctly the second time, though, so...]
When I enter a bad passphrase into pinentry, sup detects this and
won't send the message...to my knowledge, I'm not able to get a
multipart/gpg message sent if I don't enter a proper passphrase.
> Think we should move the discussion to the sup list to see if anybody
> has thoughts?
I think that's reasonable. My next thought is that there is a small
bug in the mime parsing (or creating) code...
Does anyone else have thoughts on what would cause broken gpg
signatures? I've previously had issues when using gpg2 instead of
gpg1, but that was completely the fault of gpg2 (or my use of it,
anyway). Switching to gpg1 resolved the problem at that time. In
this instance, Mark isn't able to validate my signatures and I was
able to validate his until just recently...I'm now hit-and-miss with
his.
Thoughts?
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090606/ff5e9ca6/attachment-0001.bin>
------------------------------
Message: 304
Date: Sat, 06 Jun 2009 02:35:50 +0200
From: Ingmar Vanhassel <ingmar@exherbo.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Use terminal width instead of
hardcoded 80 as the wrap length.
Message-ID: <1244248537-sup-5155@cannonball>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Wed May 27 17:58:23 +0200 2009:
> Reformatted excerpts from Ben Walton's message of 2009-05-23:
> > But if you leave sup's "we dont' force wrapping" rules alone, this
> > makes reading mail scroll free if your terminal is wide enough and
> > doesn't change the behaviour if the terminal is narrower. (Not that
> > I'm against making it an option either.)
>
> Seems like there are three main modes of operation that would be
> desirable:
>
> 1. wrap at 80 chars;
> 2. wrap at current terminal width;
> 3. don't wrap.
>
> (In all cases, existing line breaks in the message are left alone.)
>
> Would a three-way toggle irritate anyone?
Works for me.
------------------------------
Message: 305
Date: Sun, 07 Jun 2009 08:33:49 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: Sup Mailing List <sup-talk@rubyforge.org>
Subject: [sup-talk] exception with undomanager
Message-ID: <1244377876-sup-7845@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Hi All,
I bumped into this this morning. I've not used the undo stuff much,
but I tried it today. The (rough) sequence of events leading to this
was: I archived two threads separately and then decided I wanted to
undo the first of two actions. I hit u once and got the latest thread
back and when I hit it again, sup crashed. If I get a chance I'll
look into it myself, but I'm tossing it out for people more familiar
with these bits to see also.
Thanks
-Ben
$ less ~/.sup/exception-log.txt
--- NoMethodError from thread: main
undefined method `content_width' for nil:NilClass
./sup/modes/thread-index-mode.rb:868:in `from_width'
./sup/modes/thread-index-mode.rb:793:in `text_for_thread_at'
/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
`each_with_index'
./sup/modes/thread-index-mode.rb:792:in `each'
./sup/modes/thread-index-mode.rb:792:in `each_with_index'
./sup/modes/thread-index-mode.rb:792:in `text_for_thread_at'
./sup/modes/thread-index-mode.rb:753:in `regen_text'
./sup/util.rb:346:in `map_with_index'
/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
`each_with_index'
./sup/util.rb:346:in `each'
./sup/util.rb:346:in `each_with_index'
./sup/util.rb:346:in `map_with_index'
./sup/modes/thread-index-mode.rb:753:in `regen_text'
./sup/modes/thread-index-mode.rb:228:in `update'
./sup/modes/thread-index-mode.rb:697:in `add_or_unhide'
./sup/modes/thread-index-mode.rb:319:in `actually_toggle_spammed'
./sup/undo.rb:28:in `call'
./sup/undo.rb:28:in `undo'
./sup/undo.rb:28:in `each'
./sup/undo.rb:28:in `undo'
./sup/util.rb:505:in `send'
./sup/util.rb:505:in `method_missing'
./sup/modes/thread-index-mode.rb:217:in `undo'
./sup/mode.rb:50:in `send'
./sup/mode.rb:50:in `handle_input'
./sup/buffer.rb:249:in `handle_input'
../bin/sup:237
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090607/3fcc2660/attachment-0001.bin>
------------------------------
Message: 306
Date: Sun, 07 Jun 2009 12:39:17 -0400
From: Marc Hartstein <marc.hartstein@alum.vassar.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Use terminal width instead of
hardcoded 80 as the wrap length.
Message-ID: <1244392518-sup-9746@cabinet>
Content-Type: text/plain; charset="utf8"
Excerpts from William Morgan's message of Wed May 27 11:58:23 -0400 2009:
> 1. wrap at 80 chars;
> 2. wrap at current terminal width;
> 3. don't wrap.
>
> (In all cases, existing line breaks in the message are left alone.)
Do we currently honor format=flowed email?
http://joeclark.org/ffaq.html
http://www.ietf.org/rfc/rfc3676.txt
If we don't, it would be desirable to take this into account when
designing the display wrapping options, and it seems like it would be
worth implementing down the road.
I suppose it would be reasonable to treat it the same as long lines are
treated with the above options.
It might be useful to be able to specify the wrap margin to something
other than 80. I don't know if anybody would actually use this, though.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090607/fc44fb03/attachment-0001.bin>
------------------------------
Message: 307
Date: Sun, 07 Jun 2009 19:52:10 -0400
From: David L.Kaplan <sup@davekap.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] crash with .8 on save ($)
Message-ID: <1244418650-sup-3064@ubuntu>
Content-Type: text/plain; charset=UTF-8
To the best of my recollection, I had archived a few messages and then
hit $ to save state. Exception file attached.
Thanks for sup.
Dave
--- RuntimeError from thread: periodic poll
trying to delete non-corresponding entry 47607 with index message-id
"2ca9fdfb2b3c1c3c3981de95447977b2@www.facebook.com" and parameter message id
"988542971151613.JXQSVJUEOLXELKD@187-45-0-136.clientes.cilnet.com.br"
/home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/index.rb:191:in `sync_message'
/usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
/home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/index.rb:190:in `sync_message'
/home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `send'
/home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `method_missing'
/home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/poll.rb:161:in `add_messages_from'
/home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/maildir.rb:130:in `each'
/home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/maildir.rb:127:in `upto'
/home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/maildir.rb:127:in `each'
/home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/util.rb:544:in `send'
/home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/util.rb:544:in `__pass'
/home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/util.rb:531:in `method_missing'
/home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/poll.rb:141:in `add_messages_from'
/home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/poll.rb:98:in `do_poll'
/home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/poll.rb:86:in `each'
/home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/poll.rb:86:in `do_poll'
/home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/poll.rb:85:in `synchronize'
/home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/poll.rb:85:in `do_poll'
/home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `send'
/home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `method_missing'
/home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/modes/poll-mode.rb:17:in `poll'
/home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/poll.rb:53:in `poll'
/home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/poll.rb:70:in `start'
/home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup.rb:71:in `reporting_thread'
/home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup.rb:69:in `initialize'
/home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup.rb:69:in `new'
/home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup.rb:69:in `reporting_thread'
/home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/poll.rb:67:in `start'
/home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `send'
/home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `method_missing'
/home/dave/.gem/ruby/1.8/gems/sup-0.8/bin/sup:213
/usr/bin/sup:19:in `load'
/usr/bin/sup:19
------------------------------
Message: 308
Date: Sun, 7 Jun 2009 20:02:25 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk@rubyforge.org
Subject: [sup-talk] (no subject)
Message-ID:
<1244419347-11330-1-git-send-email-bwalton@artsci.utoronto.ca>
Hi All,
Here's a stab at implementing a message bouncing functionality worthy
of being included on mainline.
The first patch adds the basic functionality with the ability to
supply a command in the :bounce_sendmail option that overrides the
default command used. The default is to use the sendmail command of
the default account with -t removed.
The second patch takes this a step further and strips the
configuration option in favour of a hook named bounce-command. This
hooks gets the From header of the message being bounced and an array
of recipient addresses supplied by the user.
I think these are in good shape, with the caveat that the mail sending
(IO.popen) part could still be refactored with the code in
edit-message-mode.
Anyone interested can grab this code from the bw/bounce_message branch
of git://code.chass.utoronto.ca/bwalton-sup.git. It merges cleanly
into next as of now.
Feedback welcome.
Thanks
-Ben
------------------------------
Message: 309
Date: Sun, 7 Jun 2009 20:02:26 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk@rubyforge.org
Cc: Ben Walton <bwalton@artsci.utoronto.ca>
Subject: [sup-talk] [PATCH 1/2] Add message bouncing capability
Message-ID:
<1244419347-11330-2-git-send-email-bwalton@artsci.utoronto.ca>
Bouncing a message is akin to redirecting a mail with a .forward
entry. It is passed back to the mail system as it sits on disk.
By pressing ! while viewing a message, you can now re-inject it to the
mail system using either the command defined in bounce_sendmail or the
sendmail command for the default account with any instance of -t
removed. The user is prompted for the recipients of the message and is
offered a chance to confirm the bounce before it is sent.
The message is _not_ stored in the sent box, as this doesn't make
sense with bounced messages (and would not show up uniquely anyway).
The bounce_sendmail configuration item allows users that require
different sendmail commands depending on where the bounce is destined
to write a wrapper around their local mail tools to pick and choose
the appropriate injection method for the message based on the
addresses passed in. Most systems can likely use: sendmail -oem -i
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
---
lib/sup.rb | 1 +
lib/sup/modes/thread-view-mode.rb | 33 +++++++++++++++++++++++++++++++++
2 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/lib/sup.rb b/lib/sup.rb
index 96510b2..76444c9 100644
--- a/lib/sup.rb
+++ b/lib/sup.rb
@@ -207,6 +207,7 @@ else
:confirm_top_posting => true,
:discard_snippets_from_encrypted_messages => false,
:default_attachment_save_dir => "",
+ :bounce_sendmail => "",
}
begin
FileUtils.mkdir_p Redwood::BASE_DIR
diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb
index 42c6280..8842e59 100644
--- a/lib/sup/modes/thread-view-mode.rb
+++ b/lib/sup/modes/thread-view-mode.rb
@@ -41,6 +41,7 @@ EOS
# k.add :collapse_non_new_messages, "Collapse all but unread messages", 'N'
k.add :reply, "Reply to a message", 'r'
k.add :forward, "Forward a message or attachment", 'f'
+ k.add :bounce, "Bounce message to other recipient(s)", '!'
k.add :alias, "Edit alias/nickname for a person", 'i'
k.add :edit_as_new, "Edit message as new", 'D'
k.add :save_to_disk, "Save message/attachment to disk", 's'
@@ -172,6 +173,38 @@ EOS
end
end
+ def bounce
+ m = @message_lines[curpos] or return
+ to = BufferManager.ask_for_contacts(:people, "Bounce To: ") or return
+
+ defcmd = AccountManager.default_account.sendmail.sub(/\s(\-(ti|it|t))\b/) do |match|
+ case "$1"
+ when '-t' then ''
+ else ' -i'
+ end
+ end
+
+ cmd = case $config[:bounce_sendmail]
+ when nil, /^$/ then defcmd
+ else $config[:bounce_sendmail]
+ end + ' ' + to.map { |t| t.email }.join(' ')
+
+ bt = to.size > 1 ? "#{to.size} recipients" : to.to_s
+
+ if BufferManager.ask_yes_or_no "Really bounce to #{bt}?"
+ Redwood::log "Bounce Command: #{cmd}"
+ begin
+ IO.popen(cmd, 'w') do |sm|
+ sm.puts m.raw_message
+ end
+ raise SendmailCommandFailed, "Couldn't execute #{cmd}" unless $? == 0
+ rescue SystemCallError, SendmailCommandFailed => e
+ Redwood::log "Problem sending mail: #{e.message}"
+ BufferManager.flash "Problem sending mail: #{e.message}"
+ end
+ end
+ end
+
include CanAliasContacts
def alias
p = @person_lines[curpos] or return
--
1.6.3
------------------------------
Message: 310
Date: Sun, 7 Jun 2009 20:02:27 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk@rubyforge.org
Cc: Ben Walton <bwalton@artsci.utoronto.ca>
Subject: [sup-talk] [PATCH 2/2] Bounce Message Hook
Message-ID:
<1244419347-11330-3-git-send-email-bwalton@artsci.utoronto.ca>
Determine the command used to bounce a message based on a Hook instead
of a configuration option. Instead of writing an external script that
can send the message properly based on the recipient addresses, rely
on a hook that can return the command based on the From header in the
mail being bounced as well as the intended recipients. This is more
in line with the sup philosophy.
The default is still to strip any -t from the sendmail command of the
default account.
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
---
lib/sup.rb | 1 -
lib/sup/modes/thread-view-mode.rb | 16 ++++++++++++++--
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/lib/sup.rb b/lib/sup.rb
index 76444c9..96510b2 100644
--- a/lib/sup.rb
+++ b/lib/sup.rb
@@ -207,7 +207,6 @@ else
:confirm_top_posting => true,
:discard_snippets_from_encrypted_messages => false,
:default_attachment_save_dir => "",
- :bounce_sendmail => "",
}
begin
FileUtils.mkdir_p Redwood::BASE_DIR
diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb
index 8842e59..76a1d1e 100644
--- a/lib/sup/modes/thread-view-mode.rb
+++ b/lib/sup/modes/thread-view-mode.rb
@@ -24,6 +24,18 @@ Return value:
None. The variable 'headers' should be modified in place.
EOS
+ HookManager.register "bounce-command", <<EOS
+Determines the command used to bounce a message.
+Variables:
+ from: The From header of the message being bounced
+ (eg: likely _not_ your address).
+ to: The addresses you asked the message to be bounced to as an array.
+Return value:
+ A string representing the command to pipe the mail into. This
+ should include the entire command except for the destination addresses,
+ which will be appended by sup.
+EOS
+
register_keymap do |k|
k.add :toggle_detailed_header, "Toggle detailed header", 'h'
k.add :show_header, "Show full message header", 'H'
@@ -184,9 +196,9 @@ EOS
end
end
- cmd = case $config[:bounce_sendmail]
+ cmd = case HookManager.run "bounce-command", :from => m.from, :to => to
when nil, /^$/ then defcmd
- else $config[:bounce_sendmail]
+ else hookcmd
end + ' ' + to.map { |t| t.email }.join(' ')
bt = to.size > 1 ? "#{to.size} recipients" : to.to_s
--
1.6.3
------------------------------
Message: 311
Date: Mon, 8 Jun 2009 08:55:14 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] Fwd: [REQUEST] reply-to-list
Message-ID:
<80055d7c0906080555h37e2b551i606e60dbdd5414f2@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hello there,
Today I was told to read
http://liw.iki.fi/liw/log/2003-Enemies-of-Carlotta.html.
It suggests that a good mailing client should have a reply-to-list
button since mailing lists should not add themselves as a reply-to.
The reply-to-list uses the standard List-ID header to know where to
reply to.
As far as I can tell from ?-ing around the client, sup does not have
this feature (though kudos for having a button for unsubscribe, which
I find mildly curious but cool).
I'm told that the mutt key for this is l (ell), which I guess is reasonable.
Also, hello to the mailing list :)
Cheers,
-AT
------------------------------
Message: 312
Date: Mon, 08 Jun 2009 09:03:11 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Fwd: [REQUEST] reply-to-list
Message-ID: <1244466128-sup-135@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Andrei Thorp's message of Mon Jun 08 08:55:14 -0400 2009:
> As far as I can tell from ?-ing around the client, sup does not have
> this feature (though kudos for having a button for unsubscribe, which
> I find mildly curious but cool).
>
> I'm told that the mutt key for this is l (ell), which I guess is reasonable.
Sup handles this in a smarter way. When you hit r to reply to a
message, if it's detected as a list post, the 'reply to' menu
selection defaults to 'Mailing list.' You can toggle this selection
with the arrow keys.
HTH.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090608/00bf4f2d/attachment-0001.bin>
------------------------------
Message: 313
Date: Mon, 8 Jun 2009 11:21:52 -0400
From: Joe W?lfel <joe@talkhouse.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] Can't seem to send mail
Message-ID: <5A0B9D69-9D14-4E57-8BB1-1CE4E3AF4E65@talkhouse.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
First, Sup awesome. It's saves an incredible amount of time
searching through mail!
I haven't been able to send messages with it yet though. I can only
search and read. I used sup-config to configure imap. According to
the config.yaml file it's using sendmail -oem -ti to send. If I try
to send a message it claims it's sent, but no such luck. Do I need
to do something else in addition? Actually, I'd like to be able to
send from multiple accounts and I'm not sure how to setup Sup to do
that.
------------------------------
Message: 314
Date: Mon, 8 Jun 2009 11:50:47 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Can't seem to send mail
Message-ID:
<80055d7c0906080850o2f861903v5b3a51effb215e0b@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Well, as far as I can tell, sup doesn't actually send mail itself, and can't.
As such, it uses sendmail by default. Therefore, if you want it to
send mail properly, you want to set up sendmail to send your mail.
If you're sending through something sane, it probably uses smtp.
Today, I installed msmtp and am using it with sup successfully to
accomplish this, though you have to change the sendmail command to
/usr/bin/msmtp -t.
Alternatively, you could run your own mail server and use the sendmail
that comes with that.
------------------------------
Message: 315
Date: Mon, 08 Jun 2009 11:52:51 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Can't seem to send mail
Message-ID: <1244476264-sup-5281@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Joe W?lfel's message of Mon Jun 08 11:21:52 -0400 2009:
> I haven't been able to send messages with it yet though. I can only
> search and read. I used sup-config to configure imap. According to
> the config.yaml file it's using sendmail -oem -ti to send. If I try
> to send a message it claims it's sent, but no such luck. Do I need
> to do something else in addition? Actually, I'd like to be able to
> send from multiple accounts and I'm not sure how to setup Sup to do
> that.
Check the log buffer first to see if sup reports errors interacting
with (whatever is masquerading as) sendmail on your system...if there
aren't errors there, check the mail logs on your system, since it has
left the land of sup...If it doesn't make it to your index as a sent
item, I suspect that the sendmail command may not be working
correctly.
HTH
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090608/67753431/attachment-0001.bin>
------------------------------
Message: 316
Date: Mon, 08 Jun 2009 10:18:30 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] exception with undomanager
Message-ID: <1244481362-sup-970@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Walton's message of 2009-06-07:
> I bumped into this this morning. I've not used the undo stuff much,
> but I tried it today. The (rough) sequence of events leading to this
> was: I archived two threads separately and then decided I wanted to
> undo the first of two actions. I hit u once and got the latest thread
> back and when I hit it again, sup crashed. If I get a chance I'll
> look into it myself, but I'm tossing it out for people more familiar
> with these bits to see also.
Something like this seems to happen fairly frequently. I think it's a
(shudder) threading issue. Something is killing a buffer (possibly the
user) while it's being redrawn and this happens. I need to stick another
mutex in there somewhere. Or rewrite Sup for Ruby 1.9 with fibers
instead of threads.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 317
Date: Mon, 08 Jun 2009 10:23:43 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup/gpg
Message-ID: <1244481592-sup-4821@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Walton's message of 2009-06-06:
> Excerpts from Marc Hartstein's message of Sat Jun 06 14:53:55 -0400 2009:
> > Excerpts from Ben Walton's message of Sat Jun 06 14:45:56 -0400 2009:
> > Those were two different sup instances (I'd quit, created a branch, and
> > applied the discussed patch in between sending the two replies)
>
> Well, if the patch altered the behaviour, that's a possibility.
What was the patch?
> > I might well have typoed my passphrase for one of the messages and not
> > the other, though I'm not sure which. I think it's slightly more likely
> > that the BAD message was the one where I made a typo, though. [I then
> > proceeded to enter it correctly the second time, though, so...]
>
> When I enter a bad passphrase into pinentry, sup detects this and
> won't send the message...to my knowledge, I'm not able to get a
> multipart/gpg message sent if I don't enter a proper passphrase.
Yeah, an incorrect passphrase will error out, it won't produce a bad
message.
> I think that's reasonable. My next thought is that there is a small
> bug in the mime parsing (or creating) code...
That is where I would start looking. If you tweak crypto.rb so that it
dumps the payload somewhere (look in #format_payload), you can then
compare that to what ends up in your sent.mbox.
Also you can look at encrypting messages to yourself. Are you able to
decrypt them reliably? If not, is there a pattern? (Non-ASCII in the
headers, body, etc.?)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 318
Date: Mon, 08 Jun 2009 13:58:25 -0400
From: Marc Hartstein <marc.hartstein@alum.vassar.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup/gpg
Message-ID: <1244483397-sup-3035@cabinet>
Content-Type: text/plain; charset="utf8"
Excerpts from William Morgan's message of Mon Jun 08 13:23:43 -0400 2009:
> Reformatted excerpts from Ben Walton's message of 2009-06-06:
> What was the patch?
The regexp fix for messages with very long lines.
> Yeah, an incorrect passphrase will error out, it won't produce a bad
> message.
Yeah, it bounces me back to pinentry, where I proceeded to enter it
correctly. It *shouldn't* produce a bad message, it was just one of the
only things I could think of that had changed between the two messages
which might have led to different behavior.
> That is where I would start looking. If you tweak crypto.rb so that it
> dumps the payload somewhere (look in #format_payload), you can then
> compare that to what ends up in your sent.mbox.
I'll take a look at this...
> Also you can look at encrypting messages to yourself. Are you able to
> decrypt them reliably? If not, is there a pattern? (Non-ASCII in the
> headers, body, etc.?)
I expect this will have the same behavior as checking signatures on
messages I send, no?
Just a little background that we discussed before forwarding this to
the list:
Ben is using gpg 1 after correspondents complained the switch to gpg 2
caused his messages to have bad signatures.
I am using gpg 2.0.11
I see *all* Ben's messages as having bad signatures, and see all my own
(either in sent.mbox or bounced back to me from the list) as good. I
also see Ben's signatures as bad when looking at the same messages
through mutt. I see the same thing going back to his first signed
message to sup-talk, and also in his direct emails to me.
Ben sees most of my signatures as good, but has recently experienced an
intermittent issue where my signatures are bad.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090608/cf4da2ef/attachment-0001.bin>
------------------------------
Message: 319
Date: Mon, 08 Jun 2009 11:00:23 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup annoyances
Message-ID: <1244481844-sup-9094@entry>
Content-Type: text/plain; charset=UTF-8
Hi Edward,
I think these are by and large legitimate gripes and I'd be delighted to
have someone motivated to fix them!
Reformatted excerpts from Edward Z. Yang's message of 2009-06-05:
> 1. Threads should be lazy-loaded (possibly in the background), with
> visible messages first.
FWIW, this is particularly egregious in a direct IMAP connection, and
those of us who have switched to Maildir or who use mbox aren't
punished. But it would be very cool to have this.
> If a conversation got a new message, Sup should only take its time to
> load that message, and not the frickin' 24 other messages that were
> also incidentally there. I suspect this will require some pretty
> major refactoring.
It might not be too bad. Turn off the call to m.load_from_source! on
line 106 of thread-index-mode.rb, add a Queue to ThreadViewMode
containing messages to call #load_from_source! on, don't call m.chunks
in ThreadViewMode#regen_text unless the message has been loaded, start a
thread that pops messages from the queue, calls #load_from_source! on
them, and then calls regen_text when an open message has been loaded...
and you're 90% of the way there.
> 2. Auto-completion sucks and should be improved. I should be able
> to press "c", type two letters, and then mash tab. If auto-completion
> actually works, then I'll blame it on dismal contacts.txt support
The auto-completion is awesome. Adding a recipient to the contacts list is
a good idea.
> 3. Polling and loading of threads should started, asynchronously, at
> the same time.
> Loading of threads should not hose my CPU.
Agreed. Please fix.
> Loading of threads should do smart things, instead of doing an O(n)
> time warp.
It's definitely worse than O(n). Loading threads could be sped up
dramatically by storing the thread structure somewhere (either cached or
just for every thread), since Sup does a lot of extra work rethreading
everything every time you start it up. FWIW I'm doing this the right way
in Sup 2.0.
> 4. Sup should prompt me whether or not I want to Reply All or Reply on
> appropriate cases, like pine.
There have been a couple similar requests like this recently, though
it's not clear if everyone has known about the ability to change the
reply mode and about the reply-to hook. Since hitting 'r' defaults to
replying to the sender alone (except for mailing list messages), I'd be
ok with adding a Mutt-style reply-to-all key that starts up reply-mode
with the 'reply to all' mode active.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 320
Date: Mon, 08 Jun 2009 11:09:52 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup is hanging
Message-ID: <1244484134-sup-5651@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Edward Z. Yang's message of 2009-06-05:
> - if line =~ QUOTE_PATTERN || (line =~ QUOTE_START_PATTERN && nextline =~ QUO
> + if line =~ QUOTE_PATTERN || (line =~ /:$/ && line =~ /\w/ && nextline =~ QU
Seems fine to me. I've applied that change directly to master. Not only
are there millions of optimiziations for this stuff, there are millions
of tweaks to improve detection precision and recall.
Thanks for your help with this, Edward!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 321
Date: Mon, 8 Jun 2009 14:05:34 -0400
From: Joe W?lfel <joe@talkhouse.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Can't seem to send mail
Message-ID: <AAB8FA5E-9E58-4C24-9290-F3C80155E55D@talkhouse.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
On Jun 8, 2009, at 11:52 AM, Ben Walton wrote:
> Excerpts from Joe W?lfel's message of Mon Jun 08 11:21:52 -0400 2009:
>> I haven't been able to send messages with it yet though. I can only
>> search and read. I used sup-config to configure imap. According
>> to
>> the config.yaml file it's using sendmail -oem -ti to send. If I try
>> to send a message it claims it's sent, but no such luck. Do I need
>> to do something else in addition? Actually, I'd like to be able to
>> send from multiple accounts and I'm not sure how to setup Sup to do
>> that.
>
> Check the log buffer first to see if sup reports errors interacting
> with (whatever is masquerading as) sendmail on your system...if there
> aren't errors there, check the mail logs on your system, since it has
> left the land of sup...If it doesn't make it to your index as a sent
> item, I suspect that the sendmail command may not be working
> correctly.
>
> HTH
> -Ben
>
> --
> Ben Walton
> Systems Programmer - CHASS
> University of Toronto
> C:416.407.5610 | W:416.978.4302
>
> GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
> Contact me to arrange for a CAcert assurance meeting.
> _______________________________________________
> sup-talk mailing list
> sup-talk@rubyforge.org
> http://rubyforge.org/mailman/listinfo/sup-talk
It looks like sendmail isn't functioning and doesn't generate any
errors. Maybe it's a mac problem. I haven't tried it on anything
else yet.
------------------------------
Message: 322
Date: Mon, 08 Jun 2009 14:18:41 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] exception with undomanager
Message-ID: <1244485084-sup-973@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Mon Jun 08 13:18:30 -0400 2009:
> Something like this seems to happen fairly frequently. I think it's a
> (shudder) threading issue. Something is killing a buffer (possibly the
> user) while it's being redrawn and this happens. I need to stick another
> mutex in there somewhere. Or rewrite Sup for Ruby 1.9 with fibers
> instead of threads.
The unfortunate bit about Ruby 1.9 is that the majority of libraries sup uses
aren't on 1.9 yet...
Cheers,
Edward
------------------------------
Message: 323
Date: Mon, 08 Jun 2009 11:25:10 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup/gpg
Message-ID: <1244485140-sup-1973@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Marc Hartstein's message of 2009-06-08:
> The regexp fix for messages with very long lines.
Yeah, that shouldn't change anything. Doesn't even change Sup's output!
> Yeah, it bounces me back to pinentry, where I proceeded to enter it
> correctly. It *shouldn't* produce a bad message, it was just one of
> the only things I could think of that had changed between the two
> messages which might have led to different behavior.
Except the message content, I guess. :)
> > Also you can look at encrypting messages to yourself. Are you able
> > to decrypt them reliably? If not, is there a pattern? (Non-ASCII in
> > the headers, body, etc.?)
>
> I expect this will have the same behavior as checking signatures on
> messages I send, no?
It should; I was just suggesting it as an alternative approach to
figuring out what was causing the problem. Then Ben isn't in the loop
any more and you can spend all night happily debuggin this. :)
> Ben is using gpg 1 after correspondents complained the switch to gpg 2
> caused his messages to have bad signatures.
Was he using Sup the entire time?
> I am using gpg 2.0.11
>
> I see *all* Ben's messages as having bad signatures, and see all my
> own (either in sent.mbox or bounced back to me from the list) as good.
> I also see Ben's signatures as bad when looking at the same messages
> through mutt. I see the same thing going back to his first signed
> message to sup-talk, and also in his direct emails to me.
>
> Ben sees most of my signatures as good, but has recently experienced
> an intermittent issue where my signatures are bad.
It sounds like there might be some possibility that it's a GPG version
incompatibility, though I'd be a little surprised if that were really
the case. It might be helpful if you guys could do a control experiment
with Mutt, since I have a fair amount of faith in its GPG
implementation.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 324
Date: Mon, 8 Jun 2009 14:42:28 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Can't seem to send mail
Message-ID:
<80055d7c0906081142w63a5ddf3w2d7c06fd174b3740@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Heh.
# file /usr/sbin/sendmail
/usr/sbin/sendmail: symbolic link to `/bin/true'
Fail.
(or it would be ;)
-AT
------------------------------
Message: 325
Date: Mon, 08 Jun 2009 14:44:50 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Can't seem to send mail
Message-ID: <1244486438-sup-3501@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Joe W?lfel's message of Mon Jun 08 14:05:34 -0400 2009:
> It looks like sendmail isn't functioning and doesn't generate any
> errors. Maybe it's a mac problem. I haven't tried it on anything
> else yet.
Personally, I don't think sendmail has _ever_ been functional, but
that's just the grumpy side of me that has to configure it on clunky
old boxes still! :)
It's likely working, but has a local delivery setup configured. Try
using `mailq` to see if anything is sitting in the outbound queue.
You may also want to look in /var/spool/mail for mbox files sitting
there with the messages (or bounces) sent from sup.
If you want to get your hands dirty, I recommend exim as the
replacment for sendmail. I like it's configuration and acl setup
better than postfix, but that would also work. If you just want to
send mail quickly and easily, try msmtp or a similar package.
HTH.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090608/1f82e67c/attachment-0001.bin>
------------------------------
Message: 326
Date: Mon, 08 Jun 2009 14:50:19 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] exception with undomanager
Message-ID: <1244486944-sup-293@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Edward Z. Yang's message of Mon Jun 08 14:18:41 -0400 2009:
> The unfortunate bit about Ruby 1.9 is that the majority of libraries sup uses
> aren't on 1.9 yet...
...and some platforms don't have packages for it yet, which puts more
onus on the user to get it up and going...
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090608/836af547/attachment-0001.bin>
------------------------------
Message: 327
Date: Mon, 08 Jun 2009 11:59:04 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] exception with undomanager
Message-ID: <1244487518-sup-3141@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Edward Z. Yang's message of 2009-06-08:
> The unfortunate bit about Ruby 1.9 is that the majority of libraries
> sup uses aren't on 1.9 yet...
Not a serious suggestion. One rewrite going at a time is my rule. :)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 328
Date: Mon, 08 Jun 2009 15:02:28 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] exception with undomanager
Message-ID: <1244487681-sup-5778@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from Ben Walton's message of Mon Jun 08 14:50:19 -0400 2009:
> ...and some platforms don't have packages for it yet, which puts more
> onus on the user to get it up and going...
Ruby is basically not usable with your package manager. You *have* to
roll the gems yourself.
Cheers,
Edward
------------------------------
Message: 329
Date: Mon, 08 Jun 2009 15:20:31 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] exception with undomanager
Message-ID: <1244488618-sup-3388@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Edward Z. Yang's message of Mon Jun 08 15:02:28 -0400 2009:
> Ruby is basically not usable with your package manager. You *have* to
> roll the gems yourself.
I realize this. Gems are awesome and gems suck. I'm talking about
the matz ruby interpreter itself. In some instances, not only would
the user need all of the gems, but they'd need a 1.9 ruby too...that a
big commitment to run a mail client.
[As a side note, Debian/Ubuntu do package many of the gems, but it's a
round hole, square peg affair.]
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090608/33159422/attachment-0001.bin>
------------------------------
Message: 330
Date: Mon, 8 Jun 2009 16:03:58 -0400
From: Joe W?lfel <joe@talkhouse.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Can't seem to send mail
Message-ID: <B9FE7468-E096-4E40-A6E8-37372F266EA2@talkhouse.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
On Jun 8, 2009, at 2:44 PM, Ben Walton wrote:
> Excerpts from Joe W?lfel's message of Mon Jun 08 14:05:34 -0400 2009:
>> It looks like sendmail isn't functioning and doesn't generate any
>> errors. Maybe it's a mac problem. I haven't tried it on anything
>> else yet.
>
> Personally, I don't think sendmail has _ever_ been functional, but
> that's just the grumpy side of me that has to configure it on clunky
> old boxes still! :)
>
> It's likely working, but has a local delivery setup configured. Try
> using `mailq` to see if anything is sitting in the outbound queue.
> You may also want to look in /var/spool/mail for mbox files sitting
> there with the messages (or bounces) sent from sup.
>
> If you want to get your hands dirty, I recommend exim as the
> replacment for sendmail. I like it's configuration and acl setup
> better than postfix, but that would also work. If you just want to
> send mail quickly and easily, try msmtp or a similar package.
Thanks. Looks like msmtp did the trick. Debugging sendmail was more
than I cared to take on.
------------------------------
Message: 331
Date: Mon, 8 Jun 2009 16:53:42 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Can't seem to send mail
Message-ID:
<80055d7c0906081353s276ed18o156f12d8df981e28@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
> Thanks. ?Looks like msmtp did the trick. ?Debugging sendmail was more than I
Yeah, it sure is scary. Glad that helped.
Cheers,
-AT
------------------------------
Message: 332
Date: Mon, 08 Jun 2009 14:34:31 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Attempt at reply-from hook
Message-ID: <1244496654-sup-5759@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Edward Z. Yang's message of 2009-06-05:
> Great! My hook works now. This is the sort of functionality that I
> think is worth generalizing and implementing as a configuration
> twiddle (one, I think, that should be on by default.)
I have a strong preference for hooks over configuration variables. Look
at the .muttrc documentation for why.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 333
Date: Mon, 08 Jun 2009 17:59:39 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Attempt at reply-from hook
Message-ID: <1244498316-sup-1297@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Mon Jun 08 17:34:31 -0400 2009:
> I have a strong preference for hooks over configuration variables. Look
> at the .muttrc documentation for why.
There's an interesting usability argument there. Right now, I still (possibly
naively) believe that if you organize your configuration properly, you can
have an arbitrarily large amount of it.
What's your opinion on making this default behavior, with no configuration
twiddle?
Cheers,
Edward
------------------------------
Message: 334
Date: Mon, 08 Jun 2009 19:09:16 -0400
From: Marc Hartstein <marc.hartstein@alum.vassar.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Attempt at reply-from hook
Message-ID: <1244502124-sup-7043@cabinet>
Content-Type: text/plain; charset="utf8"
Excerpts from Edward Z. Yang's message of Mon Jun 08 17:59:39 -0400 2009:
> What's your opinion on making this default behavior, with no configuration
> twiddle?
Reading the thread, it's not clear exactly what your hook does, or what
behavior you want as the default. I didn't see anything which said what
you were trying to accomplish.
Attempting to figure it out from your code samples, I'm guessing that
you're trying to get sup to always reply with a from address of the
known address of yours found in the recipient list of the email being
relied to, if any?
If so, I accomplish that with:
-----------------------------------%<-----------------------------------
# Reply with the address they used for me if it's an account of mine
if(b = (message.to + message.cc).find { |p| AccountManager.is_account? p })
b
else
AccountManager.default_account
end
-----------------------------------%<-----------------------------------
My opinion is that this is a common enough need that it should be
provided in the set of example hooks with the distribution, and/or in a
hook cookbook on the wiki.
I do get the sense that there might be a lot of people out there who
want to use the default (always use default account) behavior, so I'm
not sure about switching the default. I wouldn't exactly be against it,
though.
Sorry if I'm misinterpreting what you've been trying to do. I didn't
see any direct mention of the goal in the thread.
Marc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090608/e2c396cd/attachment-0001.bin>
------------------------------
Message: 335
Date: Mon, 08 Jun 2009 19:14:32 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup annoyances
Message-ID: <1244502545-sup-9840@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Mon Jun 08 14:00:23 -0400 2009:
> It might not be too bad. Turn off the call to m.load_from_source! on
> line 106 of thread-index-mode.rb, add a Queue to ThreadViewMode
> containing messages to call #load_from_source! on, don't call m.chunks
> in ThreadViewMode#regen_text unless the message has been loaded, start a
> thread that pops messages from the queue, calls #load_from_source! on
> them, and then calls regen_text when an open message has been loaded...
> and you're 90% of the way there.
A few questions:
* How do I tell if a message is shown on the screen or not?
* The implementation you describe still downloads the messages
sequentially, which are usually not the messages we want to download
first. I don't mind sup blocking on downloading a message, as long
as it's one or two, which means I don't strictly need threads: I
just need some API for, when a new message is opened, downloading it
and then rendering it. What do you think of this?
> The auto-completion is awesome. Adding a recipient to the contacts list is
> a good idea.
Does contacts.rb apply to people.txt or contacts.txt?
> It's definitely worse than O(n). Loading threads could be sped up
> dramatically by storing the thread structure somewhere (either cached or
> just for every thread), since Sup does a lot of extra work rethreading
> everything every time you start it up. FWIW I'm doing this the right way
> in Sup 2.0.
Can you backport it easily to Sup 1.0?
> There have been a couple similar requests like this recently, though
> it's not clear if everyone has known about the ability to change the
> reply mode and about the reply-to hook. Since hitting 'r' defaults to
> replying to the sender alone (except for mailing list messages), I'd be
> ok with adding a Mutt-style reply-to-all key that starts up reply-mode
> with the 'reply to all' mode active.
The explicit prompt makes me think about who I want to send the message
to. I frequently forget to move the little knob with Sup's behavior.
Cheers,
Edward
------------------------------
Message: 336
Date: Mon, 08 Jun 2009 16:46:39 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup annoyances
Message-ID: <1244503985-sup-8587@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Edward Z. Yang's message of 2009-06-08:
> * How do I tell if a message is shown on the screen or not?
If m is the message, @layout[m].state will be :open, :detailed or
:closed. If it's not :closed, it is visible.
> * The implementation you describe still downloads the messages
> sequentially, which are usually not the messages we want to download
> first.
Only if you add them to the Queue sequentially. You could instead add
the ones with :unread or :starred labels first. And ideally if you
expand a collapsed unloaded message, that should be pushed to the head
of the Queue.
> I don't mind sup blocking on downloading a message, as long
> as it's one or two, which means I don't strictly need threads: I
> just need some API for, when a new message is opened, downloading it
> and then rendering it. What do you think of this?
So you would only preload the new/starred ones, and load the others only
when they're expanded? I think that simply removing that call in
thread-index-mode.rb would accomplish this.
I'd rather have the threaded version, since loading a thread of 100 new
messages sucks, but either way would be an improvement.
> > The auto-completion is awesome. Adding a recipient to the contacts
> > list is a good idea.
>
> Does contacts.rb apply to people.txt or contacts.txt?
contacts.txt. people.txt is deprecated. In fact I'm surprised you have
one.
> > It's definitely worse than O(n). Loading threads could be sped up
> > dramatically by storing the thread structure somewhere (either
> > cached or just for every thread), since Sup does a lot of extra work
> > rethreading everything every time you start it up. FWIW I'm doing
> > this the right way in Sup 2.0.
>
> Can you backport it easily to Sup 1.0?
No, it's completely different. It would be easier to rewrite from
scratch for the existing Sup.
> The explicit prompt makes me think about who I want to send the
> message to. I frequently forget to move the little knob with Sup's
> behavior.
When do you want it to prompt you? Is this a yes/no prompt?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 337
Date: Mon, 08 Jun 2009 20:12:44 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Attempt at reply-from hook
Message-ID: <1244506097-sup-8895@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from Marc Hartstein's message of Mon Jun 08 19:09:16 -0400 2009:
> Reading the thread, it's not clear exactly what your hook does, or what
> behavior you want as the default. I didn't see anything which said what
> you were trying to accomplish.
My apologies.
My sup email comes from three distinct sources, and as part of my
configuration they get a label as such (mit, twp or ita). This label
is the most visible way of telling me which source my mail came from.
I am subscribed to numerous mailing lists, however, which do not
explicitly list my mail address in To or CC. As a result, Sup defaults
to my "main address".
What I would like Sup to do is look at the label, find the appropriate
source, and use the email in the source to populate the From field.
This is different from what you describe below.
> Attempting to figure it out from your code samples, I'm guessing that
> you're trying to get sup to always reply with a from address of the
> known address of yours found in the recipient list of the email being
> relied to, if any?
If Sup doesn't do the correct thing in this case, this additional hook
would be useful.
> I do get the sense that there might be a lot of people out there who
> want to use the default (always use default account) behavior, so I'm
> not sure about switching the default. I wouldn't exactly be against it,
> though.
I would argue that most people have at least a personal and a work
email account, and that it is not appropriate to conflate the two.
They can write a hook that overrides an address (or, horror horror,
a twiddle in sources) to do it.
Cheers,
Edward
------------------------------
Message: 338
Date: Mon, 8 Jun 2009 17:37:53 -0700
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] Gmail Labels Sidebar
Message-ID:
<80055d7c0906081737s4dd3e205t2f3e69423ef48e17@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hello there,
As some of you probably remember, there is a handy sidebar in Gmail
which lists your tags and how many e-mails you have in each one.
What I do with this is have e-mail skip my inbox, get a mailing list
tag applied to it, and then get archived, at which point it shows up
in my labels sidebar. I have my "important" mail in my inbox, and the
mailing lists with updates are clearly marked.
Any suggestions as to what sup users do to have this kind of workflow?
It's preferable for me because it keeps things tidy, I can see the new
mails, and I get >50 e-mails per day. It'd be a shame to have them all
fall into my inbox and spam it up, which I prefer to keep clean for
"needs to be taken care of immediately" type e-mail.
Thanks,
-AT
------------------------------
Message: 339
Date: Mon, 08 Jun 2009 21:05:06 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Gmail Labels Sidebar
Message-ID: <1244509454-sup-1208@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Andrei Thorp's message of Mon Jun 08 20:37:53 -0400 2009:
> Any suggestions as to what sup users do to have this kind of workflow?
> It's preferable for me because it keeps things tidy, I can see the new
> mails, and I get >50 e-mails per day. It'd be a shame to have them all
> fall into my inbox and spam it up, which I prefer to keep clean for
> "needs to be taken care of immediately" type e-mail.
Use the Label view. Hit L followed by enter.
HTH
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090608/563b1ece/attachment-0001.bin>
------------------------------
Message: 340
Date: Mon, 08 Jun 2009 22:13:17 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup annoyances
Message-ID: <1244506405-sup-5117@javelin>
Content-Type: text/plain; charset=UTF-8
Thanks for the answers to the technical questions.
Excerpts from William Morgan's message of Mon Jun 08 19:46:39 -0400 2009:
> So you would only preload the new/starred ones, and load the others only
> when they're expanded? I think that simply removing that call in
> thread-index-mode.rb would accomplish this.
>
> I'd rather have the threaded version, since loading a thread of 100 new
> messages sucks, but either way would be an improvement.
I am somewhat skeptical of your described change, but I will try it
out and report back. The threaded version would certainly be a nice
thing.
> contacts.txt. people.txt is deprecated. In fact I'm surprised you have
> one.
Um... my contacts.txt is empty, and people.txt has lots of entries in it.
> No, it's completely different. It would be easier to rewrite from
> scratch for the existing Sup.
Savvy.
> > The explicit prompt makes me think about who I want to send the
> > message to. I frequently forget to move the little knob with Sup's
> > behavior.
>
> When do you want it to prompt you? Is this a yes/no prompt?
Yes. (to yes/no).
Cheers,
Edward
------------------------------
Message: 341
Date: Mon, 08 Jun 2009 22:14:30 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Gmail Labels Sidebar
Message-ID: <1244513641-sup-360@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from Ben Walton's message of Mon Jun 08 21:05:06 -0400 2009:
> Use the Label view. Hit L followed by enter.
I think what he's looking for is the information about his labels
to always be present, as opposed to something he has to remind
himself to check.
Cheers,
Edward
------------------------------
Message: 342
Date: Mon, 08 Jun 2009 22:23:44 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup annoyances
Message-ID: <1244514081-sup-2943@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from Edward Z. Yang's message of Mon Jun 08 22:13:17 -0400 2009:
> I am somewhat skeptical of your described change, but I will try it
> out and report back. The threaded version would certainly be a nice
> thing.
It works, although it acts a bit strangely when there are still
threads loading into memory.
>From b2518f113118e489e22a1c2085b33a9c18721f97 Mon Sep 17 00:00:00 2001
From: Edward Z. Yang <edwardzyang@thewritingpot.com>
Date: Mon, 8 Jun 2009 22:21:01 -0400
Subject: [PATCH] Remove message pre-loading; optimizes for the common case.
Signed-off-by: Edward Z. Yang <edwardzyang@thewritingpot.com>
---
lib/sup/modes/thread-index-mode.rb | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb
index 9b44ee3..29de39a 100644
--- a/lib/sup/modes/thread-index-mode.rb
+++ b/lib/sup/modes/thread-index-mode.rb
@@ -103,7 +103,6 @@ EOS
t.each_with_index do |(m, *o), i|
next unless m
BufferManager.say "#{message} (#{i}/#{num})", sid if t.size > 1
- m.load_from_source!
end
end
mode = ThreadViewMode.new t, @hidden_labels, self
--
1.6.0.4
------------------------------
Message: 343
Date: Mon, 08 Jun 2009 22:24:42 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Gmail Labels Sidebar
Message-ID: <1244514031-sup-2335@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Edward Z. Yang's message of Mon Jun 08 22:14:30 -0400 2009:
> I think what he's looking for is the information about his labels
> to always be present, as opposed to something he has to remind
> himself to check.
So something similar to the folder view hack/patch for mutt? That
doesn't exist in sup. The closest you get is having the 'All Labels'
buffer open. You can jump to a view of all messages with that label
by hitting enter on the selected label. Moving back to it is simple
with the buffer rolling keys. I believe that some people operate from
this buffer instead of the inbox one. Not my cup of tea though.
HTH.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090608/a9e55e8a/attachment-0001.bin>
------------------------------
Message: 344
Date: Mon, 08 Jun 2009 22:35:04 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup annoyances
Message-ID: <1244514851-sup-1414@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from Edward Z. Yang's message of Mon Jun 08 22:23:44 -0400 2009:
> It works, although it acts a bit strangely when there are still
> threads loading into memory.
I think I've been able to pin down this behavior more precisely,
and it's not just this patches fault: displaying messages seems to
block on having all of the threads present. Does this ring a bell?
Cheers,
Edward
------------------------------
Message: 345
Date: Mon, 08 Jun 2009 22:38:08 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup annoyances
Message-ID: <1244515056-sup-4758@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Mon Jun 08 14:00:23 -0400 2009:
> > 3. Polling and loading of threads should started, asynchronously, at
> > the same time.
>
> > Loading of threads should not hose my CPU.
>
> Agreed. Please fix.
It appears that polling blocks on loading threads, so it doesn't help
to fix that until we fix the thread loading code.
Cheers,
Edward
------------------------------
Message: 346
Date: Mon, 08 Jun 2009 23:00:55 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup annoyances
Message-ID: <1244515897-sup-539@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Mon Jun 08 14:00:23 -0400 2009:
> It's definitely worse than O(n). Loading threads could be sped up
> dramatically by storing the thread structure somewhere (either cached or
> just for every thread), since Sup does a lot of extra work rethreading
> everything every time you start it up. FWIW I'm doing this the right way
> in Sup 2.0.
I'm thinking about how to do this, and one of the first I'm blockers
I'm running against is that it's not quite obvious what's invoking
the thread building code thread.rb.
As for caching the thread, I'm thinking of generating a unique
ID for each thread and sticking that on every message. Whether or
not this will actually help depends a lot on what the answer to the
above question is.
Cheers,
Edward
------------------------------
Message: 347
Date: Mon, 08 Jun 2009 23:46:48 -0400
From: Marc Hartstein <marc.hartstein@alum.vassar.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Attempt at reply-from hook
Message-ID: <1244518550-sup-6361@cabinet>
Content-Type: text/plain; charset="utf8"
Excerpts from Edward Z. Yang's message of Mon Jun 08 20:12:44 -0400 2009:
> What I would like Sup to do is look at the label, find the appropriate
> source, and use the email in the source to populate the From field.
> This is different from what you describe below.
Ah, got it. That would be useful.
I think that's beyond what I'd personally think of as a "configuration
twiddle", though...
You'd do it by, what, having a 1:1 mapping between email addresses and
labels somewhere in the configuration, anything coming to the email
address gets the label, and any reply to a message with the label
(however it got it) gets the email address?
Maybe I'm just still not following your vision.
> I would argue that most people have at least a personal and a work
> email account, and that it is not appropriate to conflate the two.
> They can write a hook that overrides an address (or, horror horror,
> a twiddle in sources) to do it.
Well, that's certainly my situation. It's possible that most of the
people who'd want to conflate everything aren't the sort of people who'd
want to use sup. I certainly wouldn't argue against making the behavior
I prefer the default and letting other people override it with a hook.
;)
(It's also not as though the hook to only use your default address is
hard to write.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090608/6c709182/attachment-0001.bin>
------------------------------
Message: 348
Date: Tue, 09 Jun 2009 00:06:40 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Attempt at reply-from hook
Message-ID: <1244519893-sup-7418@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from Marc Hartstein's message of Mon Jun 08 23:46:48 -0400 2009:
> I think that's beyond what I'd personally think of as a "configuration
> twiddle", though...
Perhaps.
> You'd do it by, what, having a 1:1 mapping between email addresses and
> labels somewhere in the configuration, anything coming to the email
> address gets the label, and any reply to a message with the label
> (however it got it) gets the email address?
Yes.
> (It's also not as though the hook to only use your default address is
> hard to write.)
Indeed.
Cheers,
Edward
------------------------------
Message: 349
Date: Tue, 09 Jun 2009 13:00:13 +0300
From: Tarko Tikan <tarko@lanparty.ee>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] display_length issue with special-characters on
non-UTF8 terminal
Message-ID: <1244536704-sup-7027@valgus>
Content-Type: text/plain; charset=ISO-8859-15
hey,
When String.display_length was introduced in recent update, it broke the length for non-UTF8 strings that contain the special characters. Wrong length results corrupted display (line ends chopped off).
Terminal is iso-8859-15 and it's detected by sup correctly.
I've tracked it down to /./u regexp. Here are some examples:
irb(main):001:0> "asd".scan(/./u)
=> ["a", "s", "d"]
irb(main):002:0> "asd????".scan(/./u)
=> ["a", "s", "d", "\365\374\344\366"]
irb(main):017:0> "asd???".scan(/./u)
=> ["a", "s", "d"]
irb(main):008:0* "asd".scan(/./)
=> ["a", "s", "d"]
irb(main):009:0> "asd????".scan(/./)
=> ["a", "s", "d", "\365", "\374", "\344", "\366"]
Expecting UTF8 gives unexpected results :) Also, old behaviour of String.length gives correct results with these test cases.
--
tarko
------------------------------
Message: 350
Date: Tue, 9 Jun 2009 09:33:15 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Gmail Labels Sidebar
Message-ID:
<80055d7c0906090633t2a7aecd6i30578a9976697e4e@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Yeah, I guess that makes sense. It is a rather nice interface
actually, I didn't really think about it for some reason.
And I guess there are probably some configuration options to skip
inbox and attach labels to stuff matching stuff automatically, with
procmail. I think I saw a page about that somewhere.
I guess there is probably a way to programatically access this kind of
information also, but are there any command line tools I can use to
query for this kind of stuff? If so, I can hack my window manager's
panels to display the mails in these labels, which would be pretty
rad. (My WM is "Awesome" btw -- that's the name.)
Any suggestions for quickly getting this labels-has-unread-messages
info outside of sup?
Thanks guys! :)
-AT
------------------------------
Message: 351
Date: Tue, 9 Jun 2009 09:42:29 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Gmail Labels Sidebar
Message-ID:
<80055d7c0906090642h421964f2t41d52290042469bc@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Tue, Jun 9, 2009 at 9:33 AM, Andrei Thorp<garoth@gmail.com> wrote:
> Yeah, I guess that makes sense. It is a rather nice interface
> actually, I didn't really think about it for some reason.
I just actually ran a quick test (with 0.8) and it looks like the
label-list-mode fails to update automatically D:
What I did was put on the label-list-mode, manually send myself an
e-mail, re-run fetchmail to grab it (I get a notification via procmail
saying it came in). Then I remember that sup polls at intervals, so I
wait.
Eventually, the status bar at the bottom says that there is a new
message in the inbox, but the Inbox label does not get updated in my
view. It still says 0/0.
I press x to go back to the inbox screen, it has the mail. I go back
to label-list-mode, and now it registers it.
So I guess I'd call that a bug actually, and it's unlikely that people
operate out of this mode habitually or else this would have probably
been found.
(Unless it already has?)
Cheers,
-AT
------------------------------
Message: 352
Date: Tue, 09 Jun 2009 15:11:08 +0100
From: Marcus Williams <marcus-sup@bar-coded.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Gmail Labels Sidebar
Message-ID: <1244556424-sup-1426@tomsk>
Content-Type: text/plain; charset="utf-8"
On 9.6.2009, Andrei Thorp wrote:
> Any suggestions for quickly getting this labels-has-unread-messages
> info outside of sup?
Attached is a labels mode outside of sup... Useful for conky etc. Just
pipe the output to a file (warnings errors etc wont go to the file)
William - if you want to add this to sup/bin feel free. Its basically
the regen_text method lifted and edited slightly from the
label-list-mode
It might need a few more tweaks - I'm not sure it needs to
load/save/unlock the index really. They're there because they came for
free with the copy and paste of bin/sup-tweak-labels :)
Marcus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sup-list-labels
Type: application/octet-stream
Size: 1773 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090609/344b333b/attachment-0001.obj>
------------------------------
Message: 353
Date: Tue, 09 Jun 2009 15:24:35 +0100
From: Marcus Williams <marcus-sup@bar-coded.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Gmail Labels Sidebar
Message-ID: <1244557461-sup-4140@tomsk>
Content-Type: text/plain; charset=utf-8
On 9.6.2009, I wrote:
> On 9.6.2009, Andrei Thorp wrote:
> > Any suggestions for quickly getting this labels-has-unread-messages
> > info outside of sup?
>
> Attached is a labels mode outside of sup... Useful for conky etc. Just
> pipe the output to a file (warnings errors etc wont go to the file)
Oh and I forgot - if you want to kick off sup from a click on one of
these labels (assuming you can do something like that in your WM) you
can call sup with --search "label:somelabel" to get that label
displayed.
Marcus
------------------------------
Message: 354
Date: Tue, 09 Jun 2009 15:29:55 +0100
From: Marcus Williams <marcus-sup@bar-coded.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Gmail Labels Sidebar
Message-ID: <1244557672-sup-7417@tomsk>
Content-Type: text/plain; charset=utf-8
On 9.6.2009, I wrote:
> William - if you want to add this to sup/bin feel free. Its basically
> the regen_text method lifted and edited slightly from the
> label-list-mode
You might want to delete lines 24-26 as well to save the warning about
uninitialised variable. At some point I'll post my version with a
query which is a little less hurried, but doesnt work quite how I want
yet.
Marcus
------------------------------
Message: 355
Date: Tue, 9 Jun 2009 10:37:54 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] Fwd: Gmail Labels Sidebar
Message-ID:
<80055d7c0906090737g46f9f3b3y7ee00b91dbe08f22@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
> Oh and I forgot - if you want to kick off sup from a click on one of
> these labels (assuming you can do something like that in your WM) you
> can call sup with --search "label:somelabel" to get that label
> displayed.
Damn, that's a great idea! I didn't even think about that.
/me checks up on what else sup has in its cli flags.
Cheers,
-AT
PS.
Well, while I'm here, I guess I'll also mention this fairly obvious
script line that just outputs the unread messages in a filtered list:
sup-list-labels 2> /dev/null | grep -E "Inbox|Sent" | sed -r "s/^
*([A-Za-z]*).* ([0-9]+) unread/\1: \2/"
So to go through this:
?- Pipe the stderr to /dev/null (we don't want to see the messages)
?- grep for either "Inbox" or "Sent" -- you can put lots more |blah|blah there
?- sed magic to extract and reformat the data
This might be useful for outputting somewhere like in a shell prompt or panel.
PPS. argh, still not using sup for this mailing list so I replied to
an individual. Forwarded D:
PPPS. Sorry that it wrapped my sed command there, but I'm sure you get the idea.
PPPPS. Sorry about the unfashionable amount of PSes ;)
------------------------------
Message: 356
Date: Tue, 09 Jun 2009 09:52:37 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Attempt at reply-from hook
Message-ID: <1244565962-sup-4211@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Marc Hartstein's message of 2009-06-08:
> I think that's beyond what I'd personally think of as a "configuration
> twiddle", though...
I tend to agree. I completely understand the use case, and I agree it's
probably a common one, but this is exactly the kind of thing I want to
address with hooks instead of with configuration. (Not that there's
*really* a distinction between these two things in the first place.)
Then when the next guy comes along and says, "I like this but I want my
from address based on X instead of the label", I can also avoid having
to do any work.
Edward, if you want to invest time on making this particular scheme easy
for users, I would be happy to include contributed hooks as part of the
Sup distribution, and you can supply one that reads a simple
configuration file and produces this behavior.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 357
Date: Tue, 09 Jun 2009 10:32:53 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup annoyances
Message-ID: <1244567126-sup-1563@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Edward Z. Yang's message of 2009-06-08:
> Excerpts from William Morgan's message of Mon Jun 08 19:46:39 -0400 2009:
> > contacts.txt. people.txt is deprecated. In fact I'm surprised you have
> > one.
>
> Um... my contacts.txt is empty, and people.txt has lots of entries in it.
Does your people.txt have a really old timestamp? That file doesn't get
touched by any version of Sup later less than three months old.
Do you add people to your contact list with 'i'? If not, contacts.txt
will be empty.
> > When do you want it to prompt you? Is this a yes/no prompt?
>
> Yes. (to yes/no).
So... once you write the email and you press 'y' it prompts you whether
you want to send it? Or when you press 'r' it prompts you whether you
really want to reply?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 358
Date: Tue, 09 Jun 2009 10:40:38 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup annoyances
Message-ID: <1244569129-sup-4112@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Edward Z. Yang's message of 2009-06-08:
> I think I've been able to pin down this behavior more precisely,
> and it's not just this patches fault: displaying messages seems to
> block on having all of the threads present. Does this ring a bell?
Not entirely sure what you mean by "having all the threads present", but
opening a thread-view-mode buffer doesn't block on anything, at least
with that patch applied. Without the patch, it blocks on loading the
message body for every message in that particular thread from the
server.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 359
Date: Tue, 09 Jun 2009 10:45:45 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup annoyances
Message-ID: <1244569341-sup-7836@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Edward Z. Yang's message of 2009-06-08:
> Excerpts from William Morgan's message of Mon Jun 08 14:00:23 -0400 2009:
> > > 3. Polling and loading of threads should started, asynchronously,
> > > at the same time.
> >
> > > Loading of threads should not hose my CPU.
> >
> > Agreed. Please fix.
>
> It appears that polling blocks on loading threads, so it doesn't help
> to fix that until we fix the thread loading code.
My "agreed, please fix" was in response to "loading of threads should
not hose my CPU".
Polling currently blocks on loading threads, but that's an explicit
block. I forget why I did that now. You can unblock it and see if it
makes life better. (bin/sup circa line 205.)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 360
Date: Tue, 09 Jun 2009 10:48:59 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup annoyances
Message-ID: <1244569567-sup-7515@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Edward Z. Yang's message of 2009-06-08:
> From: Edward Z. Yang <edwardzyang@thewritingpot.com>
> Date: Mon, 8 Jun 2009 22:21:01 -0400
> Subject: [PATCH] Remove message pre-loading; optimizes for the common case.
The problem with this patch as is is that loading a large thread
composed of entirely new messages still requires loading all the message
bodies from the server, which can take a couple seconds, but now there's
no indication of what's happening. So either the fancy background
loading needs to happen, or somehow a message needs to be displayed when
the bodies are being loaded.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 361
Date: Tue, 09 Jun 2009 20:55:45 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: Sup Mailing List <sup-talk@rubyforge.org>
Subject: [sup-talk] lockmanager
Message-ID: <1244595206-sup-6689@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Hi William,
I've attached the base LockManager class that I'm envisioning for
sup. It's still rough, but the basic functionality is in place. I
think it should stand up to the potential contention between
PollManager and SentManager. If it looks reasonable, I'll flesh it
out with some timeouts and exception handling.
Let me know.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lock.rb
Type: application/octet-stream
Size: 3575 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090609/e56ad52c/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090609/e56ad52c/attachment-0001.bin>
------------------------------
Message: 362
Date: Wed, 10 Jun 2009 01:44:54 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] [PATCH] before-search hook
Message-ID: <1244612627-sup-982@javelin>
Content-Type: text/plain; charset=UTF-8
>From a5c72844e8195df7a8eabd5ea592507599de72cb Mon Sep 17 00:00:00 2001
From: Edward Z. Yang <edwardzyang@thewritingpot.com>
Date: Wed, 10 Jun 2009 01:42:50 -0400
Subject: [PATCH] Add before-search hook, for shortcuts for custom search queries.
Signed-off-by: Edward Z. Yang <edwardzyang@thewritingpot.com>
---
lib/sup/hook.rb | 4 ++++
lib/sup/index.rb | 12 +++++++++++-
2 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/lib/sup/hook.rb b/lib/sup/hook.rb
index 0a0a2f6..d446aa3 100644
--- a/lib/sup/hook.rb
+++ b/lib/sup/hook.rb
@@ -19,6 +19,10 @@ class HookManager
attr_writer :__locals
+ ## an annoying gotcha here is that if you try something
+ ## like var = var.foo(), var will magically get allocated
+ ## to Nil and method_missing will never get called. Stick
+ ## to mutation, kiddos!
def method_missing m, *a
case @__locals[m]
when Proc
diff --git a/lib/sup/index.rb b/lib/sup/index.rb
index e403570..19556f0 100644
--- a/lib/sup/index.rb
+++ b/lib/sup/index.rb
@@ -25,6 +25,13 @@ class Index
include Singleton
+ HookManager.register "before-search", <<EOS
+Executes before a string search is applied to the index.
+Variables:
+ subs: The string being searched, use gsub! to change the
+ search (you must use mutation!)
+EOS
+
## these two accessors should ONLY be used by single-threaded programs.
## otherwise you will have a naughty ferret on your hands.
attr_reader :index
@@ -508,7 +515,10 @@ protected
def parse_user_query_string s
extraopts = {}
- subs = s.gsub(/\b(to|from):(\S+)\b/) do
+ subs = String.new s
+ HookManager.run("before-search", :subs => subs)
+
+ subs = subs.gsub(/\b(to|from):(\S+)\b/) do
field, name = $1, $2
if(p = ContactManager.contact_for(name))
[field, p.email]
--
1.6.0.4
------------------------------
Message: 363
Date: Wed, 10 Jun 2009 11:19:48 -0400
From: Marc Hartstein <marc.hartstein@alum.vassar.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] sup -c while sup is running?
Message-ID: <1244646784-sup-7039@cabinet>
Content-Type: text/plain; charset="utf8"
How difficult would it be to allow sup -c to be run while sup is already
running? The goal would be to be able to use sup as a mailto: handler
effectively.
How deep does the need to lock the index run?
Might it work to set something up which is effectively compose mode
only?
I suppose I could use mutt for composing from mailto:s and find a way to
set it up to make sure sup knows about the sent mail, but that would
seem to introduce a lot of extra configuration and opportunities for
confusion.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090610/a6dfc07b/attachment-0001.bin>
------------------------------
Message: 364
Date: Wed, 10 Jun 2009 13:21:58 -0400
From: Joe W?lfel <joe@talkhouse.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] IMAP alternative for Sup?
Message-ID: <1244654260-sup-7022@joe-wolfels-power-mac-g5.local>
Content-Type: text/plain; charset=UTF-8
I am using sup with IMAP. I connect via multiple accounts using multiple
machines. This is not surprisingly very slow. Is there an IMAP alternative
that caches all messages locally that is not too complicated to setup with Sup?
Thanks,
Joe
------------------------------
Message: 365
Date: Wed, 10 Jun 2009 13:25:08 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] IMAP alternative for Sup?
Message-ID: <1244654688-sup-4183@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from Joe W?lfel's message of Wed Jun 10 13:21:58 -0400 2009:
> I am using sup with IMAP. I connect via multiple accounts using multiple
> machines. This is not surprisingly very slow. Is there an IMAP alternative
> that caches all messages locally that is not too complicated to setup with Sup?
The solution commonly recommended is OfflineImap. I have not tried this myself.
Cheers,
Edward
------------------------------
Message: 366
Date: Wed, 10 Jun 2009 10:42:34 -0400
From: Joe W?lfel <joe@talkhouse.com>
To: Sup Mailing List <sup-talk@rubyforge.org>
Subject: [sup-talk] IMAP alternative works well with sup?
Message-ID: <1244644197-sup-9224@joe-wolfels-power-mac-g5.local>
Content-Type: text/plain; charset=UTF-8
I've been using sup with IMAP and retrieving messages from 3rd party providers
is not surprisingly slow. Is there a good alternative that will cache messages
locally that isn't complicated to setup with sup? I use multiple machines with
multiple accounts.
Thanks,
Joe
------------------------------
Message: 367
Date: Wed, 10 Jun 2009 19:50:49 +0200
From: J?rg-Hendrik Bach <bachjh@googlemail.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] sup and ncursesw
Message-ID:
<91de50e10906101050p2d23a74cy1bbfe2e80e69cca2@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
I recently installed sup 0.8 and find I am having problems with umlauts and
accented characters. There is a patch for the ncurses-0.9.1 gem on the sup
wiki ("utf8-issues") which allows the characters to be displayed correctly,
but after applying the patch I can't enter proper text. Hitting 'c' for
compose works, but entering '123' for subject ends in a subject line such
as:
Subject: P<85>??P<85>???C" ?C"
(it's a different set of confused characters each time)
Similar when searching for messages using '\' or 'L'.
I am on ubuntu 9.04 with libncursesw5{,-dev} version 5.7+20090207, sup 0.8.
Any hints?
cheers,
- J?rg-Hendrik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090610/aa0a2b51/attachment-0001.html>
------------------------------
Message: 368
Date: Wed, 10 Jun 2009 17:51:01 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] before-search hook
Message-ID: <1244670591-sup-7078@javelin>
Content-Type: text/plain; charset=UTF-8
For the curious, here is the hook that I'm using with this:
subs.gsub!(/\bmy:unread\b/) do
"is:unread !label:inbox"
end
Cheers,
Edward
------------------------------
Message: 369
Date: Wed, 10 Jun 2009 23:18:46 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup annoyances
Message-ID: <1244690240-sup-884@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Tue Jun 09 13:40:38 -0400 2009:
> Not entirely sure what you mean by "having all the threads present", but
> opening a thread-view-mode buffer doesn't block on anything, at least
> with that patch applied. Without the patch, it blocks on loading the
> message body for every message in that particular thread from the
> server.
Yeah. I mean what I mean: it *shouldn't* block on anything, but as
far as I can tell from manual testing, thread-view-mode doesn't open
up until I'm done threading the index. Maybe that's why.
Cheers,
Edward
------------------------------
Message: 370
Date: Wed, 10 Jun 2009 23:19:32 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup annoyances
Message-ID: <1244690337-sup-2840@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Tue Jun 09 13:48:59 -0400 2009:
> The problem with this patch as is is that loading a large thread
> composed of entirely new messages still requires loading all the message
> bodies from the server, which can take a couple seconds, but now there's
> no indication of what's happening. So either the fancy background
> loading needs to happen, or somehow a message needs to be displayed when
> the bodies are being loaded.
Understood. There's also another odd bug where the headers for the open
messages "blow up" (get split into three lines each) which gets fixed
when you collapse and the expand the headers again.
Cheers,
Edward
------------------------------
Message: 371
Date: Wed, 10 Jun 2009 23:38:12 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Attempt at reply-from hook
Message-ID: <1244691413-sup-727@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Tue Jun 09 12:52:37 -0400 2009:
> Edward, if you want to invest time on making this particular scheme easy
> for users, I would be happy to include contributed hooks as part of the
> Sup distribution, and you can supply one that reads a simple
> configuration file and produces this behavior.
The thing is that this needs no configuration: sources.yaml will
tell us the correspondence between label and email. If anything,
I would bill this as an improvement to the "From" detection algorithm.
Cheers,
Edward
------------------------------
Message: 372
Date: Thu, 11 Jun 2009 10:05:38 +0100
From: Marcus Williams <marcus-sup@bar-coded.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Sup locking up
Message-ID: <1244710855-sup-1368@tomsk>
Content-Type: text/plain; charset=utf-8
Hi -
Something new has started happening in sup ? I think this is what
Edward was talking about, but it appears to lock up every now and
again in a way that it never used to.
Once its locked up it doesnt come back and I dont seem to be able to
ctrl-c/d/z out of it. Its only started in the last few days and I dont
think its my IMAP server.
Oddly its breaking my screen session as well which is odder still -
the screen with sup running is locked completely (I can create new
shells from screen and use them fine, its just the sup session within
screen).
Anyone else seeing this (running next branch)?
Marcus
------------------------------
Message: 373
Date: Thu, 11 Jun 2009 07:23:49 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup locking up
Message-ID: <1244719333-sup-9770@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Marcus Williams's message of Thu Jun 11 05:05:38 -0400 2009:
> Anyone else seeing this (running next branch)?
No...and I'm running from the most recent next with a few local
patches (message bouncing, currently). I run in screen as well.
Is there anything constant about when the lockup occurs? Has anything
else about your system/setup changed that could impact this?
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090611/8810e1f0/attachment-0001.bin>
------------------------------
Message: 374
Date: Thu, 11 Jun 2009 13:39:29 +0200
From: Fabio Riga <usul@aruba.it>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash after sending a message
Message-ID: <1244719933-sup-4261@viajero>
Content-Type: text/plain; charset=utf-8
Excerpts from Fabio Riga's message of Thu Jun 11 12:48:59 +0200 2009:
> a sup-sync, there are no Sent messages in index. Maybe it's a problem
> with locale (it) as sup-sync -a sup://sent gives me a lot of lines like:
>
> [Thu Jun 11 12:32:36 +0200 2009] found invalid date in potential mbox
> split line, not splitting: "From usul@aruba.it Thu Jun 11 11:45:37 +0200
> 2009\n"
> Scanned 14, added 0, updated 14 messages from sup://sent.
>
Hello again,
I translated with a script names of days and months in ~/.sup/sent.mbox,
then made a sup-sync -a sup://sent.mbox and run
$ LANG=C sup
All is fine, I just need to remember to launch sup this way. Maybe it
needs some work on localization?
Cheers,
Fabio
--
Fabio Riga
348 4458014 - fabio@comunicattiva.it
ComunicAttiva S.a.s. di Silvana D'Agata & C.
via Campestre,189 - Sesto San Giovanni (MI) - Italia
tel. 02 97373202 - fax 02 97373474
------------------------------
Message: 375
Date: Thu, 11 Jun 2009 09:17:12 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [BUG?] label-list-mode doesn't update
Message-ID:
<80055d7c0906110617j2b9a33cene229c1dd28170003@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
This is forwarded from the middle of another thread. I figured it got lost.
On Tue, Jun 9, 2009 at 9:33 AM, Andrei Thorp<garoth@gmail.com> wrote:
> Yeah, I guess that makes sense. It is a rather nice interface
> actually, I didn't really think about it for some reason.
I just actually ran a quick test (with 0.8) and it looks like the
label-list-mode fails to update automatically D:
What I did was put on the label-list-mode, manually send myself an
e-mail, re-run fetchmail to grab it (I get a notification via procmail
saying it came in). Then I remember that sup polls at intervals, so I
wait.
Eventually, the status bar at the bottom says that there is a new
message in the inbox, but the Inbox label does not get updated in my
view. It still says 0/0.
I press x to go back to the inbox screen, it has the mail. I go back
to label-list-mode, and now it registers it.
So I guess I'd call that a bug actually, and it's unlikely that people
operate out of this mode habitually or else this would have probably
been found.
(Unless it already has?)
Cheers,
-AT
------------------------------
Message: 376
Date: Thu, 11 Jun 2009 15:23:28 +0100
From: Marcus Williams <marcus-sup@bar-coded.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup locking up
Message-ID: <1244730053-sup-6905@tomsk>
Content-Type: text/plain; charset=utf-8
On 11.6.2009, Ben Walton wrote:
> No...and I'm running from the most recent next with a few local
> patches (message bouncing, currently). I run in screen as well.
Mmmmm. Strange.
> Is there anything constant about when the lockup occurs? Has anything
> else about your system/setup changed that could impact this?
I _think_ it occurs during a poll for new messages. Its difficult to
tell though because like I say that "window" in screen gets completely
blocked, only killing sup will get out of it (kill -9 rather than a
ctrl-c/z/d). Its very odd.
Nothing has changed on my box bar sup in recent weeks.
Marcus
------------------------------
Message: 377
Date: Thu, 11 Jun 2009 11:46:19 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup locking up
Message-ID: <1244735117-sup-6933@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Marcus Williams's message of Thu Jun 11 10:23:28 -0400 2009:
> I _think_ it occurs during a poll for new messages. Its difficult to
> tell though because like I say that "window" in screen gets completely
> blocked, only killing sup will get out of it (kill -9 rather than a
> ctrl-c/z/d). Its very odd.
Can you strace/truss/whatever the ruby process running sup to see what
it's doing?
> Nothing has changed on my box bar sup in recent weeks.
...ok. At least that rules out most external interference.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090611/7f2e26e6/attachment-0001.bin>
------------------------------
Message: 378
Date: Thu, 11 Jun 2009 13:58:26 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Sup locking up
Message-ID:
<80055d7c0906111058q128b5eb7na8931a8b75b0d0bf@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Yeah...
I have a theory. Have you learned some new stuff about screen lately?
Screen has this binding that pretty much makes it freeze up. I guess
I'm talking about http://savannah.gnu.org/bugs/?11610 which applies to
screen 4.0.0, which is the one people have.
Try maybe running sup out of screen for a while and see if it can happen then.
Another test: if screen locks up but sup respects regular kill (not
-9), sup's not locked up itself.
-AT
------------------------------
Message: 379
Date: Thu, 11 Jun 2009 20:09:19 +0100
From: Marcus Williams <marcus-sup@bar-coded.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup locking up
Message-ID: <1244747053-sup-4797@tomsk>
Content-Type: text/plain; charset=utf-8
On 11.6.2009, Andrei Thorp wrote:
> I have a theory. Have you learned some new stuff about screen lately?
> Screen has this binding that pretty much makes it freeze up. I guess
> I'm talking about http://savannah.gnu.org/bugs/?11610 which applies to
> screen 4.0.0, which is the one people have.
I dont think debian has this problem, although I may have hit ctrl-a
and then s by accident (I actually tried ctrl-q thinking that I had
hit ctrl-s by accident when it hung but nothing happened... forgetting
that I was in screen so would need to prepend ctrl-a). Its a bit wierd
that its happened to me recently and not before though if this is what
it was - I leave sup running in screen as it makes imap bearable and
havnt run into this problem until recently when its happened a couple
of times. I'll keep an eye on it and see if it happens again.
Marcus
------------------------------
Message: 380
Date: Thu, 11 Jun 2009 19:50:33 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] (no subject)
Message-ID: <1244764138-sup-2909@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset=UTF-8
Excerpts from Ben Walton's message of Sun Jun 07 20:02:25 -0400 2009:
Hi William,
> Here's a stab at implementing a message bouncing functionality worthy
> of being included on mainline.
Is there something you don't like about these patches or have you just
been too busy to look at them? I could collapse them into a single
patch, thus removing any trace of using $config instead of a Hook, to
keep the history cleaner if you'd prefer.
If there is something else you'd like to see changed before picking it
up, let me know.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
------------------------------
Message: 381
Date: Thu, 11 Jun 2009 12:48:59 +0200
From: Fabio Riga <usul@aruba.it>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Crash after sending a message
Message-ID: <1244717279-sup-5999@viajero>
Content-Type: text/plain; charset="utf-8"
Hi all,
First of all, Sup is a great peace of software because it's a superior and
simplified Mutt, it's fast, it isn't web-based (I hate web-based
client...) and... Well, great job!
I started using 0.7, with no problems at all, excepting those crappy
character on screen... Since upgrading to 0.8 my screen looks very nice,
but when I send a message, Sup crashes badly. It seems a problem
with Ferret failing indexing my Sent box (attached exception-log). After
a sup-sync, there are no Sent messages in index. Maybe it's a problem
with locale (it) as sup-sync -a sup://sent gives me a lot of lines like:
[Thu Jun 11 12:32:36 +0200 2009] found invalid date in potential mbox
split line, not splitting: "From usul@aruba.it gio giu 11 11:45:37 +0200
2009\n"
Scanned 14, added 0, updated 14 messages from sup://sent.
_My sent messages are much more then 14!_
Anyway, messages are sent before the crash.. like this one!
Ideas?
Thanks,
Fabio
--
Fabio Riga
348 4458014 - fabio@comunicattiva.it
ComunicAttiva S.a.s. di Silvana D'Agata & C.
via Campestre,189 - Sesto San Giovanni (MI) - Italia
tel. 02 97373202 - fax 02 97373474
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: exception-log.txt
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090611/fc505855/attachment-0001.txt>
------------------------------
Message: 382
Date: Thu, 11 Jun 2009 20:44:41 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] (no subject)
Message-ID: <1244778083-sup-4566@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Walton's message of 2009-06-11:
> Is there something you don't like about these patches or have you just
> been too busy to look at them?
Just been busy. Sorry! My Sup time tends to be very bursty. I realize
that's not great for contributors. Please have patience with your poor
maintainer and feel free to keep bugging me.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 383
Date: Fri, 12 Jun 2009 00:38:42 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup locking up
Message-ID: <1244781466-sup-4096@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from Ben Walton's message of Thu Jun 11 11:46:19 -0400 2009:
> Can you strace/truss/whatever the ruby process running sup to see what
> it's doing?
Seconded. You can attach strace to Sup while it's running, and it
will give you a good fingerprint for what the process is doing when
it locks up.
Cheers,
Edward
------------------------------
Message: 384
Date: Fri, 12 Jun 2009 09:15:05 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] (no subject)
Message-ID: <1244812410-sup-2627@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Thu Jun 11 23:44:41 -0400 2009:
> Reformatted excerpts from Ben Walton's message of 2009-06-11:
> > Is there something you don't like about these patches or have you just
> > been too busy to look at them?
>
> Just been busy. Sorry! My Sup time tends to be very bursty. I realize
> that's not great for contributors. Please have patience with your poor
> maintainer and feel free to keep bugging me.
No problem. You're just very quick to respond typically, so I wanted
to make sure that it hadn't fallen through the cracks...
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090612/0803c72a/attachment-0001.bin>
------------------------------
Message: 385
Date: Fri, 12 Jun 2009 09:21:11 -0400
From: Joe W?lfel <joe@talkhouse.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] IMAP alternative for Sup?
Message-ID: <1244812462-sup-9446@joe-wolfels-power-mac-g5.local>
Content-Type: text/plain; charset=UTF-8
Excerpts from Edward Z. Yang's message of Wed Jun 10 13:25:08 -0400 2009:
> Excerpts from Joe W?lfel's message of Wed Jun 10 13:21:58 -0400 2009:
> > I am using sup with IMAP. I connect via multiple accounts using multiple
> > machines. This is not surprisingly very slow. Is there an IMAP alternative
> > that caches all messages locally that is not too complicated to setup with Sup?
>
> The solution commonly recommended is OfflineImap. I have not tried this myself.
>
> Cheers,
> Edward
That did the trick. Now everything is instantaneous.
Also, I noticed that Sup's polling mechanism no longer locks up. With IMAP I
used to have to restart Sup on occasion. Now that doesn't seem to happen. I'm
not sure if that's relevant to the that other sup-talk thread on locking but
maybe it's helpful info .
Thanks,
Joe
------------------------------
Message: 386
Date: Fri, 12 Jun 2009 10:14:26 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] IMAP alternative for Sup?
Message-ID: <1244815945-sup-5020@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from Joe W?lfel's message of Fri Jun 12 09:21:11 -0400 2009:
> Also, I noticed that Sup's polling mechanism no longer locks up. With IMAP I
> used to have to restart Sup on occasion. Now that doesn't seem to happen. I'm
> not sure if that's relevant to the that other sup-talk thread on locking but
> maybe it's helpful info .
This is probably because OfflineIMAP polls more frequently. I've had good
results getting rid of the lock up by decreasing Sup's polling time (unfortunately
it's hard-coded in Sup).
Cheers,
Edward
------------------------------
Message: 387
Date: Fri, 12 Jun 2009 10:34:48 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] IMAP alternative for Sup?
Message-ID: <1244817210-sup-9892@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Edward Z. Yang's message of Fri Jun 12 10:14:26 -0400 2009:
> This is probably because OfflineIMAP polls more frequently. I've
> had good results getting rid of the lock up by decreasing Sup's
> polling time (unfortunately it's hard-coded in Sup).
This is one thing that would be a good candiate for a $config setting,
or maybe even a per-source value if you're in the unfortunate position
of polling multiple imap servers. Fortunately, I don't have to deal
with imap myself.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090612/1b0a66e2/attachment-0001.bin>
------------------------------
Message: 388
Date: Fri, 12 Jun 2009 11:23:05 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] (no subject)
Message-ID: <1244830970-sup-1069@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Walton's message of 2009-06-07:
> Here's a stab at implementing a message bouncing functionality worthy
> of being included on mainline.
Looks good. I've merged this into next. Thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 389
Date: Fri, 12 Jun 2009 11:56:09 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Gmail Labels Sidebar
Message-ID: <1244832722-sup-9953@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Walton's message of 2009-06-08:
> So something similar to the folder view hack/patch for mutt? That
> doesn't exist in sup. The closest you get is having the 'All Labels'
> buffer open. You can jump to a view of all messages with that label
> by hitting enter on the selected label.
FWIW, there is some preliminary support for having multiple Sup buffers
sharing the screen. (There's a notion of focus, and x/y/w/h values for
each buffer.) If someone is very excited about having this behavior from
mutt, that's how I'd try and implement it.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 390
Date: Fri, 12 Jun 2009 15:03:38 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Gmail Labels Sidebar
Message-ID:
<80055d7c0906121203g53b1e428q8abd035548331e49@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Fri, Jun 12, 2009 at 2:56 PM, William Morgan<wmorgan-sup@masanjin.net> wrote:
> Reformatted excerpts from Ben Walton's message of 2009-06-08:
>> So something similar to the folder view hack/patch for mutt? ?That
>> doesn't exist in sup. ?The closest you get is having the 'All Labels'
>> buffer open. ?You can jump to a view of all messages with that label
>> by hitting enter on the selected label.
>
> FWIW, there is some preliminary support for having multiple Sup buffers
> sharing the screen. (There's a notion of focus, and x/y/w/h values for
> each buffer.) If someone is very excited about having this behavior from
> mutt, that's how I'd try and implement it.
That is indeed very exciting. Mutt's sidebar is actually very poor and
limiting. If this could
handle it with arbitrary splitting, this would be amazingly amazing.
Thanks :)
-AT
------------------------------
Message: 391
Date: Fri, 12 Jun 2009 12:10:27 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Gmail Labels Sidebar
Message-ID: <1244833003-sup-9212@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Marcus Williams's message of 2009-06-09:
> William - if you want to add this to sup/bin feel free. Its basically
> the regen_text method lifted and edited slightly from the
> label-list-mode
Nice idea. I'd add such a thing, but I think you can make it
significantly simpler. (As you point out, locking the index is not
necessary.)
Something like:
#!/usr/bin/env ruby
require 'sup'
i = Redwood::Index.new; i.load
l = Redwood::LabelManager.new File.join(ENV["HOME"], ".sup", "labels.txt")
l.all_labels.
map { |label| [label, l.string_for(label)] }.
sort_by { |label, name| name }.
each do |label, name|
total = i.num_results_for :label => label
unread = (label == :unread)? total : i.num_results_for(:labels => [label, :unread])
printf "%20s: %6d messages, %6d unread\n", name, total, unread
end
puts "yay"
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 392
Date: Fri, 12 Jun 2009 12:14:31 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Gmail Labels Sidebar
Message-ID: <1244833856-sup-5874@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Andrei Thorp's message of 2009-06-09:
> What I did was put on the label-list-mode, manually send myself an
> e-mail, re-run fetchmail to grab it (I get a notification via procmail
> saying it came in). Then I remember that sup polls at intervals, so I
> wait.
You can press "P" to force a poll.
> Eventually, the status bar at the bottom says that there is a new
> message in the inbox, but the Inbox label does not get updated in my
> view. It still says 0/0.
Yep, currently label-list-mode only updates when one of three things
happens:
- it gets created
- it gets focus (you switch to it from another buffer)
- you press '@'
Also, it only reflects the index state, so if you read a new message
something and don't press "$", it won't reflect that change.
I'd happily accept patches for any of those issues. :)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 393
Date: Fri, 12 Jun 2009 12:18:11 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] display_length issue with special-characters
on non-UTF8 terminal
Message-ID: <1244834230-sup-1200@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Tarko Tikan's message of 2009-06-09:
> When String.display_length was introduced in recent update, it broke
> the length for non-UTF8 strings that contain the special characters.
> Wrong length results corrupted display (line ends chopped off).
That's a good point. I got a little utf8-centric with those changes.
(I'm assuming that your terminal encoding is not UTF-8.)
Does this patch fix the issue? If so, I will release an 0.8.1.
--- cut here ---
diff --git a/lib/sup.rb b/lib/sup.rb
index 4f59eaa..20835ae 100644
--- a/lib/sup.rb
+++ b/lib/sup.rb
@@ -244,7 +244,7 @@ end
Redwood::log "using character set encoding #{$encoding.inspect}"
else
Redwood::log "warning: can't find character set by using locale, defaulting
- $encoding = "utf-8"
+ $encoding = "UTF-8"
end
## now everything else (which can feel free to call Redwood::log at load time)
diff --git a/lib/sup/util.rb b/lib/sup/util.rb
index 8a3004f..d5310bc 100644
--- a/lib/sup/util.rb
+++ b/lib/sup/util.rb
@@ -172,7 +172,13 @@ class Object
end
class String
- def display_length; scan(/./u).size end
+ def display_length
+ if $encoding == "UTF-8"
+ scan(/./u).size
+ else
+ size
+ end
+ end
def camel_to_hyphy
self.gsub(/([a-z])([A-Z0-9])/, '\1-\2').downcase
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 394
Date: Fri, 12 Jun 2009 12:29:46 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Use terminal width instead of
hardcoded 80 as the wrap length.
Message-ID: <1244834906-sup-7818@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Marc Hartstein's message of 2009-06-07:
> Do we currently honor format=flowed email?
No.
> If we don't, it would be desirable to take this into account when
> designing the display wrapping options, and it seems like it would be
> worth implementing down the road.
Yes, I suppose so.
> It might be useful to be able to specify the wrap margin to something
> other than 80. I don't know if anybody would actually use this,
> though.
I will leave that kind of thing for the Sup GUI clients. :)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 395
Date: Fri, 12 Jun 2009 12:35:52 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH] fixes for ruby1.9
Message-ID: <1244835352-10370-1-git-send-email-rlane@club.cc.cmu.edu>
Change colons in case statements to 'then'
Fix a block that didn't take enough arguments
Rename variables to avoid shadowing warnings
Use String.ord (and define it for 1.8)
Use DL::Importer on 1.9
Make require 'fastthread' optional
Copy in RE_UTF8
---
bin/sup | 5 +--
lib/sup.rb | 4 +++
lib/sup/index.rb | 1 -
lib/sup/keymap.rb | 52 ++++++++++++++++++------------------
lib/sup/message-chunks.rb | 4 +-
lib/sup/message.rb | 4 +-
lib/sup/modes/edit-message-mode.rb | 5 +++-
lib/sup/util.rb | 46 ++++++++++++++++++--------------
8 files changed, 66 insertions(+), 55 deletions(-)
diff --git a/bin/sup b/bin/sup
index 9abe1b5..302ad7c 100755
--- a/bin/sup
+++ b/bin/sup
@@ -5,7 +5,6 @@ require 'ncurses'
require 'curses'
require 'fileutils'
require 'trollop'
-require 'fastthread'
require "sup"
BIN_VERSION = "git"
@@ -89,7 +88,7 @@ end
## BSD users: if libc.so.6 is not found, try installing compat6x.
require 'dl/import'
module LibC
- extend DL::Importable
+ extend DL.const_defined?(:Importer) ? DL::Importer : DL::Importable
setlocale_lib = case Config::CONFIG['arch']
when /darwin/; "libc.dylib"
when /cygwin/; "cygwin1.dll"
@@ -202,7 +201,7 @@ begin
end
end unless $opts[:no_initial_poll]
- imode.load_threads :num => ibuf.content_height, :when_done => lambda { reporting_thread("poll after loading inbox") { sleep 1; PollManager.poll } unless $opts[:no_threads] || $opts[:no_initial_poll] }
+ imode.load_threads :num => ibuf.content_height, :when_done => lambda { |num| reporting_thread("poll after loading inbox") { sleep 1; PollManager.poll } unless $opts[:no_threads] || $opts[:no_initial_poll] }
if $opts[:compose]
ComposeMode.spawn_nicely :to_default => $opts[:compose]
diff --git a/lib/sup.rb b/lib/sup.rb
index 4f59eaa..dea9355 100644
--- a/lib/sup.rb
+++ b/lib/sup.rb
@@ -5,6 +5,10 @@ require 'thread'
require 'fileutils'
require 'gettext'
require 'curses'
+begin
+ require 'fastthread'
+rescue LoadError
+end
class Object
## this is for debugging purposes because i keep calling #id on the
diff --git a/lib/sup/index.rb b/lib/sup/index.rb
index e403570..ca01ee7 100644
--- a/lib/sup/index.rb
+++ b/lib/sup/index.rb
@@ -2,7 +2,6 @@
require 'fileutils'
require 'ferret'
-require 'fastthread'
begin
require 'chronic'
diff --git a/lib/sup/keymap.rb b/lib/sup/keymap.rb
index 76c7139..cb039e4 100644
--- a/lib/sup/keymap.rb
+++ b/lib/sup/keymap.rb
@@ -9,22 +9,22 @@ class Keymap
def self.keysym_to_keycode k
case k
- when :down: Curses::KEY_DOWN
- when :up: Curses::KEY_UP
- when :left: Curses::KEY_LEFT
- when :right: Curses::KEY_RIGHT
- when :page_down: Curses::KEY_NPAGE
- when :page_up: Curses::KEY_PPAGE
- when :backspace: Curses::KEY_BACKSPACE
- when :home: Curses::KEY_HOME
- when :end: Curses::KEY_END
- when :ctrl_l: "\f"[0]
- when :ctrl_g: "\a"[0]
- when :tab: "\t"[0]
- when :enter, :return: 10 #Curses::KEY_ENTER
+ when :down then Curses::KEY_DOWN
+ when :up then Curses::KEY_UP
+ when :left then Curses::KEY_LEFT
+ when :right then Curses::KEY_RIGHT
+ when :page_down then Curses::KEY_NPAGE
+ when :page_up then Curses::KEY_PPAGE
+ when :backspace then Curses::KEY_BACKSPACE
+ when :home then Curses::KEY_HOME
+ when :end then Curses::KEY_END
+ when :ctrl_l then "\f".ord
+ when :ctrl_g then "\a".ord
+ when :tab then "\t".ord
+ when :enter, :return then 10 #Curses::KEY_ENTER
else
if k.is_a?(String) && k.length == 1
- k[0]
+ k.ord
else
raise ArgumentError, "unknown key name '#{k}'"
end
@@ -33,18 +33,18 @@ class Keymap
def self.keysym_to_string k
case k
- when :down: "<down arrow>"
- when :up: "<up arrow>"
- when :left: "<left arrow>"
- when :right: "<right arrow>"
- when :page_down: "<page down>"
- when :page_up: "<page up>"
- when :backspace: "<backspace>"
- when :home: "<home>"
- when :end: "<end>"
- when :enter, :return: "<enter>"
- when :tab: "tab"
- when " ": "<space>"
+ when :down then "<down arrow>"
+ when :up then "<up arrow>"
+ when :left then "<left arrow>"
+ when :right then "<right arrow>"
+ when :page_down then "<page down>"
+ when :page_up then "<page up>"
+ when :backspace then "<backspace>"
+ when :home then "<home>"
+ when :end then "<end>"
+ when :enter, :return then "<enter>"
+ when :tab then "tab"
+ when " " then "<space>"
else
Curses::keyname(keysym_to_keycode(k))
end
diff --git a/lib/sup/message-chunks.rb b/lib/sup/message-chunks.rb
index ba07d35..a9f1a77 100644
--- a/lib/sup/message-chunks.rb
+++ b/lib/sup/message-chunks.rb
@@ -252,8 +252,8 @@ EOS
def patina_color
case status
- when :valid: :cryptosig_valid_color
- when :invalid: :cryptosig_invalid_color
+ when :valid then :cryptosig_valid_color
+ when :invalid then :cryptosig_invalid_color
else :cryptosig_unknown_color
end
end
diff --git a/lib/sup/message.rb b/lib/sup/message.rb
index 805c2f7..8525fdf 100644
--- a/lib/sup/message.rb
+++ b/lib/sup/message.rb
@@ -414,8 +414,8 @@ private
elsif m.header["Content-Type"] && m.header["Content-Type"] !~ /^text\/plain/
extension =
case m.header["Content-Type"]
- when /text\/html/: "html"
- when /image\/(.*)/: $1
+ when /text\/html/ then "html"
+ when /image\/(.*)/ then $1
end
["sup-attachment-#{Time.now.to_i}-#{rand 10000}", extension].join(".")
diff --git a/lib/sup/modes/edit-message-mode.rb b/lib/sup/modes/edit-message-mode.rb
index d7bd41c..74bdfb7 100644
--- a/lib/sup/modes/edit-message-mode.rb
+++ b/lib/sup/modes/edit-message-mode.rb
@@ -2,7 +2,10 @@ require 'tempfile'
require 'socket' # just for gethostname!
require 'pathname'
require 'rmail'
-require 'jcode' # for RE_UTF8
+
+# from jcode.rb, not included in ruby 1.9
+PATTERN_UTF8 = '[\xc0-\xdf][\x80-\xbf]|[\xe0-\xef][\x80-\xbf][\x80-\xbf]'
+RE_UTF8 = Regexp.new(PATTERN_UTF8, 0, 'n')
module Redwood
diff --git a/lib/sup/util.rb b/lib/sup/util.rb
index 8a3004f..1513c42 100644
--- a/lib/sup/util.rb
+++ b/lib/sup/util.rb
@@ -133,8 +133,8 @@ class Object
## clone of java-style whole-method synchronization
## assumes a @mutex variable
## TODO: clean up, try harder to avoid namespace collisions
- def synchronized *meth
- meth.each do
+ def synchronized *methods
+ methods.each do |meth|
class_eval <<-EOF
alias unsynchronized_#{meth} #{meth}
def #{meth}(*a, &b)
@@ -144,8 +144,8 @@ class Object
end
end
- def ignore_concurrent_calls *meth
- meth.each do
+ def ignore_concurrent_calls *methods
+ methods.each do |meth|
mutex = "@__concurrent_protector_#{meth}"
flag = "@__concurrent_flag_#{meth}"
oldmeth = "__unprotected_#{meth}"
@@ -205,7 +205,7 @@ class String
region_start = 0
while pos <= length
newpos = case state
- when :escaped_instring, :escaped_outstring: pos
+ when :escaped_instring, :escaped_outstring then pos
else index(/[,"\\]/, pos)
end
@@ -219,26 +219,26 @@ class String
case char
when ?"
state = case state
- when :outstring: :instring
- when :instring: :outstring
- when :escaped_instring: :instring
- when :escaped_outstring: :outstring
+ when :outstring then :instring
+ when :instring then :outstring
+ when :escaped_instring then :instring
+ when :escaped_outstring then :outstring
end
when ?,, nil
state = case state
- when :outstring, :escaped_outstring:
+ when :outstring, :escaped_outstring then
ret << self[region_start ... newpos].gsub(/^\s+|\s+$/, "")
region_start = newpos + 1
:outstring
- when :instring: :instring
- when :escaped_instring: :instring
+ when :instring then :instring
+ when :escaped_instring then :instring
end
when ?\\
state = case state
- when :instring: :escaped_instring
- when :outstring: :escaped_outstring
- when :escaped_instring: :instring
- when :escaped_outstring: :outstring
+ when :instring then :escaped_instring
+ when :outstring then :escaped_outstring
+ when :escaped_instring then :instring
+ when :escaped_outstring then :outstring
end
end
pos = newpos + 1
@@ -274,6 +274,12 @@ class String
gsub(/\t/, " ").gsub(/\r/, "")
end
+ if not defined? ord
+ def ord
+ self[0]
+ end
+ end
+
## takes a space-separated list of words, and returns an array of symbols.
## typically used in Sup for translating Ferret's representation of a list
## of labels (a string) to an array of label symbols.
@@ -628,10 +634,10 @@ class Iconv
def self.easy_decode target, charset, text
return text if charset =~ /^(x-unknown|unknown[-_ ]?8bit|ascii[-_ ]?7[-_ ]?bit)$/i
charset = case charset
- when /UTF[-_ ]?8/i: "utf-8"
- when /(iso[-_ ])?latin[-_ ]?1$/i: "ISO-8859-1"
- when /iso[-_ ]?8859[-_ ]?15/i: 'ISO-8859-15'
- when /unicode[-_ ]1[-_ ]1[-_ ]utf[-_]7/i: "utf-7"
+ when /UTF[-_ ]?8/i then "utf-8"
+ when /(iso[-_ ])?latin[-_ ]?1$/i then "ISO-8859-1"
+ when /iso[-_ ]?8859[-_ ]?15/i then 'ISO-8859-15'
+ when /unicode[-_ ]1[-_ ]1[-_ ]utf[-_]7/i then "utf-7"
else charset
end
--
1.6.0.4
------------------------------
Message: 396
Date: Fri, 12 Jun 2009 12:54:26 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup -c while sup is running?
Message-ID: <1244835514-sup-3886@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Marc Hartstein's message of 2009-06-10:
> How difficult would it be to allow sup -c to be run while sup is
> already running? The goal would be to be able to use sup as a mailto:
> handler effectively.
Not that difficult. In general, N Sup processes should be able to run as
long as N-1 of them are readonly wrt the index and sources file. (I
think!) So sup -c could launch either with a readonly inbox buffer, or
without one at all. (Which would be faster, if the intention is just to
quit after sending.)
However, to be safe, locking should be added to the sent.mbox to prevent
multiple Sup processing from overwriting each other's sent messages. Ben
Walton's lock manager I think will be perfect for this.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 397
Date: Fri, 12 Jun 2009 13:03:22 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup and ncursesw
Message-ID: <1244836517-sup-5520@entry>
Content-Type: text/plain; charset=UTF-8
Hi J?rg-Hendrik,
Reformatted excerpts from J?rg-Hendrik Bach's message of 2009-06-10:
> I recently installed sup 0.8 and find I am having problems with
> umlauts and accented characters. There is a patch for the
> ncurses-0.9.1 gem on the sup wiki ("utf8-issues") which allows the
> characters to be displayed correctly, but after applying the patch I
> can't enter proper text.
What is your environment's character set? (Should be the first line of
output logged by Sup.) What is your terminal emulator? Do other widechar
ncurses programs work? And what's the behavior without the patch to
ncurses.so?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 398
Date: Fri, 12 Jun 2009 21:18:10 +0100
From: Marcus Williams <marcus-sup@bar-coded.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Gmail Labels Sidebar
Message-ID: <1244837827-sup-6632@tomsk>
Content-Type: text/plain; charset=utf-8
On 12.6.2009, William Morgan wrote:
> Nice idea. I'd add such a thing, but I think you can make it
> significantly simpler. (As you point out, locking the index is not
> necessary.)
Simpler is good - it was a quick hack anyway :) You version works out
of the box so it would be a nice addition to sup/bin
Marcus
------------------------------
Message: 399
Date: Fri, 12 Jun 2009 21:46:32 +0100
From: Marcus Williams <marcus-sup@bar-coded.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] [PATCH] Minimalist view
Message-ID: <1244839497-sup-547@tomsk>
Content-Type: text/plain; charset=utf-8
Adds a keypress to toggle to a minimalist view in thread index mode.
This removes the date, authors and number of threads from the view
leaving more room for labels/snippets
---
lib/sup/modes/thread-index-mode.rb | 34 +++++++++++++++++++++++++++-------
1 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb
index 0bd8110..5fa4f4c 100644
--- a/lib/sup/modes/thread-index-mode.rb
+++ b/lib/sup/modes/thread-index-mode.rb
@@ -45,6 +45,7 @@ EOS
k.add :apply_to_tagged, "Apply next command to all tagged threads", '+', '='
k.add :join_threads, "Force tagged threads to be joined into the same thread", '#'
k.add :undo, "Undo the previous action", 'u'
+ k.add :toggle_minimalist, "Toggle minimalist view", '~'
end
def initialize hidden_labels=[], load_thread_opts={}
@@ -62,6 +63,8 @@ EOS
@hidden_labels = hidden_labels + LabelManager::HIDDEN_RESERVED_LABELS
@date_width = DATE_WIDTH
+ @minimal = false
+
@interrupt_search = false
initialize_threads # defines @ts and @ts_mutex
@@ -261,6 +264,11 @@ EOS
end
end
+ def toggle_minimalist
+ @minimal = !@minimal
+ regen_text
+ end
+
def toggle_starred
t = cursor_thread or return
undo = actually_toggle_starred t
@@ -833,13 +841,25 @@ protected
size_widget_text = sprintf "%#{ @size_widget_width}s", size_widget
- [
- [:tagged_color, @tags.tagged?(t) ? ">" : " "],
- [:none, sprintf("%#{@date_width}s", date)],
- (starred ? [:starred_color, "*"] : [:none, " "]),
- ] +
- from +
- [
+
+ if @minimal
+ if size_widget!=""
+ size_widget_text = "+"
+ else
+ size_widget_text = " "
+ end
+ line = []
+ else
+ line = [
+ [:tagged_color, @tags.tagged?(t) ? ">" : " "],
+ [:none, sprintf("%#{@date_width}s", date)],
+ (starred ? [:starred_color, "*"] : [:none, " "]),
+ ] + from
+ end
+
+
+ line +
+ [
[subj_color, size_widget_text],
[:to_me_color, t.labels.member?(:attachment) ? "@" : " "],
[:to_me_color, dp ? ">" : (p ? '+' : " ")],
--
1.5.4.1
------------------------------
Message: 400
Date: Fri, 12 Jun 2009 18:14:55 -0400
From: Nicholas Bergson-Shilcock <me@nicholasbs.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Transitioning to OfflineIMAP
Message-ID: <1244844014-sup-6606@twoface>
Content-Type: text/plain; charset=UTF-8
Hi,
I've been using sup for the past year and love it. In an attempt to
speed things up, I'm hoping to switch to using OfflineIMAP and a maildir
source (I'm currently using straight IMAP). I've installed and
configured OfflineIMAP and have downloaded all of my messages.
Before I go any further, I wanted to know if sup supported any sort of
"graceful" account transitioning -- I'd ideally like to switch to
my new maildir source without losing the index information I have for my
IMAP source. The obvious way of switching over (removing my old source
and adding the new one) would mean essentially starting over. Is this
what I have to do or is there another way for me to switch?
Thanks! (And thanks for making sup such a joy to use!)
-Nick
------------------------------
Message: 401
Date: Fri, 12 Jun 2009 17:24:44 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Transitioning to OfflineIMAP
Message-ID: <1244852427-sup-5831@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Nicholas Bergson-Shilcock's message of 2009-06-12:
> Before I go any further, I wanted to know if sup supported any sort of
> "graceful" account transitioning -- I'd ideally like to switch to my
> new maildir source without losing the index information I have for my
> IMAP source. The obvious way of switching over (removing my old source
> and adding the new one) would mean essentially starting over. Is this
> what I have to do or is there another way for me to switch?
I wouldn't call it graceful, exactly, but you should be able to preserve
state by running sup-dump on the original source, drop the index (move
your ~/.sup/ferret directory somewhere else), edit your source.yaml
file, and use sup-sync --restored --restore <dumpfile> to scan over the
new source and restore the state for each message.
It will take a while. Try it on a subset of messages first if possible
to make sure it's working. Post any questions and I'll try and help you.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 402
Date: Sat, 13 Jun 2009 14:13:06 +0300
From: Tarko Tikan <tarko@lanparty.ee>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] display_length issue with special-characters
on non-UTF8 terminal
Message-ID: <1244891132-sup-2424@valgus>
Content-Type: text/plain; charset=ISO-8859-15
> (I'm assuming that your terminal encoding is not UTF-8.)
No, it's not.
> Does this patch fix the issue? If so, I will release an 0.8.1.
Yes it does. To me, this approach felt "hackish" so I didn't come up with a patch :) But I still don't have better idea how to fix it so it'll have to stay like this.
> + if $encoding == "UTF-8"
> + scan(/./u).size
> + else
> + size
> + end
It would probably be correct to use:
if $encoding == "UTF-8"
scan(/./u).size
else
length
end
Thats because scan returns a array (hence using the size), without scan you are just invoking on string and it's correct to use length (for some reason size works too, backward compatibility?)
--
tarko
------------------------------
Message: 403
Date: Sat, 13 Jun 2009 16:17:51 +0200
From: J?rg-Hendrik Bach <bachjh@googlemail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup and ncursesw
Message-ID:
<91de50e10906130717x3a6d6097g5249ed6bb17fbfcf@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
2009/6/12 William Morgan <wmorgan-sup@masanjin.net>
>
> What is your environment's character set? (Should be the first line of
> output logged by Sup.) What is your terminal emulator? And what's the
> behavior without the patch to ncurses.so?
After playing around a bit i think the behaviour might be related to a
problem with locale.
I reinstalled ruby, rubygems, ncurses and sup. No patch to ncurses this
time. Using gnome-terminal or xterm with "TERM=xterm" now lets umlauts etc
look like, e.g. "JM-CM-6rg-Hendrik"). The reported character set is "utf8".
The same happens when using urxvt with TERM=rxvt-unicode.
However, calling sup like this:
$ LC_ALL=en_GB.iso-8859-15 sup
results in different behaviour in the two emulators: xterm looks OK when
viewing the inbox, but inserts boxed question marks in thread-view.
rxvt-unicode displays everything correctly, but drops the last character of
a line when a non-ASCII element is somewhere in the line. In both variants
sup reports the character set correctly as iso-8859-15.
So I guess I could simply work in urxvt and that's OK, then.
Do other widechar ncurses programs work?
The only other ncurses-based program I am aware of using is midnight
commander, and it seems to be working fine. But I don't know whether it uses
the widechar variant.
cheers,
- J?rg-Hendrik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090613/c8c73902/attachment-0001.html>
------------------------------
Message: 404
Date: Sat, 13 Jun 2009 21:37:13 -0700
From: Arvid Picciani <aep@exys.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Sup won't save state
Message-ID: <1244954212-sup-8783@andariel>
Content-Type: text/plain; charset=utf8
Hi,
I'm trying out sup and I totally like the concept so far, unfortunately it
doesn't work correctly for me.
1) It doesn't save its state. The next time I open it up, read messages
are new again.
2) when pressing c, to compose a new message, it asks for a Subject.
Later in vim I see the Subject field contains random characters instead.
3) Most input "dialogs" (?) can't be killed. Pressing ESC does nothing.
The only to chancel such an operation is to kill sup.
4) It behaves very odd when two clients are using the same imap account.
Yes, the docs state that, but not how to work around that when you
_have_ to use two clients. Currently I'm trying to use offlineimap,
unfortunately that's broken.
Thank you,
Arvid
------------------------------
Message: 405
Date: Sat, 13 Jun 2009 16:22:19 -0400
From: Marc Hartstein <marc.hartstein@alum.vassar.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup won't save state
Message-ID: <1244924476-sup-3634@cabinet>
Content-Type: text/plain; charset="utf8"
Excerpts from Arvid Picciani's message of Sun Jun 14 00:37:13 -0400 2009:
>
> 3) Most input "dialogs" (?) can't be killed. Pressing ESC does nothing.
> The only to chancel such an operation is to kill sup.
Use Control-G for this.
Hopefully someone else can help you with the other issues.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 244 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090613/1493c878/attachment-0001.bin>
------------------------------
Message: 406
Date: Sat, 13 Jun 2009 21:36:41 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Minimalist view
Message-ID: <1244943297-sup-5509@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Marcus Williams's message of Fri Jun 12 16:46:32 -0400 2009:
> Adds a keypress to toggle to a minimalist view in thread index mode.
> This removes the date, authors and number of threads from the view
> leaving more room for labels/snippets
This patch looks sound, but I wonder if a Hook might be in order to
make the alternate display customizable? Not a bad idea at all
though.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090613/4467445f/attachment-0001.bin>
------------------------------
Message: 407
Date: Sun, 14 Jun 2009 14:17:38 +0100
From: Marcus Williams <marcus-sup@bar-coded.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Minimalist view
Message-ID: <1244985302-sup-9505@tomsk>
Content-Type: text/plain; charset=utf-8
On 14.6.2009, Ben Walton wrote:
> This patch looks sound, but I wonder if a Hook might be in order to
> make the alternate display customizable? Not a bad idea at all
> though.
Slightly ahead of you :) This is the default view for my next patch
which implements exactly that hook.
I'm just wandering through my local commits and cleaning stuff up for
submission so hopefully a few more to come as well.
Marcus
------------------------------
Message: 408
Date: Sun, 14 Jun 2009 17:51:18 -0700
From: Arvid Picciani <aep@exys.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup won't save state
Message-ID: <1245026779-sup-3938@andariel>
Content-Type: text/plain; charset=utf8
Sorry, still takes a little to get used to sup. I have no clue what
was on and off list, but I assume this was off, so I'm going to repost
it:
> $ in inbox mode to save, or at intervals. does clean shutdown not do
> this automatically?
"clean shutdown" is one of the reasons I went away from Gui crap.
It almost never works for me.
I don't even know how to shut down a Linux computer "cleanly" other then
by clicking some button on some Gui menu, which I don't have,
so most Gui programs just crash and leave me next time with some
ridiculous "recovery assistant".
Sup does exactly that and it's highly annoying. It doesn't even work.
Why the hell are you trying to kill a non existent sup instance?
Maybe I should just alias sup="rm .sup/lock;sup"
End of rant.
So how do I configure sup to save automatically?
PS: the encrypt/reply to menu on the reply view is pretty cool :)
------------------------------
Message: 409
Date: Sun, 14 Jun 2009 17:58:31 -0700
From: Arvid Picciani <aep@exys.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Wrong messages in thread
Message-ID: <1245027174-sup-4117@andariel>
Content-Type: text/plain; charset=utf8
Two more questions :P
1) Some messages end up in the wrong thread. When there is no other
useful info, sup appears to guess a thread by the Subject similarity.
Unfortunately that ends up being very wrong for my university mailing
list, since they have no List-Id, but the full university name in the
Subject and people won't learn to write meaningful Subjects.
[blablablalblalbafooomal uni blabla] hi
is displayed in the same thread with
[blablablalblalbafooomal uni blabla] hello
although those are two different threads.
Can I manually fix those?
2) how's that address book generated?
I have sup-talk-request and sup-talk-something
but not sup-talk.
thanks
--
Arvid
------------------------------
Message: 410
Date: Sun, 14 Jun 2009 13:36:08 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Wrong messages in thread
Message-ID: <1245000912-sup-6454@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from Arvid Picciani's message of Sun Jun 14 20:58:31 -0400 2009:
> 2) how's that address book generated?
> I have sup-talk-request and sup-talk-something
> but not sup-talk.
When you edit an address in thread-view-mode using i it gets added
to your address book. Ideally, stuff should get added when you compose
and email the first time. This is a patch I want to make at some point.
Cheers,
Edward
------------------------------
Message: 411
Date: Sun, 14 Jun 2009 13:35:57 -0700
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Sup won't save state
Message-ID:
<80055d7c0906141335r31848e05ydfc8557b0d1d9ca6@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Yeah, sorry, I replied to person accidentally while on handheld.
Thanks for forwarding.
Anyway, yeah, wish saving in sup was better. Don't really know
anything better than sup-sync.
-AT
------------------------------
Message: 412
Date: Mon, 15 Jun 2009 14:03:58 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Wrong messages in thread
Message-ID: <1245067390-sup-2318@ausone.inria.fr>
Content-Type: text/plain; charset=UTF-8
Excerpts from Edward Z. Yang's message of Sun Jun 14 19:36:08 +0200 2009:
> Excerpts from Arvid Picciani's message of Sun Jun 14 20:58:31 -0400 2009:
> > 2) how's that address book generated?
> > I have sup-talk-request and sup-talk-something
> > but not sup-talk.
>
> When you edit an address in thread-view-mode using i it gets added
> to your address book. Ideally, stuff should get added when you compose
> and email the first time. This is a patch I want to make at some point.
Yes it would be great to automatically prompt for adding the contact when
we send a message to someone not yet in contacts.
--
Nicolas Pouillard
http://nicolaspouillard.fr
------------------------------
Message: 413
Date: Mon, 15 Jun 2009 06:34:29 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Wrong messages in thread
Message-ID: <1245072716-sup-829@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Arvid Picciani's message of 2009-06-14:
> 1) Some messages end up in the wrong thread. When there is no other
> useful info, sup appears to guess a thread by the Subject similarity.
Sup does not do this. If you're seeing messages with different subjects
in the same thread, a later one contains a reference to an earlier one.
Sometimes this happens if people reply to a mailing list message and
change the subject as a way of starting a new message. You can confirm
this by examining the in-reply-to and references headers of the later
message.
> 2) how's that address book generated?
> I have sup-talk-request and sup-talk-something
> but not sup-talk.
By manually adding contacts, e.g. with 'i' in thread-view-mode, plus a
couple recent contacts automatically drawn from the index.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 414
Date: Mon, 15 Jun 2009 06:37:15 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup won't save state
Message-ID: <1245072900-sup-2799@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Arvid Picciani's message of 2009-06-13:
> 1) It doesn't save its state. The next time I open it up, read
> messages are new again.
How are you quitting Sup?
> 2) when pressing c, to compose a new message, it asks for a Subject.
> Later in vim I see the Subject field contains random characters
> instead.
Strange. Are they related in any way? Can you give an example?
> 3) Most input "dialogs" (?) can't be killed. Pressing ESC does
> nothing. The only to chancel such an operation is to kill sup.
Ctrl-g.
> 4) It behaves very odd when two clients are using the same imap
> account. Yes, the docs state that, but not how to work around that
> when you _have_ to use two clients.
If you change the IMAP folder via another client, you'll have to run
sup-sync --changed on that source before running Sup. Sup should detect
this and tell you. What "odd" behavior are you seeing?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 415
Date: Mon, 15 Jun 2009 06:42:04 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup won't save state
Message-ID: <1245073093-sup-5388@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Arvid Picciani's message of 2009-06-14:
> "clean shutdown" is one of the reasons I went away from Gui crap.
Clean shutdown has nothing to do with GUI vs not GUI.
> I don't even know how to shut down a Linux computer "cleanly" other
> then by clicking some button on some Gui menu, which I don't have,
> so most Gui programs just crash and leave me next time with some
> ridiculous "recovery assistant".
> Sup does exactly that and it's highly annoying. It doesn't even work.
It's hard to guess what you're doing here, but it sounds like you're
pressing ctrl-c to kill Sup and then pressing y at the "die ungracefully
now?" prompt. You may want to read the new user guide:
http://sup.rubyforge.org/NewUserGuide.txt.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 416
Date: Mon, 15 Jun 2009 06:50:37 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Minimalist view
Message-ID: <1245073371-sup-3704@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Walton's message of 2009-06-13:
> This patch looks sound, but I wonder if a Hook might be in order to
> make the alternate display customizable? Not a bad idea at all
> though.
Yeah, I would generally like to have this type of thing done through
hooks, but if a lot of people like this mode then I could integrate it
directly.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 417
Date: Mon, 15 Jun 2009 09:54:01 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Minimalist view
Message-ID: <1245073954-sup-8198@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Mon Jun 15 09:50:37 -0400 2009:
> Yeah, I would generally like to have this type of thing done through
> hooks, but if a lot of people like this mode then I could integrate it
> directly.
What about a Hook with this as the default alternate view if the Hook
isn't set? I'd also suggest changing the name from minimalist to
alternate, since if there is a hook available, it may not actually be
a minimal view?
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090615/82450fd6/attachment-0001.bin>
------------------------------
Message: 418
Date: Mon, 15 Jun 2009 07:04:52 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup and ncursesw
Message-ID: <1245074133-sup-9338@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from J?rg-Hendrik Bach's message of 2009-06-13:
> After playing around a bit i think the behaviour might be related to a
> problem with locale.
Yeah, this stuff is all tricky to get working right. I recommend first
trying to get to the point where you can cat and less files with funny
characters in them, and then introduce something like Sup. (And that's
typically the point where you see the difference between ncurses.so with
and without the patch.)
> Using gnome-terminal or xterm with "TERM=xterm" now lets umlauts etc
> look like, e.g. "JM-CM-6rg-Hendrik"). The reported character set is
> "utf8".
Probably the umlauts themselves aren't in utf8. I have had success with
gnome-terminal and TERM=xterm, so I bet you can get this combo to work.
Try changing your locale from utf8 to en_GB.iso-8859-15 here (if you're
using Ubuntu, you can edit /etc/default/locale an re-log in, then
`locale` to check.)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 419
Date: Mon, 15 Jun 2009 07:10:30 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] display_length issue with special-characters
on non-UTF8 terminal
Message-ID: <1245074739-sup-3954@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Tarko Tikan's message of 2009-06-13:
> Yes it does. To me, this approach felt "hackish" so I didn't come up
> with a patch :) But I still don't have better idea how to fix it so
> it'll have to stay like this.
It's hackish because Ruby 1.8 has shitty multibyte support. The only
reason it works at all is because byte length is character length (at
least most of the time) in your encoding.
There is a multibyte gem out there that I'm keeping an eye on. Also Ruby
1.9.1 allegedgly fixes this problem.
> Thats because scan returns a array (hence using the size), without
> scan you are just invoking on string and it's correct to use length
> (for some reason size works too, backward compatibility?)
Size and length are synonmys for both arrays and strings. I used size
there for symmetry.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 420
Date: Mon, 15 Jun 2009 11:20:58 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Sup won't save state
Message-ID:
<80055d7c0906150820o3ef05759j23a54e0f889594b7@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
>> 2) when pressing c, to compose a new message, it asks for a Subject.
>> Later in vim I see the Subject field contains random characters
>> instead.
>
> Strange. Are they related in any way? Can you give an example?
When this happened to me, they were absolutely unrelated, looked like
trying to vim a bit of a binary file...
But went away randomly a few days later.
-AT
------------------------------
Message: 421
Date: Mon, 15 Jun 2009 09:32:42 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] fixes for ruby1.9
Message-ID: <1245083484-sup-9468@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Rich Lane's message of 2009-06-12:
> Change colons in case statements to 'then'
> Fix a block that didn't take enough arguments
> Rename variables to avoid shadowing warnings
> Use String.ord (and define it for 1.8)
> Use DL::Importer on 1.9
> Make require 'fastthread' optional
Thanks for this. I've applied it directly to master. Now if someone
would just upgrade Ferret to 1.9, we might be able to actually run Sup!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 422
Date: Mon, 15 Jun 2009 09:53:47 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash after sending a message
Message-ID: <1245084718-sup-1647@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Fabio Riga's message of 2009-06-11:
> All is fine, I just need to remember to launch sup this way. Maybe it
> needs some work on localization?
Sorry about that. The problem is that Sup was writing an invalid
sent.mbox file in certain locales, including yours, and then dying when
it couldn't parse its own file. If you update to the latest git, this
should be fixed for new messages, and you shouldn't need the LANG=C
hack.
Please let me know if you have any more problems.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 423
Date: Mon, 15 Jun 2009 10:24:08 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] lockmanager
Message-ID: <1245084879-sup-6794@entry>
Content-Type: text/plain; charset=UTF-8
Hi Ben,
Reformatted excerpts from Ben Walton's message of 2009-06-09:
> I've attached the base LockManager class that I'm envisioning for sup.
Sorry for the delay. This looks good. Using a mutex to protect the
file-locking seems like the right idea. Carry on!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 424
Date: Mon, 15 Jun 2009 13:39:15 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] lockmanager
Message-ID: <1245087383-sup-5205@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Mon Jun 15 13:24:08 -0400 2009:
> Sorry for the delay. This looks good. Using a mutex to protect the
> file-locking seems like the right idea. Carry on!
Yah, now that 'stupid Kobe' beat the Magic last night, my evenings
should have more time for completing this. I'm just about finished
integrating it with the mbox code.
I've branched this from bw/flexible_sent, since I thought it made more
sense to go from that than from master w/o the flexible sent
parts...it should still merge decently for you, I think.
The next hurdle will be testing, which I'll need help for, since my
only mbox is sup://sent, which is now legacy only (and at some point
when I'm bored will disappear completely).
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090615/499ca4b3/attachment-0001.bin>
------------------------------
Message: 425
Date: Mon, 15 Jun 2009 10:44:25 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] before-search hook
Message-ID: <1245087294-sup-6276@entry>
Content-Type: text/plain; charset=UTF-8
Hi Edward,
Thanks for the patch. I'm interested in integrating it into Sup
mainline. A couple comments:
1. Can you rename it to custom-search? I think that's a better
description.
2. I would rather have the hook return a value. So this:
> - subs = s.gsub(/\b(to|from):(\S+)\b/) do
> + subs = String.new s
> + HookManager.run("before-search", :subs => subs)
I would rather see as:
subs = HookManager.run("before-search", :subs => s) || s
3. It's not really an issue of mutation vs no mutation. The problem is
that the parameter names in hooks are method calls, not variables. So
while "subs = subs.gsub(...)" causes a 'subs' local variable to be
created and initialized to nil, both "x = subs.gsub(...)" and "subs =
self.subs.gsub(...)" work fine.
This is probably less of an issue when the hook is returning a
values, but if you could change the comments to be a warning about
shadowing method calls instead that would be better.
Thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 426
Date: Mon, 15 Jun 2009 10:50:21 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] lockmanager
Message-ID: <1245088148-sup-5245@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Walton's message of 2009-06-15:
> I've branched this from bw/flexible_sent, since I thought it made more
> sense to go from that than from master w/o the flexible sent
> parts...it should still merge decently for you, I think.
That's fine. As long as it doesn't branch from next, I'm happy.
> The next hurdle will be testing, which I'll need help for, since my
> only mbox is sup://sent, which is now legacy only (and at some point
> when I'm bored will disappear completely).
Although the addressess are (trivially) mangled, you can use something
like http://rubyforge.org/pipermail/sup-talk/2009-June.txt.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 427
Date: Mon, 15 Jun 2009 14:45:35 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [BUG] Sup Overload
Message-ID:
<80055d7c0906151145r493c07c2h7a68d776f49ce91a@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello there!
Exciting fresh new sup crash. What's happened is that I just imported
a zillion new messages from several new sources. I downloaded all the
mail from 4 mailing lists in my gmail account. Anyway, so they all
appeared as new in my inbox. I started holding a as they appeared to
archive them. Sup blew up. See attached exception log.
Cheers.
-AT
-------------- next part --------------
--- RuntimeError from thread: poll after loading inbox
unknown drawable object: nil in #<Redwood::InboxMode:0xb745fc4c> for line 35
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/scroll-mode.rb:200:in `draw_line'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/line-cursor-mode.rb:39:in `draw_line'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/scroll-mode.rb:48:in `draw'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/scroll-mode.rb:48:in `each'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/scroll-mode.rb:48:in `draw'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/line-cursor-mode.rb:24:in `draw'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/buffer.rb:99:in `draw'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/buffer.rb:83:in `redraw'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/buffer.rb:303:in `draw_screen'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `send'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `method_missing'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/thread-index-mode.rb:187:in `handle_added_update'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/update.rb:27:in `send'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/update.rb:27:in `relay'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/update.rb:27:in `each'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/update.rb:27:in `relay'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `send'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `method_missing'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/poll.rb:162:in `add_messages_from'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/maildir.rb:130:in `each'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/maildir.rb:127:in `upto'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/maildir.rb:127:in `each'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/util.rb:544:in `send'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/util.rb:544:in `__pass'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/util.rb:531:in `method_missing'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/poll.rb:141:in `add_messages_from'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/poll.rb:98:in `do_poll'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/poll.rb:86:in `each'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/poll.rb:86:in `do_poll'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/poll.rb:85:in `synchronize'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/poll.rb:85:in `do_poll'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `send'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `method_missing'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/poll-mode.rb:17:in `poll'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/poll.rb:53:in `poll'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `send'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `method_missing'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/bin/sup:206
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup.rb:71:in `reporting_thread'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup.rb:69:in `initialize'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup.rb:69:in `new'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup.rb:69:in `reporting_thread'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/bin/sup:206
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/thread-index-mode.rb:663:in `call'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/thread-index-mode.rb:663:in `__unprotected_load_threads'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/thread-index-mode.rb:605:in `call'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/thread-index-mode.rb:605:in `load_n_threads_background'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup.rb:71:in `reporting_thread'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup.rb:69:in `initialize'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup.rb:69:in `new'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup.rb:69:in `reporting_thread'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/thread-index-mode.rb:603:in `load_n_threads_background'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/thread-index-mode.rb:673:in `__unprotected_load_threads'
(eval):12:in `load_threads'
/usr/lib/ruby/gems/1.8/gems/sup-0.8/bin/sup:206
/usr/bin/sup:19:in `load'
/usr/bin/sup:19
------------------------------
Message: 428
Date: Mon, 15 Jun 2009 14:47:22 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [BUG] Can't handle spaces in paths
Message-ID:
<80055d7c0906151147h826d5beg7e5c56092149cd54@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hey there,
I just downloaded a whole lot of mail from my gmail account via
offlineimap, and tried to add a source with a space. In short, sup
doesn't like this. It tries to do a split somewhere and it doesn't
work out for it so well :)
Not much of a bug, I ln -s'd around it. Maybe something that could be
handled somehow though? I tried quotes and whitespace backslashing in
shell, but no go.
Cheers!
-AT
------------------------------
Message: 429
Date: Mon, 15 Jun 2009 21:05:37 +0200
From: Guillaume Quintard <guillaume.quintard@gmail.com>
To: Andrei Thorp <garoth@gmail.com>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [BUG] Can't handle spaces in paths
Message-ID: <1245092672-sup-7673@altis>
Content-Type: text/plain; charset=UTF-8
Excerpts from Andrei Thorp's message of Mon Jun 15 20:47:22 +0200 2009:
> Not much of a bug, I ln -s'd around it. Maybe something that could be
> handled somehow though? I tried quotes and whitespace backslashing in
> shell, but no go.
>
Did you put a '\' before the spaces?
--
Guillaume
------------------------------
Message: 430
Date: Mon, 15 Jun 2009 15:07:50 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] [BUG] Can't handle spaces in paths
Message-ID:
<80055d7c0906151207p95bbae4w5846acb8f03044da@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
>> I tried quotes and whitespace backslashing in shell, but no go.
>>
> Did you put a '\' before the spaces?
>
> --
> Guillaume
That's what I was referring to ^
Also, I should mention that I tried sup-add as well as sup-config for
this operation.
-AT
------------------------------
Message: 431
Date: Mon, 15 Jun 2009 21:11:04 +0200
From: Guillaume Quintard <guillaume.quintard@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash after sending a message
Message-ID: <1245092885-sup-1794@altis>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Mon Jun 15 18:53:47 +0200 2009:
> Please let me know if you have any more problems.
Still have it here, arg., with next.
There is a sense of tragic in the fact that I know that after sending
that mail to get help, sup will inevitably crash :-)
--
Guillaume
------------------------------
Message: 432
Date: Mon, 15 Jun 2009 12:17:20 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash after sending a message
Message-ID: <1245093278-sup-4366@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Guillaume Quintard's message of 2009-06-15:
> Still have it here, arg., with next.
You probably still have broken lines in your sent.mbox. This fix only
works for new messages, so you'll have to edit sent.mbox by hand. Look
for "From " lines that have a localized timestamp in them, and change
them to something that Time.parse can parse. It's probably possible to
write a script to do this if you have a large number of htem.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 433
Date: Mon, 15 Jun 2009 12:18:28 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [BUG] Can't handle spaces in paths
Message-ID: <1245093476-sup-4708@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Andrei Thorp's message of 2009-06-15:
> I just downloaded a whole lot of mail from my gmail account via
> offlineimap, and tried to add a source with a space. In short, sup
> doesn't like this. It tries to do a split somewhere and it doesn't
> work out for it so well :)
Try putting a %20 instead of a space. A sad consequence of using URIs to
specify sources.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 434
Date: Mon, 15 Jun 2009 15:44:13 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] Yet Another Offlineimap Thread (YAOT)
Message-ID:
<80055d7c0906151244y1d66a4b1g8df4e3aa1d544c4f@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hello!
So I decided today to finally jump in and try to use sup for my main
gmail account and not just my work stuff. I've set up offlineimap and
downloaded the mail that I care for. Questions:
- Does imap support a way to say which mails have been read and not?
I think it probably does. If this is the case, can sup-sync-back
somehow do this? It'd be nice if my gmail understood when a mail has
been read, so when I sync back up with offlineimap, it's all savvy.
- I vaguely saw some tricks here for how to reply with different
e-mail addresses and stuff. I'd like to execute a whole different
command when replying in some situations, so that my mail gets sent
through gmail's smtp server instead of my work's one, for example. How
would I achieve this?
- I don't see a daemon mode for offlineimap. I guess the expected
usage is to make it quiet and put it in a cron/regular script? Am I
correct?
Thanks!
-AT
------------------------------
Message: 435
Date: Mon, 15 Jun 2009 23:30:13 +0200
From: Guillaume Quintard <guillaume.quintard@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash after sending a message
Message-ID: <1245101169-sup-9937@altis>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Mon Jun 15 21:17:20 +0200 2009:
> You probably still have broken lines in your sent.mbox. This fix only
> works for new messages, so you'll have to edit sent.mbox by hand. Look
> for "From " lines that have a localized timestamp in them, and change
> them to something that Time.parse can parse. It's probably possible to
> write a script to do this if you have a large number of htem.
I think I said "save them in the mbox" to sup-config, and I still get
that behaviour, so what? Do I dig in the 3.2Go .mbox (please, not that one),
do I change to "save in sup://sent"? BTW, I renamed my sent.mbox, just
in case.
If I really have to go into the huge mbox, what should I look for
exactly, I didn't quite get what the parser failed on.
Regards
--
Guillaume
------------------------------
Message: 436
Date: Mon, 15 Jun 2009 18:14:14 -0700
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [BUG] Sup Overload
Message-ID:
<80055d7c0906151814u2ab0fdf4n76144e27517870c8@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Forwarding to mailing list.
---------- Forwarded message ----------
From: Mark Alexander <marka@pobox.com>
Date: Mon, Jun 15, 2009 at 2:10 PM
Subject: Re: [sup-talk] [BUG] Sup Overload
To: Andrei Thorp <garoth@gmail.com>
This may not be related, but at one point I found that feeding
input characters to sup too quickly caused it to crash. ?I was using
X cut-and-paste as a kind of poor-man's macro facility when I ran
into this. ?If I recall correctly, the string I was cut-and-pasting into
sup was this:
? T=N=a$
which was supposed to tag all messages, mark them as read, and archive
them. ?I think it was crashing when it got to the "$", but it might
have been the "a" that did it. ?I haven't tried this in a while.
------------------------------
Message: 437
Date: Mon, 15 Jun 2009 19:18:05 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash after sending a message
Message-ID: <1245118534-sup-3523@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Guillaume Quintard's message of 2009-06-15:
> I think I said "save them in the mbox" to sup-config, and I still get
> that behaviour, so what? Do I dig in the 3.2Go .mbox (please, not that
> one), do I change to "save in sup://sent"? BTW, I renamed my
> sent.mbox, just in case.
If you're seeing that error, you should edit the "From " lines in your
sent.mbox file (which is presumably not the 3.2g one).
You'll see something like:
From guillaume.quintard@gmail.com <date>
And a couple recent messages (i.e. at the bottom of the file) will have
a <date> that's been localized to your locale. That's what has to
change.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 438
Date: Tue, 16 Jun 2009 10:06:48 +0200
From: Guillaume Quintard <guillaume.quintard@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash after sending a message
Message-ID: <1245139562-sup-3587@altis>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Tue Jun 16 04:18:05 +0200 2009:
> If you're seeing that error, you should edit the "From " lines in your
> sent.mbox file (which is presumably not the 3.2g one).
>
> You'll see something like:
> From guillaume.quintard@gmail.com <date>
>
> And a couple recent messages (i.e. at the bottom of the file) will have
> a <date> that's been localized to your locale. That's what has to
> change.
So, I grep'ed "save them in the mbox" from the big mbox, and from
sent.mbox, logically, I should have found 2 occurences, one in my mail,
one in yours, but found only one :-(.
I re-ran sup-config, told it to save in "sent", and that seems better.
But I still don't know where the few messages sent during that time are.
Plus, I sent a mail to one of my alternate addresses, and it popped up
in the mailbox, without the "Sent" label, is that expected?
--
Guillaume
------------------------------
Message: 439
Date: Tue, 16 Jun 2009 07:20:41 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash after sending a message
Message-ID: <1245150910-sup-3911@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Guillaume Quintard's message of Tue Jun 16 04:06:48 -0400 2009:
Hi Guillaume,
> I re-ran sup-config, told it to save in "sent", and that seems better.
> But I still don't know where the few messages sent during that time are.
> Plus, I sent a mail to one of my alternate addresses, and it popped up
> in the mailbox, without the "Sent" label, is that expected?
The patch that allows for using any (most) sources as the outbox
changed the way the sent label gets applied. When the message is
polled, the label 'sent' is applied iff the source of the message
matches the source uri in config.yaml. The default sent source
(outbox) is sup://sent, which translates to $SUB_BASE/sent.mbox
(normally ~/.sup/sent).
The other small behaviour change that this introduced was that
depending on poll intervals, sent messages may not be immediately
added to the index, but instead are picked up on the next run...I see
this with my Maildir outbox. The source used as the outbox is logged
at startup, although if you've restarted sup, that log is lost to you
now...
HTH
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090616/b648e879/attachment-0001.bin>
------------------------------
Message: 440
Date: Tue, 16 Jun 2009 13:52:35 +0200
From: Guillaume Quintard <guillaume.quintard@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash after sending a message
Message-ID: <1245152881-sup-3661@altis>
Content-Type: text/plain; charset=UTF-8
Excerpts from Ben Walton's message of Tue Jun 16 13:20:41 +0200 2009:
> The patch that allows for using any (most) sources as the outbox
> changed the way the sent label gets applied. When the message is
> polled, the label 'sent' is applied iff the source of the message
> matches the source uri in config.yaml. The default sent source
> (outbox) is sup://sent, which translates to $SUB_BASE/sent.mbox
> (normally ~/.sup/sent).
Well, it seems it's not the case, sent messages pop up in the mailbox
without the sent label, last message got this:
"From guillaume.quintard@gmail.com Tue Jun 16 13:47:26 +0200 2009"
as a first line, and it's my main address, yet no label.
Am I misunderstanding something?
--
Guillaume
------------------------------
Message: 441
Date: Tue, 16 Jun 2009 13:42:08 +0100
From: Marcus Williams <marcus-sup@bar-coded.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] [PATCH] Alternative View
Message-ID: <1245156068-sup-7360@tomsk>
Content-Type: text/plain; charset=utf-8
Adds a keypress to toggle to an alternative view in thread index mode.
By default this removes the date, authors and number of threads from the
view leaving more room for labels/snippets
This view is extendable via the alternative-view-widget hook. An example
hook is included in the contrib/hooks directory that implements the
standard sup view as an example. If you use this example your
alternative view will not look any different to the standard sup view.
It is meant to give you a base point for your edits.
---
contrib/hooks/alternate-view-widget.rb | 39 ++++++++++++++++++++++
lib/sup/modes/thread-index-mode.rb | 56 ++++++++++++++++++-------------
2 files changed, 71 insertions(+), 24 deletions(-)
create mode 100644 contrib/hooks/alternate-view-widget.rb
diff --git a/contrib/hooks/alternate-view-widget.rb b/contrib/hooks/alternate-view-widget.rb
new file mode 100644
index 0000000..cf936fd
--- /dev/null
+++ b/contrib/hooks/alternate-view-widget.rb
@@ -0,0 +1,39 @@
+# This hook recreates the standard sup view as the alternate view
+# Note that this will mean there is no difference when toggling
+# between the standard and alternate views in sup. This is meant to
+# serve as a starting point for your own view
+
+date_width = Time::TO_NICE_S_MAX_LEN
+date = thread.date.to_nice_s
+starred = thread.has_label? :starred
+
+dp = thread.direct_participants.any? { |p| AccountManager.is_account? p }
+p = dp || thread.participants.any? { |p| AccountManager.is_account? p }
+
+snippet = thread.snippet + (thread.snippet.empty? ? "" : "...")
+
+subj_color =
+ if thread.has_label?(:draft)
+ :index_draft_color
+ elsif thread.has_label?(:unread)
+ :index_new_color
+ elsif starred
+ :index_starred_color
+ else
+ :index_old_color
+ end
+
+[
+ [:tagged_color, tagged ? ">" : " "],
+ [:none, sprintf("%#{date_width}s", date)],
+ (starred ? [:starred_color, "*"] : [:none, " "]),
+] + from +
+[
+ [subj_color, size_widget_text],
+ [:to_me_color, thread.labels.member?(:attachment) ? "@" : " "],
+ [:to_me_color, dp ? ">" : (p ? '+' : " ")],
+] + (thread.labels - hidden_labels).map { |label| [:label_color, "#{label} "] } +
+[
+ [subj_color, thread.subj + (thread.subj.empty? ? "" : " ")],
+ [:snippet_color, snippet],
+]
diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb
index 5fa4f4c..9124dbd 100644
--- a/lib/sup/modes/thread-index-mode.rb
+++ b/lib/sup/modes/thread-index-mode.rb
@@ -8,6 +8,15 @@ class ThreadIndexMode < LineCursorMode
MIN_FROM_WIDTH = 15
LOAD_MORE_THREAD_NUM = 20
+ HookManager.register "alternate-view-widget", <<EOS
+Generates the per-thread view for each thread.
+Variables:
+ thread: The message thread to be formatted.
+ hidden_labels: the hidden label list
+ tagged: true if this thread is tagged
+ from: the sup default from/author list
+ size_widget_text: the size widget text (from hook or default sup size)
+EOS
HookManager.register "index-mode-size-widget", <<EOS
Generates the per-thread size widget for each thread.
Variables:
@@ -45,7 +54,7 @@ EOS
k.add :apply_to_tagged, "Apply next command to all tagged threads", '+', '='
k.add :join_threads, "Force tagged threads to be joined into the same thread", '#'
k.add :undo, "Undo the previous action", 'u'
- k.add :toggle_minimalist, "Toggle minimalist view", '~'
+ k.add :toggle_alternative_view, "Toggle alternative view", '~'
end
def initialize hidden_labels=[], load_thread_opts={}
@@ -63,7 +72,7 @@ EOS
@hidden_labels = hidden_labels + LabelManager::HIDDEN_RESERVED_LABELS
@date_width = DATE_WIDTH
- @minimal = false
+ @alternative = false
@interrupt_search = false
@@ -264,8 +273,8 @@ EOS
end
end
- def toggle_minimalist
- @minimal = !@minimal
+ def toggle_alternative_view
+ @alternative= !@alternative
regen_text
end
@@ -841,26 +850,8 @@ protected
size_widget_text = sprintf "%#{ @size_widget_width}s", size_widget
-
- if @minimal
- if size_widget!=""
- size_widget_text = "+"
- else
- size_widget_text = " "
- end
- line = []
- else
- line = [
- [:tagged_color, @tags.tagged?(t) ? ">" : " "],
- [:none, sprintf("%#{@date_width}s", date)],
- (starred ? [:starred_color, "*"] : [:none, " "]),
- ] + from
- end
-
-
- line +
- [
- [subj_color, size_widget_text],
+ alternateView = [
+ [subj_color, @alternative?(size_widget!=""?"+":" "):size_widget_text],
[:to_me_color, t.labels.member?(:attachment) ? "@" : " "],
[:to_me_color, dp ? ">" : (p ? '+' : " ")],
] +
@@ -869,6 +860,23 @@ protected
[subj_color, t.subj + (t.subj.empty? ? "" : " ")],
[:snippet_color, snippet],
]
+
+ defaultView = [
+ [:tagged_color, @tags.tagged?(t) ? ">" : " "],
+ [:none, sprintf("%#{@date_width}s", date)],
+ (starred ? [:starred_color, "*"] : [:none, " "]),
+ ] + from + alternateView
+
+ alternateView = [
+ [:tagged_color, @tags.tagged?(t) ? ">" : " "],
+ ] + alternateView
+
+
+ if @alternative
+ HookManager.run("alternate-view-widget", :thread => t, :hidden_labels => @hidden_labels, :tagged => @tags.tagged?(t)?true:false, :from => from, :size_widget_text => size_widget_text) || alternateView
+ else
+ defaultView
+ end
end
def dirty?; @mutex.synchronize { (@hidden_threads.keys + @threads).any? { |t| t.dirty? } } end
--
1.5.4.1
------------------------------
Message: 442
Date: Tue, 16 Jun 2009 13:45:06 +0100
From: Marcus Williams <marcus-sup@bar-coded.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Minimalist view
Message-ID: <1245156233-sup-6049@tomsk>
Content-Type: text/plain; charset=utf-8
On 15.6.2009, William Morgan wrote:
> Yeah, I would generally like to have this type of thing done through
> hooks, but if a lot of people like this mode then I could integrate it
> directly.
New patch sent as separate message - renamed to alternative view and
extendable via the hook mechanism.
Marcus
------------------------------
Message: 443
Date: Tue, 16 Jun 2009 12:34:40 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash after sending a message
Message-ID: <1245170025-sup-1339@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Guillaume Quintard's message of Tue Jun 16 07:52:35 -0400 2009:
> Well, it seems it's not the case, sent messages pop up in the mailbox
> without the sent label, last message got this:
> "From guillaume.quintard@gmail.com Tue Jun 16 13:47:26 +0200 2009"
> as a first line, and it's my main address, yet no label.
The sent label is filtered from the inbox view. Try searching for
sent mail with the search term: label:sent
> Am I misunderstanding something?
Maybe, but I may be misunderstanding too...
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090616/61ef63d0/attachment-0001.bin>
------------------------------
Message: 444
Date: Tue, 16 Jun 2009 17:24:58 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH] index: cleanup interface
Message-ID: <1245198299-18742-1-git-send-email-rlane@club.cc.cmu.edu>
Added the public methods 'each_docid', 'each_message', and 'optimize' to the
index. Removed the 'index' and 'ferret' accessors and modified their callers to
use the new methods. Bonus fixes: sup-dump no longer skips the first message
and sup_sync --start_at can now delete unseen messages.
---
bin/sup-dump | 6 ++----
bin/sup-sync | 21 +++++++--------------
bin/sup-tweak-labels | 2 +-
lib/sup/index.rb | 27 ++++++++++++++++++++-------
4 files changed, 30 insertions(+), 26 deletions(-)
diff --git a/bin/sup-dump b/bin/sup-dump
index 29f6d6e..9b0892e 100755
--- a/bin/sup-dump
+++ b/bin/sup-dump
@@ -24,8 +24,6 @@ end
index = Redwood::Index.new
index.load
-(1 ... index.index.reader.max_doc).each do |i|
- next if index.index.deleted? i
- d = index.index[i]
- puts [d[:message_id], "(" + d[:label] + ")"] * " "
+index.each_message do |m|
+ puts "#{m.id} (#{m.labels * ' '})"
end
diff --git a/bin/sup-sync b/bin/sup-sync
index 9c342d2..a6e3478 100755
--- a/bin/sup-sync
+++ b/bin/sup-sync
@@ -208,24 +208,17 @@ begin
## delete any messages in the index that claim they're from one of
## these sources, but that we didn't see.
- ##
- ## kinda crappy code here, because we delve directly into the Ferret
- ## API.
- ##
- ## TODO: move this to Index, i suppose.
- if (target == :all || target == :changed) && !opts[:start_at]
+ if (target == :all || target == :changed)
$stderr.puts "Deleting missing messages from the index..."
num_del, num_scanned = 0, 0
sources.each do |source|
raise "no source id for #{source}" unless source.id
- q = "+source_id:#{source.id}"
- q += " +source_info: >= #{opts[:start_at]}" if opts[:start_at]
- index.index.search_each(q, :limit => :all) do |docid, score|
+ index.each_message :source_id => source.id do |m|
num_scanned += 1
- mid = index.index[docid][:message_id]
- unless seen[mid]
- puts "Deleting #{mid}" if opts[:verbose]
- index.index.delete docid unless opts[:dry_run]
+ unless seen[m.id]
+ next unless m.source_info >= opts[:start_at] if opts[:start_at]
+ puts "Deleting #{m.id}" if opts[:verbose]
+ index.drop_entry m.id unless opts[:dry_run]
num_del += 1
end
end
@@ -237,7 +230,7 @@ begin
if opts[:optimize]
$stderr.puts "Optimizing index..."
- optt = time { index.index.optimize unless opts[:dry_run] }
+ optt = time { index.optimize unless opts[:dry_run] }
$stderr.puts "Optimized index of size #{index.size} in #{optt}s."
end
rescue Redwood::FatalSourceError => e
diff --git a/bin/sup-tweak-labels b/bin/sup-tweak-labels
index 538db8b..f526a95 100755
--- a/bin/sup-tweak-labels
+++ b/bin/sup-tweak-labels
@@ -118,7 +118,7 @@ begin
unless num_changed == 0
$stderr.puts "Optimizing index..."
- index.ferret.optimize unless opts[:dry_run]
+ index.optimize unless opts[:dry_run]
end
rescue Exception => e
diff --git a/lib/sup/index.rb b/lib/sup/index.rb
index ca01ee7..037b941 100644
--- a/lib/sup/index.rb
+++ b/lib/sup/index.rb
@@ -24,11 +24,6 @@ class Index
include Singleton
- ## these two accessors should ONLY be used by single-threaded programs.
- ## otherwise you will have a naughty ferret on your hands.
- attr_reader :index
- alias ferret index
-
def initialize dir=BASE_DIR
@index_mutex = Monitor.new
@@ -151,7 +146,7 @@ EOS
if File.exists? dir
Redwood::log "loading index..."
@index_mutex.synchronize do
- @index = Ferret::Index::Index.new(:path => dir, :analyzer => @analyzer)
+ @index = Ferret::Index::Index.new(:path => dir, :analyzer => @analyzer, :id_field => 'message_id')
Redwood::log "loaded index of #{@index.size} messages"
end
else
@@ -171,7 +166,7 @@ EOS
field_infos.add_field :refs
field_infos.add_field :snippet, :index => :no, :term_vector => :no
field_infos.create_index dir
- @index = Ferret::Index::Index.new(:path => dir, :analyzer => @analyzer)
+ @index = Ferret::Index::Index.new(:path => dir, :analyzer => @analyzer, :id_field => 'message_id')
end
end
end
@@ -496,6 +491,22 @@ EOS
results.hits.map { |hit| hit.doc }
end
+ def each_docid opts={}
+ query = build_query opts
+ results = @index_mutex.synchronize { @index.search query, :limit => (opts[:limit] || :all) }
+ results.hits.map { |hit| yield hit.doc }
+ end
+
+ def each_message opts={}
+ each_docid opts do |docid|
+ yield build_message(docid)
+ end
+ end
+
+ def optimize
+ @index_mutex.synchronize { @index.optimize }
+ end
+
protected
class ParseError < StandardError; end
@@ -621,6 +632,8 @@ protected
query.add_query Ferret::Search::TermQuery.new("label", "spam"), :must_not unless opts[:load_spam] || labels.include?(:spam)
query.add_query Ferret::Search::TermQuery.new("label", "deleted"), :must_not unless opts[:load_deleted] || labels.include?(:deleted)
query.add_query Ferret::Search::TermQuery.new("label", "killed"), :must_not if opts[:skip_killed]
+
+ query.add_query Ferret::Search::TermQuery.new("source_id", opts[:source_id]), :must if opts[:source_id]
query
end
--
1.6.0.4
------------------------------
Message: 445
Date: Tue, 16 Jun 2009 17:24:59 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH] index: consistent naming
Message-ID: <1245198299-18742-2-git-send-email-rlane@club.cc.cmu.edu>
Replaced use of run_query with each_docid
Rename instances of ferret query objects to 'ferret_query'
Rename 'build_query' to 'build_ferret_query'
Rename hashes passed to index methods to 'query'
Rename 'parse_user_query_string' to 'parse_query'
Change 'parse_query' to return a query hash
Rename 'drop_entry' to 'delete' and modify callers to pass msgid
---
bin/sup-sync | 2 +-
bin/sup-tweak-labels | 4 +-
lib/sup/draft.rb | 2 +-
lib/sup/index.rb | 108 +++++++++++++++------------------
lib/sup/modes/search-results-mode.rb | 20 +++----
5 files changed, 63 insertions(+), 73 deletions(-)
diff --git a/bin/sup-sync b/bin/sup-sync
index a6e3478..a759cbe 100755
--- a/bin/sup-sync
+++ b/bin/sup-sync
@@ -218,7 +218,7 @@ begin
unless seen[m.id]
next unless m.source_info >= opts[:start_at] if opts[:start_at]
puts "Deleting #{m.id}" if opts[:verbose]
- index.drop_entry m.id unless opts[:dry_run]
+ index.delete m.id unless opts[:dry_run]
num_del += 1
end
end
diff --git a/bin/sup-tweak-labels b/bin/sup-tweak-labels
index f526a95..6f603e2 100755
--- a/bin/sup-tweak-labels
+++ b/bin/sup-tweak-labels
@@ -2,6 +2,7 @@
require 'rubygems'
require 'trollop'
+require 'enumerator'
require "sup"
class Float
@@ -81,7 +82,8 @@ begin
end
query += ' ' + opts[:query] if opts[:query]
- docs = Redwood::Index.run_query query
+ parsed_query = index.parse_query query
+ docs = Enumerable::Enumerator.new(index, :each_docid, parsed_query).map
num_total = docs.size
$stderr.puts "Found #{num_total} documents across #{source_ids.length} sources. Scanning..."
diff --git a/lib/sup/draft.rb b/lib/sup/draft.rb
index 32266b5..9127739 100644
--- a/lib/sup/draft.rb
+++ b/lib/sup/draft.rb
@@ -37,7 +37,7 @@ class DraftManager
return
end
raise ArgumentError, "not a draft: source id #{entry[:source_id].inspect}, should be #{DraftManager.source_id.inspect} for #{m.id.inspect} / docno #{docid}" unless entry[:source_id].to_i == DraftManager.source_id
- Index.drop_entry docid
+ Index.delete m.id
File.delete @source.fn_for_offset(entry[:source_info])
UpdateManager.relay self, :single_message_deleted, m
end
diff --git a/lib/sup/index.rb b/lib/sup/index.rb
index 037b941..d15e7bb 100644
--- a/lib/sup/index.rb
+++ b/lib/sup/index.rb
@@ -279,28 +279,28 @@ EOS
## you should probably not call this on a block that doesn't break
## rather quickly because the results can be very large.
EACH_BY_DATE_NUM = 100
- def each_id_by_date opts={}
+ def each_id_by_date query={}
return if empty? # otherwise ferret barfs ###TODO: remove this once my ferret patch is accepted
- query = build_query opts
+ ferret_query = build_ferret_query query
offset = 0
while true
- limit = (opts[:limit])? [EACH_BY_DATE_NUM, opts[:limit] - offset].min : EACH_BY_DATE_NUM
- results = @index_mutex.synchronize { @index.search query, :sort => "date DESC", :limit => limit, :offset => offset }
- Redwood::log "got #{results.total_hits} results for query (offset #{offset}) #{query.inspect}"
+ limit = (query[:limit])? [EACH_BY_DATE_NUM, query[:limit] - offset].min : EACH_BY_DATE_NUM
+ results = @index_mutex.synchronize { @index.search ferret_query, :sort => "date DESC", :limit => limit, :offset => offset }
+ Redwood::log "got #{results.total_hits} results for query (offset #{offset}) #{ferret_query.inspect}"
results.hits.each do |hit|
yield @index_mutex.synchronize { @index[hit.doc][:message_id] }, lambda { build_message hit.doc }
end
- break if opts[:limit] and offset >= opts[:limit] - limit
+ break if query[:limit] and offset >= query[:limit] - limit
break if offset >= results.total_hits - limit
offset += limit
end
end
- def num_results_for opts={}
+ def num_results_for query={}
return 0 if empty? # otherwise ferret barfs ###TODO: remove this once my ferret patch is accepted
- q = build_query opts
- @index_mutex.synchronize { @index.search(q, :limit => 1).total_hits }
+ ferret_query = build_ferret_query query
+ @index_mutex.synchronize { @index.search(ferret_query, :limit => 1).total_hits }
end
## yield all messages in the thread containing 'm' by repeatedly
@@ -313,7 +313,7 @@ EOS
## is found.
SAME_SUBJECT_DATE_LIMIT = 7
MAX_CLAUSES = 1000
- def each_message_in_thread_for m, opts={}
+ def each_message_in_thread_for m, query={}
#Redwood::log "Building thread for #{m.id}: #{m.subj}"
messages = {}
searched = {}
@@ -332,7 +332,7 @@ EOS
q.add_query sq, :must
q.add_query Ferret::Search::RangeQuery.new(:date, :>= => date_min.to_indexable_s, :<= => date_max.to_indexable_s), :must
- q = build_query :qobj => q
+ q = build_ferret_query :qobj => q
p1 = @index_mutex.synchronize { @index.search(q).hits.map { |hit| @index[hit.doc][:message_id] } }
Redwood::log "found #{p1.size} results for subject query #{q}"
@@ -343,7 +343,7 @@ EOS
pending = (pending + p1 + p2).uniq
end
- until pending.empty? || (opts[:limit] && messages.size >= opts[:limit])
+ until pending.empty? || (query[:limit] && messages.size >= query[:limit])
q = Ferret::Search::BooleanQuery.new true
# this disappeared in newer ferrets... wtf.
# q.max_clause_count = 2048
@@ -356,14 +356,14 @@ EOS
end
pending = pending[lim .. -1]
- q = build_query :qobj => q
+ q = build_ferret_query :qobj => q
num_queries += 1
killed = false
@index_mutex.synchronize do
@index.search_each(q, :limit => :all) do |docid, score|
- break if opts[:limit] && messages.size >= opts[:limit]
- if @index[docid][:label].split(/\s+/).include?("killed") && opts[:skip_killed]
+ break if query[:limit] && messages.size >= query[:limit]
+ if @index[docid][:label].split(/\s+/).include?("killed") && query[:skip_killed]
killed = true
break
end
@@ -419,7 +419,7 @@ EOS
def wrap_subj subj; "__START_SUBJECT__ #{subj} __END_SUBJECT__"; end
def unwrap_subj subj; subj =~ /__START_SUBJECT__ (.*?) __END_SUBJECT__/ && $1; end
- def drop_entry docno; @index_mutex.synchronize { @index.delete docno } end
+ def delete id; @index_mutex.synchronize { @index.delete id } end
def load_entry_for_id mid
@index_mutex.synchronize do
@@ -478,27 +478,14 @@ EOS
@index_mutex.synchronize { @index.search(q, :limit => 1).total_hits > 0 }
end
- ## takes a user query string and returns the list of docids for messages
- ## that match the query.
- ##
- ## messages can then be loaded from the index with #build_message.
- ##
- ## raises a ParseError if the parsing failed.
- def run_query query
- qobj, opts = Redwood::Index.parse_user_query_string query
- query = Redwood::Index.build_query opts.merge(:qobj => qobj)
- results = @index.search query, :limit => (opts[:limit] || :all)
- results.hits.map { |hit| hit.doc }
- end
-
- def each_docid opts={}
- query = build_query opts
- results = @index_mutex.synchronize { @index.search query, :limit => (opts[:limit] || :all) }
+ def each_docid query={}
+ ferret_query = build_ferret_query query
+ results = @index_mutex.synchronize { @index.search ferret_query, :limit => (query[:limit] || :all) }
results.hits.map { |hit| yield hit.doc }
end
- def each_message opts={}
- each_docid opts do |docid|
+ def each_message query={}
+ each_docid query do |docid|
yield build_message(docid)
end
end
@@ -507,16 +494,15 @@ EOS
@index_mutex.synchronize { @index.optimize }
end
-protected
-
class ParseError < StandardError; end
- ## parse a query string from the user. returns a query object and a set of
- ## extra flags; both of these are meant to be passed to #build_query.
+ ## parse a query string from the user. returns a query object
+ ## that can be passed to any index method with a 'query'
+ ## argument, as well as build_ferret_query.
##
## raises a ParseError if something went wrong.
- def parse_user_query_string s
- extraopts = {}
+ def parse_query s
+ query = {}
subs = s.gsub(/\b(to|from):(\S+)\b/) do
field, name = $1, $2
@@ -542,8 +528,8 @@ protected
## final stage of query processing. if the user wants to search spam
## messages, not adding that is the right thing; if he doesn't want to
## search spam messages, then not adding it won't have any effect.
- extraopts[:load_spam] = true if subs =~ /\blabel:spam\b/
- extraopts[:load_deleted] = true if subs =~ /\blabel:deleted\b/
+ query[:load_spam] = true if subs =~ /\blabel:spam\b/
+ query[:load_deleted] = true if subs =~ /\blabel:deleted\b/
## gmail style "is" operator
subs = subs.gsub(/\b(is|has):(\S+)\b/) do
@@ -552,10 +538,10 @@ protected
when "read"
"-label:unread"
when "spam"
- extraopts[:load_spam] = true
+ query[:load_spam] = true
"label:spam"
when "deleted"
- extraopts[:load_deleted] = true
+ query[:load_deleted] = true
"label:deleted"
else
"label:#{$2}"
@@ -601,7 +587,7 @@ protected
subs = subs.gsub(/\blimit:(\S+)\b/) do
lim = $1
if lim =~ /^\d+$/
- extraopts[:limit] = lim.to_i
+ query[:limit] = lim.to_i
''
else
raise ParseError, "non-numeric limit #{lim.inspect}"
@@ -609,32 +595,36 @@ protected
end
begin
- [@qparser.parse(subs), extraopts]
+ query[:qobj] = @qparser.parse(subs)
+ query[:text] = s
+ query
rescue Ferret::QueryParser::QueryParseException => e
raise ParseError, e.message
end
end
- def build_query opts
- query = Ferret::Search::BooleanQuery.new
- query.add_query opts[:qobj], :must if opts[:qobj]
- labels = ([opts[:label]] + (opts[:labels] || [])).compact
- labels.each { |t| query.add_query Ferret::Search::TermQuery.new("label", t.to_s), :must }
- if opts[:participants]
+private
+
+ def build_ferret_query query
+ q = Ferret::Search::BooleanQuery.new
+ q.add_query query[:qobj], :must if query[:qobj]
+ labels = ([query[:label]] + (query[:labels] || [])).compact
+ labels.each { |t| q.add_query Ferret::Search::TermQuery.new("label", t.to_s), :must }
+ if query[:participants]
q2 = Ferret::Search::BooleanQuery.new
- opts[:participants].each do |p|
+ query[:participants].each do |p|
q2.add_query Ferret::Search::TermQuery.new("from", p.email), :should
q2.add_query Ferret::Search::TermQuery.new("to", p.email), :should
end
- query.add_query q2, :must
+ q.add_query q2, :must
end
- query.add_query Ferret::Search::TermQuery.new("label", "spam"), :must_not unless opts[:load_spam] || labels.include?(:spam)
- query.add_query Ferret::Search::TermQuery.new("label", "deleted"), :must_not unless opts[:load_deleted] || labels.include?(:deleted)
- query.add_query Ferret::Search::TermQuery.new("label", "killed"), :must_not if opts[:skip_killed]
+ q.add_query Ferret::Search::TermQuery.new("label", "spam"), :must_not unless query[:load_spam] || labels.include?(:spam)
+ q.add_query Ferret::Search::TermQuery.new("label", "deleted"), :must_not unless query[:load_deleted] || labels.include?(:deleted)
+ q.add_query Ferret::Search::TermQuery.new("label", "killed"), :must_not if query[:skip_killed]
- query.add_query Ferret::Search::TermQuery.new("source_id", opts[:source_id]), :must if opts[:source_id]
- query
+ q.add_query Ferret::Search::TermQuery.new("source_id", query[:source_id]), :must if query[:source_id]
+ q
end
def save_sources fn=Redwood::SOURCE_FN
diff --git a/lib/sup/modes/search-results-mode.rb b/lib/sup/modes/search-results-mode.rb
index 227ee9b..121e817 100644
--- a/lib/sup/modes/search-results-mode.rb
+++ b/lib/sup/modes/search-results-mode.rb
@@ -1,11 +1,9 @@
module Redwood
class SearchResultsMode < ThreadIndexMode
- def initialize qobj, qopts = nil
- @qobj = qobj
- @qopts = qopts
-
- super [], { :qobj => @qobj }.merge(@qopts)
+ def initialize query
+ @query = query
+ super [], query
end
register_keymap do |k|
@@ -13,9 +11,9 @@ class SearchResultsMode < ThreadIndexMode
end
def refine_search
- query = BufferManager.ask :search, "refine query: ", (@qobj.to_s + " ")
- return unless query && query !~ /^\s*$/
- SearchResultsMode.spawn_from_query query
+ text = BufferManager.ask :search, "refine query: ", (@query[:text] + " ")
+ return unless text && text !~ /^\s*$/
+ SearchResultsMode.spawn_from_query text
end
## a proper is_relevant? method requires some way of asking ferret
@@ -26,10 +24,10 @@ class SearchResultsMode < ThreadIndexMode
def self.spawn_from_query text
begin
- qobj, extraopts = Index.parse_user_query_string(text)
- return unless qobj
+ query = Index.parse_query(text)
+ return unless query
short_text = text.length < 20 ? text : text[0 ... 20] + "..."
- mode = SearchResultsMode.new qobj, extraopts
+ mode = SearchResultsMode.new query
BufferManager.spawn "search: \"#{short_text}\"", mode
mode.load_threads :num => mode.buffer.content_height
rescue Index::ParseError => e
--
1.6.0.4
------------------------------
Message: 446
Date: Wed, 17 Jun 2009 11:13:07 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Yet Another Offlineimap Thread (YAOT)
Message-ID:
<80055d7c0906170813t55bd3f7dk1286e68eea9e2ad4@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Anyway, so.
I set up a loop to run offlineimap on 5 minute intervals. Now, every
so often, sup complains that it's fallen out of sync (I have no other
clients doing anything there, just sup and offlineimap). I can't
imagine why this is happening. Hints?
-AT
------------------------------
Message: 447
Date: Wed, 17 Jun 2009 17:29:36 +0200
From: Ingmar Vanhassel <ingmar@exherbo.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Yet Another Offlineimap Thread (YAOT)
Message-ID: <1245252332-sup-8862@cannonball>
Content-Type: text/plain; charset=UTF-8
Excerpts from Andrei Thorp's message of Wed Jun 17 17:13:07 +0200 2009:
> Anyway, so.
>
> I set up a loop to run offlineimap on 5 minute intervals. Now, every
> so often, sup complains that it's fallen out of sync (I have no other
> clients doing anything there, just sup and offlineimap). I can't
> imagine why this is happening. Hints?
>
> -AT
Something is changing the state of your IMAP server, offlineimap is
mirroring that, and sup notices.
Are you running any other client (even using gmail.com) on your gmail
IMAP?
--
Exherbo KDE, X.org maintainer
------------------------------
Message: 448
Date: Wed, 17 Jun 2009 11:54:44 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] Fwd: Yet Another Offlineimap Thread (YAOT)
Message-ID:
<80055d7c0906170854p214520ck73e8d498f6a0ba1c@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Wed, Jun 17, 2009 at 11:29 AM, Ingmar Vanhassel <ingmar@exherbo.org> wrote:
>
> Excerpts from Andrei Thorp's message of Wed Jun 17 17:13:07 +0200 2009:
> > Anyway, so.
> >
> > I set up a loop to run offlineimap on 5 minute intervals. Now, every
> > so often, sup complains that it's fallen out of sync (I have no other
> > clients doing anything there, just sup and offlineimap). I can't
> > imagine why this is happening. Hints?
> >
> > -AT
>
> Something is changing the state of your IMAP server, offlineimap is
> mirroring that, and sup notices.
>
> Are you running any other client (even using gmail.com) on your gmail
> IMAP?
Ahh, yes, I understand. Well, if you read my original post in this
thread, I've actually not been able to figure out how to get sup to
send via different servers based on different situations (I'd like it
to use different send commands for work / gmail).
And yes, I've been using gmail, silly me.
> ?- Does imap support a way to say which mails have been read and not?
> I think it probably does. If this is the case, can sup-sync-back
> somehow do this? It'd be nice if my gmail understood when a mail has
> been read, so when I sync back up with offlineimap, it's all savvy.
> ?- I vaguely saw some tricks here for how to reply with different
> e-mail addresses and stuff. I'd like to execute a whole different
> command when replying in some situations, so that my mail gets sent
> through gmail's smtp server instead of my work's one, for example. How
> would I achieve this?
> ?- I don't see a daemon mode for offlineimap. I guess the expected
> usage is to make it quiet and put it in a cron/regular script? Am I
> correct?
Cheers,
-AT
------------------------------
Message: 449
Date: Wed, 17 Jun 2009 09:04:34 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] display_length issue with special-characters
on non-UTF8 terminal
Message-ID: <1245254636-sup-2210@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Tarko Tikan's message of 2009-06-13:
> william wrote:
> > Does this patch fix the issue? If so, I will release an 0.8.1.
>
> Yes it does. patch :) But I still don't have better idea how to fix
> it so it'll have to stay like this.
I have released an 0.8.1 which has this patch in it.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 450
Date: Wed, 17 Jun 2009 09:14:56 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup and ncursesw
Message-ID: <1245255253-sup-5713@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from William Morgan's message of 2009-06-15:
> (And that's typically the point where you see the difference between
> ncurses.so with and without the patch.)
BTW, it looks like the patch will not be necessary if we manage to move
to 1.9.1:
http://redmine.ruby-lang.org/issues/show/975
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 451
Date: Wed, 17 Jun 2009 12:20:30 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Yet Another Offlineimap Thread (YAOT)
Message-ID:
<80055d7c0906170920p328f6a79ye7e1f40adb2a3e0e@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Forward.
Excerpts from Andrei Thorp's message of Wed Jun 17 17:54:16 +0200 2009:
> On Wed, Jun 17, 2009 at 11:29 AM, Ingmar Vanhassel <ingmar@exherbo.org> wrote:
> >
> > Excerpts from Andrei Thorp's message of Wed Jun 17 17:13:07 +0200 2009:
> > > Anyway, so.
> > >
> > > I set up a loop to run offlineimap on 5 minute intervals. Now, every
> > > so often, sup complains that it's fallen out of sync (I have no other
> > > clients doing anything there, just sup and offlineimap). I can't
> > > imagine why this is happening. Hints?
> > >
> > > -AT
> >
> > Something is changing the state of your IMAP server, offlineimap is
> > mirroring that, and sup notices.
> >
> > Are you running any other client (even using gmail.com) on your gmail
> > IMAP?
>
> Ahh, yes, I understand. Well, if you read my original post in this
> thread, I've actually not been able to figure out how to get sup to
> send via different servers based on different situations (I'd like it
> to use different send commands for work / gmail).
Yeah, I was try to be lazy ;-)
For using multiple accounts, see
http://sup.rubyforge.org/wiki/wiki.pl?MultipleAccountsAndReply
I use 'msmtp --account=foo -t' myself, since msmtp was incredibly easy
to configure.
- Configure some defaults for all accounts (logging, tls, see `man msmtp`)
- Write a different account section in your msmtprc, then in sup's
?config.yaml, configure those accounts, where the sendmail command to
?run has an --acount=foo parameter, corresponding to an account in your
?msmtprc
Some people use a reply-from hook for dynamically setting from From:
header, you may want to search the archives if that's something you'd
like to use.
--
Exherbo KDE, X.org maintainer
------------------------------
Message: 452
Date: Wed, 17 Jun 2009 12:22:47 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Yet Another Offlineimap Thread (YAOT)
Message-ID:
<80055d7c0906170922o732fc260o3a7bdd5a825ac9c8@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Wed, Jun 17, 2009 at 12:10 PM, Ingmar Vanhassel <ingmar@exherbo.org> wrote:
> For using multiple accounts, see
> http://sup.rubyforge.org/wiki/wiki.pl?MultipleAccountsAndReply
Perfect! So now just the one issue of sup-sync-back. I guess one
"solution" would be for me to mark things as deleted instead of
archived/read, and I guess sync-back understands this. I don't love
this though. Any other suggestions?
-AT
------------------------------
Message: 453
Date: Wed, 17 Jun 2009 20:34:08 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] display_length issue with special-characters
on non-UTF8 terminal
Message-ID: <1245263427-sup-997@ausone.local>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Wed Jun 17 18:04:34 +0200 2009:
> Reformatted excerpts from Tarko Tikan's message of 2009-06-13:
> > william wrote:
> > > Does this patch fix the issue? If so, I will release an 0.8.1.
> >
> > Yes it does. patch :) But I still don't have better idea how to fix
> > it so it'll have to stay like this.
>
> I have released an 0.8.1 which has this patch in it.
I still have issues with display_length. I use UTF-8, urxvt
and some characters disappear when a line contains special characters.
For instance in thread-view-mode if a line contains a special character
then the last character is dropped.
I've "fixed" the issue by reverting a display_length call to a size call
as in the attached patch.
diff --git a/lib/sup/buffer.rb b/lib/sup/buffer.rb
index 8eedf96..795b4c9 100644
--- a/lib/sup/buffer.rb
+++ b/lib/sup/buffer.rb
@@ -114,7 +114,7 @@ class Buffer
stringl += 1 while stringl < s.length && s[0 ... stringl].display_length < maxl
@w.mvaddstr y, x, s[0 ... stringl]
unless opts[:no_fill]
- l = s.display_length
+ l = s.size
unless l >= maxl
@w.mvaddstr(y, x + l, " " * (maxl - l))
end
--
Nicolas Pouillard
http://nicolaspouillard.fr
------------------------------
Message: 454
Date: Thu, 18 Jun 2009 09:39:10 +1200
From: Jim Cheetham <jim@gonzul.net>
To: sup-talk@rubyforge.org
Subject: [sup-talk] Character encoding when displaying
quoted-printable messages
Message-ID:
<f4cc59760906171439q1b8983adw2008843b1ec02990@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi, I've been looking at sup for only a day, as I'm trying to find a
decent email client. I migrated from mutt to gmail, but now it's time
to move away from gmail because their client is not smart enough.
Sup has passed my number 1 feature test; I can easily read messages
while keeping multiple unsent messages available. Mutt does that, but
it's not easy to see what messages you are currently working on.
However, I'm coming across some character decoding issues with
quoted-printable that are making some messages hard to read. Any
advice on how to improve things would be welcome ... In the example
below, a NBSP entity is showing up as the characters "M-BM-"
I'm on Ubuntu 9.04, with the current master from git. Sup is running
in GNOME Terminal 2.26.0, with UTF-8 encoding, although unsurprisingly
switching to ISO-8859-1 makes no difference. $TERM=xterm (or 'screen'.
vt100 and vt220 cause sup to halt at startup). This is the text that
gets displayed for a sample message sent from Yahoo! mail ...
Visible in sup thread-view-mode:
videos for specific hints regarding the gestures.M-BM- Do you have a decent
recording device?M-BM- Have you seen what's available?M-BM- Do you have
editing software?
Message source:
X-Mailer: YahooMailClassic/5.4.12 YahooMailWebService/0.7.289.15
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1465842634-1245251490=:14771"
...
--0-1465842634-1245251490=:14771
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
...
more videos for specific hints regarding the gestures.=A0 Do you have a dec=
ent video recording device?=A0 Have you seen what's available?=A0 Do you ha=
ve any video editing software?
Displayed in Gmail client:
I was thinking about cleaning up the videos on YouTube, and perhaps
adding more videos for specific hints regarding the gestures. Do you
have a decent video recording device? Have you seen what's available?
Do you have any video editing software?
HTML source when viewing the MIME attached message locally:
I was thinking about cleaning up the videos on YouTube, and perhaps
adding more videos for specific hints regarding the gestures. Do
you have a decent video recording device? Have you seen what's
available? Do you have any video editing software?<br><br>[1]
------------------------------
Message: 455
Date: Thu, 18 Jun 2009 11:00:47 +0200
From: Fabio Riga <usul@aruba.it>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash after sending a message
Message-ID: <1245315146-sup-2575@viajero>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of lun giu 15 18:53:47 +0200 2009:
> Sorry about that. The problem is that Sup was writing an invalid
> sent.mbox file in certain locales, including yours, and then dying when
> it couldn't parse its own file. If you update to the latest git, this
> should be fixed for new messages, and you shouldn't need the LANG=C
> hack.
>
> Please let me know if you have any more problems.
It seems ok with sup-git. I'd rather prefer to use a "stable" branch
instead of bleeding-edge, I don't feel like a developer...
Thank you,
Fabio
--
Fabio Riga
348 4458014 - fabio@comunicattiva.it
ComunicAttiva S.a.s. di Silvana D'Agata & C.
via Campestre,189 - Sesto San Giovanni (MI) - Italia
tel. 02 97373202 - fax 02 97373474
------------------------------
Message: 456
Date: Thu, 18 Jun 2009 11:26:03 +0200
From: J?rg-Hendrik Bach <bachjh@googlemail.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup and ncursesw
Message-ID:
<91de50e10906180226sf31cf94m43b18c316e9f898@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
2009/6/17 William Morgan <wmorgan-sup@masanjin.net>:
> Reformatted excerpts from William Morgan's message of 2009-06-15:
>> (And that's typically the point where you see the difference between
>> ncurses.so with and without the patch.)
>
> BTW, it looks like the patch will not be necessary if we manage to move
> to 1.9.1:
The patch actually works for me now, and probably had been working all
the time. Whatever was screwed, after I manually redrew the screen
_twice_ after the strange chars appeared, it was all fine.
thanks for the help,
- JH
------------------------------
Message: 457
Date: Thu, 18 Jun 2009 14:31:45 -0300
From: Mariano Mara <mariano.mara@gmail.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] invalid source error
Message-ID: <20090618173145.GA4186@kafka>
Content-Type: text/plain; charset=us-ascii
Hi everyone. I have been using sup for quite some time now (great
software by the way) and although I'm not using it as my main mail
client I find it really useful to read several mailing lists I'm
subscribed.
I downloaded a few mailman archives and after a little formatting I was
able to import them in sup as mboxes. One of them, however had a lot of
errors when trying sup-sync and after a few hours of troubleshooting I
gave up and remove it (not knowing a better way, I just deleted it from
my sources.yaml).
But now, when I try to start sup I'm hitting
--- RuntimeError from thread: load threads for thread-index-mode
invalid source 19
Of course source 19 does not exist any more in sources.yaml and I don't
know what else I can do to fix it.
If you guys can give an advice I will really appreciate it.
This is my current sup version:
$ sup --version
[Thu Jun 18 14:30:08 -0300 2009] using character set encoding "UTF-8"
sup v0.8.1
and this is the content of exception-log.txt
--- RuntimeError from thread: load threads for thread-index-mode
invalid source 19
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/index.rb:403:in
`build_message'
/usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/index.rb:399:in
`build_message'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/index.rb:297:in
`each_id_by_date'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/thread.rb:330:in `call'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/thread.rb:330:in
`load_n_threads'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/index.rb:297:in
`each_id_by_date'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/index.rb:296:in `each'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/index.rb:296:in
`each_id_by_date'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/thread.rb:326:in
`load_n_threads'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:620:in
`__unprotected_load_n_threads'
(eval):12:in `load_n_threads'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:604:in
`load_n_threads_background'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:71:in
`reporting_thread'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:69:in `initialize'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:69:in `new'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:69:in
`reporting_thread'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:603:in
`load_n_threads_background'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:673:in
`__unprotected_load_threads'
(eval):12:in `load_threads'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/bin/sup:206
/usr/bin/sup:19:in `load'
/usr/bin/sup:19
Mariano
------------------------------
Message: 458
Date: Thu, 18 Jun 2009 23:58:54 -0300
From: Mariano Mara <mariano.mara@gmail.com>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] invalid source error
Message-ID:
<c1d7c48b0906181958j656eb638jf36263c682ba2756@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
2009/6/18 Mariano Mara <mariano.mara@gmail.com>
> Hi everyone. I have been using sup for quite some time now (great
> software by the way) and although I'm not using it as my main mail
> client I find it really useful to read several mailing lists I'm
> subscribed.
> I downloaded a few mailman archives and after a little formatting I was
> able to import them in sup as mboxes. One of them, however had a lot of
> errors when trying sup-sync and after a few hours of troubleshooting I
> gave up and remove it (not knowing a better way, I just deleted it from
> my sources.yaml).
> But now, when I try to start sup I'm hitting
>
> --- RuntimeError from thread: load threads for thread-index-mode
> invalid source 19
>
> Nevermind. Deleting the whole content of ~/.sup/ferret/ made the trick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090618/fbc28e20/attachment-0001.html>
------------------------------
Message: 459
Date: Fri, 19 Jun 2009 13:27:50 +0200
From: Guillaume Quintard <guillaume.quintard@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Carriage return
Message-ID: <1245410627-sup-2801@altis>
Content-Type: text/plain; charset=UTF-8
Sup seems to work smoothly now (no noticeable problem with the sent label, hoorray!!) (not complaining since I'm using the next branch). Now I'd like to fix one little annoying thing: in case of error, messages will use the newline, but not the carriage return, meaning mutiple lines messages will appear like this:
yadda yadda
yadda yadda yadda yadda
yadda yadda
Is there a way to fix that?
--
Guillaume
------------------------------
Message: 460
Date: Fri, 19 Jun 2009 14:40:07 +0200
From: Christopher Bertels <mailinglist@flasht.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Delete single message in thread-view?
Message-ID: <1245415127-sup-2107@thinkpad-ubuntu>
Content-Type: text/plain; charset=UTF-8
Hi!
Is it possible to delete a single message from a thread?
I haven't found a way to do this, but maybe I'm just blind.
Cheers,
Christopher.
--
================================
Christopher Bertels
http://www.adztec-independent.de
------------------------------
Message: 461
Date: Fri, 19 Jun 2009 09:51:12 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Carriage return
Message-ID: <1245419195-sup-7199@Longbow>
Content-Type: text/plain; charset=utf8
I'm not sure that this is carriage return related (Linux doesn't tend to
use these, right?). However, I'm certainly getting similar corruption.
This happens with errors, as well as just randomly sometimes after sup
closes/does something. My entire terminal actaully goes out of whack
and starts behaving like this.
I acutally just blamed it on my terminal being buggy somehow
(XFCE Terminal). I still think that's probably it. I'm not sure why sup
causes it though.
Anyway, reset fixes it when that happens. But yeah.... but yeah.
Cheers :)
--
Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
Resisting temptation is easier when you think you'll probably get
another chance later on.
------------------------------
Message: 462
Date: Fri, 19 Jun 2009 12:23:23 -0400
From: Joe W?lfel <joe@talkhouse.com>
To: Sup Mailing List <sup-talk@rubyforge.org>
Subject: [sup-talk] [PATCH] Hack that fixes "undefined method
multipart?" exception.
Message-ID: <1245428166-sup-5693@joe-wolfels-power-mac-g5.local>
Content-Type: text/plain; charset=UTF-8
On sup-sync -c I kept getting an exception on line 372 of message.rb in the
message_to_chunks function. The cause was that 'm' was supposed to be a
message that needed to be converted to chunks. Instead, it was
aRedwood::Chunk::CryptoNotice, which didn't have a mulitipart? method. So it
crashed on "if m.multipart?". My assumption is that a
Redwood::Chunk::CryptoNotice is already a chunk and doesn't need to be
converted. So my solution is just to return it. That fixes the bug. But
probably there is a more sensible fix. Possibly m should never have been a
chunk in the first place.
---
lib/sup/message.rb | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/lib/sup/message.rb b/lib/sup/message.rb
index ded577a..caf0cdb 100644
--- a/lib/sup/message.rb
+++ b/lib/sup/message.rb
@@ -369,6 +369,11 @@ private
## takes a RMail::Message, breaks it into Chunk:: classes.
def message_to_chunks m, encrypted=false, sibling_types=[]
+ ## TODO: Replace the following four lines with something more sensible.
+ unless m.respond_to? :multipart?
+ puts "I bet this is a Redwood::Chunk::CryptoNotice: \n#{m.class}"
+ return m
+ end
if m.multipart?
chunks =
case m.header.content_type
--
1.6.2.1
------------------------------
Message: 463
Date: Sat, 20 Jun 2009 13:49:59 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH 0/18] Xapian-based index
Message-ID: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
This patch series refactors the Index class to remove Ferret-isms and support
multiple index implementations. The included XapianIndex is a bit faster at
indexing messages and significantly faster when searching because it
precomputes thread membership. It also works on Ruby 1.9.1.
You can enable the new index with the environment variable SUP_INDEX=xapian.
It's missing a couple of features, notably threading by subject. I'm sure there
are many more bugs left, so I'd appreciate any testing or review you all can
provide.
These patches depend on the two I posted June 16: 'cleanup interface' and 'consistent naming'.
------------------------------
Message: 464
Date: Sat, 20 Jun 2009 13:50:00 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH 01/18] remove load_entry_for_id call in
sup-recover-sources
Message-ID: <1245531017-9907-2-git-send-email-rlane@club.cc.cmu.edu>
---
bin/sup-recover-sources | 12 +++++-------
lib/sup/index.rb | 6 ++++++
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/bin/sup-recover-sources b/bin/sup-recover-sources
index d3b1424..6e3810c 100755
--- a/bin/sup-recover-sources
+++ b/bin/sup-recover-sources
@@ -69,15 +69,14 @@ ARGV.each do |fn|
Redwood::MBox::Loader.new(fn, nil, !$opts[:unusual], $opts[:archive])
end
- source_ids = {}
+ source_ids = Hash.new 0
count = 0
source.each do |offset, labels|
m = Redwood::Message.new :source => source, :source_info => offset
- docid, entry = index.load_entry_for_id m.id
- next unless entry
- #puts "# #{source} #{offset} #{entry[:source_id]}"
-
- source_ids[entry[:source_id]] = (source_ids[entry[:source_id]] || 0) + 1
+ m.load_from_source!
+ source_id = index.source_for_id m.id
+ next unless source_id
+ source_ids[source_id] += 1
count += 1
break if count == $opts[:scan_num]
end
@@ -86,7 +85,6 @@ ARGV.each do |fn|
id = source_ids.keys.first.to_i
puts "assigned #{source} to #{source_ids.keys.first}"
source.id = id
- source.seek_to! source.total
index.add_source source
else
puts ">> unable to determine #{source}: #{source_ids.inspect}"
diff --git a/lib/sup/index.rb b/lib/sup/index.rb
index d15e7bb..b5d0e5d 100644
--- a/lib/sup/index.rb
+++ b/lib/sup/index.rb
@@ -494,6 +494,12 @@ EOS
@index_mutex.synchronize { @index.optimize }
end
+ def source_for_id id
+ entry = @index[id]
+ return unless entry
+ entry[:source_id].to_i
+ end
+
class ParseError < StandardError; end
## parse a query string from the user. returns a query object
--
1.6.0.4
------------------------------
Message: 465
Date: Sat, 20 Jun 2009 13:50:01 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH 02/18] remove load_entry_for_id call in
DraftManager.discard
Message-ID: <1245531017-9907-3-git-send-email-rlane@club.cc.cmu.edu>
---
lib/sup/draft.rb | 9 ++-------
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/lib/sup/draft.rb b/lib/sup/draft.rb
index 9127739..1233945 100644
--- a/lib/sup/draft.rb
+++ b/lib/sup/draft.rb
@@ -31,14 +31,9 @@ class DraftManager
end
def discard m
- docid, entry = Index.load_entry_for_id m.id
- unless entry
- Redwood::log "can't find entry for draft: #{m.id.inspect}. You probably already discarded it."
- return
- end
- raise ArgumentError, "not a draft: source id #{entry[:source_id].inspect}, should be #{DraftManager.source_id.inspect} for #{m.id.inspect} / docno #{docid}" unless entry[:source_id].to_i == DraftManager.source_id
+ raise ArgumentError, "not a draft: source id #{m.source.id.inspect}, should be #{DraftManager.source_id.inspect} for #{m.id.inspect}" unless m.source.id.to_i == DraftManager.source_id
Index.delete m.id
- File.delete @source.fn_for_offset(entry[:source_info])
+ File.delete @source.fn_for_offset(m.source_info)
UpdateManager.relay self, :single_message_deleted, m
end
end
--
1.6.0.4
------------------------------
Message: 466
Date: Sat, 20 Jun 2009 13:50:02 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH 03/18] remove ferret entry from poll/sync
interface
Message-ID: <1245531017-9907-4-git-send-email-rlane@club.cc.cmu.edu>
This leads to an extra index lookup in the sup-sync update path, but I think
it's worth it for the sake of API simplicity.
---
bin/sup-sync | 8 ++++----
bin/sup-sync-back | 6 +++---
lib/sup/index.rb | 18 ++++--------------
lib/sup/message.rb | 6 ++++++
lib/sup/poll.rb | 33 ++++++++++++++-------------------
lib/sup/sent.rb | 2 +-
6 files changed, 32 insertions(+), 41 deletions(-)
diff --git a/bin/sup-sync b/bin/sup-sync
index a759cbe..18a3cab 100755
--- a/bin/sup-sync
+++ b/bin/sup-sync
@@ -137,7 +137,7 @@ begin
num_added = num_updated = num_scanned = num_restored = 0
last_info_time = start_time = Time.now
- Redwood::PollManager.add_messages_from source, :force_overwrite => true do |m, offset, entry|
+ Redwood::PollManager.add_messages_from source, :force_overwrite => true do |m_old, m, offset|
num_scanned += 1
seen[m.id] = true
@@ -153,10 +153,10 @@ begin
## skip if we're operating only on changed messages, the message
## is in the index, and it's unchanged from what the source is
## reporting.
- next if target == :changed && entry && entry[:source_id].to_i == source.id && entry[:source_info].to_i == offset
+ next if target == :changed && m_old && m_old.source.id == source.id && m_old.source_info == offset
## get the state currently in the index
- index_state = entry[:label].symbolistize if entry
+ index_state = m_old.labels.dup if m_old
## skip if we're operating on restored messages, and this one
## ain't.
@@ -196,7 +196,7 @@ begin
puts "Adding message #{source}##{offset} from #{m.from} with state {#{m.labels * ', '}}" if opts[:verbose]
num_added += 1
else
- puts "Updating message #{source}##{offset}, source #{entry[:source_id]} => #{source.id}, offset #{entry[:source_info]} => #{offset}, state {#{index_state * ', '}} => {#{m.labels * ', '}}" if opts[:verbose]
+ puts "Updating message #{source}##{offset}, source #{m_old.source.id} => #{source.id}, offset #{m_old.source_info} => #{offset}, state {#{index_state * ', '}} => {#{m.labels * ', '}}" if opts[:verbose]
num_updated += 1
end
diff --git a/bin/sup-sync-back b/bin/sup-sync-back
index 4f1387e..1c746d2 100755
--- a/bin/sup-sync-back
+++ b/bin/sup-sync-back
@@ -105,11 +105,11 @@ EOS
num_dropped = num_moved = num_scanned = 0
out_fp = Tempfile.new "sup-sync-back-#{source.id}"
- Redwood::PollManager.add_messages_from source do |m, offset, entry|
+ Redwood::PollManager.add_messages_from source do |m_old, m, offset|
num_scanned += 1
- if entry
- labels = entry[:label].symbolistize.to_boolean_h
+ if m_old
+ labels = m_old.labels
if labels.member? :deleted
if opts[:drop_deleted]
diff --git a/lib/sup/index.rb b/lib/sup/index.rb
index b5d0e5d..89795da 100644
--- a/lib/sup/index.rb
+++ b/lib/sup/index.rb
@@ -174,16 +174,10 @@ EOS
## Syncs the message to the index, replacing any previous version. adding
## either way. Index state will be determined by the message's #labels
## accessor.
- ##
- ## if need_load is false, docid and entry are assumed to be set to the
- ## result of load_entry_for_id (which can be nil).
- def sync_message m, need_load=true, docid=nil, entry=nil, opts={}
- docid, entry = load_entry_for_id m.id if need_load
+ def sync_message m, opts={}
+ entry = @index[m.id]
raise "no source info for message #{m.id}" unless m.source && m.source_info
- @index_mutex.synchronize do
- raise "trying to delete non-corresponding entry #{docid} with index message-id #{@index[docid][:message_id].inspect} and parameter message id #{m.id.inspect}" if docid && @index[docid][:message_id] != m.id
- end
source_id = if m.source.is_a? Integer
m.source
@@ -256,13 +250,9 @@ EOS
}
@index_mutex.synchronize do
- @index.delete docid if docid
+ @index.delete m.id
@index.add_document d
end
-
- ## this hasn't been triggered in a long time.
- ## docid, entry = load_entry_for_id m.id
- ## raise "just added message #{m.id.inspect} but couldn't find it in a search" unless docid
end
def save_index fn=File.join(@dir, "ferret")
@@ -391,7 +381,7 @@ EOS
## builds a message object from a ferret result
def build_message docid
@index_mutex.synchronize do
- doc = @index[docid]
+ doc = @index[docid] or return
source = @source_mutex.synchronize { @sources[doc[:source_id].to_i] }
raise "invalid source #{doc[:source_id]}" unless source
diff --git a/lib/sup/message.rb b/lib/sup/message.rb
index 8525fdf..b667cb3 100644
--- a/lib/sup/message.rb
+++ b/lib/sup/message.rb
@@ -288,6 +288,12 @@ EOS
"Subject: #{@subj}"]
end
+ def self.build_from_source source, source_info
+ m = Message.new :source => source, :source_info => source_info
+ m.load_from_source!
+ m
+ end
+
private
## here's where we handle decoding mime attachments. unfortunately
diff --git a/lib/sup/poll.rb b/lib/sup/poll.rb
index 74f7d1c..bbad5f2 100644
--- a/lib/sup/poll.rb
+++ b/lib/sup/poll.rb
@@ -95,11 +95,11 @@ EOS
num = 0
numi = 0
- add_messages_from source do |m, offset, entry|
+ add_messages_from source do |m_old, m, offset|
## always preserve the labels on disk.
- m.labels = ((m.labels - [:unread, :inbox]) + entry[:label].symbolistize).uniq if entry
+ m.labels = ((m.labels - [:unread, :inbox]) + m_old.labels).uniq if m_old
yield "Found message at #{offset} with labels {#{m.labels * ', '}}"
- unless entry
+ unless m_old
num += 1
from_and_subj << [m.from && m.from.longname, m.subj]
if m.has_label?(:inbox) && ([:spam, :deleted, :killed] & m.labels).empty?
@@ -138,29 +138,24 @@ EOS
begin
return if source.done? || source.has_errors?
- source.each do |offset, labels|
+ source.each do |offset, default_labels|
if source.has_errors?
Redwood::log "error loading messages from #{source}: #{source.error.message}"
return
end
- labels << :sent if source.uri.eql?(SentManager.source_uri)
- labels.each { |l| LabelManager << l }
- labels = labels + (source.archived? ? [] : [:inbox])
+ m_new = Message.build_from_source source, offset
+ m_old = Index.build_message m_new.id
- m = Message.new :source => source, :source_info => offset, :labels => labels
- m.load_from_source!
+ m_new.labels = default_labels + (source.archived? ? [] : [:inbox])
+ m_new.labels << :sent if source.uri.eql?(SentManager.source_uri)
+ m_new.labels.delete :unread if m_new.source_marked_read?
+ m_new.labels.each { |l| LabelManager << l }
- if m.source_marked_read?
- m.remove_label :unread
- labels.delete :unread
- end
-
- docid, entry = Index.load_entry_for_id m.id
- HookManager.run "before-add-message", :message => m
- m = yield(m, offset, entry) or next if block_given?
- times = Index.sync_message m, false, docid, entry, opts
- UpdateManager.relay self, :added, m unless entry
+ HookManager.run "before-add-message", :message => m_new
+ m_ret = yield(m_old, m_new, offset) or next if block_given?
+ Index.sync_message m_ret, opts
+ UpdateManager.relay self, :added, m_ret unless m_old
end
rescue SourceError => e
Redwood::log "problem getting messages from #{source}: #{e.message}"
diff --git a/lib/sup/sent.rb b/lib/sup/sent.rb
index e6ae856..b750d71 100644
--- a/lib/sup/sent.rb
+++ b/lib/sup/sent.rb
@@ -30,7 +30,7 @@ class SentManager
def write_sent_message date, from_email, &block
@source.store_message date, from_email, &block
- PollManager.add_messages_from(@source) do |m, o, e|
+ PollManager.add_messages_from(@source) do |m_old, m, offset|
m.remove_label :unread
m
end
--
1.6.0.4
------------------------------
Message: 467
Date: Sat, 20 Jun 2009 13:50:03 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH 04/18] index: remove unused method
load_entry_for_id
Message-ID: <1245531017-9907-5-git-send-email-rlane@club.cc.cmu.edu>
---
lib/sup/index.rb | 11 -----------
1 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/lib/sup/index.rb b/lib/sup/index.rb
index 89795da..64afbdd 100644
--- a/lib/sup/index.rb
+++ b/lib/sup/index.rb
@@ -411,17 +411,6 @@ EOS
def delete id; @index_mutex.synchronize { @index.delete id } end
- def load_entry_for_id mid
- @index_mutex.synchronize do
- results = @index.search Ferret::Search::TermQuery.new(:message_id, mid)
- return if results.total_hits == 0
- docid = results.hits[0].doc
- entry = @index[docid]
- entry_dup = entry.fields.inject({}) { |h, f| h[f] = entry[f]; h }
- [docid, entry_dup]
- end
- end
-
def load_contacts emails, h={}
q = Ferret::Search::BooleanQuery.new true
emails.each do |e|
--
1.6.0.4
------------------------------
Message: 468
Date: Sat, 20 Jun 2009 13:50:04 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH 05/18] switch DraftManager to use
Message.build_from_source
Message-ID: <1245531017-9907-6-git-send-email-rlane@club.cc.cmu.edu>
---
lib/sup/draft.rb | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/lib/sup/draft.rb b/lib/sup/draft.rb
index 1233945..dd4574d 100644
--- a/lib/sup/draft.rb
+++ b/lib/sup/draft.rb
@@ -21,7 +21,8 @@ class DraftManager
my_message = nil
@source.each do |thisoffset, theselabels|
- m = Message.new :source => @source, :source_info => thisoffset, :labels => theselabels
+ m = Message.build_from_source @source, thisoffset
+ m.labels = theselabels
Index.sync_message m
UpdateManager.relay self, :added, m
my_message = m if thisoffset == offset
--
1.6.0.4
------------------------------
Message: 469
Date: Sat, 20 Jun 2009 13:50:06 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH 07/18] move source-related methods to
SourceManager
Message-ID: <1245531017-9907-8-git-send-email-rlane@club.cc.cmu.edu>
---
bin/sup | 10 ++++----
bin/sup-add | 10 ++++----
bin/sup-config | 14 +++++-----
bin/sup-recover-sources | 7 +++--
bin/sup-sync | 6 ++--
bin/sup-sync-back | 4 +-
bin/sup-tweak-labels | 4 +-
lib/sup.rb | 5 ++-
lib/sup/index.rb | 52 ++----------------------------------------
lib/sup/poll.rb | 2 +-
lib/sup/source.rb | 57 +++++++++++++++++++++++++++++++++++++++++++++++
11 files changed, 92 insertions(+), 79 deletions(-)
diff --git a/bin/sup b/bin/sup
index 302ad7c..1febefd 100755
--- a/bin/sup
+++ b/bin/sup
@@ -160,17 +160,17 @@ begin
Redwood::start
Index.load
- if(s = Index.source_for DraftManager.source_name)
+ if(s = Redwood::SourceManager.source_for DraftManager.source_name)
DraftManager.source = s
else
Redwood::log "no draft source, auto-adding..."
- Index.add_source DraftManager.new_source
+ Redwood::SourceManager.add_source DraftManager.new_source
end
- if(s = Index.source_for SentManager.source_uri)
+ if(s = Redwood::SourceManager.source_for SentManager.source_uri)
SentManager.source = s
else
- Index.add_source SentManager.default_source
+ Redwood::SourceManager.add_source SentManager.default_source
end
HookManager.run "startup"
@@ -190,7 +190,7 @@ begin
bm.draw_screen
- Index.usual_sources.each do |s|
+ Redwood::SourceManager.usual_sources.each do |s|
next unless s.respond_to? :connect
reporting_thread("call #connect on #{s}") do
begin
diff --git a/bin/sup-add b/bin/sup-add
index 50bbb29..c491ca7 100755
--- a/bin/sup-add
+++ b/bin/sup-add
@@ -82,12 +82,12 @@ index = Redwood::Index.new
index.lock_or_die
begin
- index.load_sources
+ Redwood::SourceManager.load_sources
ARGV.each do |uri|
labels = $opts[:labels] ? $opts[:labels].split(/\s*,\s*/).uniq : []
- if !$opts[:force_new] && index.source_for(uri)
+ if !$opts[:force_new] && Redwood::SourceManager.source_for(uri)
say "Already know about #{uri}; skipping."
next
end
@@ -99,10 +99,10 @@ begin
when "mbox+ssh"
say "For SSH connections, if you will use public key authentication, you may leave the username and password blank."
say ""
- username, password = get_login_info uri, index.sources
+ username, password = get_login_info uri, Redwood::SourceManager.sources
Redwood::MBox::SSHLoader.new uri, username, password, nil, !$opts[:unusual], $opts[:archive], nil, labels
when "imap", "imaps"
- username, password = get_login_info uri, index.sources
+ username, password = get_login_info uri, Redwood::SourceManager.sources
Redwood::IMAP.new uri, username, password, nil, !$opts[:unusual], $opts[:archive], nil, labels
when "maildir"
Redwood::Maildir.new uri, nil, !$opts[:unusual], $opts[:archive], nil, labels
@@ -114,7 +114,7 @@ begin
Trollop::die "Unknown source type #{parsed_uri.scheme.inspect}"
end
say "Adding #{source}..."
- index.add_source source
+ Redwood::SourceManager.add_source source
end
ensure
index.save
diff --git a/bin/sup-config b/bin/sup-config
index 398197f..9fcbee6 100755
--- a/bin/sup-config
+++ b/bin/sup-config
@@ -152,7 +152,7 @@ end
$terminal.wrap_at = :auto
Redwood::start
index = Redwood::Index.new
-index.load_sources
+Redwood::SourceManager.load_sources
say <<EOS
Howdy neighbor! This here's sup-config, ready to help you jack in to
@@ -191,12 +191,12 @@ $config[:editor] = editor
done = false
until done
say "\nNow, we'll tell Sup where to find all your email."
- index.load_sources
+ Redwood::SourceManager.load_sources
say "Current sources:"
- if index.sources.empty?
+ if Redwood::SourceManager.sources.empty?
say " No sources!"
else
- index.sources.each { |s| puts "* #{s}" }
+ Redwood::SourceManager.sources.each { |s| puts "* #{s}" }
end
say "\n"
@@ -210,8 +210,8 @@ end
say "\nSup needs to know where to store your sent messages."
say "Only sources capable of storing mail will be listed.\n\n"
-index.load_sources
-if index.sources.empty?
+Redwood::SourceManager.load_sources
+if Redwood::SourceManager.sources.empty?
say "\nUsing the default sup://sent, since you haven't configured other sources yet."
$config[:sent_source] = 'sup://sent'
else
@@ -222,7 +222,7 @@ else
choose do |menu|
menu.prompt = "Store my sent mail in? "
- valid_sents = index.sources.each do |s|
+ valid_sents = Redwood::SourceManager.sources.each do |s|
have_sup_sent = true if s.to_s.eql?('sup://sent')
menu.choice(s.to_s) { $config[:sent_source] = s.to_s } if s.respond_to? :store_message
diff --git a/bin/sup-recover-sources b/bin/sup-recover-sources
index 6e3810c..db75b11 100755
--- a/bin/sup-recover-sources
+++ b/bin/sup-recover-sources
@@ -48,13 +48,14 @@ EOS
end.parse(ARGV)
require "sup"
+Redwood::start
puts "loading index..."
index = Redwood::Index.new
index.load
puts "loaded index of #{index.size} messages"
ARGV.each do |fn|
- next if index.source_for fn
+ next if Redwood::SourceManager.source_for fn
## TODO: merge this code with the same snippet in import
source =
@@ -74,7 +75,7 @@ ARGV.each do |fn|
source.each do |offset, labels|
m = Redwood::Message.new :source => source, :source_info => offset
m.load_from_source!
- source_id = index.source_for_id m.id
+ source_id = Redwood::SourceManager.source_for_id m.id
next unless source_id
source_ids[source_id] += 1
count += 1
@@ -85,7 +86,7 @@ ARGV.each do |fn|
id = source_ids.keys.first.to_i
puts "assigned #{source} to #{source_ids.keys.first}"
source.id = id
- index.add_source source
+ Redwood::SourceManager.add_source source
else
puts ">> unable to determine #{source}: #{source_ids.inspect}"
end
diff --git a/bin/sup-sync b/bin/sup-sync
index 18a3cab..270524a 100755
--- a/bin/sup-sync
+++ b/bin/sup-sync
@@ -116,11 +116,11 @@ begin
index.load
sources = ARGV.map do |uri|
- index.source_for uri or Trollop::die "Unknown source: #{uri}. Did you add it with sup-add first?"
+ Redwood::SourceManager.source_for uri or Trollop::die "Unknown source: #{uri}. Did you add it with sup-add first?"
end
- sources = index.usual_sources if sources.empty?
- sources = index.sources if opts[:all_sources]
+ sources = Redwood::SourceManager.usual_sources if sources.empty?
+ sources = Redwood::SourceManager.sources if opts[:all_sources]
unless target == :new
if opts[:start_at]
diff --git a/bin/sup-sync-back b/bin/sup-sync-back
index 05b9e8c..679e03a 100755
--- a/bin/sup-sync-back
+++ b/bin/sup-sync-back
@@ -80,13 +80,13 @@ begin
index.load
sources = ARGV.map do |uri|
- s = index.source_for(uri) or die "unknown source: #{uri}. Did you add it with sup-add first?"
+ s = Redwood::SourceManager.source_for(uri) or die "unknown source: #{uri}. Did you add it with sup-add first?"
s.is_a?(Redwood::MBox::Loader) or die "#{uri} is not an mbox source."
s
end
if sources.empty?
- sources = index.usual_sources.select { |s| s.is_a? Redwood::MBox::Loader }
+ sources = Redwood::SourceManager.usual_sources.select { |s| s.is_a? Redwood::MBox::Loader }
end
unless sources.all? { |s| s.file_path.nil? } || File.executable?(dotlockfile) || opts[:dont_use_dotlockfile]
diff --git a/bin/sup-tweak-labels b/bin/sup-tweak-labels
index 6f603e2..95a3b03 100755
--- a/bin/sup-tweak-labels
+++ b/bin/sup-tweak-labels
@@ -66,10 +66,10 @@ begin
source_ids =
if opts[:all_sources]
- index.sources
+ Redwood::SourceManager.sources
else
ARGV.map do |uri|
- index.source_for uri or Trollop::die "Unknown source: #{uri}. Did you add it with sup-add first?"
+ Redwood::SourceManager.source_for uri or Trollop::die "Unknown source: #{uri}. Did you add it with sup-add first?"
end
end.map { |s| s.id }
Trollop::die "nothing to do: no sources" if source_ids.empty?
diff --git a/lib/sup.rb b/lib/sup.rb
index 8373820..5689c2b 100644
--- a/lib/sup.rb
+++ b/lib/sup.rb
@@ -115,6 +115,7 @@ module Redwood
Redwood::SuicideManager.new Redwood::SUICIDE_FN
Redwood::CryptoManager.new
Redwood::UndoManager.new
+ Redwood::SourceManager.new
end
def finish
@@ -130,7 +131,7 @@ module Redwood
def report_broken_sources opts={}
return unless BufferManager.instantiated?
- broken_sources = Index.sources.select { |s| s.error.is_a? FatalSourceError }
+ broken_sources = SourceManager.sources.select { |s| s.error.is_a? FatalSourceError }
unless broken_sources.empty?
BufferManager.spawn_unless_exists("Broken source notification for #{broken_sources.join(',')}", opts) do
TextMode.new(<<EOM)
@@ -147,7 +148,7 @@ EOM
end
end
- desynced_sources = Index.sources.select { |s| s.error.is_a? OutOfSyncSourceError }
+ desynced_sources = SourceManager.sources.select { |s| s.error.is_a? OutOfSyncSourceError }
unless desynced_sources.empty?
BufferManager.spawn_unless_exists("Out-of-sync source notification for #{broken_sources.join(',')}", opts) do
TextMode.new(<<EOM)
diff --git a/lib/sup/index.rb b/lib/sup/index.rb
index b9f4b36..7d6258d 100644
--- a/lib/sup/index.rb
+++ b/lib/sup/index.rb
@@ -26,11 +26,7 @@ class Index
def initialize dir=BASE_DIR
@index_mutex = Monitor.new
-
@dir = dir
- @sources = {}
- @sources_dirty = false
- @source_mutex = Monitor.new
wsa = Ferret::Analysis::WhiteSpaceAnalyzer.new false
sa = Ferret::Analysis::StandardAnalyzer.new [], true
@@ -112,36 +108,17 @@ EOS
end
def load
- load_sources
+ SourceManager.load_sources
load_index
end
def save
Redwood::log "saving index and sources..."
FileUtils.mkdir_p @dir unless File.exists? @dir
- save_sources
+ SourceManager.save_sources
save_index
end
- def add_source source
- @source_mutex.synchronize do
- raise "duplicate source!" if @sources.include? source
- @sources_dirty = true
- max = @sources.max_of { |id, s| s.is_a?(DraftLoader) || s.is_a?(SentLoader) ? 0 : id }
- source.id ||= (max || 0) + 1
- ##source.id += 1 while @sources.member? source.id
- @sources[source.id] = source
- end
- end
-
- def sources
- ## favour the inbox by listing non-archived sources first
- @source_mutex.synchronize { @sources.values }.sort_by { |s| s.id }.partition { |s| !s.archived? }.flatten
- end
-
- def source_for uri; sources.find { |s| s.is_source_for? uri }; end
- def usual_sources; sources.find_all { |s| s.usual? }; end
-
def load_index dir=File.join(@dir, "ferret")
if File.exists? dir
Redwood::log "loading index..."
@@ -383,7 +360,7 @@ EOS
@index_mutex.synchronize do
doc = @index[docid] or return
- source = @source_mutex.synchronize { @sources[doc[:source_id].to_i] }
+ source = SourceManager[doc[:source_id].to_i]
raise "invalid source #{doc[:source_id]}" unless source
#puts "building message #{doc[:message_id]} (#{source}##{doc[:source_info]})"
@@ -442,14 +419,6 @@ EOS
contacts.keys.compact
end
- def load_sources fn=Redwood::SOURCE_FN
- source_array = (Redwood::load_yaml_obj(fn) || []).map { |o| Recoverable.new o }
- @source_mutex.synchronize do
- @sources = Hash[*(source_array).map { |s| [s.id, s] }.flatten]
- @sources_dirty = false
- end
- end
-
def each_docid query={}
ferret_query = build_ferret_query query
results = @index_mutex.synchronize { @index.search ferret_query, :limit => (query[:limit] || :all) }
@@ -604,21 +573,6 @@ private
q.add_query Ferret::Search::TermQuery.new("source_id", query[:source_id]), :must if query[:source_id]
q
end
-
- def save_sources fn=Redwood::SOURCE_FN
- @source_mutex.synchronize do
- if @sources_dirty || @sources.any? { |id, s| s.dirty? }
- bakfn = fn + ".bak"
- if File.exists? fn
- File.chmod 0600, fn
- FileUtils.mv fn, bakfn, :force => true unless File.exists?(bakfn) && File.size(fn) == 0
- end
- Redwood::save_yaml_obj sources.sort_by { |s| s.id.to_i }, fn, true
- File.chmod 0600, fn
- end
- @sources_dirty = false
- end
- end
end
end
diff --git a/lib/sup/poll.rb b/lib/sup/poll.rb
index bbad5f2..c83290c 100644
--- a/lib/sup/poll.rb
+++ b/lib/sup/poll.rb
@@ -83,7 +83,7 @@ EOS
from_and_subj_inbox = []
@mutex.synchronize do
- Index.usual_sources.each do |source|
+ SourceManager.usual_sources.each do |source|
# yield "source #{source} is done? #{source.done?} (cur_offset #{source.cur_offset} >= #{source.end_offset})"
begin
yield "Loading from #{source}... " unless source.done? || (source.respond_to?(:has_errors?) && source.has_errors?)
diff --git a/lib/sup/source.rb b/lib/sup/source.rb
index fb98dbc..1bb7797 100644
--- a/lib/sup/source.rb
+++ b/lib/sup/source.rb
@@ -155,4 +155,61 @@ protected
end
end
+class SourceManager
+ include Singleton
+
+ def initialize
+ @sources = {}
+ @sources_dirty = false
+ @source_mutex = Monitor.new
+ self.class.i_am_the_instance self
+ end
+
+ def [](id)
+ @source_mutex.synchronize { @sources[id] }
+ end
+
+ def add_source source
+ @source_mutex.synchronize do
+ raise "duplicate source!" if @sources.include? source
+ @sources_dirty = true
+ max = @sources.max_of { |id, s| s.is_a?(DraftLoader) || s.is_a?(SentLoader) ? 0 : id }
+ source.id ||= (max || 0) + 1
+ ##source.id += 1 while @sources.member? source.id
+ @sources[source.id] = source
+ end
+ end
+
+ def sources
+ ## favour the inbox by listing non-archived sources first
+ @source_mutex.synchronize { @sources.values }.sort_by { |s| s.id }.partition { |s| !s.archived? }.flatten
+ end
+
+ def source_for uri; sources.find { |s| s.is_source_for? uri }; end
+ def usual_sources; sources.find_all { |s| s.usual? }; end
+
+ def load_sources fn=Redwood::SOURCE_FN
+ source_array = (Redwood::load_yaml_obj(fn) || []).map { |o| Recoverable.new o }
+ @source_mutex.synchronize do
+ @sources = Hash[*(source_array).map { |s| [s.id, s] }.flatten]
+ @sources_dirty = false
+ end
+ end
+
+ def save_sources fn=Redwood::SOURCE_FN
+ @source_mutex.synchronize do
+ if @sources_dirty || @sources.any? { |id, s| s.dirty? }
+ bakfn = fn + ".bak"
+ if File.exists? fn
+ File.chmod 0600, fn
+ FileUtils.mv fn, bakfn, :force => true unless File.exists?(bakfn) && File.size(fn) == 0
+ end
+ Redwood::save_yaml_obj sources.sort_by { |s| s.id.to_i }, fn, true
+ File.chmod 0600, fn
+ end
+ @sources_dirty = false
+ end
+ end
+end
+
end
--
1.6.0.4
------------------------------
Message: 470
Date: Sat, 20 Jun 2009 13:50:05 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH 06/18] index: move
has_any_from_source_with_label? to sup-sync-back
Message-ID: <1245531017-9907-7-git-send-email-rlane@club.cc.cmu.edu>
---
bin/sup-sync-back | 7 ++++++-
lib/sup/index.rb | 7 -------
2 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/bin/sup-sync-back b/bin/sup-sync-back
index 1c746d2..05b9e8c 100755
--- a/bin/sup-sync-back
+++ b/bin/sup-sync-back
@@ -4,6 +4,7 @@ require 'rubygems'
require 'uri'
require 'tempfile'
require 'trollop'
+require 'enumerator'
require "sup"
## save a message 'm' to an open file pointer 'fp'
@@ -14,6 +15,10 @@ def die msg
$stderr.puts "Error: #{msg}"
exit(-1)
end
+def has_any_from_source_with_label? index, source, label
+ query = { :source_id => source.id, :label => label, :limit => 1 }
+ not Enumerable::Enumerator.new(index, :each_docid, query).map.empty?
+end
opts = Trollop::options do
version "sup-sync-back (sup #{Redwood::VERSION})"
@@ -96,7 +101,7 @@ EOS
sources.each do |source|
$stderr.puts "Scanning #{source}..."
- unless ((opts[:drop_deleted] || opts[:move_deleted]) && index.has_any_from_source_with_label?(source, :deleted)) || ((opts[:drop_spam] || opts[:move_spam]) && index.has_any_from_source_with_label?(source, :spam))
+ unless ((opts[:drop_deleted] || opts[:move_deleted]) && has_any_from_source_with_label?(index, source, :deleted)) || ((opts[:drop_spam] || opts[:move_spam]) && has_any_from_source_with_label?(index, source, :spam))
$stderr.puts "Nothing to do from this source; skipping"
next
end
diff --git a/lib/sup/index.rb b/lib/sup/index.rb
index 64afbdd..b9f4b36 100644
--- a/lib/sup/index.rb
+++ b/lib/sup/index.rb
@@ -450,13 +450,6 @@ EOS
end
end
- def has_any_from_source_with_label? source, label
- q = Ferret::Search::BooleanQuery.new
- q.add_query Ferret::Search::TermQuery.new("source_id", source.id.to_s), :must
- q.add_query Ferret::Search::TermQuery.new("label", label.to_s), :must
- @index_mutex.synchronize { @index.search(q, :limit => 1).total_hits > 0 }
- end
-
def each_docid query={}
ferret_query = build_ferret_query query
results = @index_mutex.synchronize { @index.search ferret_query, :limit => (query[:limit] || :all) }
--
1.6.0.4
------------------------------
Message: 471
Date: Sat, 20 Jun 2009 13:50:07 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH 08/18] index: remove unused method
fresh_thread_id
Message-ID: <1245531017-9907-9-git-send-email-rlane@club.cc.cmu.edu>
---
lib/sup/index.rb | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/lib/sup/index.rb b/lib/sup/index.rb
index 7d6258d..e3f9e69 100644
--- a/lib/sup/index.rb
+++ b/lib/sup/index.rb
@@ -382,7 +382,6 @@ EOS
end
end
- def fresh_thread_id; @next_thread_id += 1; end
def wrap_subj subj; "__START_SUBJECT__ #{subj} __END_SUBJECT__"; end
def unwrap_subj subj; subj =~ /__START_SUBJECT__ (.*?) __END_SUBJECT__/ && $1; end
--
1.6.0.4
------------------------------
Message: 472
Date: Sat, 20 Jun 2009 13:50:09 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH 10/18] index: make wrap_subj methods
private
Message-ID: <1245531017-9907-11-git-send-email-rlane@club.cc.cmu.edu>
---
lib/sup/index.rb | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/sup/index.rb b/lib/sup/index.rb
index 080a4ec..5ddd6ee 100644
--- a/lib/sup/index.rb
+++ b/lib/sup/index.rb
@@ -382,9 +382,6 @@ EOS
end
end
- def wrap_subj subj; "__START_SUBJECT__ #{subj} __END_SUBJECT__"; end
- def unwrap_subj subj; subj =~ /__START_SUBJECT__ (.*?) __END_SUBJECT__/ && $1; end
-
def delete id; @index_mutex.synchronize { @index.delete id } end
def load_contacts emails, h={}
@@ -572,6 +569,9 @@ private
q.add_query Ferret::Search::TermQuery.new("source_id", query[:source_id]), :must if query[:source_id]
q
end
+
+ def wrap_subj subj; "__START_SUBJECT__ #{subj} __END_SUBJECT__"; end
+ def unwrap_subj subj; subj =~ /__START_SUBJECT__ (.*?) __END_SUBJECT__/ && $1; end
end
end
--
1.6.0.4
------------------------------
Message: 473
Date: Sat, 20 Jun 2009 13:50:10 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH 11/18] index: move Ferret-specific code to
ferret_index.rb
Message-ID: <1245531017-9907-12-git-send-email-rlane@club.cc.cmu.edu>
---
lib/sup/ferret_index.rb | 463 +++++++++++++++++++++++++++++++++++++++++++++++
lib/sup/index.rb | 453 +++++-----------------------------------------
2 files changed, 509 insertions(+), 407 deletions(-)
create mode 100644 lib/sup/ferret_index.rb
diff --git a/lib/sup/ferret_index.rb b/lib/sup/ferret_index.rb
new file mode 100644
index 0000000..53c19e0
--- /dev/null
+++ b/lib/sup/ferret_index.rb
@@ -0,0 +1,463 @@
+require 'ferret'
+
+module Redwood
+
+class FerretIndex < BaseIndex
+
+ def initialize dir=BASE_DIR
+ super
+
+ @index_mutex = Monitor.new
+ wsa = Ferret::Analysis::WhiteSpaceAnalyzer.new false
+ sa = Ferret::Analysis::StandardAnalyzer.new [], true
+ @analyzer = Ferret::Analysis::PerFieldAnalyzer.new wsa
+ @analyzer[:body] = sa
+ @analyzer[:subject] = sa
+ @qparser ||= Ferret::QueryParser.new :default_field => :body, :analyzer => @analyzer, :or_default => false
+ end
+
+ def load_index dir=File.join(@dir, "ferret")
+ if File.exists? dir
+ Redwood::log "loading index..."
+ @index_mutex.synchronize do
+ @index = Ferret::Index::Index.new(:path => dir, :analyzer => @analyzer, :id_field => 'message_id')
+ Redwood::log "loaded index of #{@index.size} messages"
+ end
+ else
+ Redwood::log "creating index..."
+ @index_mutex.synchronize do
+ field_infos = Ferret::Index::FieldInfos.new :store => :yes
+ field_infos.add_field :message_id, :index => :untokenized
+ field_infos.add_field :source_id
+ field_infos.add_field :source_info
+ field_infos.add_field :date, :index => :untokenized
+ field_infos.add_field :body
+ field_infos.add_field :label
+ field_infos.add_field :attachments
+ field_infos.add_field :subject
+ field_infos.add_field :from
+ field_infos.add_field :to
+ field_infos.add_field :refs
+ field_infos.add_field :snippet, :index => :no, :term_vector => :no
+ field_infos.create_index dir
+ @index = Ferret::Index::Index.new(:path => dir, :analyzer => @analyzer, :id_field => 'message_id')
+ end
+ end
+ end
+
+ def sync_message m, opts={}
+ entry = @index[m.id]
+
+ raise "no source info for message #{m.id}" unless m.source && m.source_info
+
+ source_id = if m.source.is_a? Integer
+ m.source
+ else
+ m.source.id or raise "unregistered source #{m.source} (id #{m.source.id.inspect})"
+ end
+
+ snippet = if m.snippet_contains_encrypted_content? && $config[:discard_snippets_from_encrypted_messages]
+ ""
+ else
+ m.snippet
+ end
+
+ ## write the new document to the index. if the entry already exists in the
+ ## index, reuse it (which avoids having to reload the entry from the source,
+ ## which can be quite expensive for e.g. large threads of IMAP actions.)
+ ##
+ ## exception: if the index entry belongs to an earlier version of the
+ ## message, use everything from the new message instead, but union the
+ ## flags. this allows messages sent to mailing lists to have their header
+ ## updated and to have flags set properly.
+ ##
+ ## minor hack: messages in sources with lower ids have priority over
+ ## messages in sources with higher ids. so messages in the inbox will
+ ## override everyone, and messages in the sent box will be overridden
+ ## by everyone else.
+ ##
+ ## written in this manner to support previous versions of the index which
+ ## did not keep around the entry body. upgrading is thus seamless.
+ entry ||= {}
+ labels = m.labels.uniq # override because this is the new state, unless...
+
+ ## if we are a later version of a message, ignore what's in the index,
+ ## but merge in the labels.
+ if entry[:source_id] && entry[:source_info] && entry[:label] &&
+ ((entry[:source_id].to_i > source_id) || (entry[:source_info].to_i < m.source_info))
+ labels = (entry[:label].symbolistize + m.labels).uniq
+ #Redwood::log "found updated version of message #{m.id}: #{m.subj}"
+ #Redwood::log "previous version was at #{entry[:source_id].inspect}:#{entry[:source_info].inspect}, this version at #{source_id.inspect}:#{m.source_info.inspect}"
+ #Redwood::log "merged labels are #{labels.inspect} (index #{entry[:label].inspect}, message #{m.labels.inspect})"
+ entry = {}
+ end
+
+ ## if force_overwite is true, ignore what's in the index. this is used
+ ## primarily by sup-sync to force index updates.
+ entry = {} if opts[:force_overwrite]
+
+ d = {
+ :message_id => m.id,
+ :source_id => source_id,
+ :source_info => m.source_info,
+ :date => (entry[:date] || m.date.to_indexable_s),
+ :body => (entry[:body] || m.indexable_content),
+ :snippet => snippet, # always override
+ :label => labels.uniq.join(" "),
+ :attachments => (entry[:attachments] || m.attachments.uniq.join(" ")),
+
+ ## always override :from and :to.
+ ## older versions of Sup would often store the wrong thing in the index
+ ## (because they were canonicalizing email addresses, resulting in the
+ ## wrong name associated with each.) the correct address is read from
+ ## the original header when these messages are opened in thread-view-mode,
+ ## so this allows people to forcibly update the address in the index by
+ ## marking those threads for saving.
+ :from => (m.from ? m.from.indexable_content : ""),
+ :to => (m.to + m.cc + m.bcc).map { |x| x.indexable_content }.join(" "),
+
+ :subject => (entry[:subject] || wrap_subj(Message.normalize_subj(m.subj))),
+ :refs => (entry[:refs] || (m.refs + m.replytos).uniq.join(" ")),
+ }
+
+ @index_mutex.synchronize do
+ @index.delete m.id
+ @index.add_document d
+ end
+ end
+
+ def save_index fn=File.join(@dir, "ferret")
+ # don't have to do anything, apparently
+ end
+
+ def contains_id? id
+ @index_mutex.synchronize { @index.search(Ferret::Search::TermQuery.new(:message_id, id)).total_hits > 0 }
+ end
+
+ def size
+ @index_mutex.synchronize { @index.size }
+ end
+
+ EACH_BY_DATE_NUM = 100
+ def each_id_by_date query={}
+ return if empty? # otherwise ferret barfs ###TODO: remove this once my ferret patch is accepted
+ ferret_query = build_ferret_query query
+ offset = 0
+ while true
+ limit = (query[:limit])? [EACH_BY_DATE_NUM, query[:limit] - offset].min : EACH_BY_DATE_NUM
+ results = @index_mutex.synchronize { @index.search ferret_query, :sort => "date DESC", :limit => limit, :offset => offset }
+ Redwood::log "got #{results.total_hits} results for query (offset #{offset}) #{ferret_query.inspect}"
+ results.hits.each do |hit|
+ yield @index_mutex.synchronize { @index[hit.doc][:message_id] }, lambda { build_message hit.doc }
+ end
+ break if query[:limit] and offset >= query[:limit] - limit
+ break if offset >= results.total_hits - limit
+ offset += limit
+ end
+ end
+
+ def num_results_for query={}
+ return 0 if empty? # otherwise ferret barfs ###TODO: remove this once my ferret patch is accepted
+ ferret_query = build_ferret_query query
+ @index_mutex.synchronize { @index.search(ferret_query, :limit => 1).total_hits }
+ end
+
+ SAME_SUBJECT_DATE_LIMIT = 7
+ MAX_CLAUSES = 1000
+ def each_message_in_thread_for m, opts={}
+ #Redwood::log "Building thread for #{m.id}: #{m.subj}"
+ messages = {}
+ searched = {}
+ num_queries = 0
+
+ pending = [m.id]
+ if $config[:thread_by_subject] # do subject queries
+ date_min = m.date - (SAME_SUBJECT_DATE_LIMIT * 12 * 3600)
+ date_max = m.date + (SAME_SUBJECT_DATE_LIMIT * 12 * 3600)
+
+ q = Ferret::Search::BooleanQuery.new true
+ sq = Ferret::Search::PhraseQuery.new(:subject)
+ wrap_subj(Message.normalize_subj(m.subj)).split.each do |t|
+ sq.add_term t
+ end
+ q.add_query sq, :must
+ q.add_query Ferret::Search::RangeQuery.new(:date, :>= => date_min.to_indexable_s, :<= => date_max.to_indexable_s), :must
+
+ q = build_ferret_query :qobj => q
+
+ p1 = @index_mutex.synchronize { @index.search(q).hits.map { |hit| @index[hit.doc][:message_id] } }
+ Redwood::log "found #{p1.size} results for subject query #{q}"
+
+ p2 = @index_mutex.synchronize { @index.search(q.to_s, :limit => :all).hits.map { |hit| @index[hit.doc][:message_id] } }
+ Redwood::log "found #{p2.size} results in string form"
+
+ pending = (pending + p1 + p2).uniq
+ end
+
+ until pending.empty? || (opts[:limit] && messages.size >= opts[:limit])
+ q = Ferret::Search::BooleanQuery.new true
+ # this disappeared in newer ferrets... wtf.
+ # q.max_clause_count = 2048
+
+ lim = [MAX_CLAUSES / 2, pending.length].min
+ pending[0 ... lim].each do |id|
+ searched[id] = true
+ q.add_query Ferret::Search::TermQuery.new(:message_id, id), :should
+ q.add_query Ferret::Search::TermQuery.new(:refs, id), :should
+ end
+ pending = pending[lim .. -1]
+
+ q = build_ferret_query :qobj => q
+
+ num_queries += 1
+ killed = false
+ @index_mutex.synchronize do
+ @index.search_each(q, :limit => :all) do |docid, score|
+ break if opts[:limit] && messages.size >= opts[:limit]
+ if @index[docid][:label].split(/\s+/).include?("killed") && opts[:skip_killed]
+ killed = true
+ break
+ end
+ mid = @index[docid][:message_id]
+ unless messages.member?(mid)
+ #Redwood::log "got #{mid} as a child of #{id}"
+ messages[mid] ||= lambda { build_message docid }
+ refs = @index[docid][:refs].split
+ pending += refs.select { |id| !searched[id] }
+ end
+ end
+ end
+ end
+
+ if killed
+ Redwood::log "thread for #{m.id} is killed, ignoring"
+ false
+ else
+ Redwood::log "ran #{num_queries} queries to build thread of #{messages.size} messages for #{m.id}: #{m.subj}" if num_queries > 0
+ messages.each { |mid, builder| yield mid, builder }
+ true
+ end
+ end
+
+ ## builds a message object from a ferret result
+ def build_message docid
+ @index_mutex.synchronize do
+ doc = @index[docid] or return
+
+ source = SourceManager[doc[:source_id].to_i]
+ raise "invalid source #{doc[:source_id]}" unless source
+
+ #puts "building message #{doc[:message_id]} (#{source}##{doc[:source_info]})"
+
+ fake_header = {
+ "date" => Time.at(doc[:date].to_i),
+ "subject" => unwrap_subj(doc[:subject]),
+ "from" => doc[:from],
+ "to" => doc[:to].split.join(", "), # reformat
+ "message-id" => doc[:message_id],
+ "references" => doc[:refs].split.map { |x| "<#{x}>" }.join(" "),
+ }
+
+ m = Message.new :source => source, :source_info => doc[:source_info].to_i,
+ :labels => doc[:label].symbolistize,
+ :snippet => doc[:snippet]
+ m.parse_header fake_header
+ m
+ end
+ end
+
+ def delete id
+ @index_mutex.synchronize { @index.delete id }
+ end
+
+ def load_contacts emails, h={}
+ q = Ferret::Search::BooleanQuery.new true
+ emails.each do |e|
+ qq = Ferret::Search::BooleanQuery.new true
+ qq.add_query Ferret::Search::TermQuery.new(:from, e), :should
+ qq.add_query Ferret::Search::TermQuery.new(:to, e), :should
+ q.add_query qq
+ end
+ q.add_query Ferret::Search::TermQuery.new(:label, "spam"), :must_not
+
+ Redwood::log "contact search: #{q}"
+ contacts = {}
+ num = h[:num] || 20
+ @index_mutex.synchronize do
+ @index.search_each q, :sort => "date DESC", :limit => :all do |docid, score|
+ break if contacts.size >= num
+ #Redwood::log "got message #{docid} to: #{@index[docid][:to].inspect} and from: #{@index[docid][:from].inspect}"
+ f = @index[docid][:from]
+ t = @index[docid][:to]
+
+ if AccountManager.is_account_email? f
+ t.split(" ").each { |e| contacts[Person.from_address(e)] = true }
+ else
+ contacts[Person.from_address(f)] = true
+ end
+ end
+ end
+
+ contacts.keys.compact
+ end
+
+ def each_docid query={}
+ ferret_query = build_ferret_query query
+ results = @index_mutex.synchronize { @index.search ferret_query, :limit => (query[:limit] || :all) }
+ results.hits.map { |hit| yield hit.doc }
+ end
+
+ def each_message query={}
+ each_docid query do |docid|
+ yield build_message(docid)
+ end
+ end
+
+ def optimize
+ @index_mutex.synchronize { @index.optimize }
+ end
+
+ def source_for_id id
+ entry = @index[id]
+ return unless entry
+ entry[:source_id].to_i
+ end
+
+ class ParseError < StandardError; end
+
+ ## parse a query string from the user. returns a query object
+ ## that can be passed to any index method with a 'query'
+ ## argument, as well as build_ferret_query.
+ ##
+ ## raises a ParseError if something went wrong.
+ def parse_query s
+ query = {}
+
+ subs = s.gsub(/\b(to|from):(\S+)\b/) do
+ field, name = $1, $2
+ if(p = ContactManager.contact_for(name))
+ [field, p.email]
+ elsif name == "me"
+ [field, "(" + AccountManager.user_emails.join("||") + ")"]
+ else
+ [field, name]
+ end.join(":")
+ end
+
+ ## if we see a label:deleted or a label:spam term anywhere in the query
+ ## string, we set the extra load_spam or load_deleted options to true.
+ ## bizarre? well, because the query allows arbitrary parenthesized boolean
+ ## expressions, without fully parsing the query, we can't tell whether
+ ## the user is explicitly directing us to search spam messages or not.
+ ## e.g. if the string is -(-(-(-(-label:spam)))), does the user want to
+ ## search spam messages or not?
+ ##
+ ## so, we rely on the fact that turning these extra options ON turns OFF
+ ## the adding of "-label:deleted" or "-label:spam" terms at the very
+ ## final stage of query processing. if the user wants to search spam
+ ## messages, not adding that is the right thing; if he doesn't want to
+ ## search spam messages, then not adding it won't have any effect.
+ query[:load_spam] = true if subs =~ /\blabel:spam\b/
+ query[:load_deleted] = true if subs =~ /\blabel:deleted\b/
+
+ ## gmail style "is" operator
+ subs = subs.gsub(/\b(is|has):(\S+)\b/) do
+ field, label = $1, $2
+ case label
+ when "read"
+ "-label:unread"
+ when "spam"
+ query[:load_spam] = true
+ "label:spam"
+ when "deleted"
+ query[:load_deleted] = true
+ "label:deleted"
+ else
+ "label:#{$2}"
+ end
+ end
+
+ ## gmail style attachments "filename" and "filetype" searches
+ subs = subs.gsub(/\b(filename|filetype):(\((.+?)\)\B|(\S+)\b)/) do
+ field, name = $1, ($3 || $4)
+ case field
+ when "filename"
+ Redwood::log "filename - translated #{field}:#{name} to attachments:(#{name.downcase})"
+ "attachments:(#{name.downcase})"
+ when "filetype"
+ Redwood::log "filetype - translated #{field}:#{name} to attachments:(*.#{name.downcase})"
+ "attachments:(*.#{name.downcase})"
+ end
+ end
+
+ if $have_chronic
+ subs = subs.gsub(/\b(before|on|in|during|after):(\((.+?)\)\B|(\S+)\b)/) do
+ field, datestr = $1, ($3 || $4)
+ realdate = Chronic.parse datestr, :guess => false, :context => :past
+ if realdate
+ case field
+ when "after"
+ Redwood::log "chronic: translated #{field}:#{datestr} to #{realdate.end}"
+ "date:(>= #{sprintf "%012d", realdate.end.to_i})"
+ when "before"
+ Redwood::log "chronic: translated #{field}:#{datestr} to #{realdate.begin}"
+ "date:(<= #{sprintf "%012d", realdate.begin.to_i})"
+ else
+ Redwood::log "chronic: translated #{field}:#{datestr} to #{realdate}"
+ "date:(<= #{sprintf "%012d", realdate.end.to_i}) date:(>= #{sprintf "%012d", realdate.begin.to_i})"
+ end
+ else
+ raise ParseError, "can't understand date #{datestr.inspect}"
+ end
+ end
+ end
+
+ ## limit:42 restrict the search to 42 results
+ subs = subs.gsub(/\blimit:(\S+)\b/) do
+ lim = $1
+ if lim =~ /^\d+$/
+ query[:limit] = lim.to_i
+ ''
+ else
+ raise ParseError, "non-numeric limit #{lim.inspect}"
+ end
+ end
+
+ begin
+ query[:qobj] = @qparser.parse(subs)
+ query[:text] = s
+ query
+ rescue Ferret::QueryParser::QueryParseException => e
+ raise ParseError, e.message
+ end
+ end
+
+private
+
+ def build_ferret_query query
+ q = Ferret::Search::BooleanQuery.new
+ q.add_query query[:qobj], :must if query[:qobj]
+ labels = ([query[:label]] + (query[:labels] || [])).compact
+ labels.each { |t| q.add_query Ferret::Search::TermQuery.new("label", t.to_s), :must }
+ if query[:participants]
+ q2 = Ferret::Search::BooleanQuery.new
+ query[:participants].each do |p|
+ q2.add_query Ferret::Search::TermQuery.new("from", p.email), :should
+ q2.add_query Ferret::Search::TermQuery.new("to", p.email), :should
+ end
+ q.add_query q2, :must
+ end
+
+ q.add_query Ferret::Search::TermQuery.new("label", "spam"), :must_not unless query[:load_spam] || labels.include?(:spam)
+ q.add_query Ferret::Search::TermQuery.new("label", "deleted"), :must_not unless query[:load_deleted] || labels.include?(:deleted)
+ q.add_query Ferret::Search::TermQuery.new("label", "killed"), :must_not if query[:skip_killed]
+
+ q.add_query Ferret::Search::TermQuery.new("source_id", query[:source_id]), :must if query[:source_id]
+ q
+ end
+
+ def wrap_subj subj; "__START_SUBJECT__ #{subj} __END_SUBJECT__"; end
+ def unwrap_subj subj; subj =~ /__START_SUBJECT__ (.*?) __END_SUBJECT__/ && $1; end
+end
+
+end
diff --git a/lib/sup/index.rb b/lib/sup/index.rb
index 5ddd6ee..be0e870 100644
--- a/lib/sup/index.rb
+++ b/lib/sup/index.rb
@@ -1,7 +1,6 @@
-## the index structure for redwood. interacts with ferret.
+## Index interface, subclassed by Ferret indexer.
require 'fileutils'
-require 'ferret'
begin
require 'chronic'
@@ -13,7 +12,7 @@ end
module Redwood
-class Index
+class BaseIndex
class LockError < StandardError
def initialize h
@h = h
@@ -25,17 +24,8 @@ class Index
include Singleton
def initialize dir=BASE_DIR
- @index_mutex = Monitor.new
@dir = dir
-
- wsa = Ferret::Analysis::WhiteSpaceAnalyzer.new false
- sa = Ferret::Analysis::StandardAnalyzer.new [], true
- @analyzer = Ferret::Analysis::PerFieldAnalyzer.new wsa
- @analyzer[:body] = sa
- @analyzer[:subject] = sa
- @qparser ||= Ferret::QueryParser.new :default_field => :body, :analyzer => @analyzer, :or_default => false
@lock = Lockfile.new lockfile, :retries => 0, :max_age => nil
-
self.class.i_am_the_instance self
end
@@ -119,155 +109,44 @@ EOS
save_index
end
- def load_index dir=File.join(@dir, "ferret")
- if File.exists? dir
- Redwood::log "loading index..."
- @index_mutex.synchronize do
- @index = Ferret::Index::Index.new(:path => dir, :analyzer => @analyzer, :id_field => 'message_id')
- Redwood::log "loaded index of #{@index.size} messages"
- end
- else
- Redwood::log "creating index..."
- @index_mutex.synchronize do
- field_infos = Ferret::Index::FieldInfos.new :store => :yes
- field_infos.add_field :message_id, :index => :untokenized
- field_infos.add_field :source_id
- field_infos.add_field :source_info
- field_infos.add_field :date, :index => :untokenized
- field_infos.add_field :body
- field_infos.add_field :label
- field_infos.add_field :attachments
- field_infos.add_field :subject
- field_infos.add_field :from
- field_infos.add_field :to
- field_infos.add_field :refs
- field_infos.add_field :snippet, :index => :no, :term_vector => :no
- field_infos.create_index dir
- @index = Ferret::Index::Index.new(:path => dir, :analyzer => @analyzer, :id_field => 'message_id')
- end
- end
+ def load_index
+ unimplemented
end
## Syncs the message to the index, replacing any previous version. adding
## either way. Index state will be determined by the message's #labels
## accessor.
def sync_message m, opts={}
- entry = @index[m.id]
-
- raise "no source info for message #{m.id}" unless m.source && m.source_info
-
- source_id = if m.source.is_a? Integer
- m.source
- else
- m.source.id or raise "unregistered source #{m.source} (id #{m.source.id.inspect})"
- end
-
- snippet = if m.snippet_contains_encrypted_content? && $config[:discard_snippets_from_encrypted_messages]
- ""
- else
- m.snippet
- end
-
- ## write the new document to the index. if the entry already exists in the
- ## index, reuse it (which avoids having to reload the entry from the source,
- ## which can be quite expensive for e.g. large threads of IMAP actions.)
- ##
- ## exception: if the index entry belongs to an earlier version of the
- ## message, use everything from the new message instead, but union the
- ## flags. this allows messages sent to mailing lists to have their header
- ## updated and to have flags set properly.
- ##
- ## minor hack: messages in sources with lower ids have priority over
- ## messages in sources with higher ids. so messages in the inbox will
- ## override everyone, and messages in the sent box will be overridden
- ## by everyone else.
- ##
- ## written in this manner to support previous versions of the index which
- ## did not keep around the entry body. upgrading is thus seamless.
- entry ||= {}
- labels = m.labels.uniq # override because this is the new state, unless...
-
- ## if we are a later version of a message, ignore what's in the index,
- ## but merge in the labels.
- if entry[:source_id] && entry[:source_info] && entry[:label] &&
- ((entry[:source_id].to_i > source_id) || (entry[:source_info].to_i < m.source_info))
- labels = (entry[:label].symbolistize + m.labels).uniq
- #Redwood::log "found updated version of message #{m.id}: #{m.subj}"
- #Redwood::log "previous version was at #{entry[:source_id].inspect}:#{entry[:source_info].inspect}, this version at #{source_id.inspect}:#{m.source_info.inspect}"
- #Redwood::log "merged labels are #{labels.inspect} (index #{entry[:label].inspect}, message #{m.labels.inspect})"
- entry = {}
- end
-
- ## if force_overwite is true, ignore what's in the index. this is used
- ## primarily by sup-sync to force index updates.
- entry = {} if opts[:force_overwrite]
-
- d = {
- :message_id => m.id,
- :source_id => source_id,
- :source_info => m.source_info,
- :date => (entry[:date] || m.date.to_indexable_s),
- :body => (entry[:body] || m.indexable_content),
- :snippet => snippet, # always override
- :label => labels.uniq.join(" "),
- :attachments => (entry[:attachments] || m.attachments.uniq.join(" ")),
-
- ## always override :from and :to.
- ## older versions of Sup would often store the wrong thing in the index
- ## (because they were canonicalizing email addresses, resulting in the
- ## wrong name associated with each.) the correct address is read from
- ## the original header when these messages are opened in thread-view-mode,
- ## so this allows people to forcibly update the address in the index by
- ## marking those threads for saving.
- :from => (m.from ? m.from.indexable_content : ""),
- :to => (m.to + m.cc + m.bcc).map { |x| x.indexable_content }.join(" "),
-
- :subject => (entry[:subject] || wrap_subj(Message.normalize_subj(m.subj))),
- :refs => (entry[:refs] || (m.refs + m.replytos).uniq.join(" ")),
- }
-
- @index_mutex.synchronize do
- @index.delete m.id
- @index.add_document d
- end
+ unimplemented
end
- def save_index fn=File.join(@dir, "ferret")
- # don't have to do anything, apparently
+ def save_index fn
+ unimplemented
end
def contains_id? id
- @index_mutex.synchronize { @index.search(Ferret::Search::TermQuery.new(:message_id, id)).total_hits > 0 }
+ unimplemented
end
+
def contains? m; contains_id? m.id end
- def size; @index_mutex.synchronize { @index.size } end
+
+ def size
+ unimplemented
+ end
+
def empty?; size == 0 end
- ## you should probably not call this on a block that doesn't break
+ ## Yields a message-id and message-building lambda for each
+ ## message that matches the given query, in descending date order.
+ ## You should probably not call this on a block that doesn't break
## rather quickly because the results can be very large.
- EACH_BY_DATE_NUM = 100
def each_id_by_date query={}
- return if empty? # otherwise ferret barfs ###TODO: remove this once my ferret patch is accepted
- ferret_query = build_ferret_query query
- offset = 0
- while true
- limit = (query[:limit])? [EACH_BY_DATE_NUM, query[:limit] - offset].min : EACH_BY_DATE_NUM
- results = @index_mutex.synchronize { @index.search ferret_query, :sort => "date DESC", :limit => limit, :offset => offset }
- Redwood::log "got #{results.total_hits} results for query (offset #{offset}) #{ferret_query.inspect}"
- results.hits.each do |hit|
- yield @index_mutex.synchronize { @index[hit.doc][:message_id] }, lambda { build_message hit.doc }
- end
- break if query[:limit] and offset >= query[:limit] - limit
- break if offset >= results.total_hits - limit
- offset += limit
- end
+ unimplemented
end
+ ## Return the number of matches for query in the index
def num_results_for query={}
- return 0 if empty? # otherwise ferret barfs ###TODO: remove this once my ferret patch is accepted
-
- ferret_query = build_ferret_query query
- @index_mutex.synchronize { @index.search(ferret_query, :limit => 1).total_hits }
+ unimplemented
end
## yield all messages in the thread containing 'm' by repeatedly
@@ -278,300 +157,60 @@ EOS
## only two options, :limit and :skip_killed. if :skip_killed is
## true, stops loading any thread if a message with a :killed flag
## is found.
- SAME_SUBJECT_DATE_LIMIT = 7
- MAX_CLAUSES = 1000
def each_message_in_thread_for m, opts={}
- #Redwood::log "Building thread for #{m.id}: #{m.subj}"
- messages = {}
- searched = {}
- num_queries = 0
-
- pending = [m.id]
- if $config[:thread_by_subject] # do subject queries
- date_min = m.date - (SAME_SUBJECT_DATE_LIMIT * 12 * 3600)
- date_max = m.date + (SAME_SUBJECT_DATE_LIMIT * 12 * 3600)
-
- q = Ferret::Search::BooleanQuery.new true
- sq = Ferret::Search::PhraseQuery.new(:subject)
- wrap_subj(Message.normalize_subj(m.subj)).split.each do |t|
- sq.add_term t
- end
- q.add_query sq, :must
- q.add_query Ferret::Search::RangeQuery.new(:date, :>= => date_min.to_indexable_s, :<= => date_max.to_indexable_s), :must
-
- q = build_ferret_query :qobj => q
-
- p1 = @index_mutex.synchronize { @index.search(q).hits.map { |hit| @index[hit.doc][:message_id] } }
- Redwood::log "found #{p1.size} results for subject query #{q}"
-
- p2 = @index_mutex.synchronize { @index.search(q.to_s, :limit => :all).hits.map { |hit| @index[hit.doc][:message_id] } }
- Redwood::log "found #{p2.size} results in string form"
-
- pending = (pending + p1 + p2).uniq
- end
-
- until pending.empty? || (opts[:limit] && messages.size >= opts[:limit])
- q = Ferret::Search::BooleanQuery.new true
- # this disappeared in newer ferrets... wtf.
- # q.max_clause_count = 2048
-
- lim = [MAX_CLAUSES / 2, pending.length].min
- pending[0 ... lim].each do |id|
- searched[id] = true
- q.add_query Ferret::Search::TermQuery.new(:message_id, id), :should
- q.add_query Ferret::Search::TermQuery.new(:refs, id), :should
- end
- pending = pending[lim .. -1]
-
- q = build_ferret_query :qobj => q
-
- num_queries += 1
- killed = false
- @index_mutex.synchronize do
- @index.search_each(q, :limit => :all) do |docid, score|
- break if opts[:limit] && messages.size >= opts[:limit]
- if @index[docid][:label].split(/\s+/).include?("killed") && opts[:skip_killed]
- killed = true
- break
- end
- mid = @index[docid][:message_id]
- unless messages.member?(mid)
- #Redwood::log "got #{mid} as a child of #{id}"
- messages[mid] ||= lambda { build_message docid }
- refs = @index[docid][:refs].split
- pending += refs.select { |id| !searched[id] }
- end
- end
- end
- end
-
- if killed
- Redwood::log "thread for #{m.id} is killed, ignoring"
- false
- else
- Redwood::log "ran #{num_queries} queries to build thread of #{messages.size} messages for #{m.id}: #{m.subj}" if num_queries > 0
- messages.each { |mid, builder| yield mid, builder }
- true
- end
+ unimplemented
end
- ## builds a message object from a ferret result
- def build_message docid
- @index_mutex.synchronize do
- doc = @index[docid] or return
-
- source = SourceManager[doc[:source_id].to_i]
- raise "invalid source #{doc[:source_id]}" unless source
-
- #puts "building message #{doc[:message_id]} (#{source}##{doc[:source_info]})"
-
- fake_header = {
- "date" => Time.at(doc[:date].to_i),
- "subject" => unwrap_subj(doc[:subject]),
- "from" => doc[:from],
- "to" => doc[:to].split.join(", "), # reformat
- "message-id" => doc[:message_id],
- "references" => doc[:refs].split.map { |x| "<#{x}>" }.join(" "),
- }
-
- m = Message.new :source => source, :source_info => doc[:source_info].to_i,
- :labels => doc[:label].symbolistize,
- :snippet => doc[:snippet]
- m.parse_header fake_header
- m
- end
+ ## Load message with the given message-id from the index
+ def build_message id
+ unimplemented
end
- def delete id; @index_mutex.synchronize { @index.delete id } end
-
- def load_contacts emails, h={}
- q = Ferret::Search::BooleanQuery.new true
- emails.each do |e|
- qq = Ferret::Search::BooleanQuery.new true
- qq.add_query Ferret::Search::TermQuery.new(:from, e), :should
- qq.add_query Ferret::Search::TermQuery.new(:to, e), :should
- q.add_query qq
- end
- q.add_query Ferret::Search::TermQuery.new(:label, "spam"), :must_not
-
- Redwood::log "contact search: #{q}"
- contacts = {}
- num = h[:num] || 20
- @index_mutex.synchronize do
- @index.search_each q, :sort => "date DESC", :limit => :all do |docid, score|
- break if contacts.size >= num
- #Redwood::log "got message #{docid} to: #{@index[docid][:to].inspect} and from: #{@index[docid][:from].inspect}"
- f = @index[docid][:from]
- t = @index[docid][:to]
-
- if AccountManager.is_account_email? f
- t.split(" ").each { |e| contacts[Person.from_address(e)] = true }
- else
- contacts[Person.from_address(f)] = true
- end
- end
- end
+ ## Delete message with the given message-id from the index
+ def delete id
+ unimplemented
+ end
- contacts.keys.compact
+ ## Given an array of email addresses, return an array of Person objects that
+ ## have sent mail to or received mail from any of the given addresses.
+ def load_contacts email_addresses, h={}
+ unimplemented
end
+ ## Yield each docid matching query
def each_docid query={}
- ferret_query = build_ferret_query query
- results = @index_mutex.synchronize { @index.search ferret_query, :limit => (query[:limit] || :all) }
- results.hits.map { |hit| yield hit.doc }
+ unimplemented
end
+ ## Yield each messages matching query
def each_message query={}
- each_docid query do |docid|
- yield build_message(docid)
- end
+ unimplemented
end
+ ## Implementation-specific optimization step
def optimize
- @index_mutex.synchronize { @index.optimize }
+ unimplemented
end
+ ## Return the id source of the source the message with the given message-id
+ ## was synced from
def source_for_id id
- entry = @index[id]
- return unless entry
- entry[:source_id].to_i
+ unimplemented
end
class ParseError < StandardError; end
## parse a query string from the user. returns a query object
## that can be passed to any index method with a 'query'
- ## argument, as well as build_ferret_query.
+ ## argument.
##
## raises a ParseError if something went wrong.
def parse_query s
- query = {}
-
- subs = s.gsub(/\b(to|from):(\S+)\b/) do
- field, name = $1, $2
- if(p = ContactManager.contact_for(name))
- [field, p.email]
- elsif name == "me"
- [field, "(" + AccountManager.user_emails.join("||") + ")"]
- else
- [field, name]
- end.join(":")
- end
-
- ## if we see a label:deleted or a label:spam term anywhere in the query
- ## string, we set the extra load_spam or load_deleted options to true.
- ## bizarre? well, because the query allows arbitrary parenthesized boolean
- ## expressions, without fully parsing the query, we can't tell whether
- ## the user is explicitly directing us to search spam messages or not.
- ## e.g. if the string is -(-(-(-(-label:spam)))), does the user want to
- ## search spam messages or not?
- ##
- ## so, we rely on the fact that turning these extra options ON turns OFF
- ## the adding of "-label:deleted" or "-label:spam" terms at the very
- ## final stage of query processing. if the user wants to search spam
- ## messages, not adding that is the right thing; if he doesn't want to
- ## search spam messages, then not adding it won't have any effect.
- query[:load_spam] = true if subs =~ /\blabel:spam\b/
- query[:load_deleted] = true if subs =~ /\blabel:deleted\b/
-
- ## gmail style "is" operator
- subs = subs.gsub(/\b(is|has):(\S+)\b/) do
- field, label = $1, $2
- case label
- when "read"
- "-label:unread"
- when "spam"
- query[:load_spam] = true
- "label:spam"
- when "deleted"
- query[:load_deleted] = true
- "label:deleted"
- else
- "label:#{$2}"
- end
- end
-
- ## gmail style attachments "filename" and "filetype" searches
- subs = subs.gsub(/\b(filename|filetype):(\((.+?)\)\B|(\S+)\b)/) do
- field, name = $1, ($3 || $4)
- case field
- when "filename"
- Redwood::log "filename - translated #{field}:#{name} to attachments:(#{name.downcase})"
- "attachments:(#{name.downcase})"
- when "filetype"
- Redwood::log "filetype - translated #{field}:#{name} to attachments:(*.#{name.downcase})"
- "attachments:(*.#{name.downcase})"
- end
- end
-
- if $have_chronic
- subs = subs.gsub(/\b(before|on|in|during|after):(\((.+?)\)\B|(\S+)\b)/) do
- field, datestr = $1, ($3 || $4)
- realdate = Chronic.parse datestr, :guess => false, :context => :past
- if realdate
- case field
- when "after"
- Redwood::log "chronic: translated #{field}:#{datestr} to #{realdate.end}"
- "date:(>= #{sprintf "%012d", realdate.end.to_i})"
- when "before"
- Redwood::log "chronic: translated #{field}:#{datestr} to #{realdate.begin}"
- "date:(<= #{sprintf "%012d", realdate.begin.to_i})"
- else
- Redwood::log "chronic: translated #{field}:#{datestr} to #{realdate}"
- "date:(<= #{sprintf "%012d", realdate.end.to_i}) date:(>= #{sprintf "%012d", realdate.begin.to_i})"
- end
- else
- raise ParseError, "can't understand date #{datestr.inspect}"
- end
- end
- end
-
- ## limit:42 restrict the search to 42 results
- subs = subs.gsub(/\blimit:(\S+)\b/) do
- lim = $1
- if lim =~ /^\d+$/
- query[:limit] = lim.to_i
- ''
- else
- raise ParseError, "non-numeric limit #{lim.inspect}"
- end
- end
-
- begin
- query[:qobj] = @qparser.parse(subs)
- query[:text] = s
- query
- rescue Ferret::QueryParser::QueryParseException => e
- raise ParseError, e.message
- end
- end
-
-private
-
- def build_ferret_query query
- q = Ferret::Search::BooleanQuery.new
- q.add_query query[:qobj], :must if query[:qobj]
- labels = ([query[:label]] + (query[:labels] || [])).compact
- labels.each { |t| q.add_query Ferret::Search::TermQuery.new("label", t.to_s), :must }
- if query[:participants]
- q2 = Ferret::Search::BooleanQuery.new
- query[:participants].each do |p|
- q2.add_query Ferret::Search::TermQuery.new("from", p.email), :should
- q2.add_query Ferret::Search::TermQuery.new("to", p.email), :should
- end
- q.add_query q2, :must
- end
-
- q.add_query Ferret::Search::TermQuery.new("label", "spam"), :must_not unless query[:load_spam] || labels.include?(:spam)
- q.add_query Ferret::Search::TermQuery.new("label", "deleted"), :must_not unless query[:load_deleted] || labels.include?(:deleted)
- q.add_query Ferret::Search::TermQuery.new("label", "killed"), :must_not if query[:skip_killed]
-
- q.add_query Ferret::Search::TermQuery.new("source_id", query[:source_id]), :must if query[:source_id]
- q
+ unimplemented
end
-
- def wrap_subj subj; "__START_SUBJECT__ #{subj} __END_SUBJECT__"; end
- def unwrap_subj subj; subj =~ /__START_SUBJECT__ (.*?) __END_SUBJECT__/ && $1; end
end
end
+
+require 'lib/sup/ferret_index'
+Redwood::Index = Redwood::FerretIndex
--
1.6.0.4
------------------------------
Message: 474
Date: Sat, 20 Jun 2009 13:50:11 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH 12/18] remove last external uses of ferret
docid
Message-ID: <1245531017-9907-13-git-send-email-rlane@club.cc.cmu.edu>
---
bin/sup-sync-back | 2 +-
bin/sup-tweak-labels | 6 +++---
lib/sup/ferret_index.rb | 10 ++--------
lib/sup/index.rb | 12 +++++++-----
4 files changed, 13 insertions(+), 17 deletions(-)
diff --git a/bin/sup-sync-back b/bin/sup-sync-back
index 679e03a..8aa2039 100755
--- a/bin/sup-sync-back
+++ b/bin/sup-sync-back
@@ -17,7 +17,7 @@ def die msg
end
def has_any_from_source_with_label? index, source, label
query = { :source_id => source.id, :label => label, :limit => 1 }
- not Enumerable::Enumerator.new(index, :each_docid, query).map.empty?
+ not Enumerable::Enumerator.new(index, :each_id, query).map.empty?
end
opts = Trollop::options do
diff --git a/bin/sup-tweak-labels b/bin/sup-tweak-labels
index 95a3b03..a8115ea 100755
--- a/bin/sup-tweak-labels
+++ b/bin/sup-tweak-labels
@@ -83,14 +83,14 @@ begin
query += ' ' + opts[:query] if opts[:query]
parsed_query = index.parse_query query
- docs = Enumerable::Enumerator.new(index, :each_docid, parsed_query).map
- num_total = docs.size
+ ids = Enumerable::Enumerator.new(index, :each_id, parsed_query).map
+ num_total = ids.size
$stderr.puts "Found #{num_total} documents across #{source_ids.length} sources. Scanning..."
num_changed = num_scanned = 0
last_info_time = start_time = Time.now
- docs.each do |id|
+ ids.each do |id|
num_scanned += 1
m = index.build_message id
diff --git a/lib/sup/ferret_index.rb b/lib/sup/ferret_index.rb
index 53c19e0..a2c30ab 100644
--- a/lib/sup/ferret_index.rb
+++ b/lib/sup/ferret_index.rb
@@ -301,16 +301,10 @@ class FerretIndex < BaseIndex
contacts.keys.compact
end
- def each_docid query={}
+ def each_id query={}
ferret_query = build_ferret_query query
results = @index_mutex.synchronize { @index.search ferret_query, :limit => (query[:limit] || :all) }
- results.hits.map { |hit| yield hit.doc }
- end
-
- def each_message query={}
- each_docid query do |docid|
- yield build_message(docid)
- end
+ results.hits.map { |hit| yield @index[hit.doc][:message_id] }
end
def optimize
diff --git a/lib/sup/index.rb b/lib/sup/index.rb
index be0e870..45382f1 100644
--- a/lib/sup/index.rb
+++ b/lib/sup/index.rb
@@ -177,14 +177,16 @@ EOS
unimplemented
end
- ## Yield each docid matching query
- def each_docid query={}
+ ## Yield each message-id matching query
+ def each_id query={}
unimplemented
end
- ## Yield each messages matching query
- def each_message query={}
- unimplemented
+ ## Yield each message matching query
+ def each_message query={}, &b
+ each_id query do |id|
+ yield build_message(id)
+ end
end
## Implementation-specific optimization step
--
1.6.0.4
------------------------------
Message: 475
Date: Sat, 20 Jun 2009 13:50:08 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH 09/18] index: revert overeager opts->query
rename in each_message_in_thread_for
Message-ID: <1245531017-9907-10-git-send-email-rlane@club.cc.cmu.edu>
---
lib/sup/index.rb | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/sup/index.rb b/lib/sup/index.rb
index e3f9e69..080a4ec 100644
--- a/lib/sup/index.rb
+++ b/lib/sup/index.rb
@@ -280,7 +280,7 @@ EOS
## is found.
SAME_SUBJECT_DATE_LIMIT = 7
MAX_CLAUSES = 1000
- def each_message_in_thread_for m, query={}
+ def each_message_in_thread_for m, opts={}
#Redwood::log "Building thread for #{m.id}: #{m.subj}"
messages = {}
searched = {}
@@ -310,7 +310,7 @@ EOS
pending = (pending + p1 + p2).uniq
end
- until pending.empty? || (query[:limit] && messages.size >= query[:limit])
+ until pending.empty? || (opts[:limit] && messages.size >= opts[:limit])
q = Ferret::Search::BooleanQuery.new true
# this disappeared in newer ferrets... wtf.
# q.max_clause_count = 2048
@@ -329,8 +329,8 @@ EOS
killed = false
@index_mutex.synchronize do
@index.search_each(q, :limit => :all) do |docid, score|
- break if query[:limit] && messages.size >= query[:limit]
- if @index[docid][:label].split(/\s+/).include?("killed") && query[:skip_killed]
+ break if opts[:limit] && messages.size >= opts[:limit]
+ if @index[docid][:label].split(/\s+/).include?("killed") && opts[:skip_killed]
killed = true
break
end
--
1.6.0.4
------------------------------
Message: 476
Date: Sat, 20 Jun 2009 13:50:13 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH 14/18] index: choose index implementation
with config entry or environment variable
Message-ID: <1245531017-9907-15-git-send-email-rlane@club.cc.cmu.edu>
---
lib/sup.rb | 2 ++
lib/sup/index.rb | 10 ++++++++--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/lib/sup.rb b/lib/sup.rb
index 5689c2b..54de73f 100644
--- a/lib/sup.rb
+++ b/lib/sup.rb
@@ -54,6 +54,8 @@ module Redwood
YAML_DOMAIN = "masanjin.net"
YAML_DATE = "2006-10-01"
+ DEFAULT_INDEX = 'ferret'
+
## record exceptions thrown in threads nicely
@exceptions = []
@exception_mutex = Mutex.new
diff --git a/lib/sup/index.rb b/lib/sup/index.rb
index 45382f1..df428f7 100644
--- a/lib/sup/index.rb
+++ b/lib/sup/index.rb
@@ -212,7 +212,13 @@ EOS
end
end
+index_name = ENV['SUP_INDEX'] || $config[:index] || DEFAULT_INDEX
+begin
+ require "sup/#{index_name}_index"
+rescue LoadError
+ fail "invalid index name #{index_name.inspect}"
end
+Index = Redwood.const_get "#{index_name.capitalize}Index"
+Redwood::log "using index #{Index.name}"
-require 'lib/sup/ferret_index'
-Redwood::Index = Redwood::FerretIndex
+end
--
1.6.0.4
------------------------------
Message: 477
Date: Sat, 20 Jun 2009 13:50:12 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH 13/18] add Message.indexable_{body, chunks,
subject}
Message-ID: <1245531017-9907-14-git-send-email-rlane@club.cc.cmu.edu>
---
lib/sup/message.rb | 16 ++++++++++++++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/lib/sup/message.rb b/lib/sup/message.rb
index b667cb3..2999986 100644
--- a/lib/sup/message.rb
+++ b/lib/sup/message.rb
@@ -270,11 +270,23 @@ EOS
to.map { |p| p.indexable_content },
cc.map { |p| p.indexable_content },
bcc.map { |p| p.indexable_content },
- chunks.select { |c| c.is_a? Chunk::Text }.map { |c| c.lines },
- Message.normalize_subj(subj),
+ indexable_chunks.map { |c| c.lines },
+ indexable_subject,
].flatten.compact.join " "
end
+ def indexable_body
+ indexable_chunks.map { |c| c.lines }.flatten.compact.join " "
+ end
+
+ def indexable_chunks
+ chunks.select { |c| c.is_a? Chunk::Text }
+ end
+
+ def indexable_subject
+ Message.normalize_subj(subj)
+ end
+
def quotable_body_lines
chunks.find_all { |c| c.quotable? }.map { |c| c.lines }.flatten
end
--
1.6.0.4
------------------------------
Message: 478
Date: Sat, 20 Jun 2009 13:50:14 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH 15/18] index: add xapian implementation
Message-ID: <1245531017-9907-16-git-send-email-rlane@club.cc.cmu.edu>
---
lib/sup/poll.rb | 2 +-
lib/sup/xapian_index.rb | 483 +++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 484 insertions(+), 1 deletions(-)
create mode 100644 lib/sup/xapian_index.rb
diff --git a/lib/sup/poll.rb b/lib/sup/poll.rb
index c83290c..8a9d218 100644
--- a/lib/sup/poll.rb
+++ b/lib/sup/poll.rb
@@ -147,7 +147,7 @@ EOS
m_new = Message.build_from_source source, offset
m_old = Index.build_message m_new.id
- m_new.labels = default_labels + (source.archived? ? [] : [:inbox])
+ m_new.labels += default_labels + (source.archived? ? [] : [:inbox])
m_new.labels << :sent if source.uri.eql?(SentManager.source_uri)
m_new.labels.delete :unread if m_new.source_marked_read?
m_new.labels.each { |l| LabelManager << l }
diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
new file mode 100644
index 0000000..7faa64d
--- /dev/null
+++ b/lib/sup/xapian_index.rb
@@ -0,0 +1,483 @@
+require 'xapian'
+require 'gdbm'
+require 'set'
+
+module Redwood
+
+# This index implementation uses Xapian for searching and GDBM for storage. It
+# tends to be slightly faster than Ferret for indexing and significantly faster
+# for searching due to precomputing thread membership.
+class XapianIndex < BaseIndex
+ STEM_LANGUAGE = "english"
+
+ def initialize dir=BASE_DIR
+ super
+
+ @index_mutex = Monitor.new
+
+ @entries = MarshalledGDBM.new File.join(dir, "entries.db")
+ @docids = MarshalledGDBM.new File.join(dir, "docids.db")
+ @thread_members = MarshalledGDBM.new File.join(dir, "thread_members.db")
+ @thread_ids = MarshalledGDBM.new File.join(dir, "thread_ids.db")
+ @assigned_docids = GDBM.new File.join(dir, "assigned_docids.db")
+
+ @xapian = Xapian::WritableDatabase.new(File.join(dir, "xapian"), Xapian::DB_CREATE_OR_OPEN)
+ @term_generator = Xapian::TermGenerator.new()
+ @term_generator.stemmer = Xapian::Stem.new(STEM_LANGUAGE)
+ @enquire = Xapian::Enquire.new @xapian
+ @enquire.weighting_scheme = Xapian::BoolWeight.new
+ @enquire.docid_order = Xapian::Enquire::ASCENDING
+ end
+
+ def load_index
+ end
+
+ def save_index
+ end
+
+ def optimize
+ end
+
+ def size
+ synchronize { @xapian.doccount }
+ end
+
+ def contains_id? id
+ synchronize { @entries.member? id }
+ end
+
+ def source_for_id id
+ synchronize { @entries[id][:source_id] }
+ end
+
+ def delete id
+ synchronize { @xapian.delete_document @docids[id] }
+ end
+
+ def build_message id
+ entry = synchronize { @entries[id] }
+ return unless entry
+
+ source = SourceManager[entry[:source_id]]
+ raise "invalid source #{entry[:source_id]}" unless source
+
+ mk_addrs = lambda { |l| l.map { |e,n| "#{n} <#{e}>" } * ', ' }
+ mk_refs = lambda { |l| l.map { |r| "<#{r}>" } * ' ' }
+ fake_header = {
+ 'message-id' => entry[:message_id],
+ 'date' => Time.at(entry[:date]),
+ 'subject' => entry[:subject],
+ 'from' => mk_addrs[[entry[:from]]],
+ 'to' => mk_addrs[[entry[:to]]],
+ 'cc' => mk_addrs[[entry[:cc]]],
+ 'bcc' => mk_addrs[[entry[:bcc]]],
+ 'reply-tos' => mk_refs[entry[:replytos]],
+ 'references' => mk_refs[entry[:refs]],
+ }
+
+ m = Message.new :source => source, :source_info => entry[:source_info],
+ :labels => entry[:labels],
+ :snippet => entry[:snippet]
+ m.parse_header fake_header
+ m
+ end
+
+ def sync_message m, opts={}
+ entry = synchronize { @entries[m.id] }
+ snippet = m.snippet
+ entry ||= {}
+ labels = m.labels
+ entry = {} if opts[:force_overwrite]
+
+ d = {
+ :message_id => m.id,
+ :source_id => m.source.id,
+ :source_info => m.source_info,
+ :date => (entry[:date] || m.date),
+ :snippet => snippet,
+ :labels => labels.uniq,
+ :from => (entry[:from] || [m.from.email, m.from.name]),
+ :to => (entry[:to] || m.to.map { |p| [p.email, p.name] }),
+ :cc => (entry[:cc] || m.cc.map { |p| [p.email, p.name] }),
+ :bcc => (entry[:bcc] || m.bcc.map { |p| [p.email, p.name] }),
+ :subject => m.subj,
+ :refs => (entry[:refs] || m.refs),
+ :replytos => (entry[:replytos] || m.replytos),
+ }
+
+ m.labels.each { |l| LabelManager << l }
+
+ synchronize do
+ index_message m, opts
+ union_threads([m.id] + m.refs + m.replytos)
+ @entries[m.id] = d
+ end
+ true
+ end
+
+ def num_results_for query={}
+ xapian_query = build_xapian_query query
+ matchset = run_query xapian_query, 0, 0, 100
+ matchset.matches_estimated
+ end
+
+ EACH_ID_PAGE = 100
+ def each_id query={}
+ offset = 0
+ page = EACH_ID_PAGE
+
+ xapian_query = build_xapian_query query
+ while true
+ ids = run_query_ids xapian_query, offset, (offset+page)
+ ids.each { |id| yield id }
+ break if ids.size < page
+ offset += page
+ end
+ end
+
+ def each_id_by_date query={}
+ each_id(query) { |id| yield id, lambda { build_message id } }
+ end
+
+ def each_message_in_thread_for m, opts={}
+ # TODO thread by subject
+ # TODO handle killed threads
+ ids = synchronize { @thread_members[@thread_ids[m.id]] } || []
+ ids.select { |id| contains_id? id }.each { |id| yield id, lambda { build_message id } }
+ true
+ end
+
+ def load_contacts emails, opts={}
+ contacts = Set.new
+ num = opts[:num] || 20
+ each_id_by_date :participants => emails do |id,b|
+ break if contacts.size >= num
+ m = b.call
+ ([m.from]+m.to+m.cc+m.bcc).compact.each { |p| contacts << [p.name, p.email] }
+ end
+ contacts.to_a.compact.map { |n,e| Person.new n, e }[0...num]
+ end
+
+ # TODO share code with the Ferret index
+ def parse_query s
+ query = {}
+
+ subs = s.gsub(/\b(to|from):(\S+)\b/) do
+ field, name = $1, $2
+ if(p = ContactManager.contact_for(name))
+ [field, p.email]
+ elsif name == "me"
+ [field, "(" + AccountManager.user_emails.join("||") + ")"]
+ else
+ [field, name]
+ end.join(":")
+ end
+
+ ## if we see a label:deleted or a label:spam term anywhere in the query
+ ## string, we set the extra load_spam or load_deleted options to true.
+ ## bizarre? well, because the query allows arbitrary parenthesized boolean
+ ## expressions, without fully parsing the query, we can't tell whether
+ ## the user is explicitly directing us to search spam messages or not.
+ ## e.g. if the string is -(-(-(-(-label:spam)))), does the user want to
+ ## search spam messages or not?
+ ##
+ ## so, we rely on the fact that turning these extra options ON turns OFF
+ ## the adding of "-label:deleted" or "-label:spam" terms at the very
+ ## final stage of query processing. if the user wants to search spam
+ ## messages, not adding that is the right thing; if he doesn't want to
+ ## search spam messages, then not adding it won't have any effect.
+ query[:load_spam] = true if subs =~ /\blabel:spam\b/
+ query[:load_deleted] = true if subs =~ /\blabel:deleted\b/
+
+ ## gmail style "is" operator
+ subs = subs.gsub(/\b(is|has):(\S+)\b/) do
+ field, label = $1, $2
+ case label
+ when "read"
+ "-label:unread"
+ when "spam"
+ query[:load_spam] = true
+ "label:spam"
+ when "deleted"
+ query[:load_deleted] = true
+ "label:deleted"
+ else
+ "label:#{$2}"
+ end
+ end
+
+ ## gmail style attachments "filename" and "filetype" searches
+ subs = subs.gsub(/\b(filename|filetype):(\((.+?)\)\B|(\S+)\b)/) do
+ field, name = $1, ($3 || $4)
+ case field
+ when "filename"
+ Redwood::log "filename - translated #{field}:#{name} to attachment:\"#{name.downcase}\""
+ "attachment:\"#{name.downcase}\""
+ when "filetype"
+ Redwood::log "filetype - translated #{field}:#{name} to attachment_extension:#{name.downcase}"
+ "attachment_extension:#{name.downcase}"
+ end
+ end
+
+ if $have_chronic
+ lastdate = 2<<32 - 1
+ firstdate = 0
+ subs = subs.gsub(/\b(before|on|in|during|after):(\((.+?)\)\B|(\S+)\b)/) do
+ field, datestr = $1, ($3 || $4)
+ realdate = Chronic.parse datestr, :guess => false, :context => :past
+ if realdate
+ case field
+ when "after"
+ Redwood::log "chronic: translated #{field}:#{datestr} to #{realdate.end}"
+ "date:#{realdate.end.to_i}..#{lastdate}"
+ when "before"
+ Redwood::log "chronic: translated #{field}:#{datestr} to #{realdate.begin}"
+ "date:#{firstdate}..#{realdate.end.to_i}"
+ else
+ Redwood::log "chronic: translated #{field}:#{datestr} to #{realdate}"
+ "date:#{realdate.begin.to_i}..#{realdate.end.to_i}"
+ end
+ else
+ raise ParseError, "can't understand date #{datestr.inspect}"
+ end
+ end
+ end
+
+ ## limit:42 restrict the search to 42 results
+ subs = subs.gsub(/\blimit:(\S+)\b/) do
+ lim = $1
+ if lim =~ /^\d+$/
+ query[:limit] = lim.to_i
+ ''
+ else
+ raise ParseError, "non-numeric limit #{lim.inspect}"
+ end
+ end
+
+ qp = Xapian::QueryParser.new
+ qp.database = @xapian
+ qp.stemmer = Xapian::Stem.new(STEM_LANGUAGE)
+ qp.stemming_strategy = Xapian::QueryParser::STEM_SOME
+ qp.default_op = Xapian::Query::OP_AND
+ qp.add_valuerangeprocessor(Xapian::NumberValueRangeProcessor.new(DATE_VALUENO, 'date:', true))
+ NORMAL_PREFIX.each { |k,v| qp.add_prefix k, v }
+ BOOLEAN_PREFIX.each { |k,v| qp.add_boolean_prefix k, v }
+ xapian_query = qp.parse_query(subs, Xapian::QueryParser::FLAG_PHRASE|Xapian::QueryParser::FLAG_BOOLEAN|Xapian::QueryParser::FLAG_LOVEHATE|Xapian::QueryParser::FLAG_WILDCARD, PREFIX['body'])
+
+ raise ParseError if xapian_query.nil? or xapian_query.empty?
+ query[:qobj] = xapian_query
+ query[:text] = s
+ query
+ end
+
+ private
+
+ # Stemmed
+ NORMAL_PREFIX = {
+ 'subject' => 'S',
+ 'body' => 'B',
+ 'from_name' => 'FN',
+ 'to_name' => 'TN',
+ 'name' => 'N',
+ 'attachment' => 'A',
+ }
+
+ # Unstemmed
+ BOOLEAN_PREFIX = {
+ 'type' => 'K',
+ 'from_email' => 'FE',
+ 'to_email' => 'TE',
+ 'email' => 'E',
+ 'date' => 'D',
+ 'label' => 'L',
+ 'source_id' => 'I',
+ 'attachment_extension' => 'O',
+ }
+
+ PREFIX = NORMAL_PREFIX.merge BOOLEAN_PREFIX
+
+ DATE_VALUENO = 0
+
+ # Xapian can very efficiently sort in ascending docid order. Sup always wants
+ # to sort by descending date, so this method maps between them. In order to
+ # handle multiple messages per second, we use a logistic curve centered
+ # around MIDDLE_DATE so that the slope (docid/s) is greatest in this time
+ # period. A docid collision is not an error - the code will pick the next
+ # smallest unused one.
+ DOCID_SCALE = 2.0**32
+ TIME_SCALE = 2.0**27
+ MIDDLE_DATE = Time.gm(2011)
+ def assign_docid m
+ t = (m.date.to_i - MIDDLE_DATE.to_i).to_f
+ docid = (DOCID_SCALE - DOCID_SCALE/(Math::E**(-(t/TIME_SCALE)) + 1)).to_i
+ begin
+ while @assigned_docids.member? [docid].pack("N")
+ docid -= 1
+ end
+ rescue
+ end
+ @assigned_docids[[docid].pack("N")] = ''
+ docid
+ end
+
+ def synchronize &b
+ @index_mutex.synchronize &b
+ end
+
+ def run_query xapian_query, offset, limit, checkatleast=0
+ synchronize do
+ @enquire.query = xapian_query
+ @enquire.mset(offset, limit-offset, checkatleast)
+ end
+ end
+
+ def run_query_ids xapian_query, offset, limit
+ matchset = run_query xapian_query, offset, limit
+ matchset.matches.map { |r| r.document.data }
+ end
+
+ Q = Xapian::Query
+ def build_xapian_query opts
+ labels = ([opts[:label]] + (opts[:labels] || [])).compact
+ neglabels = [:spam, :deleted, :killed].reject { |l| (labels.include? l) || opts.member?("load_#{l}".intern) }
+ pos_terms, neg_terms = [], []
+
+ pos_terms << mkterm(:type, 'mail')
+ pos_terms.concat(labels.map { |l| mkterm(:label,l) })
+ pos_terms << opts[:qobj] if opts[:qobj]
+ pos_terms << mkterm(:source_id, opts[:source_id]) if opts[:source_id]
+
+ if opts[:participants]
+ participant_terms = opts[:participants].map { |p| mkterm(:email,:any, (Redwood::Person === p) ? p.email : p) }
+ pos_terms << Q.new(Q::OP_OR, participant_terms)
+ end
+
+ neg_terms.concat(neglabels.map { |l| mkterm(:label,l) })
+
+ pos_query = Q.new(Q::OP_AND, pos_terms)
+ neg_query = Q.new(Q::OP_OR, neg_terms)
+
+ if neg_query.empty?
+ pos_query
+ else
+ Q.new(Q::OP_AND_NOT, [pos_query, neg_query])
+ end
+ end
+
+ def index_message m, opts
+ terms = []
+ text = []
+
+ subject_text = m.indexable_subject
+ body_text = m.indexable_body
+
+ # Person names are indexed with several prefixes
+ person_termer = lambda do |d|
+ lambda do |p|
+ ["#{d}_name", "name", "body"].each do |x|
+ text << [p.name, PREFIX[x]]
+ end if p.name
+ [d, :any].each { |x| terms << mkterm(:email, x, p.email) }
+ end
+ end
+
+ person_termer[:from][m.from] if m.from
+ (m.to+m.cc+m.bcc).each(&(person_termer[:to]))
+
+ terms << mkterm(:date,m.date) if m.date
+ m.labels.each { |t| terms << mkterm(:label,t) }
+ terms << mkterm(:type, 'mail')
+ terms << mkterm(:source_id, m.source.id)
+ m.attachments.each do |a|
+ a =~ /\.(\w+)$/ or next
+ t = mkterm(:attachment_extension, $1)
+ terms << t
+ end
+
+ # Full text search content
+ text << [subject_text, PREFIX['subject']]
+ text << [subject_text, PREFIX['body']]
+ text << [body_text, PREFIX['body']]
+ m.attachments.each { |a| text << [a, PREFIX['attachment']] }
+
+ # Date value for range queries
+ date_value = Xapian.sortable_serialise(m.date.to_i)
+
+ doc = Xapian::Document.new
+ docid = @docids[m.id] || assign_docid(m)
+
+ @term_generator.document = doc
+ text.each { |text,prefix| @term_generator.index_text text, 1, prefix }
+ terms.each { |term| doc.add_term term }
+ doc.add_value DATE_VALUENO, date_value
+ doc.data = m.id
+
+ @xapian.replace_document docid, doc
+ @docids[m.id] = docid
+ end
+
+ # Construct a Xapian term
+ def mkterm type, *args
+ case type
+ when :label
+ PREFIX['label'] + args[0].to_s.downcase
+ when :type
+ PREFIX['type'] + args[0].to_s.downcase
+ when :date
+ PREFIX['date'] + args[0].getutc.strftime("%Y%m%d%H%M%S")
+ when :email
+ case args[0]
+ when :from then PREFIX['from_email']
+ when :to then PREFIX['to_email']
+ when :any then PREFIX['email']
+ else raise "Invalid email term type #{args[0]}"
+ end + args[1].to_s.downcase
+ when :source_id
+ PREFIX['source_id'] + args[0].to_s.downcase
+ when :attachment_extension
+ PREFIX['attachment_extension'] + args[0].to_s.downcase
+ else
+ raise "Invalid term type #{type}"
+ end
+ end
+
+ # Join all the given message-ids into a single thread
+ def union_threads ids
+ seen_threads = Set.new
+ related = Set.new
+
+ # Get all the ids that will be in the new thread
+ ids.each do |id|
+ related << id
+ thread_id = @thread_ids[id]
+ if thread_id && !seen_threads.member?(thread_id)
+ thread_members = @thread_members[thread_id]
+ related.merge thread_members
+ seen_threads << thread_id
+ end
+ end
+
+ # Pick a leader and move all the others to its thread
+ a = related.to_a
+ best, *rest = a.sort_by { |x| x.hash }
+ @thread_members[best] = a
+ @thread_ids[best] = best
+ rest.each do |x|
+ @thread_members.delete x
+ @thread_ids[x] = best
+ end
+ end
+end
+
+end
+
+class MarshalledGDBM < GDBM
+ def []= k, v
+ super k, Marshal.dump(v)
+ end
+
+ def [] k
+ v = super k
+ v ? Marshal.load(v) : nil
+ end
+end
--
1.6.0.4
------------------------------
Message: 479
Date: Sat, 20 Jun 2009 13:50:16 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH 17/18] add limit argument to
author_names_and_newness_for_thread
Message-ID: <1245531017-9907-18-git-send-email-rlane@club.cc.cmu.edu>
---
lib/sup/modes/thread-index-mode.rb | 15 ++++++++++-----
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb
index 0bd8110..b671119 100644
--- a/lib/sup/modes/thread-index-mode.rb
+++ b/lib/sup/modes/thread-index-mode.rb
@@ -1,3 +1,5 @@
+require 'set'
+
module Redwood
## subclasses should implement:
@@ -757,10 +759,12 @@ protected
def authors; map { |m, *o| m.from if m }.compact.uniq; end
- def author_names_and_newness_for_thread t
+ def author_names_and_newness_for_thread t, limit=nil
new = {}
- authors = t.map do |m, *o|
+ authors = Set.new
+ t.each do |m, *o|
next unless m
+ break if limit and authors.size >= limit
name =
if AccountManager.is_account?(m.from)
@@ -772,12 +776,13 @@ protected
end
new[name] ||= m.has_label?(:unread)
- name
+ authors << name
end
- authors.compact.uniq.map { |a| [a, new[a]] }
+ authors.to_a.map { |a| [a, new[a]] }
end
+ AUTHOR_LIMIT = 5
def text_for_thread_at line
t, size_widget = @mutex.synchronize { [@threads[line], @size_widgets[line]] }
@@ -787,7 +792,7 @@ protected
## format the from column
cur_width = 0
- ann = author_names_and_newness_for_thread t
+ ann = author_names_and_newness_for_thread t, AUTHOR_LIMIT
from = []
ann.each_with_index do |(name, newness), i|
break if cur_width >= from_width
--
1.6.0.4
------------------------------
Message: 480
Date: Sat, 20 Jun 2009 13:50:15 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH 16/18] fix String#ord monkeypatch
Message-ID: <1245531017-9907-17-git-send-email-rlane@club.cc.cmu.edu>
---
lib/sup/util.rb | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/sup/util.rb b/lib/sup/util.rb
index 8f60cc4..0609908 100644
--- a/lib/sup/util.rb
+++ b/lib/sup/util.rb
@@ -282,7 +282,7 @@ class String
gsub(/\t/, " ").gsub(/\r/, "")
end
- if not defined? ord
+ unless method_defined? :ord
def ord
self[0]
end
--
1.6.0.4
------------------------------
Message: 481
Date: Sat, 20 Jun 2009 13:50:17 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH 18/18] dont using SavingHash#[] for
membership test
Message-ID: <1245531017-9907-19-git-send-email-rlane@club.cc.cmu.edu>
---
lib/sup/thread.rb | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/lib/sup/thread.rb b/lib/sup/thread.rb
index 99f21dc..d395c35 100644
--- a/lib/sup/thread.rb
+++ b/lib/sup/thread.rb
@@ -310,13 +310,15 @@ class ThreadSet
private :prune_thread_of
def remove_id mid
- return unless(c = @messages[mid])
+ return unless @messages.member?(mid)
+ c = @messages[mid]
remove_container c
prune_thread_of c
end
def remove_thread_containing_id mid
- c = @messages[mid] or return
+ return unless @messages.member?(mid)
+ c = @messages[mid]
t = c.root.thread
@threads.delete_if { |key, thread| t == thread }
end
@@ -355,7 +357,7 @@ class ThreadSet
return if threads.size < 2
containers = threads.map do |t|
- c = @messages[t.first.id]
+ c = @messages.member?(c) ? @messages[t.first.id] : nil
raise "not in threadset: #{t.first.id}" unless c && c.message
c
end
--
1.6.0.4
------------------------------
Message: 482
Date: Mon, 22 Jun 2009 10:46:10 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH 18/18] dont using SavingHash#[] for
membership test
Message-ID: <1245681928-sup-3077@Longbow>
Content-Type: text/plain; charset=utf8
Wow, that's one heck of a set of patches... good work dude :)
-AT
--
Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
Make it idiot-proof, and someone will breed a better idiot.
-- Oliver Elphick
------------------------------
Message: 483
Date: Wed, 24 Jun 2009 09:30:39 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH 0/18] Xapian-based index
Message-ID: <1245854803-sup-4481@entry>
Content-Type: text/plain; charset=UTF-8
Hi Rich,
Reformatted excerpts from Rich Lane's message of 2009-06-20:
> This patch series refactors the Index class to remove Ferret-isms and
> support multiple index implementations. The included XapianIndex is a
> bit faster at indexing messages and significantly faster when
> searching because it precomputes thread membership. It also works on
> Ruby 1.9.1.
This is great. Really, really great. You've refactored a crufty
interface that's been growing untamed over the past three years, you've
gotten us away from the unmaintained scariness that is Ferret, you've
fixed the largest source of interface slowness (thread recomputation),
and you've enabled us to move to the beautiful, speedy, encoding-aware
world of Ruby 1.9. Thank you for satisfying all of my Sup-related
desires in one fell swoop. From my lofty throne, I commend thee.
Once the bugs are ironed out, I would like to make this the default
index format and eventually deprecate Ferret.
In the mean time, I've placed your patches on a branch called xapian. If
anyone wants to play with this, here's what you do:
1. install the ruby xapian library and the ruby gdbm library, if you
don't have them. These are packaged by your distro, and are not gems.
2. git fetch
3. git checkout -b xapian origin/xapian
4. cp ~/.sup/sources.yaml /tmp # just in case
5. sup-dump > dumpfile
6. SUP_INDEX=xapian sup-sync --all --all-sources --restore dumpfile
7. SUP_INDEX=xapian bin/sup -o
8. Oooh, fast.
This should not disturb your Ferret index, so you can switch back and
forth between the two. (Message state, of course, is not shared.)
However, adding new messages to one index will prevent it from being
automatically added to the other, so I recommend running in Xapian mode
with -o and not pressing 'P'.
> It's missing a couple of features, notably threading by subject.
FWIW, I've been thinking about deprecating that particular feature for
quite some time.
> I'm sure there are many more bugs left, so I'd appreciate any testing
> or review you all can provide.
sup-sync crashes for me fairly systematically with this error:
./lib/sup/xapian_index.rb:404:in `sortable_serialise': Expected argument 0 of type double, but got Fixnum 51767811298 (TypeError)
in SWIG method 'Xapian::sortable_serialise'
from ./lib/sup/xapian_index.rb:404:in `index_message'
from ./lib/sup/xapian_index.rb:111:in `sync_message'
from /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
from ./lib/sup/xapian_index.rb:324:in `synchronize'
from ./lib/sup/xapian_index.rb:110:in `sync_message'
from ./lib/sup/util.rb:519:in `send'
from ./lib/sup/util.rb:519:in `method_missing'
from ./lib/sup/poll.rb:157:in `add_messages_from'
from ./lib/sup/source.rb:100:in `each'
from ./lib/sup/util.rb:558:in `send'
from ./lib/sup/util.rb:558:in `__pass'
from ./lib/sup/util.rb:545:in `method_missing'
from ./lib/sup/poll.rb:141:in `add_messages_from'
from ./lib/sup/util.rb:519:in `send'
from ./lib/sup/util.rb:519:in `method_missing'
from bin/sup-sync:140
from bin/sup-sync:135:in `each'
from bin/sup-sync:135
I haven't spent any time tracking it down. Other than that, so far so
good.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 484
Date: Wed, 24 Jun 2009 10:33:46 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH 0/18] Xapian-based index
Message-ID: <1245864733-sup-1216@entry>
Content-Type: text/plain; charset="utf-8"
Reformatted excerpts from William Morgan's message of 2009-06-24:
> sup-sync crashes for me fairly systematically with this error:
>
> ./lib/sup/xapian_index.rb:404:in `sortable_serialise': Expected argument 0 of
> type double, but got Fixnum 51767811298 (TypeError)
This turns out to be due to dates being far in the future (e.g. on spam
messages). I'm using the attached patch, which is pretty much a hack, to
force them to be between 1969 and 2038. Better solutions welcome. (I
haven't committed this.)
--
William <wmorgan-sup@masanjin.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-bugfix-dates-need-to-be-truncated-for-xapian-to-ind.patch
Type: application/octet-stream
Size: 2484 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090624/fae22ca3/attachment-0001.obj>
------------------------------
Message: 485
Date: Fri, 26 Jun 2009 02:00:57 +0000 (UTC)
From: Olly Betts <olly@survex.com>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] [PATCH 0/18] Xapian-based index
Message-ID: <loom.20090625T222159-861@post.gmane.org>
Content-Type: text/plain; charset=us-ascii
William Morgan <wmorgan-sup@masanjin.net> writes:
> Reformatted excerpts from William Morgan's message of 2009-06-24:
> > sup-sync crashes for me fairly systematically with this error:
> >
> > ./lib/sup/xapian_index.rb:404:in `sortable_serialise': Expected argument 0 of
> > type double, but got Fixnum 51767811298 (TypeError)
>
> This turns out to be due to dates being far in the future (e.g. on spam
> messages). I'm using the attached patch, which is pretty much a hack, to
> force them to be between 1969 and 2038. Better solutions welcome. (I
> haven't committed this.)
The error you get here is actually a bug in SWIG (http://www.swig.org/). Xapian
uses SWIG to generate the wrappers for Ruby.
The code SWIG currently uses to convert a parameter when a C/C++ function
takes a double doesn't handle a "fixnum" which is larger than MAXINT. I've
just applied a fix to SWIG SVN:
http://swig.svn.sourceforge.net/viewvc/swig?view=rev&revision=11320
I'll make sure this fix makes it into the next Xapian release (which will be
1.0.14).
Cheers,
Olly
------------------------------
Message: 486
Date: Fri, 26 Jun 2009 06:49:40 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH 0/18] Xapian-based index
Message-ID: <1246022094-sup-3336@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Olly Betts's message of 2009-06-25:
> I'll make sure this fix makes it into the next Xapian release (which
> will be 1.0.14).
Awesome, thanks!
Though even with SWIG fixed there will still be some tweaking necessary
in Sup because the logistic function used for generating Xapian docids
still has trouble with extreme dates.
BTW, more kudos to Rich for somehow finding a way to use a logistic
function in an email client.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 487
Date: Fri, 26 Jun 2009 13:10:01 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] before-search hook
Message-ID: <1246035946-sup-7069@javelin>
Content-Type: text/plain; charset=UTF-8
Done.
>From 19f9da29020f1dfa97a4e6d0e4866cec840cfddc Mon Sep 17 00:00:00 2001
From: Edward Z. Yang <edwardzyang@thewritingpot.com>
Date: Wed, 10 Jun 2009 01:42:50 -0400
Subject: [PATCH 1/2] Add custom-search hook, for shortcuts for custom search queries.
Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
---
lib/sup/hook.rb | 5 +++++
lib/sup/index.rb | 14 +++++++++++++-
2 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/lib/sup/hook.rb b/lib/sup/hook.rb
index 0a0a2f6..33a97b2 100644
--- a/lib/sup/hook.rb
+++ b/lib/sup/hook.rb
@@ -19,6 +19,11 @@ class HookManager
attr_writer :__locals
+ ## an annoying gotcha here is that if you try something
+ ## like var = var.foo(), var will magically get allocated
+ ## to Nil and method_missing will never get called. You
+ ## can work around this by calling self.var or simply
+ ## not assigning it to itself.
def method_missing m, *a
case @__locals[m]
when Proc
diff --git a/lib/sup/index.rb b/lib/sup/index.rb
index ca01ee7..9c985d9 100644
--- a/lib/sup/index.rb
+++ b/lib/sup/index.rb
@@ -24,6 +24,16 @@ class Index
include Singleton
+ HookManager.register "custom-search", <<EOS
+Executes before a string search is applied to the index,
+returning a new search string.
+Variables:
+ subs: The string being searched. Be careful about shadowing:
+ this variable is actually a method, so use a temporary variable
+ or explicitly call self.subs; the substitutions in index.rb
+ don't actually work.
+EOS
+
## these two accessors should ONLY be used by single-threaded programs.
## otherwise you will have a naughty ferret on your hands.
attr_reader :index
@@ -507,7 +517,9 @@ protected
def parse_user_query_string s
extraopts = {}
- subs = s.gsub(/\b(to|from):(\S+)\b/) do
+ subs = HookManager.run("custom-search", :subs => s) || s
+
+ subs = subs.gsub(/\b(to|from):(\S+)\b/) do
field, name = $1, $2
if(p = ContactManager.contact_for(name))
[field, p.email]
--
1.6.3.2
------------------------------
Message: 488
Date: Sun, 28 Jun 2009 22:32:02 -0400
From: Nicholas Bergson-Shilcock <me@nicholasbs.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Transitioning to OfflineIMAP
Message-ID: <1246242608-sup-3151@twoface>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Fri Jun 12 20:24:44 -0400 2009:
> Reformatted excerpts from Nicholas Bergson-Shilcock's message of 2009-06-12:
> > Before I go any further, I wanted to know if sup supported any sort of
> > "graceful" account transitioning -- I'd ideally like to switch to my
> > new maildir source without losing the index information I have for my
> > IMAP source. The obvious way of switching over (removing my old source
> > and adding the new one) would mean essentially starting over. Is this
> > what I have to do or is there another way for me to switch?
>
> I wouldn't call it graceful, exactly, but you should be able to preserve
> state by running sup-dump on the original source, drop the index (move
> your ~/.sup/ferret directory somewhere else), edit your source.yaml
> file, and use sup-sync --restored --restore <dumpfile> to scan over the
> new source and restore the state for each message.
>
> It will take a while. Try it on a subset of messages first if possible
> to make sure it's working. Post any questions and I'll try and help you.
I just finally got around to trying this and it worked perfectly on the
first try. Thank you, thank you, thank you! My mail is now about an
order of magnitude faster.
Keep up the awesome work,
-Nick
------------------------------
Message: 489
Date: Wed, 1 Jul 2009 17:20:10 +1200
From: Jim Cheetham <jim@gonzul.net>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Character encoding when displaying
quoted-printable messages
Message-ID:
<f4cc59760906302220v1595b4a8xf600a96747d2c408@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Thu, Jun 18, 2009 at 9:39 AM, Jim Cheetham<jim@gonzul.net> wrote:
> However, I'm coming across some character decoding issues with
> quoted-printable that are making some messages hard to read. Any
> advice on how to improve things would be welcome ... In the example
> below, a NBSP entity is showing up as the characters "M-BM-"
Nicely fixed by using the hack ncursesw branch, by the way.
http://sup.rubyforge.org/wiki/wiki.pl?UTF8
-jim
------------------------------
Message: 490
Date: Wed, 01 Jul 2009 10:38:36 +0200
From: Ingmar Vanhassel <ingmar@exherbo.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] ncurses-ruby-1.2.3 + ncursesw hack breaks search
Message-ID: <1246437271-sup-7636@cannonball>
Content-Type: text/plain; charset=UTF-8
Excerpts from Jim Cheetham's message of Wed Jul 01 07:20:10 +0200 2009:
> Nicely fixed by using the hack ncursesw branch, by the way.
> http://sup.rubyforge.org/wiki/wiki.pl?UTF8
Has anyone noticed that newer versions of ncurses-ruby plus that
ncursesw hack [1] (to link to ncurses with widechar support) breaks search?
When I search for 'foo', sup launches a search for a bunch of weird
characters, not for 'foo', which obviously returns nothing useful.
I can trigger this with ncurses-ruby 1.2.2, 1.2.3. Version 1.1 seems to
be unaffected.
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477366#52
--
Exherbo KDE, X.org maintainer
------------------------------
Message: 491
Date: Wed, 01 Jul 2009 11:20:05 +0200
From: Helge Titlestad <helgedt@tihlde.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Sup crash when adding CC to forwarded message
Message-ID: <1246439829-sup-6907@colargol.tihlde.org>
Content-Type: text/plain; charset=UTF-8
Hi,
sup 0.8 just crashed on me. What I did was:
* From thread-view, hit "f" to forward.
* Enter address to forward to.
* Just hit "enter" when asked for CC.
* Save message (unedited).
* Hit "c" to edit CC
-> crash
This is reproducible (only tried on one message, though.)
bt:
--- NoMethodError from thread: main
undefined method `join' for "":String
/home/xhs/helgedt/gems/gems/sup-0.8/lib/sup/modes/edit-message-mode.rb:414:in `edit_field'
/home/xhs/helgedt/gems/gems/sup-0.8/lib/sup/modes/edit-message-mode.rb:119:in `edit_cc'
/home/xhs/helgedt/gems/gems/sup-0.8/lib/sup/mode.rb:50:in `send'
/home/xhs/helgedt/gems/gems/sup-0.8/lib/sup/mode.rb:50:in `handle_input'
/home/xhs/helgedt/gems/gems/sup-0.8/lib/sup/buffer.rb:249:in `handle_input'
/home/xhs/helgedt/gems/gems/sup-0.8/bin/sup:238
/home/xhs/helgedt/gems/bin/sup:19:in `load'
/home/xhs/helgedt/gems/bin/sup:19
--
alge
------------------------------
Message: 492
Date: Wed, 1 Jul 2009 21:48:30 +1200
From: Jim Cheetham <jim@gonzul.net>
To: sup-talk@rubyforge.org
Subject: [sup-talk] sent_source - singular or per-account?
Message-ID:
<f4cc59760907010248r5598eb50sf29b3ae8f500e5f8@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
It looks like there is only one place that outbound mail can be stored
-- sent_source in config.yaml specifies it globally.
I'd like to be able to save outgoing email into the mailstore for the
matching account; can anyone suggest some way to do this? Hacking code
is an option, although I'd appreciate some pointers ...
------------------------------
Message: 493
Date: Wed, 01 Jul 2009 08:28:46 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] ncurses-ruby-1.2.3 + ncursesw hack breaks
search
Message-ID: <1246461233-sup-208@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ingmar Vanhassel's message of 2009-07-01:
> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477366#52
Interesting thread. I disagree with the conclusion that a separate
libncursesw-ruby package should be created. Maybe I'll respond.
The analysis of Sup is wrong. He says: "Looking at the source code of
the mailer I'd say that it is not really suited for UTF-8 encoded
strings yet, as it still assumes that the length of a string in bytes is
equal to the number of characters in the string." This is not really
true. What Sup assumes is that String#length gives the length of the
string in characters. This is obviously false in Ruby 1.8 (without
monkeypatching), but it is true in Ruby 1.9.
What *does* need to happen for Sup to really, actually, correctly
display non-ASCII characters, besides having a ncurses library that's
linked against ncursesw, is to be able to call the 'wcwidth' and
'wcswidth' functions. The current #display_length function is a hack
that's broken for e.g. Chinese characters.
One way to do this would be to use dl/import like we do for setlocale().
I've played around with this but haven't really gotten it to work. If
someone can get any further than the below, please let me know:
require 'dl/import'
module LibC
extend DL.const_defined?(:Importer) ? DL::Importer : DL::Importable
dlload "libc.so.6"
extern "void setlocale(int, const char *)"
extern "int wcwidth(int)"
extern "int wcswidth(const int*, int)"
end
That "works", as in doesn't throw any exceptions, but then calling
LibC.wcswidth doesn't return the right thing, presumably because the
Ruby string isn't being converted into an array of ints, or something. I
don't really know how this works.
> Has anyone noticed that newer versions of ncurses-ruby plus that
> ncursesw hack [1] (to link to ncurses with widechar support) breaks
> search?
I don't have these newer versions available on my system yet (Ubuntu).
> When I search for 'foo', sup launches a search for a bunch of weird
> characters, not for 'foo', which obviously returns nothing useful.
Disturbing.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 494
Date: Wed, 01 Jul 2009 17:42:04 +0200
From: "Jörg-Hendrik Bach" <bachjh@googlemail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] ncurses-ruby-1.2.3 + ncursesw hack breaks
search
Message-ID: <1246462442-sup-1884@BlackMesa>
Content-Type: text/plain; charset=UTF-8
Ingmar Vanhassel, Wed Jul 01 10:38:36 +0200 2009:
> Has anyone noticed that newer versions of ncurses-ruby plus that
> ncursesw hack [1] (to link to ncurses with widechar support) breaks search?
I can confirm the behaviour.
> When I search for 'foo', sup launches a search for a bunch of weird
> characters, not for 'foo', which obviously returns nothing useful.
True. However, with the following workaround, you can get proper search results:
- search for foo -> garbled search, no proper results
- hit 'x' to destroy the result buffer
- hit '\' to search again.
- hit uparrow to go to previous search. backspace all the garbled characters there.
- repeat the uparrow + remove until it shows your last working search (or until there's no more previous search to go to)
- type foo again, hit enter: works.
Not that this is the type of thing you'd want to do for a simple search. Guess we'll have to wait for ruby 1.9?
cheers,
- J?rg-Hendrik
>
> I can trigger this with ncurses-ruby 1.2.2, 1.2.3. Version 1.1 seems to
> be unaffected.
>
> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477366#52
------------------------------
Message: 495
Date: Wed, 01 Jul 2009 17:29:22 +0200
From: Ingmar Vanhassel <ingmar@exherbo.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Sup on Ruby-1.9
Message-ID: <1246461780-sup-5146@cannonball>
Content-Type: text/plain; charset=UTF-8
Has anyone been keeping a TODO list for running sup on ruby-1.9?
I haven't had the time to try it myself, but I'd like to have a rough
idea of what I'm looking at.
--
Exherbo KDE, X.org maintainer
------------------------------
Message: 496
Date: Wed, 01 Jul 2009 11:11:37 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup on Ruby-1.9
Message-ID: <1246471261-sup-3755@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ingmar Vanhassel's message of 2009-07-01:
> Has anyone been keeping a TODO list for running sup on ruby-1.9?
The major blocker for a while was the Ferret gem. With the advent of the
Xapian branch, I have been toying around with getting Sup + Xapian to
work on 1.9.1. So far all the gem dependencies seem to compile except
ncurses, which needs some minor code tweaks.
The latest Xapian has Ruby 1.9.1-compatible bindings, but unfortunately
the API seems to have shifted since Rich's patches. I get:
lib/sup/xapian_index.rb:24:in `initialize': Wrong arguments for overloaded method 'WritableDatabase.new'. (ArgumentError)
Possible C/C++ prototypes are:
WritableDatabase.new()
WritableDatabase.new(std::string const &path, int action)
WritableDatabase.new(Xapian::WritableDatabase const &other)
from lib/sup/xapian_index.rb:24:in `new'
from lib/sup/xapian_index.rb:24:in `initialize'
from bin/sup:132:in `new'
from bin/sup:132:in `<module:Redwood>'
from bin/sup:62:in `<main>'
Moving to 1.9 is highly desirable. It would be a major win for non-ASCII
display issues and for speed in general. I would also like to try moving
some of the display code from threads to fibers, since there are still
weird threading bugs in there that occasionally crop up, and I think it
would simplify the implementation.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 497
Date: Wed, 01 Jul 2009 11:19:27 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup crash when adding CC to forwarded message
Message-ID: <1246472248-sup-591@entry>
Content-Type: text/plain; charset=UTF-8
Hi Helge,
Reformatted excerpts from Helge Titlestad's message of 2009-07-01:
> sup 0.8 just crashed on me. What I did was:
> * From thread-view, hit "f" to forward.
> * Enter address to forward to.
> * Just hit "enter" when asked for CC.
> * Save message (unedited).
> * Hit "c" to edit CC
> -> crash
>
> This is reproducible (only tried on one message, though.)
I can't reproduce this. Does it happen on all messages, or just on that
one? Does it happen if you specify someting for the cc: header?
Thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 498
Date: Wed, 01 Jul 2009 11:23:09 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Delete single message in thread-view?
Message-ID: <1246472570-sup-6752@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Christopher Bertels's message of 2009-06-19:
> Is it possible to delete a single message from a thread? I haven't
> found a way to do this, but maybe I'm just blind.
Not currently. Sorry! It's all or nothing for now.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 499
Date: Wed, 01 Jul 2009 20:54:20 +0200
From: Helge Titlestad <helgedt@tihlde.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup crash when adding CC to forwarded message
Message-ID: <1246474215-sup-7272@colargol.tihlde.org>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Wed Jul 01 20:19:27 +0200 2009:
>> [Adding CC crash procedure]
>
> I can't reproduce this. Does it happen on all messages, or just on that
> one? Does it happen if you specify someting for the cc: header?
It's stopped being reproducible now. \:
For the record, there was one "?" in the subject field. Probably shouldn't
be related, but you never know with these utf-8 woes. (:
--
alge
------------------------------
Message: 500
Date: Wed, 01 Jul 2009 11:57:55 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup crash when adding CC to forwarded message
Message-ID: <1246474654-sup-137@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Helge Titlestad's message of 2009-07-01:
> For the record, there was one "?" in the subject field. Probably
> shouldn't be related, but you never know with these utf-8 woes. (:
I'd be surprised... but yeah, who knows!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 501
Date: Wed, 01 Jul 2009 12:15:45 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup on Ruby-1.9
Message-ID: <1246475697-sup-7574@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from William Morgan's message of 2009-07-01:
> The latest Xapian has Ruby 1.9.1-compatible bindings, but unfortunately
> the API seems to have shifted since Rich's patches.
Hm, AFAIK that isn't an API change. Maybe I compiled my Xapian bindings
wrong somehow. Or something.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 502
Date: Wed, 01 Jul 2009 15:39:57 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sent_source - singular or per-account?
Message-ID: <1246476925-sup-5046@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Jim Cheetham's message of Wed Jul 01 05:48:30 -0400 2009:
> I'd like to be able to save outgoing email into the mailstore for the
> matching account; can anyone suggest some way to do this? Hacking code
> is an option, although I'd appreciate some pointers ...
This is an interesting idea. I think the best way to do it might be
to implement a sent_source hook that can override the global default.
It would be wise to either a) not use mbox or b) have dedicated mboxes
for this purpose...until I finally get around to finishing the lock
manager to make shared access safe.
The other gotcha with a hook to pick the source for message storage is
that not all sources are capable of storing mail presently (mbox,
maildir and imap are the only supported types, which admittedly should
cover most people).
I think this would be quite simple to add.
I've also toyed around with the idea of 'patterned' sources so that
you could specify a source as maildir:///u/bwalton/Maildir/inbox-%Y%m
and have new sources picked up automatically as they're created
(possibly by procmail doing autofiling, or something).
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090701/64c4a100/attachment-0001.bin>
------------------------------
Message: 503
Date: Wed, 01 Jul 2009 22:07:22 +0200
From: Andrea Fazzi <andrea.fazzi@alcacoop.it>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Reconnect command
Message-ID: <1246478645-sup-1505@ganimoide>
Content-Type: text/plain; charset=UTF-8
Hi all,
finally I found the mail client I was searching for :) So, thanks for this
great software.
Sometime, it happens that I lost my internet connection (e.g. after a
suspend/resume). Occasionally I noticed that, after the connection is
restored, sup can't polling for new messages anymore. At the moment, I
"fix" the issue restarting sup. In fact, it seems that doing a new login to
the imap server solves the problem and I can fetch the new messages. I know
I should investigate deeper and I'll do. But now I wonder if a "reconnect"
command can be an useful feature. Thoughts?
Cheers,
Andrea
--
Andrea Fazzi @ Alca Societ? Cooperativa
Follow me on http://twitter.com/remogatto
------------------------------
Message: 504
Date: Thu, 2 Jul 2009 14:30:25 +1200
From: Jim Cheetham <jim@gonzul.net>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] sent_source - singular or per-account?
Message-ID:
<f4cc59760907011930x4678e623j33a777ef03b7da55@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Thu, Jul 2, 2009 at 7:39 AM, Ben Walton<bwalton@artsci.utoronto.ca> wrote:
> Excerpts from Jim Cheetham's message of Wed Jul 01 05:48:30 -0400 2009:
>> I'd like to be able to save outgoing email into the mailstore for the
>> matching account; can anyone suggest some way to do this? Hacking code
>> is an option, although I'd appreciate some pointers ...
>
> This is an interesting idea. ?I think the best way to do it might be
> to implement a sent_source hook that can override the global default.
'best' or 'simplest'?
There already exists logic for determining which account a given
outgoing message belongs to, because that's how the :sendmail: target
is being used.
If you are arguing that having a different sent_source per (outgoing)
message is useful, then perhaps a hook makes sense; but the simpler
case probably doesn't need it.
> It would be wise to either a) not use mbox or b) have dedicated mboxes
> for this purpose...until I finally get around to finishing the lock
> manager to make shared access safe.
Certainly the sent_source mbox shouldn't be subject to something
inconvenient like delivery of new mail while we're updating it :-) but
I'm not sure that mbox people would be unhappy having sent mail in a
separate file ... ?
-jim
------------------------------
Message: 505
Date: Wed, 01 Jul 2009 23:17:57 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sent_source - singular or per-account?
Message-ID: <1246502666-sup-1295@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Jim Cheetham's message of Wed Jul 01 22:30:25 -0400 2009:
> On Thu, Jul 2, 2009 at 7:39 AM, Ben Walton<bwalton@artsci.utoronto.ca> wrote:
> > Excerpts from Jim Cheetham's message of Wed Jul 01 05:48:30 -0400 2009:
> >> I'd like to be able to save outgoing email into the mailstore for the
> >> matching account; can anyone suggest some way to do this? Hacking code
> >> is an option, although I'd appreciate some pointers ...
> >
> > This is an interesting idea. ?I think the best way to do it might be
> > to implement a sent_source hook that can override the global default.
>
> 'best' or 'simplest'?
Both?
> There already exists logic for determining which account a given
> outgoing message belongs to, because that's how the :sendmail:
> target is being used.
>
> If you are arguing that having a different sent_source per (outgoing)
> message is useful, then perhaps a hook makes sense; but the simpler
> case probably doesn't need it.
I'm not arguing anything, and perhaps using sent_source as the
(hypothetical) hook name was a bad choice...
If I'm understanding you correctly, you want to write to a different
source depending on which address is used in the From. You'd either
need to make a separate config entry in each account that gets setup
(similar to the sendmail that you note) or provide the ability for the
user to select the sent box in some other way.
In the 'simpler' case where the decision is made based on account
used, you've got a chunk of static code making the choice and
defaulting as it would now. The hook would simply take the place of
the static decision maker. The decision has to be made per message
regardless of how it's implemented, so doing it in a hook is a better
option, imo. The Hook route would be slightly slower, since there are
extra activation records on the stack for the function calls, but it
should be negligible.
The other advantage to a Hook is that the decision could be made based
on more than simply the From:. Maybe other users would prefer to
store mail based on who it was sent To...or a combo of From/To?
I'm interested in William's thoughts on this. It's not a feature I'd
use, but I do think it's a good feature to have.
I hope this explains my thinking more clearly.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090701/eb941c06/attachment-0001.bin>
------------------------------
Message: 506
Date: Thu, 2 Jul 2009 22:14:23 +1200
From: Jim Cheetham <jim@gonzul.net>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] sent_source - singular or per-account?
Message-ID:
<f4cc59760907020314o60100e01r1a1f8af4d354030a@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Thu, Jul 2, 2009 at 3:17 PM, Ben Walton<bwalton@artsci.utoronto.ca> wrote:
> Excerpts from Jim Cheetham's message of Wed Jul 01 22:30:25 -0400 2009:
> If I'm understanding you correctly, you want to write to a different
> source depending on which address is used in the From.
Almost; what I (could have) said was that I wanted to write to a
different source depending on which account is in use for the current
message; I wasn't fixating on the From address itself, although with a
better understanding of the code you might declare that they are
effectively the same anyway :-)
> ?You'd either
> need to make a separate config entry in each account that gets setup
> (similar to the sendmail that you note) or provide the ability for the
> user to select the sent box in some other way.
Yes; and in either case I think we can't just override the current
global sent_source, because this is being used to read messages from,
in order to include them in the threads.
> In the 'simpler' case where the decision is made based on account
> used, you've got a chunk of static code making the choice and
> defaulting as it would now. ?The hook would simply take the place of
> the static decision maker. ?The decision has to be made per message
> regardless of how it's implemented, so doing it in a hook is a better
> option, imo. ?The Hook route would be slightly slower, since there are
> extra activation records on the stack for the function calls, but it
> should be negligible.
Mmm, I think the hook route would expose you to a lot of change,
because whenever a 'new' source (i.e. one not known about as load
time) is declared in the hook, you'll have to remember it so it can be
included in the index, and be available next time sup starts too.
Whereas requiring sent_sources to be declared at load time only means
they can be added as sources just like the current singular one is.
I've been browsing the source this evening, I don't have a very good
grasp of Ruby idiom but I do find it to be very readable in general
:-) However, I've come to a halt in SentManager.write_sent_message,
because I haven't figured out how @source.store_message relates to my
store URI, and therefore the relevant store_message function. I mean,
if :sent_store: is configured, how does @source get created from
@source_uri?
If we have multiple sent_sources, that contradicts the singleton
SentManager, unless @source becomes a hash keyed off from_email ... at
which point I'm pushing my Ruby skills too far for the evening.
Any comments or specific code pointers welcomed! I'd be happy to
attempt a patch for this, but I may need a little help ...
-jim
------------------------------
Message: 507
Date: Thu, 02 Jul 2009 10:02:56 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sent_source - singular or per-account?
Message-ID: <1246542975-sup-7239@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Jim Cheetham's message of Thu Jul 02 06:14:23 -0400 2009:
> Almost; what I (could have) said was that I wanted to write to a
> different source depending on which account is in use for the
> current message; I wasn't fixating on the From address itself,
> although with a better understanding of the code you might declare
> that they are effectively the same anyway :-)
Ok. I _think_ that difference would come out in the wash, unless I'm
overlooking a subtlety. Thanks for clarifying your needs/wants
though.
> > ?You'd either need to make a separate config entry in each account
> > that gets setup (similar to the sendmail that you note) or provide
> > the ability for the user to select the sent box in some other way.
>
> Yes; and in either case I think we can't just override the current
> global sent_source, because this is being used to read messages from,
> in order to include them in the threads.
As long as sup is configured with all sources that might be returned
from the hook, including the default source, it should be ok. It'll
still poll all sources and thread messages appropriately.
> Mmm, I think the hook route would expose you to a lot of change,
> because whenever a 'new' source (i.e. one not known about as load
> time) is declared in the hook, you'll have to remember it so it can be
> included in the index, and be available next time sup starts too.
My take on this is that the hook would be constrained to return only
existing sources. On the other hand, aside from an initial import of
any existing mail in a new folder, I'm not sure that adding new
sources on the fly would be that bad.
> Whereas requiring sent_sources to be declared at load time only means
> they can be added as sources just like the current singular one is.
I was picturing the hook return value to be a uri suitable for passing
to Index.source_for. If that method call failed, the default would be
used. There are of course other (maybe better) ways to do this, but
that's what I was thinking last night. Using this technique, you're
limited to existing sources and you also have an easy way to back out
of a 'hook gone wild.'
> I've been browsing the source this evening, I don't have a very good
> grasp of Ruby idiom but I do find it to be very readable in general
> :-) However, I've come to a halt in SentManager.write_sent_message,
It is a beautiful, expressive language! :)
> because I haven't figured out how @source.store_message relates to my
> store URI, and therefore the relevant store_message function. I mean,
> if :sent_store: is configured, how does @source get created from
> @source_uri?
At startup, SentManager is initialized with a URI. This is either the
value of :sent_source: from config.yaml or the default (special) value
sup://sent. A little later on, after the Index has been initialized,
it is asked for the source that corresponds to the URI value passed to
SentManager. If this source is found in the Index, it is assigned to
the @source value. Otherwise, the SentManager.default_source method
is triggered.
So, when one of the message modes calls write_sent_message, it has
either a specific source or the default ready to go. Sources usable
by SentManager are constrained such that they must respond to
store_message. This excludes ssh+mbox URI's from being a valid sent
mail source.
> If we have multiple sent_sources, that contradicts the singleton
> SentManager, unless @source becomes a hash keyed off from_email ... at
> which point I'm pushing my Ruby skills too far for the evening.
I don't think it precludes it from being a singleton, but it would
require some heavy reworking of the initialization logic for it.
I just popped into sent.rb and was all set to knock out a patch to add
the hook and I discovered that my memory of this wasn't what I
thought. SentManager doesn't ever _see_ the message. It simply
facilitates calling the store_message method of whatever source is
configured and that source object in turn provides an object that acts
like an IO object to the edit-message-mode call site. This
complicates either approach discussed here since the determination of
which source to use can't be constrained to SentManager...presently,
it would end up in edit-message-mode, which wouldn't be the right spot
for the logic, I don't think.
More thinking required, I believe.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090702/9f959f68/attachment-0001.bin>
------------------------------
Message: 508
Date: Thu, 02 Jul 2009 13:16:17 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk@rubyforge.org
Subject: [sup-talk] Sup doesn't respect Reply-To header
Message-ID: <1246554940-sup-138@javelin>
Content-Type: text/plain; charset=UTF-8
It doesn't look like Sup respects Reply-To headers. Is this
intentional? It breaks some mailing list agents.
Cheers,
Edward
------------------------------
Message: 509
Date: Fri, 3 Jul 2009 18:05:23 +0200
From: J?rg-Hendrik Bach <bachjh@googlemail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] colour customisation
Message-ID:
<91de50e10907030905l6673a7c3n380f6daeccfb14ab@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hello list,
is there any documentation on which parts of the display can be changed via the
.sup/colors.yaml? From the wiki entry[1] it is possible to figure out some of
the variables, but I haven't got all.
cheers,
- J?rg-Hendrik
[1] http://sup.rubyforge.org/wiki/wiki.pl?CustomizingColors
------------------------------
Message: 510
Date: Fri, 03 Jul 2009 13:13:29 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] colour customisation
Message-ID: <1246641077-sup-9945@Longbow>
Content-Type: text/plain; charset=utf8
Excerpts from J?rg-Hendrik Bach's message of Fri Jul 03 12:05:23 -0400 2009:
> Hello list,
>
> is there any documentation on which parts of the display can be changed via the
> .sup/colors.yaml? From the wiki entry[1] it is possible to figure out some of
> the variables, but I haven't got all.
I don't really know, but from browsing the source briefly, I've
found (formatted as quote):
> DEFAULT_COLORS = {
> :status => { :fg => "white", :bg => "blue", :attrs => ["bold"] },
> :index_old => { :fg => "white", :bg => "default" },
> :index_new => { :fg => "white", :bg => "default", :attrs => ["bold"] },
> :index_starred => { :fg => "yellow", :bg => "default", :attrs => ["bold"] },
> :index_draft => { :fg => "red", :bg => "default", :attrs => ["bold"] },
> :labellist_old => { :fg => "white", :bg => "default" },
> :labellist_new => { :fg => "white", :bg => "default", :attrs => ["bold"] },
> :twiddle => { :fg => "blue", :bg => "default" },
> :label => { :fg => "yellow", :bg => "default" },
> :message_patina => { :fg => "black", :bg => "green" },
> :alternate_patina => { :fg => "black", :bg => "blue" },
> :missing_message => { :fg => "black", :bg => "red" },
> :attachment => { :fg => "cyan", :bg => "default" },
> :cryptosig_valid => { :fg => "yellow", :bg => "default", :attrs => ["bold"] },
> :cryptosig_unknown => { :fg => "cyan", :bg => "default" },
> :cryptosig_invalid => { :fg => "yellow", :bg => "red", :attrs => ["bold"] },
> :generic_notice_patina => { :fg => "cyan", :bg => "default" },
> :quote_patina => { :fg => "yellow", :bg => "default" },
> :sig_patina => { :fg => "yellow", :bg => "default" },
> :quote => { :fg => "yellow", :bg => "default" },
> :sig => { :fg => "yellow", :bg => "default" },
> :to_me => { :fg => "green", :bg => "default" },
> :starred => { :fg => "yellow", :bg => "default", :attrs => ["bold"] },
> :starred_patina => { :fg => "yellow", :bg => "green", :attrs => ["bold"] },
> :alternate_starred_patina => { :fg => "yellow", :bg => "blue", :attrs => ["bold"] },
> :snippet => { :fg => "cyan", :bg => "default" },
> :option => { :fg => "white", :bg => "default" },
> :tagged => { :fg => "yellow", :bg => "default", :attrs => ["bold"] },
> :draft_notification => { :fg => "red", :bg => "default", :attrs => ["bold"] },
> :completion_character => { :fg => "white", :bg => "default", :attrs => ["bold"] },
> :horizontal_selector_selected => { :fg => "yellow", :bg => "default", :attrs => ["bold"] },
> :horizontal_selector_unselected => { :fg => "cyan", :bg => "default" },
> :search_highlight => { :fg => "black", :bg => "yellow", :attrs => ["bold"] },
> :system_buf => { :fg => "blue", :bg => "default" },
> :regular_buf => { :fg => "white", :bg => "default" },
> :modified_buffer => { :fg => "yellow", :bg => "default", :attrs => ["bold"] },
> }
You can probably extrapolate how to do colouring based on this? If you
have the energy, please update the wiki to maybe mention this list, etc.
Last I saw, the page was fairly out of date.
Hope this helps,
--
Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
------------------------------
Message: 511
Date: Fri, 03 Jul 2009 11:37:46 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: Marc Weber <marco-oweber@gmx.de>
Cc: sup-talk mailing list <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup
Message-ID: <1246645330-sup-1433@entry>
Content-Type: text/plain; charset=UTF-8
[cc'ing sup-talk]
Hi Marc,
Reformatted excerpts from Marc Weber's message of 2009-07-03:
> I finally managed to package sup on nix. (nixos.org) and I'm ready to
> give sup a try.
Great!
> a) if ferret does save the whole messages you don't really need the
> original sources (maildir, mbox files), right?
That's basically correct, but:
a) Ferret doesn't store the entire message as represented in the
mailstore (e.g. it only keeps a subset of the headers).
b) Ferret has had corruption problems in the past, which I believe have
now been fixed, but I wouldn't bet my mailstore on it.
c) It's easy to turn that feature off, i.e., Ferret can index email for
search without directly storing the email. The only reason I have
Ferret store the email is because it makes changing the message
labels quicker. If the Ferret index is too large, you can disable
this feature at the expense of some speed.
> b) [redacted] on irc told me that ferret has been abandoned in favour of
> Xapian ? So are there any plans in replacing Ferret by Xapian as well?
It hasn't happened quite yet (the Xapian backend is very recent and
experimental), but that's the goal. I'm currently thinking about having
the next release of Sup use Xapian as the default index, but still
support Ferret, and the release after that not support Ferret at all.
But we shall see. I'm also working on a sup server, which will act as
yet another index type.
> c) I've got about 280MB of mails from the haskelcafe mailinglist or
> such. I missed telling sup to mark those old mails as read as well
> as adding a "haskell-cafe" tag. It's not a big problem because all
> mails contain [haskell-cafe] in the subject. However finding all
> threads (using !!) takes ages (more than 20min or so?) so I didn't
> wait until it finished. Opening the same maildir in mutt takes less
> than a minute.
The Xapian backend will speed this up dramatically, because the thread
structures are cached, and that's what's expensive in this case. But the
best solution is to use sup-tweak-labels, which is an offline tool built
for exactly this purpose.
> I've seen that ferret does save mails but displays threads.
> Would it make sense to index the threads instead of mails?
> Then displaying them and querying them could be even faster?
See above.
Welcome to Sup!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 512
Date: Fri, 03 Jul 2009 11:54:46 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] colour customisation
Message-ID: <1246646592-sup-3461@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Andrei Thorp's message of 2009-07-03:
> I don't really know, but from browsing the source briefly, I've
> found (formatted as quote):
This is correct. That is the list of parts of the display that can be
changed, and their default colors. The possible colors for both
foreground and background are the curses palette: black, red, green,
yellow, blue, magenta, cyan, white, and "default". The possible
attributes are the curses attributes: normal, standout, underline,
reverse, blink, dim, bold, protect, invis. (I have no idea what many
of those actually do.)
Any of those settings can be overwritten by making a ~/.sup/colors.yaml
file, which should be a YAML hash of the exact same format as
DEFAULT_COLORS.
A good way to get started it to do this:
ruby -rubygems -rsup -e 'print Redwood::Colormap::DEFAULT_COLORS.to_yaml' > ~/.sup/colors.yaml
and then edit the result.
A gold star to whoever updates the wiki.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 513
Date: Sat, 04 Jul 2009 14:01:25 +0200
From: J?rg-Hendrik Bach <j.bach@uni-oldenburg.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] colour customisation
Message-ID: <1246708626-sup-8076@lambda>
Content-Type: text/plain; charset=UTF-8
I started updating the wiki page on customized colours,
http://sup.rubyforge.org/wiki/wiki.pl?CustomizingColors
I added explanations for the obvious entries, and a few that I found by
trial and error. However, a large part of the description is still
missing, I didn't have enough time to find all the colours; but at least
it's a start.
------------------------------
Message: 514
Date: Mon, 06 Jul 2009 09:47:42 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] colour customisation
Message-ID: <1246887804-sup-6728@Longbow>
Content-Type: text/plain; charset=utf8
Excerpts from J?rg-Hendrik Bach's message of Sat Jul 04 08:01:25 -0400 2009:
> I started updating the wiki page on customized colours,
> http://sup.rubyforge.org/wiki/wiki.pl?CustomizingColors
>
> I added explanations for the obvious entries, and a few that I found by
> trial and error. However, a large part of the description is still
> missing, I didn't have enough time to find all the colours; but at least
> it's a start.
Daaamn. Fine work you've done there. I'm really impressed with the
graphics :)
Just from reading over the names of the list and not consulting the
source:
- index_draft is obviously what colour drafts in the inbox are
- cryptosig variables probably have to do with what colours the stuff
for signed messages are.
- search_highlight is probably the colour for when you search in a
buffer and some stuff is highlighted (yellow)
Anyway, thanks for all your work.
--
Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
------------------------------
Message: 515
Date: Tue, 07 Jul 2009 01:20:51 -0700
From: Jonathan Lassoff <jof@thejof.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] sup 0.8.1 crash
Message-ID: <1246954373-sup-4550@sfo.thejof.com>
Content-Type: text/plain; charset=UTF-8
Yikes! I found a way to crash my sup!
I'm running sup 0.8.1 (sourced from whatever's current on rubygems.org, not a git branch), and can get sup to crash on specific searches.
I took a little time to poke around in the sup source to try and get an idea what was going on. I'm led to believe this is because I added a source in the past that I later deleted -- but all of the mesages are still in the index. So, when certain searches turn up results that are in that deleted source, the sup index fails to reference the message source in Redwood::Index. Is there a way to delete a source without having to re-index everything?
So, I figured I might find a way to search the index for any documents whose source id is the same as the deleted one and remove them from the index, but am having a hard time finding a way to iterate over all documents in the index (no search query). Is there a simple way to iterate over all messages?
Here's some example crash output:
--- RuntimeError from thread: load threads for thread-index-mode
invalid source 1
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/index.rb:403:in `build_message'
/usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/index.rb:399:in `build_message'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/index.rb:297:in `each_id_by_date'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/thread.rb:330:in `call'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/thread.rb:330:in `load_n_threads'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/index.rb:297:in `each_id_by_date'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/index.rb:296:in `each'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/index.rb:296:in `each_id_by_date'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/thread.rb:326:in `load_n_threads'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:620:in `__unprotected_load_n_threads'
(eval):12:in `load_n_threads'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:604:in `load_n_threads_background'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:71:in `reporting_thread'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:69:in `initialize'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:69:in `new'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:69:in `reporting_thread'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:603:in `load_n_threads_background'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:673:in `__unprotected_load_threads'
(eval):12:in `load_threads'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/modes/search-results-mode.rb:34:in `spawn_from_query'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/bin/sup:270
/usr/bin/sup:19:in `load'
/usr/bin/sup:19
Thanks,
jonathan
------------------------------
Message: 516
Date: Tue, 7 Jul 2009 15:08:44 +0200
From: Marc Weber <marco-oweber@gmx.de>
To: sup-talk@rubyforge.org
Subject: [sup-talk] Backups ?
Message-ID: <20090707130844.GA23073@gmx.de>
Content-Type: text/plain; charset=utf-8
Hi, I'd like to setup an automatic backup system cause I don't want to
tag my mails twice and I don't want to loose the information about
archived mails etc.
What do you think about something like this?
Is it enough to keep 4 dumps?
What about moving this code into sup shutdown?
I think everyone wants to have this feature?
run_sup(){
# untested draft
local dump_dir="/var"
sup
sup-dump | bzip2 > "$dump_dir/sup-dumps-`date`"
ls -1t "$dump_dir"/sup-dumps-* | { read; read; read; read; cat } | xargs rm
}
Marc Weber
------------------------------
Message: 517
Date: Tue, 07 Jul 2009 11:26:35 -0400
From: wagnerdm@seas.upenn.edu
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Backups ?
Message-ID: <20090707112635.14736pk1mxi8r9k4@webmail.seas.upenn.edu>
Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes";
format="flowed"
Quoting Marc Weber <marco-oweber@gmx.de>:
> ls -1t "$dump_dir"/sup-dumps-* | { read; read; read; read; cat } | xargs rm
"{ read; read; read; read; cat }" could probably better be done as
"tail +5"; makes it easier to adjust to people's choice of backup
count, too. ;-)
- Daniel "Bikeshedder" Wagner
------------------------------
Message: 518
Date: Tue, 07 Jul 2009 12:10:42 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Backups ?
Message-ID: <1246982848-sup-5820@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from wagnerdm's message of Tue Jul 07 11:26:35 -0400 2009:
> > ls -1t "$dump_dir"/sup-dumps-* | { read; read; read; read; cat } | xargs rm
>
> "{ read; read; read; read; cat }" could probably better be done as
> "tail +5"; makes it easier to adjust to people's choice of backup
Or:
DAYS=5
find $dump_dir -mtime +${DAYS} -name "*sup-dumps-*" -print0 | xargs -0 --no-run-if-empty rm
(adjust xargs options to suit your environment...I don't think
--no-run-if-empty is all that portable.)
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090707/e4d9cdb7/attachment-0001.bin>
------------------------------
Message: 519
Date: Tue, 07 Jul 2009 18:19:14 +0200
From: Ingmar Vanhassel <ingmar@exherbo.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Backups ?
Message-ID: <1246983494-sup-6924@cannonball>
Content-Type: text/plain; charset=UTF-8
Excerpts from wagnerdm's message of Tue Jul 07 17:26:35 +0200 2009:
> Quoting Marc Weber <marco-oweber@gmx.de>:
>
> > ls -1t "$dump_dir"/sup-dumps-* | { read; read; read; read; cat } | xargs rm
>
> "{ read; read; read; read; cat }" could probably better be done as
> "tail +5"; makes it easier to adjust to people's choice of backup
> count, too. ;-)
> - Daniel "Bikeshedder" Wagner
"tail -n+5", which is POSIX compatible
--
Exherbo KDE, X.org maintainer
------------------------------
Message: 520
Date: Tue, 07 Jul 2009 18:44:18 +0100
From: Iain <rhomunuq+ml_sup@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Exception Log
Message-ID: <1246988396-sup-8372@leda>
Content-Type: text/plain; charset=UTF-8
I'm using Sup 0.8.1 on Ubuntu 8.10 -- from the .deb kindly put together
by Decklin Foster, <http://apt.rupamsunyata.org/sup/>.
A few minutes ago, sup crashed on me. ~/.sup/exception-log.txt :
--- NoMethodError from thread: main
undefined method `title' for nil:NilClass
/usr/lib/ruby/1.8/sup/buffer.rb:747:in `get_status_and_title'
/usr/lib/ruby/1.8/sup/buffer.rb:281:in `draw_screen'
/usr/bin/sup-mail:306
The crash may have something to do with receiving a new message (from an
automatic poll of a Maildir) at the same time as having just read and
archived the prior first message in the inbox, using: ".a".
------------------------------
Message: 521
Date: Thu, 9 Jul 2009 21:55:17 +0200
From: Adeodato Sim? <dato@net.com.org.es>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH] Use /etc/mailname if present to determine
the hostname for Message-Id
Message-ID:
<e23a0f3ed1ae4e2007d0f8144207e0e2fe3d8c11.1247169308.git.dato@net.com.org.es>
Content-Type: text/plain; charset=utf-8
Signed-off-by: Adeodato Sim? <dato@net.com.org.es>
---
Hello,
on many systems (notably Debian-based systems), the /etc/mailname file
can be created to specify the public mail name for a host. If that file
exists, it'd be good to use its contents for generating the Message-Id
header.
I'd be grateful if you'd consider applying this patch.
lib/sup/modes/edit-message-mode.rb | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/lib/sup/modes/edit-message-mode.rb b/lib/sup/modes/edit-message-mode.rb
index f956d65..a48930a 100644
--- a/lib/sup/modes/edit-message-mode.rb
+++ b/lib/sup/modes/edit-message-mode.rb
@@ -73,7 +73,14 @@ EOS
@attachment_names = []
end
- @message_id = "<#{Time.now.to_i}-sup-#{rand 10000}@#{Socket.gethostname}>"
+ begin
+ hostname = File.open("/etc/mailname", "r").gets.chomp
+ rescue
+ nil
+ end
+ hostname = Socket.gethostname if hostname.nil? or hostname.empty?
+
+ @message_id = "<#{Time.now.to_i}-sup-#{rand 10000}@#{hostname}>"
@edited = false
@selectors = []
@selector_label_width = 0
--
1.6.3.3
------------------------------
Message: 522
Date: Fri, 10 Jul 2009 02:34:21 +0200
From: Michael Stapelberg <michael@stapelberg.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] sup opens multiple connections to the same
imap-server
Message-ID: <1247185833-sup-8539@x200>
Content-Type: text/plain; charset=UTF-8
Hi,
for some reason my cyrus-imapd does not handle multiple connections so well.
There are 27 processes on my server which are all caused by sup. Probably sup
opens one imap connection for each source I configured, which are 28. In my
opinion, one connection to the server should be enough. Especially because
sup hangs for ages until it manages to talk to my imap server correctly.
Is there an easy way to make sup use only one connection? If not, I?ll see
if this problem still arises after I re-install my server (probably with
dovecot instead of cyrus this time).
Best regards,
Michael
------------------------------
Message: 523
Date: Fri, 10 Jul 2009 02:38:25 +0200
From: Michael Stapelberg <michael@stapelberg.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Using sup on multiple computers?
Message-ID: <1247186181-sup-1712@x200>
Content-Type: text/plain; charset=UTF-8
Hi,
I?d like to use sup on my notebook and on my workstation. Is there any
simple/recommended way to synchronize the index? I figured using multiple
clients in parallel is one of the big advantages of IMAP and I?d love to keep
it that way while using sup.
Best regards,
Michael
------------------------------
Message: 524
Date: Thu, 09 Jul 2009 22:57:14 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Using sup on multiple computers?
Message-ID: <1247194599-sup-5843@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from Michael Stapelberg's message of Thu Jul 09 20:38:25 -0400 2009:
> I?d like to use sup on my notebook and on my workstation. Is there any
> simple/recommended way to synchronize the index? I figured using multiple
> clients in parallel is one of the big advantages of IMAP and I?d love to keep
> it that way while using sup.
The easiest way is to not; since Sup is a command line application, it's trivial
to spin it up on a server you have access to and simply SSH in to check your
mail.
Cheers,
Edward
------------------------------
Message: 525
Date: Thu, 09 Jul 2009 20:03:22 -0700
From: Jonathan Lassoff <jof@thejof.com>
To: Michael Stapelberg <michael@stapelberg.de>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Using sup on multiple computers?
Message-ID: <1247194844-sup-6153@sfo.thejof.com>
Content-Type: text/plain; charset=UTF-8
Excerpts from Michael Stapelberg's message of Thu Jul 09 17:38:25 -0700 2009:
> Hi,
>
> I'd like to use sup on my notebook and on my workstation. Is there any
> simple/recommended way to synchronize the index?
As far as I know, this isn't supported in sup yet.
One way I work around this to use sup on two machines is that I know my
access is mutually exclusive i.e. I don't use more than one host at
once.
So, when I switch from one host to another, I quit sup and rsync my ~/.sup to the
machine I'm moving to and rysnc it back again when I return.
Hacky, but functional enough.
Cheers,
jonathan
------------------------------
Message: 526
Date: Fri, 10 Jul 2009 12:59:42 +0200
From: Michael Stapelberg <michael+sup@stapelberg.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Using sup on multiple computers?
Message-ID: <1247223427-sup-4016@x200>
Content-Type: text/plain; charset=UTF-8
Hi,
Excerpts from Edward Z. Yang's message of Fr Jul 10 04:57:14 +0200 2009:
> The easiest way is to not; since Sup is a command line application, it's trivial
> to spin it up on a server you have access to and simply SSH in to check your
> mail.
I?ve been using mutt like this for about a year or so but I generally
don?t want to continue with this approach. It has the disadvantage of
having the need to copy attachments to your computer before being able
to display them (think of PDFs) and of not scaling well when on a slow
internet connection (IMAP traffic is less than a whole user interface).
Best regards,
Michael
------------------------------
Message: 527
Date: Fri, 10 Jul 2009 10:30:40 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Using sup on multiple computers?
Message-ID: <1247236046-sup-9543@Longbow>
Content-Type: text/plain; charset=utf8
Excerpts from Jonathan Lassoff's message of Thu Jul 09 23:03:22 -0400 2009:
> Excerpts from Michael Stapelberg's message of Thu Jul 09 17:38:25 -0700 2009:
> > Hi,
> >
> > I'd like to use sup on my notebook and on my workstation. Is there any
> > simple/recommended way to synchronize the index?
>
> As far as I know, this isn't supported in sup yet.
>
> One way I work around this to use sup on two machines is that I know my
> access is mutually exclusive i.e. I don't use more than one host at
> once.
The smarter way of doing this is to keep your .sup on a remote server as
a share and mount it onto the right place in your home when you log in.
This still has the disadvantage of only being able to use one sup at a
time, but at least sup will lock the index using its lockfile, so you
can't accidentally run two at once and screw something up.
It also prevents you from having to manually rsync stuff.
The nicest way to do this would to probably use sshfs. This way, the
index is shared, you only need ssh (no NFS nastiness), it can mount
automatically, and since sup is actually running on your local machine,
it can save attachments just fine.
One note: You need to either have _identical_ imap folders on your
computers in the identical filesystem paths, or you need to have your
mail delivered to the server and share that too.
--
Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
------------------------------
Message: 528
Date: Fri, 10 Jul 2009 17:00:29 +0200
From: Adeodato Sim? <dato@net.com.org.es>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH] mime-decode hook: provide a "charset"
variable with the attachment charset
Message-ID:
<6fc2e5dd8aa2b0b8547375d77b1776d779f85817.1247238014.git.dato@net.com.org.es>
Content-Type: text/plain; charset=utf-8
This is useful, for example, for HTML attachments which are sent in a
charset different from the default for the system (eg., ISO-8859-1 on an
UTF-8 system), so that the converter program can be told what charset it
should be converting from.
Signed-off-by: Adeodato Sim? <dato@net.com.org.es>
---
lib/sup/message-chunks.rb | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/lib/sup/message-chunks.rb b/lib/sup/message-chunks.rb
index 0d742d9..ea04ed7 100644
--- a/lib/sup/message-chunks.rb
+++ b/lib/sup/message-chunks.rb
@@ -50,7 +50,8 @@ directly in Sup. For attachments that you wish to use a separate program
to view (e.g. images), you should use the mime-view hook instead.
Variables:
- content_type: the content-type of the message
+ content_type: the content-type of the attachment
+ charset: the charset of the attachment, if applicable
filename: the filename of the attachment as saved to disk
sibling_types: if this attachment is part of a multipart MIME attachment,
an array of content-types for all attachments. Otherwise,
@@ -103,6 +104,7 @@ EOS
else
HookManager.run "mime-decode", :content_type => content_type,
:filename => lambda { write_to_disk },
+ :charset => encoded_content.charset,
:sibling_types => sibling_types
end
--
1.6.3.3
------------------------------
Message: 529
Date: Fri, 10 Jul 2009 22:19:14 +0200
From: Michael Stapelberg <michael+sup@stapelberg.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Validating GPG keys in parallel and in background
Message-ID: <1247256988-sup-2799@x200>
Content-Type: text/plain; charset=UTF-8
Hi,
it seems like sup is blocking during the validation of GPG signed/encrypted
mails. While for encryption it makes some sense to block, for signed mails
it would be better to just display the message and add the information about
the signature status later. The same approach could be used for encrypted
messages: Display "decrypting..." and update it when done.
This is especially important for big mailing lists (like debian-devel) which
contain many signed mails.
Best regards,
Michael
------------------------------
Message: 530
Date: Sat, 11 Jul 2009 13:57:55 +0200
From: Adeodato Sim? <dato@net.com.org.es>
To: sup-talk@rubyforge.org
Cc: Adeodato Sim? <dato@net.com.org.es>
Subject: [sup-talk] [PATCH] Unbreak "bounce-command" hook (was
referencing an nonexistent variable)
Message-ID:
<ef3825cbc25db1005616823980a339827c9db65e.1247313450.git.dato@net.com.org.es>
Content-Type: text/plain; charset=utf-8
Signed-off-by: Adeodato Sim? <dato@net.com.org.es>
---
lib/sup/modes/thread-view-mode.rb | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb
index 759191e..737f6f1 100644
--- a/lib/sup/modes/thread-view-mode.rb
+++ b/lib/sup/modes/thread-view-mode.rb
@@ -204,7 +204,7 @@ EOS
end
end
- cmd = case HookManager.run "bounce-command", :from => m.from, :to => to
+ cmd = case (hookcmd = HookManager.run "bounce-command", :from => m.from, :to => to)
when nil, /^$/ then defcmd
else hookcmd
end + ' ' + to.map { |t| t.email }.join(' ')
--
1.6.3.3
------------------------------
Message: 531
Date: Sat, 11 Jul 2009 10:12:17 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup opens multiple connections to the same
imap-server
Message-ID: <1247321064-sup-4795@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Michael Stapelberg's message of Thu Jul 09 20:34:21 -0400 2009:
> Is there an easy way to make sup use only one connection? If not, I?ll see
> if this problem still arises after I re-install my server (probably with
> dovecot instead of cyrus this time).
I don't believe there is a way to do this currently. It would require
some refactoring of the code.
Roughly:
The IMAP source would refer to an IMAPManager for a connection. The
IMAP manager would handle creating new connections when required or
passing a reference to an existing connection if it had already
created. A tuple of (imap server, username, password) could be used
to determine the uniqueness of the request.
The unsafe_connect method of the IMAP source could move to the
IMAPManager and calls to unsafe_connect could be rerouted to
IMAPManager.connection_for(server, user, password) or some such...
It shouldn't be a bad addition to add if you're interested.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090711/4edae96c/attachment-0001.bin>
------------------------------
Message: 532
Date: Sat, 11 Jul 2009 10:28:58 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Unbreak "bounce-command" hook (was
referencing an nonexistent variable)
Message-ID: <1247322405-sup-1564@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Adeodato Sim?'s message of Sat Jul 11 07:57:55 -0400 2009:
> Signed-off-by: Adeodato Sim? <dato@net.com.org.es>
> ---
> lib/sup/modes/thread-view-mode.rb | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
+1 for this. Not sure how I managed to submit the original patch like
this, since I did test various forms of results returned from the
bounce-command hook...anyway, I've applied this and verified it.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090711/3b5d572f/attachment-0001.bin>
------------------------------
Message: 533
Date: Sat, 11 Jul 2009 17:36:23 +0200
From: Michael Stapelberg <michael+sup@stapelberg.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup opens multiple connections to the same
imap-server
Message-ID: <1247326506-sup-1002@x200>
Content-Type: text/plain; charset=UTF-8
Hi Ben,
Excerpts from Ben Walton's message of Sa Jul 11 16:12:17 +0200 2009:
> It shouldn't be a bad addition to add if you're interested.
Thanks for pointing out how it could be done. Unfortunately, I?ve never
done any ruby code. I?ll have a look at sup?s source in a few weeks and
I can try to implement it. Don?t count on it, though (meaning: if you
can do it better/faster, go for it).
Best regards,
Michael
------------------------------
Message: 534
Date: Sat, 11 Jul 2009 18:53:35 +0200
From: Michael Stapelberg <michael+sup@stapelberg.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Adding/saving multiple attachments?
Message-ID: <1247331130-sup-4923@x200>
Content-Type: text/plain; charset=UTF-8
Hi,
I?ve had the same problem with mutt: Isn?t there a way to add or save
multiple attachments? Why can?t I add ~/work/foo/* when pressing 'a'?
Why doesn?t the file browser save the last directory I?ve been in?
Can we please get a binding to save all attachments of a message into
a folder?
Best regards,
Michael
------------------------------
Message: 535
Date: Mon, 13 Jul 2009 11:01:10 +0200
From: Nico Schottelius <nico-sup@schottelius.org>
To: sup-talk@rubyforge.org
Subject: [sup-talk] Invalid character on import
Message-ID: <20090713090110.GA20996@ikn.schottelius.org>
Content-Type: text/plain; charset=us-ascii
Hello!
I'm trying to import my current maildir into sup, but
it fails with the following error:
--------------------------------------------------------------------------------
[Mon Jul 13 09:33:17 +0200 2009] scanning maildir /home/spieler/Maildir/INBOX...
[Mon Jul 13 09:33:17 +0200 2009] no poll on cur. mtime on indicates no new messages.
[Mon Jul 13 09:33:17 +0200 2009] no poll on new. mtime on indicates no new messages.
[Mon Jul 13 09:33:18 +0200 2009] done scanning maildir
## read 13228m (about 84%) @ 6.1m/s. 0:36:04 elapsed, about 0:06:49 remaining
## read 13306m (about 84%) @ 6.1m/s. 0:36:19 elapsed, about 0:06:48 remaining
[Mon Jul 13 09:33:34 +0200 2009] unlocking /home/spieler/.sup/lock...
/home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:647:in `iconv': " " (Iconv::InvalidCharacter)
from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:647:in `easy_decode'
from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/message.rb:430:in `message_to_chunks'
from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/message.rb:209:in `load_from_source!'
from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/poll.rb:151:in `add_messages_from'
from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/maildir.rb:130:in `each'
from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/maildir.rb:127:in `upto'
from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/maildir.rb:127:in `each'
from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:552:in `send'
from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:552:in `__pass'
from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:539:in `method_missing'
from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/poll.rb:141:in `add_messages_from'
from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:513:in `send'
from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:513:in `method_missing'
from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/bin/sup-sync:140
from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/bin/sup-sync:135:in `each'
from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/bin/sup-sync:135
from /home/spieler/.gem/ruby/1.8/bin/sup-sync:19:in `load'
from /home/spieler/.gem/ruby/1.8/bin/sup-sync:19
--------------------------------------------------------------------------------
Any idea what's wrong here? sup's installed via gem install.
Nico
------------------------------
Message: 536
Date: Mon, 13 Jul 2009 11:15:16 +0200
From: Nico Schottelius <nico-sup@schottelius.org>
To: sup-talk@rubyforge.org
Subject: [sup-talk] Slow import of messages
Message-ID: <20090713091516.GA21214@ikn.schottelius.org>
Content-Type: text/plain; charset=us-ascii
Hello!
I'm looking at sup as a replacement for mutt.
Following the idea of sup, I took a snapshot of
my Mails from 2008-2009 (~56k mails) and run
sup-sync --all-sources
Now the problem is that sup gets about 3 mails per
second into its index. That means it takes about
56k/3 ~= 15k; 15000/60 = 250 minutes
That import is already from a local Maildir (synced with
offlineimap).
For me, this is incredibly slow. Using mutt it's way faster,
not even comparing the fact the speed improvement you get
when dividing into folders.
What's your impression? Am I totally wrong or is sup just
the wrong tool for handling a lot of messages?
Sincerly,
Nico
------------------------------
Message: 537
Date: Mon, 13 Jul 2009 11:26:14 +0200
From: Michael Stapelberg <michael+sup@stapelberg.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Slow import of messages
Message-ID: <1247477044-sup-6433@midna>
Content-Type: text/plain; charset=UTF-8
Hi Nico,
Excerpts from Nico Schottelius's message of Mo Jul 13 11:15:16 +0200 2009:
> I'm looking at sup as a replacement for mutt.
> Following the idea of sup, I took a snapshot of
> my Mails from 2008-2009 (~56k mails) and run
I have about 33k emails on my IMAP server in my LAN.
> Now the problem is that sup gets about 3 mails per
> second into its index. That means it takes about
I got around 10 MB/s performance using sup-sync. Maybe
your mails are all very large, I don?t know. Maybe maildir is
just a lot slower than IMAP in sup-sync.
> What's your impression? Am I totally wrong or is sup just
> the wrong tool for handling a lot of messages?
My impression is that sup-sync can definitely be improved regarding
its speed. I?m not sure if it is actually doable or if it is some ruby
library (Ferret?) which is the limiting factor here. However, it was
not as bad for me as it is for you ;-).
Best regards,
Michael
------------------------------
Message: 538
Date: Mon, 13 Jul 2009 22:17:26 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: Nico Schottelius <nico-sup@schottelius.org>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Invalid character on import
Message-ID: <1247516120-sup-3116@ausone.local>
Content-Type: text/plain; charset=UTF-8
Excerpts from Nico Schottelius's message of Mon Jul 13 11:01:10 +0200 2009:
> Hello!
Hello,
> I'm trying to import my current maildir into sup, but
> it fails with the following error:
The fix is trivial, I've submitted a merge request for exactly this:
http://gitorious.org/~ertai/sup/clone-by-ertai
--
Nicolas Pouillard
http://nicolaspouillard.fr
------------------------------
Message: 539
Date: Tue, 14 Jul 2009 09:22:04 +1200
From: Jim Cheetham <jim@gonzul.net>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Slow import of messages
Message-ID:
<f4cc59760907131422p3dd1d429ka9d334e509b992d7@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Mon, Jul 13, 2009 at 9:15 PM, Nico
Schottelius<nico-sup@schottelius.org> wrote:
> What's your impression? Am I totally wrong or is sup just
> the wrong tool for handling a lot of messages?
No, it's just slow to index for the first time. Unless you receive
1000s of messages per hour, you should be OK ...
-jim
------------------------------
Message: 540
Date: Mon, 13 Jul 2009 23:20:22 +0200
From: Luis Ca?as D?az <lcanas@libresoft.es>
To: sup-talk@rubyforge.org
Subject: [sup-talk] problems with Maildir and IMAP offline
Message-ID: <20090713232022.fe1d4839.lcanas@libresoft.es>
Content-Type: text/plain; charset=ISO-8859-1
Hi guys,
first things first. Your mail client looks promising, I've been testing many of them (most of them from the kde/gnome world) and yours seems to be perfect to be running in my dear mac mini ;)
This afternoon I've been trying to set up a gmail account with offlineimap and I'm having the same problem reported by this guy[1]. I run offlineimap and it creates a Maildir directory with 4hundred read mails and 2hundred unread mails (yes, I should pay more attention to my gmail account;). The problem is that sup sees all of the messages as unread which is not true according to the Maildir structure:
[luis@gongbu INBOX]$ ls new/|wc -l;ls cur/|wc -l
210
412
After applying changes with sup, the state is the same. When using sup I "delete" messages and mark them as read.
The sup version is:
[luis@gongbu ~]$ sup -v
[Mon Jul 13 23:14:25 +0200 2009] using character set encoding "UTF-8"
sup v0.8.1
Last thing, I haven't seen it written by I guess it's a good idea having the files locally to use the search engine. Am I right?
Thanks for your help! :)
[1] http://osdir.com/ml/mail.sup.general/2008-08/msg00029.html
--
Luis Ca?as D?az | GSyC/LibreSoft Research Lab
http://libresoft.es | Grupo de Sistemas y Comunicaciones
Tel: (+34) 91 488 85 23 | Universidad Rey Juan Carlos
------------------------------
Message: 541
Date: Tue, 14 Jul 2009 09:24:32 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] problems with Maildir and IMAP offline
Message-ID: <1247577490-sup-7098@Longbow>
Content-Type: text/plain; charset=utf8
Excerpts from Luis Ca?as D?az's message of Mon Jul 13 17:20:22 -0400 2009:
> After applying changes with sup, the state is the same. When using sup I
> "delete" messages and mark them as read.
I'm somewhat unhappy about this too. It seems to me that sup just plain
does not support the read features of maildirs.
a) It doesn't import them as read
b) sup-sync-back does not mark them as read.
The best I could find is manually marking things as read and deleting
them, and then using sup-sync-back with the deleted options which it
does understand.
On the other hand, sup provides hooks to make calling offlineimap and
sup-sync-back completely transparent and well-timed. You can call
sup-sync-back followed by offlineimap on each sup poll, so that's pretty
sweet.
--
Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
------------------------------
Message: 542
Date: Tue, 14 Jul 2009 10:02:11 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] problems with Maildir and IMAP offline
Message-ID: <1247580020-sup-9946@Longbow>
Content-Type: text/plain; charset=utf8
Excerpts from Tim Gray's message of Tue Jul 14 09:45:44 -0400 2009:
> On Tue 14, Jul'09 at 9:24 AM -0400, Andrei Thorp wrote:
>
> > a) It doesn't import them as read
> > b) sup-sync-back does not mark them as read.
I'm forwarding a summary of your message with my replies to the mailing
list. It seems like you replied to me only by accident?
> From my playing around with sup and from what I've read, sup just doesn't
> play nicely with other mail clients. Sup will read from your sources, but
> the sources never get modified.
Again, see sup-sync-back -- it does indeed have _some_ ability to write
its state back to the source.
> I know sup is slowly moving in the direction of a more locked in design. I
> just wish sup added automatic sync back capabilities.
Put this in a hook and it's automatic. That's the beauty of the
hook/multiple binary design.
> As far as OfflineIMAP goes, I didn't think I would do this, but I've been
> running it in it's full curses mode with an auto refresh set.
I'm not entirely sure why you want this. If you're worried about
failures, do they really happen? If you want to see the log, aren't you
already piping it? If you want notifications, you could hook them up to
happen in your sup hook (the one I described before) rather trivially
via notify-send.
--
Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
------------------------------
Message: 543
Date: Tue, 14 Jul 2009 11:00:34 -0400
From: Tim Gray <lists+sup@protozoic.com>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] problems with Maildir and IMAP offline
Message-ID: <20090714150034.GA393@d228.scdc1.swarthmore.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
On Tue 14, Jul'09 at 10:02 AM -0400, Andrei Thorp wrote:
> I'm forwarding a summary of your message with my replies to the mailing
> list. It seems like you replied to me only by accident?
Whoops. I didn't realize this list didn't have reply-to set. Thanks.
> Again, see sup-sync-back -- it does indeed have _some_ ability to write
> its state back to the source.
To me, this is a vital feature of any mail client. I'll look into it, but I
would really like this to be fully integrated into my mail client. And from
I've read, this isn't something that's going to happen.
Sometimes I need to use mutt/pine. Sometimes webmail. Most importantly, I
want all my mail in a form that is easy to backup, human readable, and can
be manipulated with standard utilities. Maildir fits the bill.
I think it'd be fantastic if there was a mail client that allowed you to
sort by folders, but also provided a sup-like view that laid on top if/when
you needed.
> Put this in a hook and it's automatic. That's the beauty of the
> hook/multiple binary design.
Honestly, if it's that easy, shouldn't it be configured like that out of the
box?
> I'm not entirely sure why you want this. If you're worried about
> failures, do they really happen? If you want to see the log, aren't you
> already piping it? If you want notifications, you could hook them up to
> happen in your sup hook (the one I described before) rather trivially
> via notify-send.
For use with other mail clients for one. It's kind of nice having my IMAP
syncing separate from the mail client. I'm sure I could run it
automatically via cron, but then you'd have to give up the quick refresh
capability (minor) and the IDLE mode. Sure, I could pipe the output
somewhere else, but wouldn't that accomplish the same thing as just looking
at the output already provided, either curses or one of the other ones?
Again, it's running in screen so I don't even have it open on any windows.
Of course, that doesn't mean this is the best route to go, but it's been
working for me for so far - I am new to it though. It's a nice pretty
colored interface too :)
Tim
------------------------------
Message: 544
Date: Tue, 14 Jul 2009 11:07:46 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] problems with Maildir and IMAP offline
Message-ID: <1247584002-sup-504@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Tim Gray's message of Tue Jul 14 11:00:34 -0400 2009:
> > Again, see sup-sync-back -- it does indeed have _some_ ability to write
> > its state back to the source.
>
> To me, this is a vital feature of any mail client. I'll look into it, but I
> would really like this to be fully integrated into my mail client. And from
> I've read, this isn't something that's going to happen.
There was some talk a while back about modifying the behaviour of
Maildir sources. The issue was that there is an odd scanning bug with
Maildir that sometimes sees messages get skipped. A proposed solution
was to have sup start 'playing nice' with Maildir so that when new
messages were found in new/, they'd be indexed and recorded with a
filename in cur/, presumably with the S (seen) flag appended properly.
I _think_ William was looking at that, but I'm not sure. It's
something I'd like too (not to play nice with other clients, but
because it's "just better"). I haven't had much time lately, but if
William confirms he's not working on it, I'd be interested in
implementing it.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090714/e30a5b14/attachment-0001.bin>
------------------------------
Message: 545
Date: Tue, 14 Jul 2009 11:14:50 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] problems with Maildir and IMAP offline
Message-ID: <1247584404-sup-7126@Longbow>
Content-Type: text/plain; charset=utf8
Excerpts from Tim Gray's message of Tue Jul 14 11:00:34 -0400 2009:
> On Tue 14, Jul'09 at 10:02 AM -0400, Andrei Thorp wrote:
> > Put this in a hook and it's automatic. That's the beauty of the
> > hook/multiple binary design.
>
> Honestly, if it's that easy, shouldn't it be configured like that out of the
> box?
People perhaps don't want this. It's slower, and a lot of folks probably
do no syncing back since all they use is sup anyway.
> > I'm not entirely sure why you want this. If you're worried about
> > failures, do they really happen? If you want to see the log, aren't you
> > already piping it? If you want notifications, you could hook them up to
> > happen in your sup hook (the one I described before) rather trivially
> > via notify-send.
>
> For use with other mail clients for one.
Understood. Makes sense in your use case. I don't really understand why
you'd want to use pine/mutt when you've already got sup though ;)
--
Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
------------------------------
Message: 546
Date: Tue, 14 Jul 2009 11:28:06 -0400
From: Tim Gray <lists+sup@protozoic.com>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] problems with Maildir and IMAP offline
Message-ID: <20090714152806.GC393@d228.scdc1.swarthmore.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
On Tue 14, Jul'09 at 11:07 AM -0400, Ben Walton wrote:
> It's something I'd like too (not to play nice with other clients, but
> because it's "just better").
This sound like a good thing. In my experience, 'just better' usually
equals 'playing nice', since 'playing nice' usually equals following the
standards. That's how Maildirs are supposed to work - if everybody followed
the spec, we'd be set.
Though I don't program for a living, nor do I know any Ruby, it seems like a
doable thing. Is there something fundamental blocking per-message sync-back
of status as you read/delete/otherwise modify your mail? I would assume
there a reference to the original message location in a message's database
entry. If a message gets read, write an S at the end of the filename and
move it to /cur. If it gets deleted, delete it. Operations on a message
should affect the database and the mail store at the same time. Why is
something like sup-sync-back even necessary?
Anyway, these are just the musings of someone who doesn't have the tools to
write something like sup, so I'll be quiet now before I embarrass myself any
further.
------------------------------
Message: 547
Date: Tue, 14 Jul 2009 11:39:09 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] problems with Maildir and IMAP offline
Message-ID: <1247585761-sup-5167@Longbow>
Content-Type: text/plain; charset=utf8
Excerpts from Tim Gray's message of Tue Jul 14 11:28:06 -0400 2009:
> On Tue 14, Jul'09 at 11:07 AM -0400, Ben Walton wrote:
> > It's something I'd like too (not to play nice with other clients, but
> > because it's "just better").
>
> This sound like a good thing. In my experience, 'just better' usually
> equals 'playing nice', since 'playing nice' usually equals following the
> standards. That's how Maildirs are supposed to work - if everybody followed
> the spec, we'd be set.
I'd just like to mention that the reason we tend not to sync back in
general isn't because we hate standards and want people to get hurt :)
It's roughly because of the extra features in sup:
- It keeps a database so it can search for stuff quickly
- It implements its own tagging regardless of source (unlike stuff like
mutt that just rely on "physical" folders)
- It merges sources
So while it's possible to do some merging back, it's sometimes awkward
because sup's tags do not have to map 1:1 to IMAP folders or anything
else. It's otherwise also a bit awkward because we might have mail from
many sources in one place, so writing back isn't as simple as just
editing files. You also have to _not_ edit files.
Anyway, that all said, it's clearly possible and would be very nice to
have.
--
Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
------------------------------
Message: 548
Date: Tue, 14 Jul 2009 11:45:07 -0400
From: Tim Gray <lists+sup@protozoic.com>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] problems with Maildir and IMAP offline
Message-ID: <20090714154507.GD393@d228.scdc1.swarthmore.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
On Tue 14, Jul'09 at 11:14 AM -0400, Andrei Thorp wrote:
> People perhaps don't want this. It's slower, and a lot of folks probably
> do no syncing back since all they use is sup anyway.
I would hope in this day in age we can change a database entry and move a
file at the same time without too much of a performance hit. I would think
it only gets unbearable when you don't update as you go and you have to do a
large batch of messages. But you are right, maybe people don't want that.
Personally, and this is a side note, if I was involved in the project, I'd
push for canning the built in IMAP capabilities all together. Just run
offlineimap or one of the other IMAP syncing utilities. Add to that beefing
up the Maildir handling. Just worry about better and more transparent
sync-back-to-Maildir capabilities and let offlineimap worry about the server
side of the equation.
> Understood. Makes sense in your use case. I don't really understand why
> you'd want to use pine/mutt when you've already got sup though ;)
As you can tell, I'm not quite sold on sup yet. I've switched mail clients
enough over the past few years that switching in and of itself is a giant
pain. I've settled on Maildir as my 'client' for now. I can serve it via
IMAP if I need, I can read it with a couple mail clients, and I can easily
convert it to mbox however I want to with some simple Python code.
If I switch to sup full time, I would be comforted by the fact that if I
choose to change in 2 years, all of my mail is marked read, deleted mail is
actually deleted, and even though I was using sup labels for my
organization, things are still organized in some fashion by appropriate
folders on the file system. The last part could be achievable by some
combination of offlineimap + gmail/sieve filtering and fetchmail/getmail +
procmail. It'd still be nice to be able to move physical messages around in
sup though. Maybe I'm just nuts though.
------------------------------
Message: 549
Date: Tue, 14 Jul 2009 11:59:16 -0400
From: Tim Gray <lists+sup@protozoic.com>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] problems with Maildir and IMAP offline
Message-ID: <20090714155916.GE393@d228.scdc1.swarthmore.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
On Tue 14, Jul'09 at 11:39 AM -0400, Andrei Thorp wrote:
> I'd just like to mention that the reason we tend not to sync back in
> general isn't because we hate standards and want people to get hurt :)
Haha. Of course.
> It's roughly because of the extra features in sup:
I got you. Still, I envisage a mail client that has an underlying structure
built on folders. On top of that a database/virtual folder interface is
built. Of course, you'd have the ability to access the folder based
structure when needed. So you could move a message or a conversation to a
given folder if you want.
For example, I have work emails for a certain project with a given label.
It's wonderful that in sup, those currently in my physical inbox and those
currently in an archive folder somewhere show up under the same label in
sup. But there's no mechanism to moving those in my physical inbox to the
archive folder. Some might say who cares, but I can't leave all my email in
my physical inbox forever, which is synced by offlineimap, because people
associated with this project have a nasty habit of sending 10-20 mb
attachments and I don't want to clutter up my IMAP boxes with hundreds of
megs of attachments forever. Heck, I can't do that unless I have an IMAP
service with 25 gigs of storage.* Sometimes they just need to be collected
in a totally offline box, but somewhere that is still accessible by
searching if I need access to it.
Sup is pretty close to this already, minus the access to the underlying
structure.
---
[*] Obviously for those of you using Gmail, this isn't an issue. Who cares
about deleting messages?
------------------------------
Message: 550
Date: Tue, 14 Jul 2009 18:21:45 +0200
From: Israel Herraiz <isra@herraiz.org>
To: Luis Cañas DÃaz <lcanas@libresoft.es>
Cc: sup-talk@rubyforge.org
Subject: Re: [sup-talk] problems with Maildir and IMAP offline
Message-ID: <1247587742-sup-5619@elly>
Content-Type: text/plain; charset=utf8
Excerpts from Luis's message on Jul 13, 2009 about 11 PM:
> This afternoon I've been trying to set up a gmail account with offlineimap and
> I'm having the same problem reported by this guy[1]. I run offlineimap and it
> creates a Maildir directory with 4hundred read mails and 2hundred unread mails
> (yes, I should pay more attention to my gmail account;).
I have not used IMAP with Sup, but AFAIK, Sup does not touch the
original sources of email. For instance, it does not read nor modify
messages using IMAP, it just read them using that protocol (or maildir
or whatever).
Therefore, the only way to get those messages marked as read is using
sup-sync with the --read option. That will mark the messages as read
in Sup.
However there are two problems. If all the messages (unread or read)
are in the same source, there is no way to indicate which messages are
going to be marked as read and which are not.
Moreover, if you read a message in Sup, it still will appear in Gmail
as unread.
I also use Gmail with Sup, but using POP. I use the web interface of
Gmail when I cannnot access my laptop. I use IMAP from my mobile
phone. And I download all my email to my laptop using POP.
If I get a message in my laptop, it is marked as archived and read in
GMail, so it does not appear as unread in the web nor in my phone.
However, if I read the message in the phone or the web, it will appear
as unread in Sup.
Still it is a good solution if you have a "central" node where you
store your mail, and do your main work (my laptop), and a couple of
"external" agents (phone, web) to be able of reading your email if you
do not have your laptop at hand.
Another advantage is that you keep a copy of your mail in your
laptop. GMail is not going to last forever (of course, it still has a
long live) and with this you ensure that you will not loose your
old-email in GMail is closed some day, and it is also very handy to
make backups of all your email (just copy the mbox file to another
location).
To get the email I use getmail [1], and msmtp [2] with these scripts
[3] (see last section) as a lightweight replacement for sendmail. I
can provide you my config scripts if you want.
It is not a good solution though if you read your email from several
different computers.
Cheers,
Israel
[1] http://pyropus.ca/software/getmail/
[2] http://msmtp.sourceforge.net/
[3] http://wiki.archlinux.org/index.php/Msmtp
------------------------------
Message: 551
Date: Tue, 14 Jul 2009 09:43:01 -0600
From: John Bent <johnbent@lanl.gov>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Using sup on multiple computers?
Message-ID: <1247585908-sup-4190@tangerine.lanl.gov>
Content-Type: text/plain; charset=UTF-8
Excerpts from Michael Stapelberg's message of Thu Jul 09 18:38:25 -0600
2009:
> Hi,
>
> I?d like to use sup on my notebook and on my workstation. Is there any
> simple/recommended way to synchronize the index? I figured using
> multiple clients in parallel is one of the big advantages of IMAP and
> I?d love to keep it that way while using sup.
>
This won't really answer your exact question but I also use sup on a
workstation and a notebook. What I do is run sup in a screen session on
the workstation and then connect to it from the laptop. The window size
is different on the workstation and the laptop so whenever I switch, I
have to do:
<ctr-a>F : to get screen to resize
@ : to get sup to redraw itself
Hope that helps,
John
> Best regards,
> Michael
------------------------------
Message: 552
Date: Tue, 14 Jul 2009 15:33:36 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Using sup on multiple computers?
Message-ID: <1247599899-sup-811@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from John Bent's message of Tue Jul 14 11:43:01 -0400 2009:
> @ : to get sup to redraw itself
Try Ctrl+L for the redraw. Saves having sup do any work at all. This
is also good for when the display gets corrupted in screen. It's a
pretty standard sequence too, so you may find it applicable elsewhere
(eg: it'll clear your terminal for you, redraw and centre a buffer in
emacs, etc).
HTH.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090714/143b6aca/attachment-0001.bin>
------------------------------
Message: 553
Date: Tue, 14 Jul 2009 21:35:12 +0200
From: Michael Stapelberg <michael+sup@stapelberg.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Using sup on multiple computers?
Message-ID: <1247600011-sup-635@midna>
Content-Type: text/plain; charset=UTF-8
Hi John,
Excerpts from John Bent's message of Di Jul 14 17:43:01 +0200 2009:
> <ctr-a>F : to get screen to resize
> @ : to get sup to redraw itself
> Hope that helps,
Thanks, that?s at least a good start to get where I was with mutt. However,
it does not solve the other problems (GUI traffic/latency vs. IMAP,
opening/adding attachments).
Best regards,
Michael
------------------------------
Message: 554
Date: Sat, 18 Jul 2009 09:42:07 +1000
From: Richard Heycock <rgh@roughage.com.au>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH 0/18] Xapian-based index
Message-ID: <1247873980-sup-8574@wrasse>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Fri Jun 26 23:49:40 +1000 2009:
> Reformatted excerpts from Olly Betts's message of 2009-06-25:
> > I'll make sure this fix makes it into the next Xapian release (which
> > will be 1.0.14).
>
> Awesome, thanks!
>
> Though even with SWIG fixed there will still be some tweaking necessary
> in Sup because the logistic function used for generating Xapian docids
> still has trouble with extreme dates.
>
> BTW, more kudos to Rich for somehow finding a way to use a logistic
> function in an email client.
I've been meaning to respond to this the day this was posted. Rich Lane
thank you, thank you. Ferret was one of by biggest gripes of using sup.
I've used it elsewhere and it's a shocker; I eventually migrated it all
to Xapian which has worked flawlessly since. I used to rebuild by ferret
index almost on a weekly basis (I'm running debian unstable, which at
the moment is really living up to it's name) at one stage something I
haven't had to do once since migrating to Xapian.
I got it work with 1.9 once but there are some problems that I just
haven't had the time to look into but I will do and post any problems to
the list.
rgh
------------------------------
Message: 555
Date: Sat, 18 Jul 2009 01:41:51 -0600
From: lee <lee@yun.yagibdah.de>
To: sup-talk@rubyforge.org
Subject: [sup-talk] trying out sup ...
Message-ID: <20090718074151.GF30748@cat.rubenette.is-a-geek.com>
Content-Type: text/plain; charset=us-ascii
Hi,
I've started trying out sup on Debian Testing amd64. Searching didn't
work, so I installed a replacement library[1] after finding a bug
report[2].
Now the search would work, but when I'm trying to enter something to
search for or only press enter to see a list of labels I used, no
matches are found, and the status line shows some garbage characters
as string that has been searched for. This happens when sup is running
in an xterm or in rxvt; it doesn't happen when I switch to the console
and run sup there.
So I had sup running on the console and tried out to search for
something while sup was looking for new messages in a maildir. But
then it crashed and told me I should send a bug report[3].
Maybe I have created some incompatibilities by installing the
replacement library. But is it currently possible to run sup on Debian
Testing without too much difficulty? If so, what do I need to do?
[1]:
http://apt.rupamsunyata.org/sup/libncurses-ruby1.8_1.2.3-0.2_amd64.deb
[2]:
http://groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/d79896cacc28e0e8/7a76dece1e5ef6a3?lnk=raot
[3]: ~/.sup/exception-log.txt:
--- NoMethodError from thread: poll after loading inbox
undefined method `content_width' for nil:NilClass
/usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:747:in `from_width'
/usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:672:in `text_for_thread_at'
/usr/lib/ruby/1.8/sup/hook.rb:134:in `each_with_index'
/usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:671:in `each'
/usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:671:in `each_with_index'
/usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:671:in `text_for_thread_at'
/usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:632:in `regen_text'
/usr/lib/ruby/1.8/sup/util.rb:344:in `map_with_index'
/usr/lib/ruby/1.8/sup/hook.rb:134:in `each_with_index'
/usr/lib/ruby/1.8/sup/util.rb:344:in `each'
/usr/lib/ruby/1.8/sup/util.rb:344:in `each_with_index'
/usr/lib/ruby/1.8/sup/util.rb:344:in `map_with_index'
/usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:632:in `regen_text'
/usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:219:in `update'
/usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:576:in `add_or_unhide'
/usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:181:in `handle_added_update'
/usr/lib/ruby/1.8/sup/update.rb:27:in `send'
/usr/lib/ruby/1.8/sup/update.rb:27:in `relay'
/usr/lib/ruby/1.8/sup/update.rb:27:in `each'
/usr/lib/ruby/1.8/sup/update.rb:27:in `relay'
/usr/lib/ruby/1.8/sup/util.rb:499:in `send'
/usr/lib/ruby/1.8/sup/util.rb:499:in `method_missing'
/usr/lib/ruby/1.8/sup/poll.rb:161:in `add_messages_from'
/usr/lib/ruby/1.8/sup/maildir.rb:130:in `each'
/usr/lib/ruby/1.8/sup/maildir.rb:127:in `upto'
/usr/lib/ruby/1.8/sup/maildir.rb:127:in `each'
/usr/lib/ruby/1.8/sup/util.rb:538:in `send'
/usr/lib/ruby/1.8/sup/util.rb:538:in `__pass'
/usr/lib/ruby/1.8/sup/util.rb:525:in `method_missing'
/usr/lib/ruby/1.8/sup/poll.rb:141:in `add_messages_from'
/usr/lib/ruby/1.8/sup/poll.rb:98:in `do_poll'
/usr/lib/ruby/1.8/sup/poll.rb:86:in `each'
/usr/lib/ruby/1.8/sup/poll.rb:86:in `do_poll'
/usr/lib/ruby/1.8/sup/poll.rb:85:in `synchronize'
/usr/lib/ruby/1.8/sup/poll.rb:85:in `do_poll'
/usr/lib/ruby/1.8/sup/util.rb:499:in `send'
/usr/lib/ruby/1.8/sup/util.rb:499:in `method_missing'
/usr/lib/ruby/1.8/sup/modes/poll-mode.rb:17:in `poll'
/usr/lib/ruby/1.8/sup/poll.rb:53:in `poll'
/usr/lib/ruby/1.8/sup/util.rb:499:in `send'
/usr/lib/ruby/1.8/sup/util.rb:499:in `method_missing'
/usr/bin/sup-mail:173
/usr/lib/ruby/1.8/sup.rb:84:in `reporting_thread'
/usr/lib/ruby/1.8/sup.rb:82:in `initialize'
/usr/lib/ruby/1.8/sup.rb:82:in `new'
/usr/lib/ruby/1.8/sup.rb:82:in `reporting_thread'
/usr/bin/sup-mail:173
/usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:543:in `call'
/usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:543:in `__unprotected_load_threads'
/usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:485:in `call'
/usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:485:in `load_n_threads_background'
/usr/lib/ruby/1.8/sup.rb:84:in `reporting_thread'
/usr/lib/ruby/1.8/sup.rb:82:in `initialize'
/usr/lib/ruby/1.8/sup.rb:82:in `new'
/usr/lib/ruby/1.8/sup.rb:82:in `reporting_thread'
/usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:483:in `load_n_threads_background'
/usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:553:in `__unprotected_load_threads'
(eval):12:in `load_threads'
/usr/bin/sup-mail:173
------------------------------
Message: 556
Date: Mon, 20 Jul 2009 14:34:56 +0200
From: Michael Stapelberg <michael+sup@stapelberg.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] [PATCH] GSSAPI support for net/imap.rb and sup
Message-ID: <1248092732-sup-9960@midna>
Content-Type: text/plain; charset="utf-8"
Hi,
since I installed my new mailserver with Kerberos auth only, I needed to
implement GSSAPI support for Net::IMAP and sup.
I found the C bindings called ruby-gss at:
http://devel.it.su.se/pub/jsp/polopoly.jsp?d=1047&a=3790
Using them (and adding the wrap/unwrap methods for a context, see
03-ruby-gss.patch), it was relatively easy to implement GSSAPIAuthenticator
(see 02-net_imap-gssapi.patch). The addition of the authenticator to sup is
trivial (see 01-sup_gssapi.patch).
Here comes the catch:
As I?m not very much involved in the ruby community (in fact, this is my first
piece of ruby code), I need someone to help me get things upstream (for
Net::IMAP in the first place, but someone maintaining ruby-gss would be great).
As for the sup patch, I think this already is the right place to post it ;-).
Short installation instructions for those not so familiar with ruby:
$ cd ruby-gss
$ ruby extconf.rb
$ make
$ sudo make install
# patch /usr/lib/ruby/1.8/net/imap.rb
# patch /usr/lib/ruby/1.8/sup/imap.rb
Best regards,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 01-sup_gssapi.patch
Type: application/octet-stream
Size: 1936 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090720/9d9a88ec/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 02-net_imap_gssapi.patch
Type: application/octet-stream
Size: 2373 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090720/9d9a88ec/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 03-ruby-gss.patch
Type: application/octet-stream
Size: 2891 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090720/9d9a88ec/attachment-0005.obj>
------------------------------
Message: 557
Date: Wed, 22 Jul 2009 21:10:41 -0400
From: Steve Goldman <sgoldman@tower-research.com>
To: Sup Talk List <sup-talk@rubyforge.org>
Subject: [sup-talk] Choose "From:" address based on message content?
Message-ID: <1248311332-sup-1053@sgoldmanlinux.tower-research.com>
Content-Type: text/plain; charset=UTF-8
Here's what I want:
After I compose an email (new or a reply), I want sup to grep the
entire message (recipients, subject, body, etc.) for a single word and
choose address A if that word is there and address B otherwise.
Can sup do it?
Thanks.
--
Steve Goldman
sgoldman@tower-research.com
T: 212.219.6014
F: 212.219.6007
Tower Research Capital, LLC
377 Broadway, 11th Fl.
New York, NY 10013
------------------------------
Message: 558
Date: Wed, 22 Jul 2009 22:51:54 -0400
From: Steve Goldman <sgoldman@tower-research.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Choose "From:" address based on message
content?
Message-ID: <1248317360-sup-4094@sgoldmanlinux.tower-research.com>
Content-Type: text/plain; charset=UTF-8
Excerpts from Steve Goldman's message of Wed Jul 22 21:10:41 -0400 2009:
>
> Here's what I want:
>
> After I compose an email (new or a reply), I want sup to grep the
> entire message (recipients, subject, body, etc.) for a single word and
> choose address A if that word is there and address B otherwise.
>
> Can sup do it?
>
> Thanks.
>
I think I answered my own question.
I added an "after-edit" hook call in edit-message-mode.rb and wrote a
hook that looks like this:
require 'eregex'
r = Regexp.new('word', Regexp::IGNORECASE);
if header.to_s.grep(r).size > 0 or body.to_s.grep(r).size > 0
header["From"] = "Steve Goldman <sgoldman@other-address.com>"
end
--
Steve Goldman
sgoldman@tower-research.com
T: 212.219.6014
F: 212.219.6007
Tower Research Capital, LLC
377 Broadway, 11th Fl.
New York, NY 10013
------------------------------
Message: 559
Date: Thu, 23 Jul 2009 11:35:43 +0200
From: Adeodato Sim? <dato@net.com.org.es>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] [PATCH] mime-decode hook: provide a "charset"
variable with the attachment charset
Message-ID: <20090723093543.GA2265@chistera.yi.org>
Content-Type: text/plain; charset=utf-8
+ Adeodato Sim? (Fri, 10 Jul 2009 17:00:29 +0200):
> + :charset => encoded_content.charset,
Hm, so apparently encoded_content doesn't always have a charset
member...
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
------------------------------
Message: 560
Date: Thu, 23 Jul 2009 12:23:25 +0200
From: Adeodato Sim? <dato@net.com.org.es>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] [PATCH 0/18] Xapian-based index
Message-ID: <20090723102325.GA4291@chistera.yi.org>
Content-Type: text/plain; charset=us-ascii
+ Richard Heycock (Sat, 18 Jul 2009 09:42:07 +1000):
> I've been meaning to respond to this the day this was posted. Rich Lane
> thank you, thank you. Ferret was one of by biggest gripes of using sup.
> I've used it elsewhere and it's a shocker; I eventually migrated it all
> to Xapian which has worked flawlessly since. I used to rebuild by ferret
> index almost on a weekly basis (I'm running debian unstable, which at
> the moment is really living up to it's name) at one stage something I
> haven't had to do once since migrating to Xapian.
Yeah, thanks Rich! However, there seems to be something wrong with the
parsing of contacts. After reindexing with Xapian, my contact list has
entries like:
<dato <dato@net.com.org.esadeodato
<other <other@foo.ua.esfoo
dato@net.com.org.esAdeodato Simo other2@domain.netother2 surname2
Plus, nor '!label:inbox' or '-label:inbox' work for me. From an
inspection of the code, it doesn't look to me as random negated labels
are being parsed.
Any hints?
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
------------------------------
Message: 561
Date: Thu, 23 Jul 2009 19:12:58 +0200
From: Adeodato Sim? <dato@net.com.org.es>
To: sup-talk@rubyforge.org
Cc: Adeodato Sim? <dato@net.com.org.es>
Subject: [sup-talk] [RFC] Fix parsing of encrypted messages that
contain further multipart elements
Message-ID:
<ff7df0405d003a8f4e88f0dd191d8bf4875f73f3.1248368899.git.dato@net.com.org.es>
---
Hello,
this is just a RFC, because I can't think of any elegant way to address
the issue, given the shortcomings of the RMail API. Please read the
lengthy comment in the patch, and let me know if anybody has any ideas
about this issue.
P.S.: I've created a "sup-dato" repository in Gitorious, in case that's
helpful. Should I be creating merge requests?
lib/sup/crypto.rb | 19 ++++++++++++++++++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/lib/sup/crypto.rb b/lib/sup/crypto.rb
index 8ec277b..6ef0c0e 100644
--- a/lib/sup/crypto.rb
+++ b/lib/sup/crypto.rb
@@ -132,8 +132,25 @@ class CryptoManager
end
end
+ # This is gross. The decrypted payload could very well be a multipart
+ # element itself, as opposed to a simple payload; for example, a
+ # multipart/signed element, like Mutt does when encrypting and signing a
+ # message (instead of clearsigning it). Supposedly, decrypted_payload
+ # being a multipart element ought to work out nicely because in
+ # Message::multipart_encrypted_to_chunks() the decrypted message is run
+ # though message_to_chunks() again to get any children. However, it does
+ # not work as intended because this inner payload need not carry a
+ # MIME-Version header, yet they are fed to RMail as a top-level message,
+ # for which the MIME-Version header is required, which causes for the
+ # part not to be detected as multipart. If we detect this is happening,
+ # force the payload to be interpreted as MIME.
+ msg = RMail::Parser.read(decrypted_payload)
+ if msg.header.content_type =~ %r{^multipart/} and not msg.multipart?
+ decrypted_payload = "MIME-Version: 1.0\n" + decrypted_payload
+ msg = RMail::Parser.read(decrypted_payload)
+ end
notice = Chunk::CryptoNotice.new :valid, "This message has been decrypted for display"
- [RMail::Parser.read(decrypted_payload), sig, notice]
+ [msg, sig, notice]
else
notice = Chunk::CryptoNotice.new :invalid, "This message could not be decrypted", output.split("\n")
[nil, nil, notice]
--
1.6.3.3
------------------------------
Message: 562
Date: Thu, 23 Jul 2009 19:19:51 +0200
From: Adeodato Sim? <dato@net.com.org.es>
To: sup-talk@rubyforge.org
Cc: Adeodato Sim? <dato@net.com.org.es>
Subject: [sup-talk] [PATCH] Fix parsing of encrypted messages that
contain further multipart elements
Message-ID:
<6fd87965a2e243b190678edb6c4b9cefbde9ae66.1248369563.git.dato@net.com.org.es>
---
Amended patch follows, with a better wording that I had seemingly not
committed. Sorry for the noise.
lib/sup/crypto.rb | 20 +++++++++++++++++++-
1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/lib/sup/crypto.rb b/lib/sup/crypto.rb
index 8ec277b..acbc1d8 100644
--- a/lib/sup/crypto.rb
+++ b/lib/sup/crypto.rb
@@ -132,8 +132,26 @@ class CryptoManager
end
end
+ # This is gross. This decrypted payload could very well be a multipart
+ # element itself, as opposed to a simple payload. For example, a
+ # multipart/signed element, like those generated by Mutt when encrypting
+ # and signing a message (instead of just clearsigning the body).
+ # Supposedly, decrypted_payload being a multipart element ought to work
+ # out nicely because Message::multipart_encrypted_to_chunks() runs the
+ # decrypted message through message_to_chunks() again to get any
+ # children. However, it does not work as intended because these inner
+ # payloads need not carry a MIME-Version header, yet they are fed to
+ # RMail as a top-level message, for which the MIME-Version header is
+ # required. This causes for the part not to be detected as multipart,
+ # hence being shown as an attachment. If we detect this is happening,
+ # we force the decrypted payload to be interpreted as MIME.
+ msg = RMail::Parser.read(decrypted_payload)
+ if msg.header.content_type =~ %r{^multipart/} and not msg.multipart?
+ decrypted_payload = "MIME-Version: 1.0\n" + decrypted_payload
+ msg = RMail::Parser.read(decrypted_payload)
+ end
notice = Chunk::CryptoNotice.new :valid, "This message has been decrypted for display"
- [RMail::Parser.read(decrypted_payload), sig, notice]
+ [msg, sig, notice]
else
notice = Chunk::CryptoNotice.new :invalid, "This message could not be decrypted", output.split("\n")
[nil, nil, notice]
--
1.6.3.3
------------------------------
Message: 563
Date: Fri, 24 Jul 2009 18:35:15 +0200
From: Marc Weber <marco-oweber@gmx.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Exception
Message-ID: <1248453259-sup-3604@nixos>
Content-Type: text/plain; charset=UTF-8
Hi, when either running sup-sync or sup (without -n) I get this
exception:
--- NoMethodError from thread: poll after loading inbox
undefined method `to_indexable_s' for nil:NilClass
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/index.rb:244:in `sync_message'
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:513:in `send'
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:513:in `method_missing'
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/poll.rb:161:in `add_messages_from'
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/source.rb:100:in `each'
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:552:in `send'
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:552:in `__pass'
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:539:in `method_missing'
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/poll.rb:141:in `add_messages_from'
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/poll.rb:98:in `do_poll'
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/poll.rb:86:in `each'
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/poll.rb:86:in `do_poll'
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/poll.rb:85:in `synchronize'
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/poll.rb:85:in `do_poll'
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:513:in `send'
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:513:in `method_missing'
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/modes/poll-mode.rb:17:in `poll'
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/poll.rb:53:in `poll'
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:513:in `send'
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:513:in `method_missing'
/home/marc/.nix-profile/gems/sup-0.8.1/bin/sup:206
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup.rb:71:in `reporting_thread'
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup.rb:69:in `initialize'
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup.rb:69:in `new'
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup.rb:69:in `reporting_thread'
/home/marc/.nix-profile/gems/sup-0.8.1/bin/sup:206
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:663:in `call'
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:663:in `__unprotected_load_threads'
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:605:in `call'
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:605:in `load_n_threads_background'
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup.rb:71:in `reporting_thread'
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup.rb:69:in `initialize'
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup.rb:69:in `new'
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup.rb:69:in `reporting_thread'
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:603:in `load_n_threads_background'
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:673:in `__unprotected_load_threads'
(eval):12:in `load_threads'
/home/marc/.nix-profile/gems/sup-0.8.1/bin/sup:206
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/bin/.sup-wrapped:19:in `load'
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/bin/.sup-wrapped:19
Do you see what's happening here or shall I start debugging?
The sup-sync exception trace looks like this:
/nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/index.rb:244:in `sync_message': undefined method `to_indexable_s' for nil:NilClass (NoMethodError)
from /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:513:in `send'
from /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:513:in `method_missing'
from /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/poll.rb:161:in `add_messages_from'
from /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/source.rb:100:in `each'
from /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:552:in `send'
from /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:552:in `__pass'
from /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:539:in `method_missing'
from /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/poll.rb:141:in `add_messages_from'
from /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:513:in `send'
from /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:513:in `method_missing'
from /home/marc/.nix-profile/gems/sup-0.8.1/bin/sup-sync:140
from /home/marc/.nix-profile/gems/sup-0.8.1/bin/sup-sync:135:in `each'
from /home/marc/.nix-profile/gems/sup-0.8.1/bin/sup-sync:135
from /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/bin/.sup-sync-wrapped:19:in `load'
from /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/bin/.sup-sync-wrapped:19
Marc Weber
------------------------------
Message: 564
Date: Fri, 24 Jul 2009 19:50:54 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH] xapian: initialize sources in sup-dump
Message-ID: <1248490254-31895-1-git-send-email-rlane@club.cc.cmu.edu>
---
bin/sup-dump | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/bin/sup-dump b/bin/sup-dump
index 9b0892e..c18a767 100755
--- a/bin/sup-dump
+++ b/bin/sup-dump
@@ -22,6 +22,7 @@ EOS
end
index = Redwood::Index.new
+Redwood::SourceManager.new
index.load
index.each_message do |m|
--
1.6.0.4
------------------------------
Message: 565
Date: Fri, 24 Jul 2009 20:25:09 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH] xapian: fix mk_addrs args in build_message
Message-ID: <1248492309-1980-1-git-send-email-rlane@club.cc.cmu.edu>
---
lib/sup/xapian_index.rb | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
index d064ffc..23af431 100644
--- a/lib/sup/xapian_index.rb
+++ b/lib/sup/xapian_index.rb
@@ -68,9 +68,9 @@ class XapianIndex < BaseIndex
'date' => Time.at(entry[:date]),
'subject' => entry[:subject],
'from' => mk_addrs[[entry[:from]]],
- 'to' => mk_addrs[[entry[:to]]],
- 'cc' => mk_addrs[[entry[:cc]]],
- 'bcc' => mk_addrs[[entry[:bcc]]],
+ 'to' => mk_addrs[entry[:to]],
+ 'cc' => mk_addrs[entry[:cc]],
+ 'bcc' => mk_addrs[entry[:bcc]],
'reply-tos' => mk_refs[entry[:replytos]],
'references' => mk_refs[entry[:refs]],
}
--
1.6.0.4
------------------------------
Message: 566
Date: Sat, 25 Jul 2009 00:53:07 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: Adeodato Sim? <dato@net.com.org.es>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH 0/18] Xapian-based index
Message-ID: <1248497184-sup-939@pion.club.cc.cmu.edu>
Content-Type: text/plain; charset=UTF-8
> Yeah, thanks Rich! However, there seems to be something wrong with the
> parsing of contacts. After reindexing with Xapian, my contact list has
> entries like:
>
> <dato <dato@net.com.org.esadeodato
> <other <other@foo.ua.esfoo
> dato@net.com.org.esAdeodato Simo other2@domain.netother2 surname2
Thanks for the bug report, I've posted a patch (fix-mk_addrs-args) to
fix this. You shouldn't need to reindex after applying the patch.
> Plus, nor '!label:inbox' or '-label:inbox' work for me. From an
> inspection of the code, it doesn't look to me as random negated labels
> are being parsed.
>
> Any hints?
You need to specify a non-negated term in the query.
"type:mail -label:inbox" should work.
------------------------------
Message: 567
Date: Sat, 25 Jul 2009 11:21:16 +0200
From: Adeodato Sim? <dato@net.com.org.es>
To: Rich Lane <rlane@club.cc.cmu.edu>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH 0/18] Xapian-based index
Message-ID: <1248513425-sup-2484@chistera.yi.org>
Content-Type: text/plain; charset=UTF-8
+ Rich Lane (Sat, 25 Jul 2009 06:53:07 +0200):
> Thanks for the bug report, I've posted a patch (fix-mk_addrs-args) to
> fix this. You shouldn't need to reindex after applying the patch.
Great, thanks. The patch indeed fixes the issue.
> > Plus, nor '!label:inbox' or '-label:inbox' work for me. From an
> > inspection of the code, it doesn't look to me as random negated labels
> > are being parsed.
> > Any hints?
> You need to specify a non-negated term in the query.
> "type:mail -label:inbox" should work.
Oh, I see. Yes, that works, thanks.
One extra issue I just noticed: after dumping with ferret, reloading
into Xapian, and doing a dump again (with Xapian this time), all the
messages tagged "deleted" or "spam" do not appear in the dump at all.
Any ideas?
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
------------------------------
Message: 568
Date: Sat, 25 Jul 2009 14:10:54 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Reply calculation
Message-ID: <1248545266-sup-6886@javelin>
Content-Type: text/plain; charset=UTF-8
I think sup's "To" address calculation algorithm is wrong, and
messes up in some important edge-cases. The two edge
cases I have in mind are:
* When a mailing list sends an unsubscribe/subscribe notification
* When someone posts to a mailing list with an explicit Reply-to
header.
In both of these cases, the mail will commonly have an explicit
Reply-to header. However, Sup will by default disregard this
header in favor for List-id, which is *wrong*.
You can guess, this has bitten me several times.
I think the correct behavior is to only use List-id when Reply-to
is not explicitly set, since List-id is "magical" whereas Reply-to
is commonly explicit.
Cheers,
Edward
------------------------------
Message: 569
Date: Sat, 25 Jul 2009 14:24:15 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Reply calculation
Message-ID: <1248546228-sup-9505@javelin>
Content-Type: text/plain; charset=UTF-8
Here is a patch that changes the behavior:
>From 58a8d325286703f9057dd5d07094d0c6a061377c Mon Sep 17 00:00:00 2001
From: Edward Z. Yang <ezyang@mit.edu>
Date: Sat, 25 Jul 2009 14:17:08 -0400
Subject: [PATCH] Use Reply-to if it is explicitly set.
Previously, Sup would ignore an explicit Reply-to
in favor of List-id. This is the wrong behavior for
the following cases:
* List subscribe and unsubscribe messages will commonly
have List-id set, but set Reply-to for their own
nefarious purposes (the "you should be able to reply
to this email and have it work")
* People will sometimes send mail to a list with an
explicit Reply-to header to get responses offlist.
This brings Sup's behavior more inline with traditional
mail clients. Since most lists already set Reply-to
(and most mail clients don't respect List-id), there will
probably be no breakage.
Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
---
lib/sup/modes/reply-mode.rb | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/lib/sup/modes/reply-mode.rb b/lib/sup/modes/reply-mode.rb
index c79c5db..ca423c1 100644
--- a/lib/sup/modes/reply-mode.rb
+++ b/lib/sup/modes/reply-mode.rb
@@ -81,10 +81,8 @@ EOS
AccountManager.default_account
end
- ## now, determine to: and cc: addressess. we ignore reply-to for list
- ## messages because it's typically set to the list address, which we
- ## explicitly treat with reply type :list
- to = @m.is_list_message? ? @m.from : (@m.replyto || @m.from)
+ ## if someone overrode reply-to, it was for a good reason
+ to = (@m.replyto || @m.from)
## next, cc:
cc = (@m.to + @m.cc - [from, to]).uniq
@@ -115,7 +113,7 @@ EOS
} unless not_me_ccs.empty?
@headers[:list] = {
- "To" => [@m.list_address.full_address],
+ "To" => [@m.replyto.full_address || @m.list_address.full_address],
} if @m.is_list_message?
refs = gen_references
--
1.6.3.3
------------------------------
Message: 570
Date: Sat, 25 Jul 2009 15:03:31 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Reply calculation
Message-ID: <1248548497-sup-1158@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from Edward Z. Yang's message of Sat Jul 25 14:24:15 -0400 2009:
> Here is a patch that changes the behavior:
Actually, the patch is not quite correct. Let me think about this
some more.
Cheers,
Edward
------------------------------
Message: 571
Date: Sat, 25 Jul 2009 15:15:59 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Reply calculation
Message-ID: <1248549271-sup-3371@javelin>
Content-Type: text/plain; charset=UTF-8
After thinking about this some, I think that the only way
to reasonably handle all corner cases is to explicitly ask
the user for a choice in corner cases. Having the default
subtly change based on some non-obvious attributes of an
email is a great way to break muscle memory.
Myself, I have :user in my reply-to.rb hook for now.
Cheers,
Edward
------------------------------
Message: 572
Date: Sat, 25 Jul 2009 12:27:08 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH] xapian: dont exclude spam/etc in some
internal searches
Message-ID: <1248550028-9703-1-git-send-email-rlane@club.cc.cmu.edu>
---
bin/sup-dump | 2 +-
bin/sup-sync | 2 +-
bin/sup-sync-back | 2 +-
bin/sup-tweak-labels | 1 +
4 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/bin/sup-dump b/bin/sup-dump
index c18a767..ba36b21 100755
--- a/bin/sup-dump
+++ b/bin/sup-dump
@@ -25,6 +25,6 @@ index = Redwood::Index.new
Redwood::SourceManager.new
index.load
-index.each_message do |m|
+index.each_message :load_spam => true, :load_deleted => true, :load_killed => true do |m|
puts "#{m.id} (#{m.labels * ' '})"
end
diff --git a/bin/sup-sync b/bin/sup-sync
index 270524a..8e37c74 100755
--- a/bin/sup-sync
+++ b/bin/sup-sync
@@ -213,7 +213,7 @@ begin
num_del, num_scanned = 0, 0
sources.each do |source|
raise "no source id for #{source}" unless source.id
- index.each_message :source_id => source.id do |m|
+ index.each_message :source_id => source.id, :load_spam => true, :load_deleted => true, :load_killed => true do |m|
num_scanned += 1
unless seen[m.id]
next unless m.source_info >= opts[:start_at] if opts[:start_at]
diff --git a/bin/sup-sync-back b/bin/sup-sync-back
index da94bbd..56ac4eb 100755
--- a/bin/sup-sync-back
+++ b/bin/sup-sync-back
@@ -16,7 +16,7 @@ def die msg
exit(-1)
end
def has_any_from_source_with_label? index, source, label
- query = { :source_id => source.id, :label => label, :limit => 1 }
+ query = { :source_id => source.id, :label => label, :limit => 1, :load_spam => true, :load_deleted => true, :load_killed => true }
not Enumerable::Enumerator.new(index, :each_id, query).map.empty?
end
diff --git a/bin/sup-tweak-labels b/bin/sup-tweak-labels
index a8115ea..8ae5c26 100755
--- a/bin/sup-tweak-labels
+++ b/bin/sup-tweak-labels
@@ -83,6 +83,7 @@ begin
query += ' ' + opts[:query] if opts[:query]
parsed_query = index.parse_query query
+ parsed_query.merge! :load_spam => true, :load_deleted => true, :load_killed => true
ids = Enumerable::Enumerator.new(index, :each_id, parsed_query).map
num_total = ids.size
--
1.6.0.4
------------------------------
Message: 573
Date: Sat, 25 Jul 2009 15:59:19 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: Adeodato Sim? <dato@net.com.org.es>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH 0/18] Xapian-based index
Message-ID: <1248550384-sup-74@pion.club.cc.cmu.edu>
Content-Type: text/plain; charset=UTF-8
Excerpts from Adeodato Sim?'s message of Sat Jul 25 05:21:16 -0400 2009:
> One extra issue I just noticed: after dumping with ferret, reloading
> into Xapian, and doing a dump again (with Xapian this time), all the
> messages tagged "deleted" or "spam" do not appear in the dump at all.
> Any ideas?
The patch "xapian: dont exclude spam..." should fix this.
One issue I've noticed is that removing labels from messages doesn't
always immediately work. For example, label-list-mode shows a label as
having some unread messages even though all of them are actually read.
This tends to happen only after sup's been running for a while and
restarting sup fixes it.
------------------------------
Message: 574
Date: Sun, 26 Jul 2009 01:28:16 +0200
From: Ingmar Vanhassel <ingmar@exherbo.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH 0/18] Xapian-based index
Message-ID: <1248564412-sup-7548@cannonball>
Content-Type: text/plain; charset=UTF-8
Excerpts from Rich Lane's message of Sat Jul 25 21:59:19 +0200 2009:
> One issue I've noticed is that removing labels from messages doesn't
> always immediately work. For example, label-list-mode shows a label as
> having some unread messages even though all of them are actually read.
> This tends to happen only after sup's been running for a while and
> restarting sup fixes it.
I was just about to report that. :)
Besides that, the Xapian index works very nicely. So I'd be happy to see
it in next when that last regression (as far as my testing showed them) is fixed!
--
Exherbo KDE, X.org maintainer
------------------------------
Message: 575
Date: Mon, 27 Jul 2009 08:46:21 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH 0/18] Xapian-based index
Message-ID: <1248709366-sup-5856@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Rich Lane's message of 2009-07-24:
> > Plus, nor '!label:inbox' or '-label:inbox' work for me. From an
> > inspection of the code, it doesn't look to me as random negated
> > labels are being parsed.
> >
> > Any hints?
>
> You need to specify a non-negated term in the query. "type:mail
> -label:inbox" should work.
This is a typical restriction for inverted index-based search engines.
You need to have at least one positive term or the computation is too
expensive (it would have to iterate over every term ever seen.) It's
true of Ferret, Google, etc.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 576
Date: Mon, 27 Jul 2009 08:48:38 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH 0/18] Xapian-based index
Message-ID: <1248709681-sup-4141@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Rich Lane's message of 2009-07-25:
> One issue I've noticed is that removing labels from messages doesn't
> always immediately work.
Is this true even after you sync changes to the index? What about if you
reload the label list buffer? ('@')
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 577
Date: Mon, 27 Jul 2009 09:13:16 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk mailing list <sup-talk@rubyforge.org>
Subject: [sup-talk] xapian merged into next
Message-ID: <1248711109-sup-7061@entry>
Content-Type: text/plain; charset=UTF-8
I've merged the xapian branch into next. Users of next need not worry;
xapian only enabled when you set the environment variable
SUP_INDEX=xapian. (And you'll have to regenerate your index; see my
message of a few weeks ago for how.)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 578
Date: Mon, 27 Jul 2009 09:16:43 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] xapian: dont exclude spam/etc in some
internal searches
Message-ID: <1248711395-sup-5867@entry>
Content-Type: text/plain; charset=UTF-8
Applied, thanks.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 579
Date: Mon, 27 Jul 2009 09:17:00 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] xapian: fix mk_addrs args in
build_message
Message-ID: <1248711412-sup-674@entry>
Content-Type: text/plain; charset=UTF-8
Applied, thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 580
Date: Mon, 27 Jul 2009 09:17:14 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] xapian: initialize sources in sup-dump
Message-ID: <1248711426-sup-1184@entry>
Content-Type: text/plain; charset=UTF-8
Aaaand applied. Thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 581
Date: Mon, 27 Jul 2009 09:22:48 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Unbreak "bounce-command" hook (was
referencing an nonexistent variable)
Message-ID: <1248711741-sup-3733@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Walton's message of 2009-07-11:
> +1 for this. Not sure how I managed to submit the original patch like
> this, since I did test various forms of results returned from the
> bounce-command hook...anyway, I've applied this and verified it.
I don't see this in your bw/bounce_message branch. I'd like to remerge
that.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 582
Date: Mon, 27 Jul 2009 18:16:50 +0200
From: Guillaume Quintard <guillaume.quintard@gmail.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk mailing list <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] xapian merged into next
Message-ID:
<1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Mon, Jul 27, 2009 at 6:13 PM, William Morgan<wmorgan-sup@masanjin.net> wrote:
> I've merged the xapian branch into next. Users of next need not worry;
> xapian only enabled when you set the environment variable
> SUP_INDEX=xapian. (And you'll have to regenerate your index; see my
> message of a few weeks ago for how.)
The big question is: is it interesting, as a user, to switch? :-)
--
Guillaume
------------------------------
Message: 583
Date: Mon, 27 Jul 2009 12:25:52 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Unbreak "bounce-command" hook (was
referencing an nonexistent variable)
Message-ID: <1248711899-sup-4693@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Mon Jul 27 12:22:48 -0400 2009:
> I don't see this in your bw/bounce_message branch. I'd like to remerge
> that.
Sorry. I didn't publish the change, I thought it would be `git am`'d
from the original mail. I applied it to my local running copy of next
though, which is what I was referring to. I'll try to remember to
push things like this in the future.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090727/85a7f7a7/attachment-0001.bin>
------------------------------
Message: 584
Date: Mon, 27 Jul 2009 09:27:42 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk mailing list <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] xapian merged into next
Message-ID: <1248711777-sup-9329@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Guillaume Quintard's message of 2009-07-27:
> The big question is: is it interesting, as a user, to switch? :-)
Yes. It's noticeably faster than Ferret, especially for loading large
threads in thread-index-mode. (Which isn't Xapian per se, but other
improvements Rich has made).
It's also much larger on disk, though there might be a way to trim that
down.
At some point I want to deprecate Ferret, since it's unmaintained, so
you'll be forced to switch. No timeline on that though.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 585
Date: Mon, 27 Jul 2009 09:29:20 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Unbreak "bounce-command" hook (was
referencing an nonexistent variable)
Message-ID: <1248712076-sup-7189@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Walton's message of 2009-07-27:
> Sorry. I didn't publish the change, I thought it would be `git am`'d
> from the original mail.
No problem. We can do it either way. I'll apply this patch directly.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 586
Date: Mon, 27 Jul 2009 12:30:20 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Unbreak "bounce-command" hook (was
referencing an nonexistent variable)
Message-ID: <1248712092-sup-5843@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Ben Walton's message of Mon Jul 27 12:25:52 -0400 2009:
> Sorry. I didn't publish the change, I thought it would be `git am`'d
> from the original mail. I applied it to my local running copy of next
> though, which is what I was referring to. I'll try to remember to
> push things like this in the future.
I've now `git am`'d and pushed on my development copy to
git://code.chass.utoronto.ca/bwalton-sup.git. You should be able to
remerge the bw/bounce_message branch and get Adeodato's fix.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090727/eb249faf/attachment-0001.bin>
------------------------------
Message: 587
Date: Mon, 27 Jul 2009 09:30:50 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Unbreak "bounce-command" hook (was
referencing an nonexistent variable)
Message-ID: <1248712242-sup-2953@entry>
Content-Type: text/plain; charset=UTF-8
Applied, thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 588
Date: Mon, 27 Jul 2009 18:31:46 +0200
From: Guillaume Quintard <guillaume.quintard@gmail.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk mailing list <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] xapian merged into next
Message-ID:
<1e5fdab70907270931t7dfbe285h67197a7355b611d6@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Mon, Jul 27, 2009 at 6:27 PM, William Morgan<wmorgan-sup@masanjin.net> wrote:
> Yes. It's noticeably faster than Ferret, especially for loading large
> threads in thread-index-mode. (Which isn't Xapian per se, but other
> improvements Rich has made).
Yummy!
> It's also much larger on disk, though there might be a way to trim that
> down.
Less yummy!
So, we just export SUP_INDEX=xapian and that's it? We start with an
empty sup and we just have to reimport the mbox/maildir/whatever?
Means losing the red states and tags, I guess.
--
Guillaume
------------------------------
Message: 589
Date: Mon, 27 Jul 2009 09:41:05 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Exception
Message-ID: <1248712764-sup-736@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Marc Weber's message of 2009-07-24:
> Hi, when either running sup-sync or sup (without -n) I get this
> exception:
>
> --- NoMethodError from thread: poll after loading inbox
> undefined method `to_indexable_s' for nil:NilClass
Weird. It looks like a date parsing issue, but I'm having a hard time
seeing where the logic fails such that no date field is set.
Can you try applying the following patch, and then running sup-sync with
-v? I'm hoping that the debugging output prefixed with XX will provide a
clue.
Thanks!
--- a/lib/sup/message.rb
+++ b/lib/sup/message.rb
@@ -92,11 +92,14 @@ class Message
begin
Time.parse date
rescue ArgumentError => e
- #Redwood::log "faking mangled date header for #{@id} (orig #{header['da
+ Redwood::log "faking mangled date header for #{@id} (orig #{header['dat
Time.now
end
- else
- #Redwood::log "faking non-existent date header for #{@id}"
+ end
+
+ @date ||= begin
+ Redwood::log "XX original header was #{header["date"].inspect}"
+ Redwood::log "XX faking non-existent date header for #{@id}"
Time.now
end
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 590
Date: Mon, 27 Jul 2009 09:44:54 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk mailing list <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] xapian merged into next
Message-ID: <1248712876-sup-1446@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Guillaume Quintard's message of 2009-07-27:
> So, we just export SUP_INDEX=xapian and that's it? We start with an
> empty sup and we just have to reimport the mbox/maildir/whatever?
> Means losing the red states and tags, I guess.
Current instructions:
1. install the ruby xapian library and the ruby gdbm library, if you
don't have them. These are packaged by your distro, and are not gems.
2. git checkout next
3. git pull
4. cp ~/.sup/sources.yaml /tmp # just in case
5. ruby -Ilib bin/sup-dump > dumpfile
6. SUP_INDEX=xapian ruby -Ilib bin/sup-sync --all --all-sources --restore dumpfile
7. SUP_INDEX=xapian ruby -Ilib bin/sup -o
8. Oooh, fast.
This should not disturb your Ferret index, so you can switch back and forth
between the two. (Message state, of course, is not shared.) However, adding new
messages to one index will prevent it from being automatically added to the
other, so I recommend running in Xapian mode with -o and not pressing 'P'.
Unless, of of course, you're ready to switch permanently, in which case rm -rf
~/.sup/ferret. :)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 591
Date: Mon, 27 Jul 2009 09:45:17 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Unbreak "bounce-command" hook (was
referencing an nonexistent variable)
Message-ID: <1248713108-sup-884@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Walton's message of 2009-07-27:
> I've now `git am`'d and pushed on my development copy to
> git://code.chass.utoronto.ca/bwalton-sup.git. You should be able to
> remerge the bw/bounce_message branch and get Adeodato's fix.
Heh. :)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 592
Date: Mon, 27 Jul 2009 18:47:13 +0200
From: Guillaume Quintard <guillaume.quintard@gmail.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk mailing list <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] xapian merged into next
Message-ID:
<1e5fdab70907270947n1866decdoc8a568cc9a2733ae@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Mon, Jul 27, 2009 at 6:44 PM, William Morgan<wmorgan-sup@masanjin.net> wrote:
> Unless, of of course, you're ready to switch permanently, in which case rm -rf
> ~/.sup/ferret. :)
There's no reason not to, right?
/me is following blinding the given instructions :-)
--
Guillaume
------------------------------
Message: 593
Date: Mon, 27 Jul 2009 09:49:11 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Reply calculation
Message-ID: <1248713182-sup-172@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Edward Z. Yang's message of 2009-07-25:
> After thinking about this some, I think that the only way to
> reasonably handle all corner cases is to explicitly ask the user for a
> choice in corner cases.
What was the breakage when favoring reply-to over list-id? I was buying
your arguments...
Is it possible to identify these corner cases? Is it always when there's
a reply-to and a list-id both set?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 594
Date: Mon, 27 Jul 2009 09:50:12 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk mailing list <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] xapian merged into next
Message-ID: <1248713360-sup-5448@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Guillaume Quintard's message of 2009-07-27:
> There's no reason not to, right?
Well, the code isn't quite as well tested...
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 595
Date: Mon, 27 Jul 2009 09:51:17 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] mime-decode hook: provide a "charset"
variable with the attachment charset
Message-ID: <1248713434-sup-4961@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Adeodato Sim?'s message of 2009-07-23:
> + Adeodato Sim? (Fri, 10 Jul 2009 17:00:29 +0200):
>
> > + :charset => encoded_content.charset,
>
> Hm, so apparently encoded_content doesn't always have a charset
> member...
>
In which case that value of that variable is nil, right? Is that a
problem? The patch still seems useful.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 596
Date: Mon, 27 Jul 2009 09:52:02 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Choose "From:" address based on message
content?
Message-ID: <1248713502-sup-312@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Steve Goldman's message of 2009-07-22:
> Can sup do it?
Shit yes. These insane requests are exactly why I am favoring hooks over
configuration.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 597
Date: Mon, 27 Jul 2009 09:53:58 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Choose "From:" address based on message
content?
Message-ID: <1248713574-sup-6167@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Steve Goldman's message of 2009-07-22:
> require 'eregex'
>
> r = Regexp.new('word', Regexp::IGNORECASE);
> if header.to_s.grep(r).size > 0 or body.to_s.grep(r).size > 0
You can just use body.to_s =~ /word/i || header.join =~ /i/. No need for
all the fancy libraries and method calls.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 598
Date: Mon, 27 Jul 2009 18:55:46 +0200
From: Marc Weber <marco-oweber@gmx.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Exception
Message-ID: <1248713299-sup-9062@nixos>
Content-Type: text/plain; charset=UTF-8
You're right. I fixed it today by running sup-sync. (I was still reading
my mails that's why I didn't respond earlier).
I used p m at that location to get a message output saying something
about offset is out of sync. Then I tried sup-sync -c.
The strange thing is that I didn't open the mbox file using another
program such as mutt. Maybe a locking issue or such ? I'm using
procmail.
I was surprised how easy it was to find the cause after starting looking
into it.
Thanks for taking the time sending this patch!
Marc Weber
Excerpts from William Morgan's message of Mon Jul 27 18:41:05 +0200 2009:
> Reformatted excerpts from Marc Weber's message of 2009-07-24:
> > Hi, when either running sup-sync or sup (without -n) I get this
> > exception:
> >
> > --- NoMethodError from thread: poll after loading inbox
> > undefined method `to_indexable_s' for nil:NilClass
>
> Weird. It looks like a date parsing issue, but I'm having a hard time
> seeing where the logic fails such that no date field is set.
>
> Can you try applying the following patch, and then running sup-sync with
> -v? I'm hoping that the debugging output prefixed with XX will provide a
> clue.
>
> Thanks!
>
> --- a/lib/sup/message.rb
> +++ b/lib/sup/message.rb
> @@ -92,11 +92,14 @@ class Message
> begin
> Time.parse date
> rescue ArgumentError => e
> - #Redwood::log "faking mangled date header for #{@id} (orig #{header['da
> + Redwood::log "faking mangled date header for #{@id} (orig #{header['dat
> Time.now
> end
> - else
> - #Redwood::log "faking non-existent date header for #{@id}"
> + end
> +
> + @date ||= begin
> + Redwood::log "XX original header was #{header["date"].inspect}"
> + Redwood::log "XX faking non-existent date header for #{@id}"
> Time.now
> end
>
------------------------------
Message: 599
Date: Mon, 27 Jul 2009 18:56:28 +0200
From: Ingmar Vanhassel <ingmar@exherbo.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH 0/18] Xapian-based index
Message-ID: <1248713376-sup-5163@cannonball>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Mon Jul 27 17:48:38 +0200 2009:
> Reformatted excerpts from Rich Lane's message of 2009-07-25:
> > One issue I've noticed is that removing labels from messages doesn't
> > always immediately work.
>
> Is this true even after you sync changes to the index? What about if you
> reload the label list buffer? ('@')
It's true in both cases. Even after a sync, 'U' still produces read
messages (among unread), and a search for label:foo has threads without
that label. If you quit sup & restart it things work as expected for a
while.
I've also noticed that sup takes a long time to quit with the xapian
index. This delay happens after this message:
[Mon Jul 27 16:56:01 +0000 2009] unlocking /home/ingmar/.sup/lock...
--
Exherbo KDE, X.org maintainer
------------------------------
Message: 600
Date: Mon, 27 Jul 2009 13:06:34 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH 0/18] Xapian-based index
Message-ID: <1248710432-sup-1734@pion.club.cc.cmu.edu>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Mon Jul 27 11:48:38 -0400 2009:
> Reformatted excerpts from Rich Lane's message of 2009-07-25:
> > One issue I've noticed is that removing labels from messages doesn't
> > always immediately work.
>
> Is this true even after you sync changes to the index? What about if you
> reload the label list buffer? ('@')
Yes. This is looking like a Xapian bug - I've reproduced it without any
Sup code. I'm working on a fix.
------------------------------
Message: 601
Date: Mon, 27 Jul 2009 13:09:13 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Reply calculation
Message-ID: <1248713591-sup-8324@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Mon Jul 27 12:49:11 -0400 2009:
> What was the breakage when favoring reply-to over list-id? I was buying
> your arguments...
First and foremost, s/list-id/list-post/ in my previous posts; I was quoting
the wrong field and double checked message.rb just now.
I received mail from a mailing list as a call for applications that should
not be sent back to the list. The mail was constructed with headers like:
From: correct@example.com
To: correct@example.com
Reply-To: correct@example.com
List-Post: mailto:incorrect@example.com
Sup detects List-Post, categorizes the message as a list message, and then
sets the default reply mode as list, which results in List-Post being used
as the to address.
> Is it possible to identify these corner cases? Is it always when there's
> a reply-to and a list-id both set?
Unfortunately, mailing list administrating is notoriously broken. I'm not
sure at all what the right solution is. Take for example this other case:
From: person@example.com
To: list@example.com
Reply-To: person@example.com
List-Post: mailto:list@example.com
Reply-To, in this case, was set by the mailing list server. This makes
having Reply-To be the end-all be-all kind of spurious. If we try
to make Sup do the Right Thing (TM), you probably want to send mail to
the list as a whole, which means you do want to either "reply all" semantics
or "list post" magic. ("reply all" semantics are what you see in traditional
mail clients when you hit the "reply all" button.)
However, consider the next case:
From: persona@example.com
To: list@example.com
Cc: me@example.com
Which is when someone else hit "Reply all" and you got CC'ed. This means
that the mail never passed through the mailing list agent, the List-Post/Reply-To
headers never got set, and the only way to tell that you should reply to the
whole list is to explicitly ask for "Reply all" semantics (Sup defaults to
"Reply" semantics, which is damn confusing if you're not paying attention).
The core problem is that subtle changes in state should not require the user
to do things differently; it breaks muscle memory and makes mistakes easy.
We could try to make it so that Sup requires /no/ user intervention, but
this is seems to be an AI-hard problem. Then, the logical other direction,
is to make the interface as consistent as possible.
Cheers,
Edward
PS. Djb wrote an article along these lines:
http://cr.yp.to/proto/replyto.html
I've skimmed it but I'm kind of skeptical about client support and not sure
if it actually gives useful recommendations.
------------------------------
Message: 602
Date: Mon, 27 Jul 2009 19:09:19 +0200
From: Guillaume Quintard <guillaume.quintard@gmail.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk mailing list <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] xapian merged into next
Message-ID:
<1e5fdab70907271009v46639384w4bb3461ccaccf0cc@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Mon, Jul 27, 2009 at 6:50 PM, William Morgan<wmorgan-sup@masanjin.net> wrote:
> Well, the code isn't quite as well tested...
Someone has to do it, plus I still have my mbox archive...
...and I was getting tired of this mostly bugless mail experience.
--
Guillaume
------------------------------
Message: 603
Date: Mon, 27 Jul 2009 13:13:01 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Odd key bug
Message-ID: <1248714653-sup-6926@javelin>
Content-Type: text/plain; charset=UTF-8
After I finish editing a message and exit out of my editor (vim),
if I try to press up arrow in order to move my focus to the
reply mode field to toggle it, I get the errors:
unknown keypress '^[' for compose-mode
unknown keypress 'A' for compose-mode
It then works properly. A guess is something is messing with the
terminal? This is 100% reproduceable.
Cheers,
Edward
------------------------------
Message: 604
Date: Mon, 27 Jul 2009 10:16:02 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup 0.8.1 crash
Message-ID: <1248714912-sup-9402@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Jonathan Lassoff's message of 2009-07-07:
> I took a little time to poke around in the sup source to try and get
> an idea what was going on. I'm led to believe this is because I added
> a source in the past that I later deleted -- but all of the mesages
> are still in the index.
That would do it!
> So, when certain searches turn up results that are in that deleted
> source, the sup index fails to reference the message source in
> Redwood::Index. Is there a way to delete a source without having to
> re-index everything?
Yes, using devel/console.sh. Are you running master or next? (Or a
release?) Details differ depending.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 605
Date: Mon, 27 Jul 2009 10:19:14 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Use /etc/mailname if present to
determine the hostname for Message-Id
Message-ID: <1248715131-sup-8076@entry>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Adeodato Sim?'s message of 2009-07-09:
> on many systems (notably Debian-based systems), the /etc/mailname file
> can be created to specify the public mail name for a host. If that
> file exists, it'd be good to use its contents for generating the
> Message-Id header.
Excellent idea. Applied directly to master. Thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 606
Date: Mon, 27 Jul 2009 10:24:09 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Validating GPG keys in parallel and in
background
Message-ID: <1248715421-sup-9481@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Michael Stapelberg's message of 2009-07-10:
> it seems like sup is blocking during the validation of GPG
> signed/encrypted mails. While for encryption it makes some sense to
> block, for signed mails it would be better to just display the message
> and add the information about the signature status later. The same
> approach could be used for encrypted messages: Display "decrypting..."
> and update it when done.
I agree. This would be great.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 607
Date: Mon, 27 Jul 2009 10:25:36 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Adding/saving multiple attachments?
Message-ID: <1248715516-sup-4466@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Michael Stapelberg's message of 2009-07-11:
> I?ve had the same problem with mutt: Isn?t there a way to add or save
> multiple attachments? Why can?t I add ~/work/foo/* when pressing 'a'?
> Why doesn?t the file browser save the last directory I?ve been in?
> Can we please get a binding to save all attachments of a message into
> a folder?
All excellent ideas. I too am annoyed when I have more than one
attachment to save.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 608
Date: Mon, 27 Jul 2009 10:26:06 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Invalid character on import
Message-ID: <1248715552-sup-271@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Nicolas Pouillard's message of 2009-07-13:
> The fix is trivial, I've submitted a merge request for exactly this:
>
> http://gitorious.org/~ertai/sup/clone-by-ertai
This has been applied to master. Thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 609
Date: Mon, 27 Jul 2009 10:31:09 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] GSSAPI support for net/imap.rb and sup
Message-ID: <1248715761-sup-5112@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Michael Stapelberg's message of 2009-07-20:
> As I?m not very much involved in the ruby community (in fact, this is
> my first piece of ruby code), I need someone to help me get things
> upstream (for Net::IMAP in the first place, but someone maintaining
> ruby-gss would be great).
I don't have much advice for you other than find the guy who maintains
Net::IMAP, beating him on the head a few times for me, and send him the
patch. I believe net/imap is part of core ruby, which means you can
probably just take this to the ruby-core mailing list.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 610
Date: Mon, 27 Jul 2009 10:33:57 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Odd key bug
Message-ID: <1248715911-sup-4656@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Edward Z. Yang's message of 2009-07-27:
> It then works properly. A guess is something is messing with the
> terminal? This is 100% reproduceable.
This happens to me too. Maybe there's some more curses weirdness that
needs to happen when shelling out---you can see the current magic spell
at buffer.rb circa line 724, in BufferManager#shell_out. I've just
suffered through it for the past three years.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 611
Date: Mon, 27 Jul 2009 10:34:59 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk mailing list <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] xapian merged into next
Message-ID: <1248716073-sup-7443@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Guillaume Quintard's message of 2009-07-27:
> Someone has to do it, plus I still have my mbox archive...
> ...and I was getting tired of this mostly bugless mail experience.
Ok, you're the official guinea pig then. :)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 612
Date: Mon, 27 Jul 2009 13:36:10 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Odd bug with lazy-loaded messages
Message-ID: <1248716007-sup-5156@javelin>
Content-Type: text/plain; charset=UTF-8
I've been experiencing an odd bug with the following patch
for lazy loading messages:
--- a/lib/sup/modes/thread-index-mode.rb
+++ b/lib/sup/modes/thread-index-mode.rb
@@ -103,7 +103,6 @@ EOS
t.each_with_index do |(m, *o), i|
next unless m
BufferManager.say "#{message} (#{i}/#{num})", sid if t.size > 1
- m.load_from_source!
end
end
Specifically, the "default" opened message when I open a thread
gets a weird misrendering of the headers that looks like:
To: foo
foo <foo@example.com>
foo
And so forth, for all lines in To and Cc.
Any ideas what could be causing this? I checked load_from_source! in message.rb
but didn't see anything obvious that would prevent this behavior.
Cheers,
Edward
------------------------------
Message: 613
Date: Mon, 27 Jul 2009 13:39:27 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] [PATCH] Make logging less chatty
Message-ID: <1248716313-sup-1608@javelin>
Content-Type: text/plain; charset=UTF-8
Sup currently generates a lot of logging spew during initial startup
when it is threading. This makes it difficult to see other log
messages that are more interesting. I propose we turn these messages
off.
>From 1fc4107013a991f24a62dad54509913bb1270d5d Mon Sep 17 00:00:00 2001
From: Edward Z. Yang <ezyang@mit.edu>
Date: Sat, 25 Jul 2009 14:16:40 -0400
Subject: [PATCH] Make logging less chatty.
Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
---
lib/sup/index.rb | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/sup/index.rb b/lib/sup/index.rb
index 9c985d9..fa33baa 100644
--- a/lib/sup/index.rb
+++ b/lib/sup/index.rb
@@ -394,10 +394,10 @@ EOS
end
if killed
- Redwood::log "thread for #{m.id} is killed, ignoring"
+ #Redwood::log "thread for #{m.id} is killed, ignoring"
false
else
- Redwood::log "ran #{num_queries} queries to build thread of #{messages.size} messages for #{m.id}: #{m.subj}" if num_queries > 0
+ #Redwood::log "ran #{num_queries} queries to build thread of #{messages.size} messages for #{m.id}: #{m.subj}" if num_queries > 0
messages.each { |mid, builder| yield mid, builder }
true
end
--
1.6.3.3
------------------------------
Message: 614
Date: Mon, 27 Jul 2009 13:40:48 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] before-search hook
Message-ID: <1248716405-sup-6097@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from Edward Z. Yang's message of Fri Jun 26 13:10:01 -0400 2009:
> Done.
What's the status on getting this patch into the tree?
Cheers,
Edward
------------------------------
Message: 615
Date: Mon, 27 Jul 2009 13:27:33 -0400
From: Alex Vandiver <alex@chmrr.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Odd key bug
Message-ID: <1248715577-sup-4766@utwig>
Content-Type: text/plain; charset=UTF-8
At Mon Jul 27 13:13:01 -0400 2009, Edward Z. Yang wrote:
> After I finish editing a message and exit out of my editor (vim),
> if I try to press up arrow in order to move my focus to the
> reply mode field to toggle it, I get the errors:
>
> unknown keypress '^[' for compose-mode
> unknown keypress 'A' for compose-mode
>
> It then works properly. A guess is something is messing with the
> terminal? This is 100% reproduceable.
As another data point, I also see this, with emacs as my editor.
- Alex
--
Networking -- only one letter away from not working
------------------------------
Message: 616
Date: Mon, 27 Jul 2009 10:45:32 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk mailing list <sup-talk@rubyforge.org>
Subject: [sup-talk] xapian question
Message-ID: <1248716325-sup-7534@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Hey, I finally get to ask a question!
One of the mildly irritating things about Ferret was that it was
impossible to update the labels of a message without updating the entire
entry, i.e. including the body. So updating the labels of a message and
saving that to disk required either re-loading the body from the source,
or keeping the body explicitly in the index so that it could be loaded
without going back to the source.
The latter approach is used by the current Ferret index implementation,
since it's significantly faster (especially for slow sources like IMAP
servers), but at the cost of a lot of disk space.
My understanding of Xapian is that this is also the case, since fields
are essentially represented as prefixed terms, and so you're basically
updating a big blog, but I wanted to confirm this. I ask because the
entries.db file is very big. :)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 617
Date: Mon, 27 Jul 2009 13:48:05 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Make logging less chatty
Message-ID: <1248716783-sup-6509@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Edward Z. Yang's message of Mon Jul 27 13:39:27 -0400 2009:
> Sup currently generates a lot of logging spew during initial startup
> when it is threading. This makes it difficult to see other log
> messages that are more interesting. I propose we turn these messages
> off.
+1 for the idea, but wouldn't a command line verbosity toggle be a
better way to do this? Maybe an arg that accepts a numeric value and
then debug statements of type foo if $val > bar?
Makes debugging this stuff easier, but the output is still optional
and presumably below the default threshold.
Just a thought.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090727/60963ec8/attachment-0001.bin>
------------------------------
Message: 618
Date: Mon, 27 Jul 2009 13:52:02 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Odd key bug
Message-ID: <1248717027-sup-9556@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Alex Vandiver's message of Mon Jul 27 13:27:33 -0400 2009:
> As another data point, I also see this, with emacs as my editor.
And I saw it with vim until I switched to emacs a few months back. I
wonder if this is anything to do with how these curses apps interact
with the 'alternate' screen buffer or something? For the record, I've
always run sup inside of screen...
I've just been suffering through it too. Edward, you've given voice
to this insidious little annoyance! :)
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090727/580ec624/attachment-0001.bin>
------------------------------
Message: 619
Date: Mon, 27 Jul 2009 14:13:12 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Odd key bug
Message-ID: <1248718344-sup-1931@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Mon Jul 27 13:33:57 -0400 2009:
> This happens to me too. Maybe there's some more curses weirdness that
> needs to happen when shelling out---you can see the current magic spell
> at buffer.rb circa line 724, in BufferManager#shell_out. I've just
> suffered through it for the past three years.
I tried cargo culting a few extra function calls from the web, to no
avail. Man, where's an ncurses expert when you need them...
Cheers,
Edward
------------------------------
Message: 620
Date: Mon, 27 Jul 2009 14:30:46 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Odd key bug
Message-ID: <1248719342-sup-9126@javelin>
Content-Type: text/plain; charset=UTF-8
I currently suspect that if I send a null character to the stdscr
(which would require bin/sup to be rewritten a little to make stdscr
globally available) it would serve as a decent workaround. I don't
actually know how global variables work in Ruby.
(Basically, add stdscr.keypad(0) when we return from the external shell.)
Cheers,
Edward
------------------------------
Message: 621
Date: Mon, 27 Jul 2009 21:47:00 +0300
From: Tarko Tikan <tarko@lanparty.ee>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Odd key bug
Message-ID: <1248720085-sup-7444@valgus>
Content-Type: text/plain; charset=ISO-8859-15
hey,
> After I finish editing a message and exit out of my editor (vim),
> if I try to press up arrow in order to move my focus to the
> reply mode field to toggle it, I get the errors:
Running sup in screen and seeing it aswell.
As the discussion goes around external editor (and problems switching to and back), I want to throw up an question/idea.
Currently, as the external editor is run, there is no way to switch between sup and external editor (for obvious reasons). Is anyone aware of any better idea how to integrate vim (even better, any editor) into sup and still have the excellent buffer system. Currently, going between received emails, and the one being composed, is a real pain.
Inventing own editor is ofc one solution but it sounds silly to do it from scratch.
--
tarko
------------------------------
Message: 622
Date: Mon, 27 Jul 2009 15:15:27 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Odd key bug
Message-ID: <1248721402-sup-3517@javelin>
Content-Type: text/plain; charset=UTF-8
Alex Vandiver points out that stdscr is a member variable of Ncurses.
As such, this patch appears to fix the issue.
However, my rationale in my previous message was completely bogus (I
checked the manpage and keypad does NOT send a null key); thus,
I have no fucking clue why this works. Perhaps forcibly setting this
setting clears some internal buffer. Either 1 or 0 works, we probably
want 1 since that's what bin/sup sets.
Yay cargo culting! Whoo!
>From 61696b6a097a949545db52b4a537d74f8256d807 Mon Sep 17 00:00:00 2001
From: Edward Z. Yang <ezyang@mit.edu>
Date: Mon, 27 Jul 2009 15:03:58 -0400
Subject: [PATCH] Fix broken arrow keypresses after shelling out.
Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
---
lib/sup/buffer.rb | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/lib/sup/buffer.rb b/lib/sup/buffer.rb
index 8eedf96..5f52d1d 100644
--- a/lib/sup/buffer.rb
+++ b/lib/sup/buffer.rb
@@ -723,6 +723,7 @@ EOS
Ncurses.sync do
Ncurses.endwin
system command
+ Ncurses.stdscr.keypad 1
Ncurses.refresh
Ncurses.curs_set 0
end
--
1.6.3.3
------------------------------
Message: 623
Date: Mon, 27 Jul 2009 12:40:05 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] before-search hook
Message-ID: <1248717965-sup-1834@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Edward Z. Yang's message of 2009-07-27:
> What's the status on getting this patch into the tree?
Thanks for the ping. I've put this on branch custom-search-hook and
merged into next. Note that it only applies to Ferret for now. Now that
we've split into two indexes, we need to plan out how this hook is going
to work going forward, since different indexes have different query
languages. Probably the best option is to have the index type be passed
as an argument, and let the user special-case on that.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 624
Date: Mon, 27 Jul 2009 22:04:58 +0200
From: Guillaume Quintard <guillaume.quintard@gmail.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk mailing list <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] xapian merged into next
Message-ID:
<1e5fdab70907271304xcc52d55pb745cb85d258fdc4@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Mon, Jul 27, 2009 at 6:44 PM, William Morgan<wmorgan-sup@masanjin.net> wrote:
all went well until:
> 5. ruby -Ilib bin/sup-dump > dumpfile
-> produces a empty file (not sure it's normal)
> 6. SUP_INDEX=xapian ruby -Ilib bin/sup-sync --all --all-sources --restore dumpfile
-> error
[Mon Jul 27 22:01:35 +0200 2009] using character set encoding "UTF-8"
./lib/sup/xapian_index.rb:17:in `at': bignum too big to convert into
`long' (RangeError)
from ./lib/sup/xapian_index.rb:17
from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `require'
from ./lib/sup/index.rb:217
from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `require'
from ./lib/sup.rb:269
from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `require'
from bin/sup-sync:6
l17 of xapian_index.rb is MAX_DATE = Time.at(2**31)
--
Guillaume
------------------------------
Message: 625
Date: Mon, 27 Jul 2009 13:11:53 -0700
From: Andrew Pimlott <andrew@pimlott.net>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Odd key bug
Message-ID: <20090727201153.GI14010@pimlott.net>
Content-Type: text/plain; charset=us-ascii
On Mon, Jul 27, 2009 at 09:47:00PM +0300, Tarko Tikan wrote:
> Currently, as the external editor is run, there is no way to switch between sup and external editor (for obvious reasons). Is anyone aware of any better idea how to integrate vim (even better, any editor) into sup and still have the excellent buffer system.
My idea is to make sup act like a shell and implement job control, so
when you ctrl-z out of your editor, you're back in sup. You can have
multiple editors stopped in the background, and resume any of them at
any point.
Andrew
------------------------------
Message: 626
Date: Tue, 28 Jul 2009 10:33:16 +1000
From: Richard Heycock <rgh@roughage.com.au>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] xapian merged into next
Message-ID: <1248740968-sup-759@wrasse>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Tue Jul 28 02:27:42 +1000 2009:
> Reformatted excerpts from Guillaume Quintard's message of 2009-07-27:
> > The big question is: is it interesting, as a user, to switch? :-)
>
> Yes. It's noticeably faster than Ferret, especially for loading large
> threads in thread-index-mode. (Which isn't Xapian per se, but other
> improvements Rich has made).
>
> It's also much larger on disk, though there might be a way to trim that
> down.
>
> At some point I want to deprecate Ferret, since it's unmaintained, so
> you'll be forced to switch. No timeline on that though.
Just to add to Williams answer not only is it faster it's also
*significantly* more robust. I'm running Debian unstable which, at the
moment is really living up to it's name, consequently my machine is
dying a lot more times than it should and I haven't had to rebuild the
index once. Compare that to ferret where I pretty much has to rebuild
the index every time; I even wrote myself a one line script to do it.
William there is work being done on the next xapian "engine" which aims
to reduce the disc size.
rgh
------------------------------
Message: 627
Date: Mon, 27 Jul 2009 20:19:29 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH 1/2] xapian: fix MAX_DATE
Message-ID: <1248751170-4102-1-git-send-email-rlane@club.cc.cmu.edu>
---
lib/sup/xapian_index.rb | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
index 303b4d0..6358a20 100644
--- a/lib/sup/xapian_index.rb
+++ b/lib/sup/xapian_index.rb
@@ -14,7 +14,7 @@ class XapianIndex < BaseIndex
## so we must ensure they're reasonably valid. this typically only affect
## spam.
MIN_DATE = Time.at 0
- MAX_DATE = Time.at(2**31)
+ MAX_DATE = Time.at(2**31-1)
def initialize dir=BASE_DIR
super
--
1.6.0.4
------------------------------
Message: 628
Date: Mon, 27 Jul 2009 20:19:30 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH 2/2] xapian: fix issue with empty ferret
query
Message-ID: <1248751170-4102-2-git-send-email-rlane@club.cc.cmu.edu>
---
lib/sup/ferret_index.rb | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/lib/sup/ferret_index.rb b/lib/sup/ferret_index.rb
index f2bb2a0..5473814 100644
--- a/lib/sup/ferret_index.rb
+++ b/lib/sup/ferret_index.rb
@@ -442,6 +442,7 @@ private
def build_ferret_query query
q = Ferret::Search::BooleanQuery.new
+ q.add_query Ferret::Search::MatchAllQuery.new, :must
q.add_query query[:qobj], :must if query[:qobj]
labels = ([query[:label]] + (query[:labels] || [])).compact
labels.each { |t| q.add_query Ferret::Search::TermQuery.new("label", t.to_s), :must }
--
1.6.0.4
------------------------------
Message: 629
Date: Mon, 27 Jul 2009 23:33:16 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] xapian merged into next
Message-ID: <1248751256-sup-4491@pion.club.cc.cmu.edu>
Content-Type: text/plain; charset=UTF-8
Excerpts from Guillaume Quintard's message of Mon Jul 27 16:04:58 -0400 2009:
> > 5. ruby -Ilib bin/sup-dump > dumpfile
> -> produces a empty file (not sure it's normal)
>
> ./lib/sup/xapian_index.rb:17:in `at': bignum too big to convert into
Oops, breaking sup-dump would make switching to Xapian a little
difficult. I've posted patches for both these issues. We really should
have more tests to catch this sort of thing...
------------------------------
Message: 630
Date: Mon, 27 Jul 2009 22:02:29 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH] explicitly load messages in testcase
Message-ID: <1248757349-11301-1-git-send-email-rlane@club.cc.cmu.edu>
---
test/test_message.rb | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/test/test_message.rb b/test/test_message.rb
index 0a7db45..675b81d 100644
--- a/test/test_message.rb
+++ b/test/test_message.rb
@@ -73,6 +73,7 @@ EOS
source_info = 0
sup_message = Message.new( {:source => source, :source_info => source_info } )
+ sup_message.load_from_source!
# see how well parsing the header went
@@ -222,6 +223,7 @@ EOS
source_info = 0
sup_message = Message.new( {:source => source, :source_info => source_info } )
+ sup_message.load_from_source!
# read the message body chunks
@@ -271,6 +273,7 @@ EOS
source_info = 0
sup_message = Message.new( {:source => source, :source_info => source_info } )
+ sup_message.load_from_source!
to = sup_message.to
@@ -316,6 +319,7 @@ EOS
source_info = 0
sup_message = Message.new( {:source => source, :source_info => source_info } )
+ sup_message.load_from_source!
# read the message body chunks: no errors should reach this level
@@ -414,6 +418,7 @@ EOS
source_info = 0
sup_message = Message.new( {:source => source, :source_info => source_info } )
+ sup_message.load_from_source!
# read the message body chunks
@@ -504,6 +509,7 @@ EOS
source_info = 0
sup_message = Message.new( {:source => source, :source_info => source_info } )
+ sup_message.load_from_source!
# See how well parsing the message ID went.
id = sup_message.id
--
1.6.0.4
------------------------------
Message: 631
Date: Tue, 28 Jul 2009 13:47:07 +0000 (UTC)
From: Olly Betts <olly@survex.com>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] [PATCH 0/18] Xapian-based index
Message-ID: <loom.20090728T134034-967@post.gmane.org>
Content-Type: text/plain; charset=us-ascii
William Morgan <wmorgan-sup@masanjin.net> writes:
> Reformatted excerpts from Olly Betts's message of 2009-06-25:
> > I'll make sure this fix makes it into the next Xapian release (which
> > will be 1.0.14).
>
> Awesome, thanks!
Just to update, Xapian 1.0.14 was released last week with this fix.
I tested with a distilled micro-testcase rather than sup and these patches,
so if you still see problems please open a ticket on http://trac.xapian.org/
Cheers,
Olly
------------------------------
Message: 632
Date: Tue, 28 Jul 2009 08:06:34 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] trying out sup ...
Message-ID: <1248793474-sup-9541@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Hi Lee,
Reformatted excerpts from lee's message of 2009-07-18:
> So I had sup running on the console and tried out to search for
> something while sup was looking for new messages in a maildir. But
> then it crashed and told me I should send a bug report[3].
>
> Maybe I have created some incompatibilities by installing the
> replacement library. But is it currently possible to run sup on Debian
> Testing without too much difficulty? If so, what do I need to do?
That particular crash is a transient thing, I think---there is some
race condition with the display logic that occasionally manifests itself
as such. I would just retry. I have tentative plans to rewrite a lot of
the display stuff without threads once we're Ruby 1.9 ready.
I don't know why display is corrupt in rxvt. Do other ncurses apps
display ok?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 633
Date: Tue, 28 Jul 2009 08:07:11 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH 0/18] Xapian-based index
Message-ID: <1248793614-sup-5597@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Olly Betts's message of 2009-07-28:
> Just to update, Xapian 1.0.14 was released last week with this fix.
>
> I tested with a distilled micro-testcase rather than sup and these patches,
> so if you still see problems please open a ticket on http://trac.xapian.org/
Excellent. Thank you.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 634
Date: Tue, 28 Jul 2009 08:12:51 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] explicitly load messages in testcase
Message-ID: <1248793905-sup-2227@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Hi Rich,
Not to be a pain, but can you give a little more context for this patch
(and the other two you sent recently)? I'm just trying to understand
what this fixes.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 635
Date: Tue, 28 Jul 2009 08:13:52 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] xapian merged into next
Message-ID: <1248793998-sup-5987@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Rich Lane's message of 2009-07-27:
> We really should have more tests to catch this sort of thing...
Agreed. Mostly my fault, I'm afraid.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 636
Date: Tue, 28 Jul 2009 08:17:52 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Odd key bug
Message-ID: <1248794177-sup-3810@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Edward Z. Yang's message of 2009-07-27:
> Alex Vandiver points out that stdscr is a member variable of Ncurses.
> As such, this patch appears to fix the issue.
Applied with great relish direct to master. Thanks!
> I have no fucking clue why this works. Perhaps forcibly setting this
> setting clears some internal buffer. Either 1 or 0 works, we probably
> want 1 since that's what bin/sup sets.
Welcome to ncurses programming. Much like fortran, everyone who once
knew what this stuff meant has since died.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 637
Date: Tue, 28 Jul 2009 08:25:23 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Make logging less chatty
Message-ID: <1248794676-sup-7855@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Walton's message of 2009-07-27:
> +1 for the idea, but wouldn't a command line verbosity toggle be a
> better way to do this?
I've applied the patch, but yes, the whole Redwood::log thing is crufty
and needs to be replaced with a logger that's aware of levels.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 638
Date: Tue, 28 Jul 2009 11:31:24 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Odd key bug
Message-ID: <1248795045-sup-4556@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Tue Jul 28 11:17:52 -0400 2009:
> Welcome to ncurses programming. Much like fortran, everyone who once
> knew what this stuff meant has since died.
...or is making a 'mint' maintaining crap^H^H^H^Hcode from the 80's?
<grin>
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090728/7f69db3f/attachment-0001.bin>
------------------------------
Message: 639
Date: Tue, 28 Jul 2009 11:39:16 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] explicitly load messages in testcase
Message-ID: <1248794785-sup-1840@pion.club.cc.cmu.edu>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Tue Jul 28 11:12:51 -0400 2009:
> Hi Rich,
>
> Not to be a pain, but can you give a little more context for this patch
> (and the other two you sent recently)? I'm just trying to understand
> what this fixes.
Sure. The commit "don't automatically parse header on Message#new" broke
test_message because the message id/etc fields are nil until
load_from_source! is called. This patch just calls load_from_source!
whenever we create a message in the testcase.
The other two are fixes for problems reported by Guillaume Quintard.
Ferret sup-dump was failing because the query passed to each_id didn't
have any positive terms. The date-ceiling code was broken on 32 bit
machines because the maximum signed long is 2**31-1, not 2**31.
------------------------------
Message: 640
Date: Tue, 28 Jul 2009 08:48:48 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Reply calculation
Message-ID: <1248794955-sup-3347@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Edward Z. Yang's message of 2009-07-27:
> From: correct@example.com
> To: correct@example.com
> Reply-To: correct@example.com
> List-Post: mailto:incorrect@example.com
>
> Sup detects List-Post, categorizes the message as a list message, and then
> sets the default reply mode as list, which results in List-Post being used
> as the to address.
So in this case, following reply-to is correct.
> Unfortunately, mailing list administrating is notoriously broken. I'm not
> sure at all what the right solution is. Take for example this other case:
>
> From: person@example.com
> To: list@example.com
> Reply-To: person@example.com
> List-Post: mailto:list@example.com
>
> Reply-To, in this case, was set by the mailing list server.
In this case, I'd argue that this means the list administrator wants the
default reply behavior to be to the individual and not the list. So I'd
again prefer Sup default to the reply-to address rather than the list
address. (With the caveat that this is overrideable by hooks on a
per-list basis, so if it's a matter of an incompetent list
administrator, or simply disagreeing with them, one can override this
behavior for this list.)
> However, consider the next case:
>
> From: persona@example.com
> To: list@example.com
> Cc: me@example.com
>
> Which is when someone else hit "Reply all" and you got CC'ed. This means
> that the mail never passed through the mailing list agent, the
> List-Post/Reply-To
> headers never got set, and the only way to tell that you should reply to the
> whole list is to explicitly ask for "Reply all" semantics (Sup defaults to
> "Reply" semantics, which is damn confusing if you're not paying attention).
There's not much to be done in this case, EXCEPT that if you receive
more than one copy of the message, you should keep the list header
around. Then the only time you're in a funny situation is when you've
received the first but not the other.
This is presumably why Mutt had you register your mailing list addresses
explicitly, which I always found a little irritating.
(Or to have Sup keep around email addresses known to belong to lists,
and match those in the To: field against that, which seems significantly
more complicated.)
> The core problem is that subtle changes in state should not require the user
> to do things differently; it breaks muscle memory and makes mistakes easy.
I agree with this in principle, but I see addressing a message as a
fundamental part of composing it. You can remove the notion of a smart
default reply-to address from your Sup, if you like, by using the
reply-to hook.
And as for the default, I think I'm of the opinion that setting the
default reply address so as to obey the reply-to is correcter than
anything else (including whatever Sup does currently).
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 641
Date: Tue, 28 Jul 2009 11:57:56 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] xapian question
Message-ID: <1248795865-sup-6634@pion.club.cc.cmu.edu>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Mon Jul 27 13:45:32 -0400 2009:
> Hey, I finally get to ask a question!
>
> One of the mildly irritating things about Ferret was that it was
> impossible to update the labels of a message without updating the entire
> entry, i.e. including the body. So updating the labels of a message and
> saving that to disk required either re-loading the body from the source,
> or keeping the body explicitly in the index so that it could be loaded
> without going back to the source.
>
> The latter approach is used by the current Ferret index implementation,
> since it's significantly faster (especially for slow sources like IMAP
> servers), but at the cost of a lot of disk space.
>
> My understanding of Xapian is that this is also the case, since fields
> are essentially represented as prefixed terms, and so you're basically
> updating a big blog, but I wanted to confirm this. I ask because the
> entries.db file is very big. :)
Xapian actually provides add_term and remove_term for documents. I'd
definitely like to use these for label updates, but we need a way to
tell if only the labels have changed in sync_message. Or, we update the
index in Message#add_label/etc and get rid of the need to save buffers.
That might not be an option for the Ferret index, though.
We don't store the body in entries.db, just enough info for
thread-index-mode. It's only about 800 bytes/message for me, but I don't
have snippets enabled so yours would be larger.
------------------------------
Message: 642
Date: Tue, 28 Jul 2009 09:04:20 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] explicitly load messages in testcase
Message-ID: <1248796949-sup-4949@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Rich Lane's message of 2009-07-28:
> Sure. The commit "don't automatically parse header on Message#new" broke
> test_message because the message id/etc fields are nil until
> load_from_source! is called. This patch just calls load_from_source!
> whenever we create a message in the testcase.
Got it. Applied, thanks!
> The other two are fixes for problems reported by Guillaume Quintard.
> Ferret sup-dump was failing because the query passed to each_id didn't
> have any positive terms.
Hah.
> The date-ceiling code was broken on 32 bit machines because the
> maximum signed long is 2**31-1, not 2**31.
Ok, both applied. Thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 643
Date: Tue, 28 Jul 2009 16:53:46 +0000 (UTC)
From: Olly Betts <olly@survex.com>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] [PATCH 0/18] Xapian-based index
Message-ID: <loom.20090728T134845-816@post.gmane.org>
Content-Type: text/plain; charset=us-ascii
William Morgan <wmorgan-sup@masanjin.net> writes:
> Reformatted excerpts from Rich Lane's message of 2009-07-24:
> > You need to specify a non-negated term in the query. "type:mail
> > -label:inbox" should work.
>
> This is a typical restriction for inverted index-based search engines.
> You need to have at least one positive term or the computation is too
> expensive (it would have to iterate over every term ever seen.) It's
> true of Ferret, Google, etc.
Actually, Xapian supports this - Xapian.Query.new("") is a "magic" query
which matches all documents.
It doesn't need to iterate over every term, just all documents. But if you
want the top ten documents without a particular filter, there's no relevance
ranking, so it can stop after it has found ten matches, which should be
pretty quick.
This isn't currently supported by the QueryParser when using "-" on terms
(the reasoning was that it was too easy to accidentally invoke when pasting
text), but 'NOT label:inbox' will work if you enable it using
QueryParser.FLAG_PURE_NOT.
Cheers,
Olly
------------------------------
Message: 644
Date: Tue, 28 Jul 2009 10:01:43 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH 0/18] Xapian-based index
Message-ID: <1248800452-sup-1121@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Olly Betts's message of 2009-07-28:
> Actually, Xapian supports this - Xapian.Query.new("") is a "magic"
> query which matches all documents.
Yeah, I think Rich Lane just taught me how Ferret supports this too.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 645
Date: Tue, 28 Jul 2009 12:57:57 -0400
From: Mark Alexander <marka@pobox.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Make logging less chatty
Message-ID:
<a412e2a70907280957y73c1f562mc2dc51eb2d738ae0@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On 7/28/09, William Morgan <wmorgan-sup@masanjin.net> wrote:
> ... but yes, the whole Redwood::log thing is crufty
> and needs to be replaced with a logger that's aware of levels.
Or maybe something combining types and levels that you
could configure like this in config.yaml:
:logging:
:mbox: 2
:maildir: 3
:ferret: 0
...etc...
------------------------------
Message: 646
Date: Tue, 28 Jul 2009 14:34:46 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Reply calculation
Message-ID: <1248805830-sup-2383@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Tue Jul 28 11:48:48 -0400 2009:
> > Unfortunately, mailing list administrating is notoriously broken. I'm not
> > sure at all what the right solution is. Take for example this other case:
> >
> > From: person@example.com
> > To: list@example.com
> > Reply-To: person@example.com
> > List-Post: mailto:list@example.com
> >
> > Reply-To, in this case, was set by the mailing list server.
>
> In this case, I'd argue that this means the list administrator wants the
> default reply behavior to be to the individual and not the list. So I'd
> again prefer Sup default to the reply-to address rather than the list
> address. (With the caveat that this is overrideable by hooks on a
> per-list basis, so if it's a matter of an incompetent list
> administrator, or simply disagreeing with them, one can override this
> behavior for this list.)
Nods.
> > However, consider the next case:
> >
> > From: persona@example.com
> > To: list@example.com
> > Cc: me@example.com
> >
> > Which is when someone else hit "Reply all" and you got CC'ed. This means
> > that the mail never passed through the mailing list agent, the
> > List-Post/Reply-To
> > headers never got set, and the only way to tell that you should reply to the
> > whole list is to explicitly ask for "Reply all" semantics (Sup defaults to
> > "Reply" semantics, which is damn confusing if you're not paying attention).
>
> There's not much to be done in this case, EXCEPT that if you receive
> more than one copy of the message, you should keep the list header
> around. Then the only time you're in a funny situation is when you've
> received the first but not the other.
This situation is not that uncommon; many mailing list software will notice
that someone is on a CC list and will purposely omit them.
> I agree with this in principle, but I see addressing a message as a
> fundamental part of composing it. You can remove the notion of a smart
> default reply-to address from your Sup, if you like, by using the
> reply-to hook.
This is true. However, when you compose a non-reply message, Sup prompts
you for To, Cc and Subject, because they are such fundamental components
of all messages you would write (well, maybe not so much Cc) and the
user always has to make a judgment call there.
> And as for the default, I think I'm of the opinion that setting the
> default reply address so as to obey the reply-to is correcter than
> anything else (including whatever Sup does currently).
Fair enough. You may get some complaints because this /will/ break muscle
memory, and still presents the possibility for messages to have different
behavior in subtle ways, as detailed in the Cc versus mailing list example
from above.
Cheers,
Edward
------------------------------
Message: 647
Date: Tue, 21 Jul 2009 12:05:20 +0200
From: paro 462 <paro462@gmail.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] error with Sup while sending mails
Message-ID:
<956dbab30907210305s1127ace3s315c8505c9c38141@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi William,
First of all, thank you for Sup, I find it just great !
Next, excuse me for my english, I'm french...
I'm experiencing troubles to send mails with Sup. I configured msmtp
as shown in your wiki. I even tested it with mutt and it worked. But
when I tried to do it with Sup, it crashed, showing what is in the
attachment. I first tried it with the debian/Sid package and saw by a
search that the git version could fix this problem. So I uninstalled
the package and removed the .sup folder and did a git clone
git://gitorious.org/sup/mainline.git
Then tried to launch Sup but it needed some Ruby / Rubygems
dependencies. I installed it by running gem install <dependency>.
Sup did worked like this, launched with a
ruby -I lib bin/sup-config
and then with
ruby -I lib bin/sup
But when I configured it to work with msmtp again, it just crashed the
same way the package version did when I tried to send a mail...
I think it's a problem with my locales so here's the result of the
locale command :
$ locale
LANG=fr_FR.utf8
LC_CTYPE="fr_FR.utf8"
LC_NUMERIC="fr_FR.utf8"
LC_TIME="fr_FR.utf8"
LC_COLLATE="fr_FR.utf8"
LC_MONETARY="fr_FR.utf8"
LC_MESSAGES="fr_FR.utf8"
LC_PAPER="fr_FR.utf8"
LC_NAME="fr_FR.utf8"
LC_ADDRESS="fr_FR.utf8"
LC_TELEPHONE="fr_FR.utf8"
LC_MEASUREMENT="fr_FR.utf8"
LC_IDENTIFICATION="fr_FR.utf8"
LC_ALL=
If you could help me getting this work it would be great :)
Sincerely,
Flo
-------------- next part --------------
--- NoMethodError from thread: poll after loading inbox
undefined method `to_indexable_s' for nil:NilClass
./lib/sup/index.rb:243:in `sync_message'
./lib/sup/util.rb:519:in `send'
./lib/sup/util.rb:519:in `method_missing'
./lib/sup/poll.rb:162:in `add_messages_from'
./lib/sup/source.rb:100:in `each'
./lib/sup/util.rb:558:in `send'
./lib/sup/util.rb:558:in `__pass'
./lib/sup/util.rb:545:in `method_missing'
./lib/sup/poll.rb:141:in `add_messages_from'
./lib/sup/poll.rb:98:in `do_poll'
./lib/sup/poll.rb:86:in `each'
./lib/sup/poll.rb:86:in `do_poll'
./lib/sup/poll.rb:85:in `synchronize'
./lib/sup/poll.rb:85:in `do_poll'
./lib/sup/util.rb:519:in `send'
./lib/sup/util.rb:519:in `method_missing'
./lib/sup/modes/poll-mode.rb:17:in `poll'
./lib/sup/poll.rb:53:in `poll'
./lib/sup/util.rb:519:in `send'
./lib/sup/util.rb:519:in `method_missing'
bin/sup:204
./lib/sup.rb:75:in `reporting_thread'
./lib/sup.rb:73:in `initialize'
./lib/sup.rb:73:in `new'
./lib/sup.rb:73:in `reporting_thread'
bin/sup:204
./lib/sup/modes/thread-index-mode.rb:664:in `call'
./lib/sup/modes/thread-index-mode.rb:664:in `__unprotected_load_threads'
./lib/sup/modes/thread-index-mode.rb:606:in `call'
./lib/sup/modes/thread-index-mode.rb:606:in `load_n_threads_background'
./lib/sup.rb:75:in `reporting_thread'
./lib/sup.rb:73:in `initialize'
./lib/sup.rb:73:in `new'
./lib/sup.rb:73:in `reporting_thread'
./lib/sup/modes/thread-index-mode.rb:604:in `load_n_threads_background'
./lib/sup/modes/thread-index-mode.rb:674:in `__unprotected_load_threads'
(eval):12:in `load_threads'
bin/sup:204
------------------------------
Message: 648
Date: Tue, 28 Jul 2009 19:58:23 +0300
From: Kornilios Kourtis <kkourt@cslab.ece.ntua.gr>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH] handle malformed multiplart messages
Message-ID: <20090728165823.GA29533@solar.cslab.ece.ntua.gr>
Content-Type: text/plain; charset=us-ascii
Hi,
I've tried to use sup-mail, but sup-sync blows up due to some malformed
messages I keep in my mailbox. Below is a quick patch that seems to fix the
above issue for me.
Thanks,
--
Kornilios Kourtis
diff --git a/lib/sup/message.rb b/lib/sup/message.rb
index ded577a..c6e6baf 100644
--- a/lib/sup/message.rb
+++ b/lib/sup/message.rb
@@ -385,11 +385,15 @@ private
chunks
elsif m.header.content_type == "message/rfc822"
- payload = RMail::Parser.read(m.body)
- from = payload.header.from.first
- from_person = from ? Person.from_address(from.format) : nil
- [Chunk::EnclosedMessage.new(from_person, payload.to_s)] +
- message_to_chunks(payload, encrypted)
+ if m.body
+ payload = RMail::Parser.read(m.body)
+ from = payload.header.from.first
+ from_person = from ? Person.from_address(from.format) : nil
+ [Chunk::EnclosedMessage.new(from_person, payload.to_s)] +
+ message_to_chunks(payload, encrypted)
+ else
+ [Chunk::EnclosedMessage.new(nil, "")]
+ end
else
filename =
## first, paw through the headers looking for a filename
------------------------------
Message: 649
Date: Tue, 28 Jul 2009 11:55:50 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] error with Sup while sending mails
Message-ID: <1248807059-sup-8075@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Hi Flo,
Reformatted excerpts from paro 462's message of 2009-07-21:
> --- NoMethodError from thread: poll after loading inbox
> undefined method `to_indexable_s' for nil:NilClass
> ./lib/sup/index.rb:243:in `sync_message'
Interesting. You're the second person who's reported this. It has
something to do with parsing a particular date. I'm not sure if it's
locale-related... maybe.
Can you try applying the following patch? I'm hoping that the debugging
output prefixed with XX will provide a clue.
--- a/lib/sup/message.rb
+++ b/lib/sup/message.rb
@@ -92,11 +92,14 @@ class Message
begin
Time.parse date
rescue ArgumentError => e
- #Redwood::log "faking mangled date header for #{@id} (orig #{header['date'].inspect} gave error: #{e.message})"
+ Redwood::log "faking mangled date header for #{@id} (orig #{header['date'].inspect} gave error: #{e.message})"
Time.now
end
- else
- #Redwood::log "faking non-existent date header for #{@id}"
+ end
+
+ @date ||= begin
+ Redwood::log "XX original header was #{header["date"].inspect}"
+ Redwood::log "XX faking non-existent date header for #{@id}"
Time.now
end
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 650
Date: Tue, 28 Jul 2009 12:05:39 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] xapian question
Message-ID: <1248807365-sup-4965@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Rich Lane's message of 2009-07-28:
> Xapian actually provides add_term and remove_term for documents.
Excellent.
> I'd definitely like to use these for label updates, but we need a way
> to tell if only the labels have changed in sync_message.
I've been running into this same issue with my sup-server experiments,
so I think we should split the API into, say, three separate calls:
something like add_new_message, update_labels, and update_body. (AFAIK
the only client of update_body is in some of the draft editing stuff.)
WDYT?
> Or, we update the index in Message#add_label/etc and get rid of the
> need to save buffers. That might not be an option for the Ferret
> index, though.
I think that would actually be fine for Ferret, and it's a direction
that's often been discussed. (Especially now that we have undo.) If we
do the above, we can certainly do this as a later step.
> We don't store the body in entries.db, just enough info for
> thread-index-mode. It's only about 800 bytes/message for me, but I
> don't have snippets enabled so yours would be larger.
On second glance, it's a little smaller than I remembered. For my sample
212m mbox, it's about 20m with snippets enabled.
The total index size under Xapian (the xapian/ dir and all gdbm files)
is larger than the original mbox file, which seems a little insane. But
hey, disk space is cheap.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 651
Date: Tue, 28 Jul 2009 12:10:57 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Slow import of messages
Message-ID: <1248808053-sup-5358@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Hi Nico,
Reformatted excerpts from Nico Schottelius's message of 2009-07-13:
> Now the problem is that sup gets about 3 mails per second into its
> index.
As others have pointed out, messages only have to be indexed once, so
this isn't ultimately that big of a deal. But 3m/s seems very slow for a
Maildir source.
With my mbox on my reasonably-fast laptop, I start with around 50m/s
using Ferret, and at 80m/s using Xapian. (These numbers degrade slightly
as the index gets fuller.) I would expect similar numbers from Maildir.
So something weird is happening for you. Do you have a notion of whether
it's disk or CPU that's the bottleneck?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 652
Date: Wed, 29 Jul 2009 09:09:42 +0300
From: iny+dev@iki.fi (Ilpo Nyyss?nen )
To: sup-talk@rubyforge.org
Subject: [sup-talk] Handling big mailing lists
Message-ID: <m3zlaovx3t.fsf@iny.iki.fi>
Content-Type: text/plain; charset=iso-8859-1
I'm searching alternatives for my Gnus email + news setup. I don't
expect Sup to be able to do everything Gnus can yet, but maybe in
future? :) Note that I have never used Gmail.
I tried to test Sup, but I wasn't able to get any emails because Sup
failed to login to my IMAP server. This happened because the server
requires client certificates and it looks like Sup doesn't support
those.
The bigger question is about handling big amount of mailing list mail.
I'm reading many small mailing lists and some big ones. Biggest is
linux-kernel. I can split this to two: daily reading routine and
expiration.
How would my daily reading routine work with Sup? I want to read
things in priority order:
1. Personal email
2. Emails related to my programming hobby
3. Emails related to some associations like user groups
4. Mailing lists, also in priority order
The order is such that if I need to stop reading, I have read the most
important ones already. The order is not static, I want to be able to
change it.
I have understood that labels are way to get this kind of grouping.
Can I get a view where the labels are sorted like this? And can I
continue reading the next label in that order after I have finished
the one before?
Then about the expiration. The linux-kernel mailing list gets so much
email that some kind of expiration is a must. Can Sup do such
automatic deleting of old emails? Can Sup handle some other process
doing such automatic deletion? (I would actually prefer some other
process do it.)
I'm mostly reading just only few authors from linux-kernel and skipping
rest, but I do like to see the rest in the thread view as sometimes some
subject is interesting and sometimes some thread gets big and is
interesting because of that. How would this work?
I would actually recommend reading linux-kernel to test Sup. :)
--
Ilpo Nyyss?nen # biny # /* :-) */
------------------------------
Message: 653
Date: Wed, 29 Jul 2009 12:27:06 +0200
From: Marc Weber <marco-oweber@gmx.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] error with Sup while sending mails
Message-ID: <1248863105-sup-6533@nixos>
Content-Type: text/plain; charset=UTF-8
> undefined method `to_indexable_s' for nil:NilClass
> ./lib/sup/index.rb:243:in `sync_message'
> ./lib/sup/util.rb:519:in `send'
sup-sync -c did it for me. I don't know what was wrong at all though.
This will take some time.
If you open index.rb:243 you may want to add a
p m where m is the message object? Maybe the output will give you more
insight as well.
I hope sync helps you as well.
Marc Weber
------------------------------
Message: 654
Date: Wed, 29 Jul 2009 14:54:11 +0200
From: Marc Weber <marco-oweber@gmx.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Handling big mailing lists
Message-ID: <1248871866-sup-9988@nixos>
Content-Type: text/plain; charset=UTF-8
You can use hooks to add labels:
my "~/.sup/hooks/before-add-message.rb":
def matchR(email)
not message.recipients.find{ |to| /^#{email}$/i =~ to.email}.nil?
end
def matchRAddLabel(email, label, inbox = 0)
if matchR email then
message.add_label label
message.remove_label :inbox unless inbox
end
end
def importantFrom(email)
message.add_label :Starred if message.from.email == email
end
importantFrom "info@webkos.de"
matchRAddLabel("mod_python@modpython.org","mod-python", 1)
matchRAddLabel("mod_python@modpython.org","mod-python", 0)
if message.subj =~ /^Project Notification$/ && message.from.email == "info@guru.com" then
message.add_label "GURU_PROJECT_NOTIFICATION"
message.add_label "delete_after_one_month"
end
if message.subj =~ /^WEBKOS_/ then
message.remove_label :inbox
message.add_label "WEBKOS_"
end
So adding labels onle if a contsraint is met is easy.
About deleting mails: There is sup-sync-back. So there must be a way to delete
"old" / whatever mails. I haven't used it yet.
I'm new to sup myself.
Yours
Marc Weber
------------------------------
Message: 655
Date: Wed, 29 Jul 2009 06:46:19 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Handling big mailing lists
Message-ID: <1248874122-sup-3830@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Hi,
Excellent set of questions. Handling large volumes of mail is one of my
main goals with Sup.
Reformatted excerpts from iny+dev's message of 2009-07-28:
> I tried to test Sup, but I wasn't able to get any emails because Sup
> failed to login to my IMAP server. This happened because the server
> requires client certificates and it looks like Sup doesn't support
> those.
As far as IMAP goes, Sup supports whatever authentication the Ruby IMAP
libraries supports, which is probably not much.
Any serious use of Sup with IMAP is best done via an intermediate like
offlineimap, which syncs an IMAP folder to a local Maildir folder. The
Ruby IMAP libraries, and possibly IMAP itself, is a little too slow for
how Sup likes to work.
> How would my daily reading routine work with Sup? I want to read
> things in priority order:
>
> 1. Personal email
> 2. Emails related to my programming hobby
> 3. Emails related to some associations like user groups
> 4. Mailing lists, also in priority order
Sup gives you two tools: search and labels. Sup will present a list of
threads that match any search query. So, each of those steps is
possible, to the extent that you can compose a search query that
reflects it.
You can automatically add labels via arbitrary code, so you have a fair
amount of flexibility here.
> The order is such that if I need to stop reading, I have read the most
> important ones already. The order is not static, I want to be able to
> change it. I have understood that labels are way to get this kind of
> grouping. Can I get a view where the labels are sorted like this?
Sup currently only orders chronologically. It would not be difficult to
add a second level of user-defined sorting *on top* of the chronological
one, but it would be difficult, if not impossible, to order all email in
the index by an arbitrary function.
(To be pedantic, if you can come up with a single number for each email,
which never changes, and which is known at add time, you can order by
that, with some work. But it doesn't sound like that's what you want.)
> And can I continue reading the next label in that order after I have
> finished the one before?
Certainly, but not automatically. You can view one label, and then pick
another label to view, etc.
I suppose if the above second-round of ordering were implemented, you
could view both labels at once and make an ordering function that placed
one above the other.
> Then about the expiration. The linux-kernel mailing list gets so much
> email that some kind of expiration is a must.
You don't want to just buy a bigger hard drive?
> Can Sup do such automatic deleting of old emails? Can Sup handle some
> other process doing such automatic deletion? (I would actually prefer
> some other process do it.)
That's best left to another process. You'll then have to tell Sup which
messages were deleted so that it can remove them from the index. Let me
know when you're at this point and I can help you---it will require a
brief Ruby script.
> I would actually recommend reading linux-kernel to test Sup. :)
I read ruby-talk, which is probably not too far off.
One last comment: large threads are irritatingly slow to create in
thread-view-mode with the Ferret index, but there's a new Xapian index
which is fast for this. It's still slightly experimental.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 656
Date: Wed, 29 Jul 2009 20:24:43 +0300
From: iny+dev@iki.fi (Ilpo Nyyss?nen )
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Handling big mailing lists
Message-ID: <m3prbjwgf8.fsf@iny.iki.fi>
Content-Type: text/plain; charset=iso-8859-1
William Morgan <wmorgan-sup@masanjin.net> writes:
> Sup currently only orders chronologically. It would not be difficult to
> add a second level of user-defined sorting *on top* of the chronological
> one, but it would be difficult, if not impossible, to order all email in
> the index by an arbitrary function.
I'm not talking about ordering of emails, I'm talking about ordering of
the labels.
When I start my daily routine, I want to see a list of labels with
numbers telling how many unread emails each has. Labels containing
nothing new must be hidden. And this list must be sorted to priority
order. Then I want to read those labels through in that order.
How many labels would I have? At least tens, probably over hundred.
>> And can I continue reading the next label in that order after I have
>> finished the one before?
>
> Certainly, but not automatically. You can view one label, and then pick
> another label to view, etc.
Picking one from alphabetically sorted list or writing it is not usable.
I don't remember the order, I just want to get the next one.
>> Then about the expiration. The linux-kernel mailing list gets so much
>> email that some kind of expiration is a must.
>
> You don't want to just buy a bigger hard drive?
It's not a disk space problem. The problem is that many things would get
slow (or I would need to configure exceptions) and I just do not have
any need for them. They are all in searchable mailing list archives
anyway.
And another point is that I actually prefer not to order mailing lists.
It is much easier to just get them with nntp from news.gmane.org. How? I
have a nntp to imap gateway and I use it to read also from other nntp
servers. The thing here is that nntp servers usually do expire messages
and so to be able to use that with Sup, it would need to tolerate the
expiration.
> That's best left to another process. You'll then have to tell Sup which
> messages were deleted so that it can remove them from the index.
So, I don't do the expiration. I guess it should be possible to find out
the ones that went away when checking for new ones.
> Let me know when you're at this point and I can help you---it will
> require a brief Ruby script.
Well, it is looking like in current state I won't even start trying.
>> I would actually recommend reading linux-kernel to test Sup. :)
>
> I read ruby-talk, which is probably not too far off.
Hmm,
http://dir.gmane.org/gmane.comp.lang.ruby.general
http://dir.gmane.org/gmane.linux.kernel
I guess so. How long it takes to index few months of ruby-talk?
Could Sup use IMAP search features?
--
Ilpo Nyyss?nen # biny # /* :-) */
------------------------------
Message: 657
Date: Thu, 30 Jul 2009 17:56:56 +0200
From: Adeodato Sim? <dato@net.com.org.es>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] [PATCH] mime-decode hook: provide a "charset"
variable with the attachment charset
Message-ID: <20090730155656.GA20442@chistera.yi.org>
Content-Type: text/plain; charset=utf-8
+ William Morgan (Mon, 27 Jul 2009 09:51:17 -0700):
> Reformatted excerpts from Adeodato Sim?'s message of 2009-07-23:
> > + Adeodato Sim? (Fri, 10 Jul 2009 17:00:29 +0200):
> > > + :charset => encoded_content.charset,
> > Hm, so apparently encoded_content doesn't always have a charset
> > member...
> In which case that value of that variable is nil, right? Is that a
> problem? The patch still seems useful.
Yes, I took a closer look and you're right the result of
encoded_content.charset is nil in that case. I also saw (I think) where
the traceback I was seeing is coming from: apparently it's not possible
to pass to HookContext a local that is nil, since then "super" will get
called in HookContext::method_missing() as far as I can see.
So, perhaps, to fix this patch, one could do:
:charset => encoded_content.charset || ''
But then, I think it would be better to fix HookContext to allow for
@__locals to contain nil. I'm not very familiar with that class, but it
seems easy enough to fix, see upcoming patch (also found in
~dato/sup/sup-dato:fixes at Gitorious, if you prefer that). With it,
this improvement to mime-decode seems to work without any further
trouble.
Cheers,
--
- Are you sure we're good?
- Always. -- Rory and Lorelai
------------------------------
Message: 658
Date: Thu, 30 Jul 2009 17:57:16 +0200
From: Adeodato Sim? <dato@net.com.org.es>
To: sup-talk@rubyforge.org
Cc: Adeodato Sim? <dato@net.com.org.es>
Subject: [sup-talk] [PATCH] HookContext::method_missing(): allow
locals to be nil
Message-ID:
<b6ff832e5f1872bda03e7846260165e8571c6dae.1248969435.git.dato@net.com.org.es>
Content-Type: text/plain; charset=utf-8
With the previous implementation of method_missing() in HookContext, it
was not possible to set the value of a local to nil, since that would be
assumed to mean "that local does not exist" and super would get called.
Now we use has_key? to check whether the local exists or not, and nil
will be returned normally from method_missing if that's the value of the
@__locals[name].
Signed-off-by: Adeodato Sim? <dato@net.com.org.es>
---
lib/sup/hook.rb | 12 +++++++-----
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/lib/sup/hook.rb b/lib/sup/hook.rb
index 0a0a2f6..8a52a96 100644
--- a/lib/sup/hook.rb
+++ b/lib/sup/hook.rb
@@ -20,13 +20,15 @@ class HookManager
attr_writer :__locals
def method_missing m, *a
- case @__locals[m]
- when Proc
- @__locals[m] = @__locals[m].call(*a) # only call the proc once
- when nil
+ if not @__locals.has_key? m
super
else
- @__locals[m]
+ case @__locals[m]
+ when Proc
+ @__locals[m] = @__locals[m].call(*a) # only call the proc once
+ else
+ @__locals[m]
+ end
end
end
--
1.6.3.3
------------------------------
Message: 659
Date: Thu, 30 Jul 2009 20:31:12 +0200
From: Tomas Carnecky <tom@dbservice.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] sup on opensolaris
Message-ID: <C1361ACC-8CF6-4AD9-955C-0B812197AF19@dbservice.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Kids, don't try this at home, it kills kittens! Well, not directly,
but trying to get sup running will drive you so mad you will try to
kill everything that moves. In other words: it doesn't work and the
fact that I'm trying this on opensolaris doesn't make it any easier.
The biggest issue is that the ruby binary from the package manager is
linked against the ancient solaris curses.so but ruby-ncurses needs
ncurses.so (which, to make the issue even more complicated, is in /usr/
gnu/lib). When both libraries are liked into one application, they
don't play along well (=segfaults). I had to compile ruby from source
and make sure it's not liked with curses.so, and also patch ruby-
ncurses slightly. I then managed to get sup to start up and read my
mails. However, there is one issue left that I'm not able to fix:
Ncurses.field.field_buffer() is returning garbage, and that makes is
impossible to write mails, search and set tags etc. The problem is
somewhere inside sup, as the ruby-ncurses example form2.rb is working
just fine (maybe it has something to do with encoding/locale?).
I have an ugly patch for lib/sup/textfield.rb that uses its own string
buffer instead of relying on field_buffer(). It's not perfect, but it
at least allows me to write emails and assign tags.
Other issues:
- strftime("%P") is a GNU extension, I work around this by using
strftime("%p").downcase.
- Iconv.iconv(target + "//IGNORE", charset, text + " ") <- the "//
IGNORE" is causing an InvalidEncoding exception, removing it didn't
seem to cause any regressions
tom
------------------------------
Message: 660
Date: Fri, 31 Jul 2009 11:17:28 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Smooth Paging
Message-ID: <1249053249-sup-9884@Longbow>
Content-Type: text/plain; charset=utf8
Hello,
One thing's that I've found a bit suboptimal in Sup has been the paging
ie. scrolling of e-mails. When you reach the bottom, it scrolls the
whole page up, rather than scrolling smoothly as might be the default
behaviour of Vim for example.
I find this really awkward at times, since I can't see what I just read
while reading the next line. It's also just kind of jumpy. One main use
case that his damages is when I'm doing patch review on mailing lists
and stuff.
I'll open a long e-mail with diffs in it, and I will be scrolling to see
the patch. Then, as I reach the bottom, it jumps and hides what I just
read, making understanding code logic painful at times. So then I have
to jump up and down some more to figure it out, but that sucks because I
have to look between the top and bottom of the screen.
What do you guys think?
--
Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
------------------------------
Message: 661
Date: Fri, 31 Jul 2009 11:23:07 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Sup Resource Usage
Message-ID: <1249053483-sup-9050@Longbow>
Content-Type: text/plain; charset=utf8
This isn't a serious complaint, but I'd just like to bring a couple
things with respect to Sup resource usage to the light.
According to top, Sup uses a fair bit of ram: about 30 MB at any point.
For comparison, pidgin uses about that much, and firefox uses 4x more.
That's generally acceptable, but more than I'd expect from a CLI app.
This is probably unavoidable.
What I find a bit more curious is Sup's wakeups. According to powertop,
sup is actually one of the top power munchers on my computers. I don't
understand why it has to wake up as often as it does: it's responsible
for 20% of all wakeups, with a rating of ~115. By comparison, firefox
does almost exactly the same amount of wakeups, and sup is the third
thing on my list, way above my window manager/de which does considerably
more.
I wonder what could be up here. Anyway, I'm fine with it if it's
un-investigated. Cheers.
--
Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
------------------------------
Message: 662
Date: Fri, 31 Jul 2009 11:38:00 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Smooth Paging
Message-ID: <1249054651-sup-1510@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from Andrei Thorp's message of Fri Jul 31 11:17:28 -0400 2009:
> One thing's that I've found a bit suboptimal in Sup has been the paging
> ie. scrolling of e-mails. When you reach the bottom, it scrolls the
> whole page up, rather than scrolling smoothly as might be the default
> behaviour of Vim for example.
I agree with this assessment and think smoother scrolling would be a
nice extra touch.
Cheers,
Edward
------------------------------
Message: 663
Date: Fri, 31 Jul 2009 08:43:26 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup Resource Usage
Message-ID: <1249054758-sup-9479@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Andrei Thorp's message of 2009-07-31:
> What I find a bit more curious is Sup's wakeups. According to
> powertop, sup is actually one of the top power munchers on my
> computers. I don't understand why it has to wake up as often as it
> does: it's responsible for 20% of all wakeups, with a rating of ~115.
What's the wakeup behavior of "ruby -esleep"?
What's the behavior of this Ruby program:
require 'rubygems'
require 'ncurses'
Ncurses.initscr
c = Ncurses.getch
Ncurses.endwin
puts c
I'd also be curious if things change under Ruby 1.9.1, since I'd like to
move to that as soon as feasible.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 664
Date: Fri, 31 Jul 2009 08:44:25 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Smooth Paging
Message-ID: <1249055039-sup-8105@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Andrei Thorp's message of 2009-07-31:
> What do you guys think?
Have you tried J and K vs j and k to scroll?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 665
Date: Fri, 31 Jul 2009 11:46:40 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Smooth Paging
Message-ID: <1249055175-sup-4619@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Fri Jul 31 11:44:25 -0400 2009:
> Have you tried J and K vs j and k to scroll?
In general, I use PgUp and PgDn to scroll. I didn't realize those keybindings
existed. :-)
Cheers,
Edward
------------------------------
Message: 666
Date: Fri, 31 Jul 2009 08:56:52 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup on opensolaris
Message-ID: <1249055178-sup-7149@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Hi Tom,
Thanks for the report! It's nice to have another system "supported", at
least technically.
Reformatted excerpts from Tomas Carnecky's message of 2009-07-30:
> However, there is one issue left that I'm not able to fix:
> Ncurses.field.field_buffer() is returning garbage, and that makes is
> impossible to write mails, search and set tags etc. The problem is
> somewhere inside sup, as the ruby-ncurses example form2.rb is working
> just fine (maybe it has something to do with encoding/locale?).
The ncurses field stuff is some hellish bullshit that I hate with all my
heart. It may very well be a locale problem... I really don't want to
debug it.
> I have an ugly patch for lib/sup/textfield.rb that uses its own string
> buffer instead of relying on field_buffer(). It's not perfect, but it
> at least allows me to write emails and assign tags.
If it's not too much work to clean up, I'd be interested in this patch.
The field buffer stuff is broken in weird ways anyways (the history
never seems to be quite right), and anything that reduces the reliance
on ncurses is always the right approach.
> - strftime("%P") is a GNU extension, I work around this by using
> strftime("%p").downcase.
Submit a patch! I'm fine with this.
> - Iconv.iconv(target + "//IGNORE", charset, text + " ") <- the "//
> IGNORE" is causing an InvalidEncoding exception, removing it didn't
> seem to cause any regressions
Hm, this is a trickier one. Allegedly the //IGNORE reduces the
exceptions thrown by Iconv, but since we're catching them all anyways,
we might be able to get away with removing this. Or we could
special-case it to your arch.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 667
Date: Fri, 31 Jul 2009 08:57:43 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Smooth Paging
Message-ID: <1249055837-sup-9394@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Edward Z. Yang's message of 2009-07-31:
> In general, I use PgUp and PgDn to scroll. I didn't realize those
> keybindings existed. :-)
Ctrl-e and ctrl-y work as well, if you're a vi addict.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 668
Date: Fri, 31 Jul 2009 12:00:00 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup Resource Usage
Message-ID: <1249055796-sup-2690@Longbow>
Content-Type: text/plain; charset=utf8
Excerpts from William Morgan's message of Fri Jul 31 11:43:26 -0400 2009:
> What's the wakeup behavior of "ruby -esleep"?
Well, you can easily test this yourself with powertop, but just running
this command does not cause a lot of wakeups. (It's not in the top
causes list.)
> What's the behavior of this Ruby program:
>
> require 'rubygems'
> require 'ncurses'
>
> Ncurses.initscr
> c = Ncurses.getch
> Ncurses.endwin
>
> puts c
This program exits right away, so I don't really know how to test it.
--
Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
------------------------------
Message: 669
Date: Fri, 31 Jul 2009 12:01:08 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Smooth Paging
Message-ID: <1249056026-sup-1964@Longbow>
Content-Type: text/plain; charset=utf8
Excerpts from William Morgan's message of Fri Jul 31 11:44:25 -0400 2009:
> Reformatted excerpts from Andrei Thorp's message of 2009-07-31:
> > What do you guys think?
>
> Have you tried J and K vs j and k to scroll?
No I haven't, but I'm glad to know they exist :)
Thanks.
--
Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
------------------------------
Message: 670
Date: Fri, 31 Jul 2009 12:11:29 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Smooth Paging
Message-ID: <1249056674-sup-2428@Longbow>
Content-Type: text/plain; charset=utf8
Excerpts from William Morgan's message of Fri Jul 31 11:57:43 -0400 2009:
> Reformatted excerpts from Edward Z. Yang's message of 2009-07-31:
> > In general, I use PgUp and PgDn to scroll. I didn't realize those
> > keybindings existed. :-)
>
> Ctrl-e and ctrl-y work as well, if you're a vi addict.
I didn't even know that one o_0. (in vim)
--
Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
------------------------------
Message: 671
Date: Fri, 31 Jul 2009 12:20:41 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH 0/18] Xapian-based index
Message-ID: <1249056691-sup-9011@pion.club.cc.cmu.edu>
Content-Type: text/plain; charset=UTF-8
Excerpts from Rich Lane's message of Mon Jul 27 13:06:34 -0400 2009:
> Excerpts from William Morgan's message of Mon Jul 27 11:48:38 -0400 2009:
> > Reformatted excerpts from Rich Lane's message of 2009-07-25:
> > > One issue I've noticed is that removing labels from messages doesn't
> > > always immediately work.
> >
> > Is this true even after you sync changes to the index? What about if you
> > reload the label list buffer? ('@')
>
> Yes. This is looking like a Xapian bug - I've reproduced it without any
> Sup code. I'm working on a fix.
I've fixed this, it should be released in Xapian 1.0.15. Or, grab Xapian
SVN and you can try out the Chert backend too (XAPIAN_PREFER_CHERT=1).
------------------------------
Message: 672
Date: Fri, 31 Jul 2009 12:59:16 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup on opensolaris
Message-ID: <1249059493-sup-7953@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Fri Jul 31 11:56:52 -0400 2009:
> Thanks for the report! It's nice to have another system "supported", at
> least technically.
I'm the ruby maintainer for OpenCSW, which provides binary packages
for solaris 8+ linked against a modern curses. Everything lives in
/opt/csw/, so it's self contained except where linking to system
stuff.
I _think_ this should all work on opensolaris (but I don't use it) if
you're interested in trying it. That won't help things like %P (%z is
another common offender I come across), but it may make part of your
life easier.
You'll get a modern libiconv too, although the version in opensolaris
shouldn't be that old?
http://www.opencsw.org/
HTH
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090731/84805c4a/attachment-0001.bin>
------------------------------
Message: 673
Date: Sat, 01 Aug 2009 02:28:19 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] xapian question
Message-ID: <1249098509-sup-6664@pion.club.cc.cmu.edu>
Content-Type: text/plain; charset=UTF-8
I tried out using add_term/remove_term for immediate label changes. It's
significantly faster than sync_message, but it still makes the interface
feel laggy. There's known room for improvement in Xapian's
replace_document. However, we'll still have a lot of latency when we
start using remote sup-servers, so I don't think it's a good idea to do
these index operations synchronously with the UI.
We could queue up index writes and execute them in a background thread.
We'd want label additions to show up immediately in a search, though.
This is easy to do for inbox-mode and label-view-mode, which covers most
of my daily usage. If/when we support multiple clients connecting to a
sup-server, we'll need a way to notify them that someone else modified a
message. We can implement a simple version of this now that notifies
search-results-mode after the write completes.
If we're getting rid of buffer saving, it'd probably be easiest to use a
weak-ref table so we keep at most 1 copy of each message in memory -
this would make updating messages across buffers simpler.
How is sup-server development going?
------------------------------
Message: 674
Date: Sat, 01 Aug 2009 11:26:25 +0200
From: Christopher Bertels <mailinglist@flasht.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Smooth Paging
Message-ID: <1249118728-sup-5483@thinkpad-debian>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Fr Jul 31 17:44:25 +0200 2009:
> Have you tried J and K vs j and k to scroll?
Wow, cool. :)
Good to know.
--
================================
Christopher Bertels
http://www.adztec-independent.de
------------------------------
Message: 675
Date: Sat, 1 Aug 2009 19:44:50 +0200
From: Guillaume Quintard <guillaume.quintard@gmail.com>
To: "Sup-talk@rubyforge.org" <sup-talk@rubyforge.org>
Subject: [sup-talk] Fwd: xapian merged into next
Message-ID:
<1e5fdab70908011044q6743d213o554a7bd039e237c2@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
I get this when I run "SUP_INDEX=xapian ruby -Ilib bin/sup-sync --all
--all-sources --restore dumpfile" (only had the time to do it today):
./lib/sup/xapian_index.rb:435:in `replace_document':
InvalidArgumentError: Term too long (> 245):
E"name.surname@enst-bretagne.fr,
my_name.my_surname@enst-bretagne.fr, name.surname@enst-bretagne.fr,
name.surname@enst-bretagne.fr,
name.surname@telecom-bretagne.eu,
name.surname@telecom-bretagne.eu,
name.surname@telecom-bretagne.eu, name.surname"@telecom-bretagne.eu
(ArgumentError)
? ? ? ?from ./lib/sup/xapian_index.rb:435:in `index_message'
? ? ? ?from ./lib/sup/xapian_index.rb:117:in `sync_message'
? ? ? ?from /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
? ? ? ?from ./lib/sup/xapian_index.rb:330:in `synchronize'
? ? ? ?from ./lib/sup/xapian_index.rb:116:in `sync_message'
? ? ? ?from ./lib/sup/util.rb:519:in `send'
? ? ? ?from ./lib/sup/util.rb:519:in `method_missing'
? ? ? ?from ./lib/sup/poll.rb:157:in `add_messages_from'
? ? ? ?from ./lib/sup/source.rb:100:in `each'
? ? ? ?from ./lib/sup/util.rb:558:in `send'
? ? ? ?from ./lib/sup/util.rb:558:in `__pass'
? ? ? ?from ./lib/sup/util.rb:545:in `method_missing'
? ? ? ?from ./lib/sup/poll.rb:141:in `add_messages_from'
? ? ? ?from ./lib/sup/util.rb:519:in `send'
? ? ? ?from ./lib/sup/util.rb:519:in `method_missing'
? ? ? ?from bin/sup-sync:140
? ? ? ?from bin/sup-sync:135:in `each'
? ? ? ?from bin/sup-sync:135
Cheers!
--
Guillaume
------------------------------
Message: 676
Date: Sat, 01 Aug 2009 14:14:34 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Fwd: xapian merged into next
Message-ID: <1249149855-sup-2211@pion.club.cc.cmu.edu>
Content-Type: text/plain; charset=UTF-8
Excerpts from Guillaume Quintard's message of Sat Aug 01 13:44:50 -0400 2009:
> E"name.surname@enst-bretagne.fr,
> my_name.my_surname@enst-bretagne.fr, name.surname@enst-bretagne.fr,
> name.surname@enst-bretagne.fr,
> name.surname@telecom-bretagne.eu,
> name.surname@telecom-bretagne.eu,
> name.surname@telecom-bretagne.eu, name.surname"@telecom-bretagne.eu
That's a very strange email address :). Could you track down the message
causing this and post the headers? It looks like it's getting parsed
incorrectly.
I think we'd be safe not adding terms for email addresses longer than
244 characters on the assumption that the user isn't going to want to
search for them.
------------------------------
Message: 677
Date: Sat, 01 Aug 2009 20:31:55 +0200
From: Guillaume Quintard <guillaume.quintard@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Fwd: xapian merged into next
Message-ID: <1249151189-sup-3864@altis>
Content-Type: text/plain; charset=UTF-8
Excerpts from Rich Lane's message of Sat Aug 01 20:14:34 +0200 2009:
> I think we'd be safe not adding terms for email addresses longer than
> 244 characters on the assumption that the user isn't going to want to
> search for them.
http://files.getdropbox.com/u/155904/grepped
I did a simple grep, tell me if it's not enough (I'd rather not dive
into the humongous mbox file).
The mails come from the mailing-list admin tool (sympa), encoding
problem it looks, the mangled part is "Propri?taires de liste" (list
owners in french)
--
Guillaume
------------------------------
Message: 678
Date: Sat, 01 Aug 2009 17:58:13 -0400
From: vasudeva <vasudeva@linkswarm.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Smooth Paging
Message-ID: <1249163726-sup-5839@lenin>
Content-Type: text/plain; charset=UTF-8
Excerpts from Christopher Bertels's message of Sat Aug 01 05:26:25 -0400 2009:
> Excerpts from William Morgan's message of Fr Jul 31 17:44:25 +0200 2009:
> > Have you tried J and K vs j and k to scroll?
>
> Wow, cool. :)
> Good to know.
That is nifty -- I didn't know it existed either. It seems slow on this machine though, and after using it in thread-view-mode, inbox-mode seems to have lost its mind a bit.
I had wondered if the behavior the original poster was after might be akin to vim's 'scrolloff' setting.
Setting scrolloff=10 in vim means the selected line moves freely up and down but you're always going to have 10 lines of context at the edges; that is, the text starts scrolling upward when the selected line reaches 10 lines from the bottom. It kind of applies a 'force field' to the top and bottom edges of the page view so you never hit top or bottom of the viewport until you're at the top or bottom of the file itself.
--
linkswarm.com :: Collaborative Insolence
vasudeva.linkswarm.com/gallery2 :: For The Faint of Heart
------------------------------
Message: 679
Date: Sat, 1 Aug 2009 15:56:09 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH] xapian: drop excessively long terms
Message-ID: <1249167369-16043-1-git-send-email-rlane@club.cc.cmu.edu>
---
lib/sup/xapian_index.rb | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
index 6358a20..5a5dfc1 100644
--- a/lib/sup/xapian_index.rb
+++ b/lib/sup/xapian_index.rb
@@ -304,6 +304,8 @@ class XapianIndex < BaseIndex
DATE_VALUENO = 0
+ MAX_TERM_LENGTH = 245
+
# Xapian can very efficiently sort in ascending docid order. Sup always wants
# to sort by descending date, so this method maps between them. In order to
# handle multiple messages per second, we use a logistic curve centered
@@ -428,7 +430,7 @@ class XapianIndex < BaseIndex
@term_generator.document = doc
text.each { |text,prefix| @term_generator.index_text text, 1, prefix }
- terms.each { |term| doc.add_term term }
+ terms.each { |term| doc.add_term term if term.length <= MAX_TERM_LENGTH }
doc.add_value DATE_VALUENO, date_value
doc.data = m.id
--
1.6.0.4
------------------------------
Message: 680
Date: Sat, 01 Aug 2009 19:03:06 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Fwd: xapian merged into next
Message-ID: <1249167402-sup-6423@pion.club.cc.cmu.edu>
Content-Type: text/plain; charset=UTF-8
Excerpts from Guillaume Quintard's message of Sat Aug 01 14:31:55 -0400 2009:
> Excerpts from Rich Lane's message of Sat Aug 01 20:14:34 +0200 2009:
> > I think we'd be safe not adding terms for email addresses longer than
> > 244 characters on the assumption that the user isn't going to want to
> > search for them.
>
> http://files.getdropbox.com/u/155904/grepped
>
> I did a simple grep, tell me if it's not enough (I'd rather not dive
> into the humongous mbox file).
> The mails come from the mailing-list admin tool (sympa), encoding
> problem it looks, the mangled part is "Propri?taires de liste" (list
> owners in french)
>
I posted a patch that should keep Xapian from throwing an exception
with long email addresses. I'm not any sort of encoding expert, but I'd
guess that sup isn't responsible for the mangling.
------------------------------
Message: 681
Date: Sun, 02 Aug 2009 01:35:25 +0200
From: Guillaume Quintard <guillaume.quintard@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Fwd: xapian merged into next
Message-ID: <1249169629-sup-5176@altis>
Content-Type: text/plain; charset=UTF-8
Excerpts from Rich Lane's message of Sun Aug 02 01:03:06 +0200 2009:
> with long email addresses. I'm not any sort of encoding expert, but I'd
> guess that sup isn't responsible for the mangling.
it isn't, the mangling comes from the mbox file, yet sup was able to
import it at some point. I guesse the quotes don't really help.
--
Guillaume
------------------------------
Message: 682
Date: Sun, 02 Aug 2009 01:51:06 +0200
From: Christopher Bertels <mailinglist@flasht.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Smooth Paging
Message-ID: <1249170613-sup-5276@thinkpad-debian>
Content-Type: text/plain; charset=UTF-8
Excerpts from vasudeva's message of Sa Aug 01 23:58:13 +0200 2009:
> I had wondered if the behavior the original poster was after might be akin to
> vim's 'scrolloff' setting.
>
> Setting scrolloff=10 in vim means the selected line moves freely up and down
> but you're always going to have 10 lines of context at the edges; that is, the
> text starts scrolling upward when the selected line reaches 10 lines from the
> bottom. It kind of applies a 'force field' to the top and bottom edges of the
> page view so you never hit top or bottom of the viewport until you're at the
> top or bottom of the file itself.
I'd actually love to see something like this in sup as well.
--
================================
Christopher Bertels
http://www.adztec-independent.de
------------------------------
Message: 683
Date: Sun, 2 Aug 2009 15:11:44 +0200
From: "Igor Brkic" <Igor.Brkic@fer.hr>
To: <sup-talk@rubyforge.org>
Subject: [sup-talk] sup crashing after sending mail
Message-ID: <CBBB81512D1FE445823400465FCCFFF2D8AA45@sluga.fer.hr>
Content-Type: text/plain; charset="iso-8859-1"
Hello to everyone! I'm new sup user and so far I have found it to be exactly what I was looking for, but there is one problem - I cannot send mail :(
For mail sending I use sSMTP and my ISP's SMTP server. When I try to send mail from sup, after pressing y on keyboard, mail gets sent but sup crashes (exception-log_0.txt in attachment). After that when I try to run sup, GUI shows up, but after few seconds ("Polling for new messages") it crashes again (exception-log_1.txt in attachment).
Cheers,
Igor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090802/d29461bd/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: exception-log_0.txt
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090802/d29461bd/attachment-0002.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: exception-log_1.txt
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090802/d29461bd/attachment-0003.txt>
------------------------------
Message: 684
Date: Sun, 02 Aug 2009 17:23:47 +0200
From: Beno?t PIERRE <benoit.pierre@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] [PATCH] run-mailcap fix
Message-ID: <1249226521-sup-4719@localdomain>
Content-Type: text/plain; charset="utf-8"
I use this line in my ~/.mailcap to view HTML attachements in Mutt:
text/html; w3m -dump -T text/html %s | pager; needsterminal; description=HTML Text; nametemplate=%s.html
which doesn't work with Sup. The attached patch fix this by not redirecting
stderr to /dev/null. It also restores the correct ncurses state (including
arrow keypresses, thanks to Edward Z. Yang recent patch).
--
A: Because it destroys the flow of conversation.
Q: Why is top posting dumb?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sup-run-mailcap.patch
Type: application/octet-stream
Size: 704 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090802/1fa7b4f6/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090802/1fa7b4f6/attachment-0001.bin>
------------------------------
Message: 685
Date: Mon, 3 Aug 2009 09:16:24 +0100
From: Mark Drayton <mark@markdrayton.info>
To: sup-talk@rubyforge.org
Subject: [sup-talk] Stack overflow in regexp matcher
Message-ID:
<92457f310908030116k146a901aleee95a09db907d97@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi there
I'm trying to run sup 0.8.1 on Mac OS 10.5.6, Ruby 1.8.6 but sup-sync
is repeatedly dying:
MC-S001930:~ draytm01$ sup-sync -c
[..]
[Mon Aug 03 08:45:18 +0100 2009] Connecting to IMAP server foo:143...
[Mon Aug 03 08:45:18 +0100 2009] Logging in...
[..]
[Mon Aug 03 08:45:19 +0100 2009] fetching IMAP headers 1..1002
[Mon Aug 03 08:45:20 +0100 2009] done fetching IMAP headers
Scanning imap://foo/INBOX...
[..]
## read 440m (about 52%) @ 2.2m/s. 0:03:19 elapsed, about 0:03:03 remaining
[Mon Aug 03 08:48:49 +0100 2009] unlocking /Users/draytm01/.sup/lock...
/Library/Ruby/Gems/1.8/gems/sup-0.8.1/lib/sup/util.rb:204:in `split':
Stack overflow in regexp matcher:
/,\s*(?=(?:[^"]*"[^"]*")*(?![^"]*"))/ (RegexpError)
from /Library/Ruby/Gems/1.8/gems/sup-0.8.1/lib/sup/util.rb:204:in
`split_on_commas'
from /Library/Ruby/Gems/1.8/gems/sup-0.8.1/lib/sup/person.rb:110:in
`from_address_list'
from /Library/Ruby/Gems/1.8/gems/sup-0.8.1/lib/sup/message.rb:104:in
`parse_header'
from /Library/Ruby/Gems/1.8/gems/sup-0.8.1/lib/sup/message.rb:208:in
`load_from_source!'
from /Library/Ruby/Gems/1.8/gems/sup-0.8.1/lib/sup/poll.rb:151:in
`add_messages_from'
from /Library/Ruby/Gems/1.8/gems/sup-0.8.1/lib/sup/imap.rb:187:in `each'
from /Library/Ruby/Gems/1.8/gems/sup-0.8.1/lib/sup/imap.rb:175:in `upto'
from /Library/Ruby/Gems/1.8/gems/sup-0.8.1/lib/sup/imap.rb:175:in `each'
... 7 levels...
from /Library/Ruby/Gems/1.8/gems/sup-0.8.1/bin/sup-sync:135:in `each'
from /Library/Ruby/Gems/1.8/gems/sup-0.8.1/bin/sup-sync:135
from /usr/bin/sup-sync:19:in `load'
from /usr/bin/sup-sync:19
This error seems to have cropped up in other software so I suspect
it's a problem with Ruby, not sup. Anyone able to confirm this?
Cheers,
Mark
------------------------------
Message: 686
Date: Mon, 03 Aug 2009 10:18:50 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Odd bug with lazy-loaded messages
Message-ID: <1249319474-sup-8322@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Sorry I didn't respond to this earlier.
Reformatted excerpts from Edward Z. Yang's message of 2009-07-27:
> Specifically, the "default" opened message when I open a thread
> gets a weird misrendering of the headers that looks like:
>
> To: foo
> foo <foo@example.com>
> foo
>
> And so forth, for all lines in To and Cc.
This is because we store a couple variants of the address in the index
(e.g. the email address to the left of the @), so that a search on any
of them will bring up the message. Without #load_from_source!, the
message is loaded from the index, so it reflects those fields. So it's
basically a hack at this point. You could further hack it by undoing
that transformation. Or we could add the original version of the fields
to the index in a separate, non-searchable field, incurring the
associated storage penalties.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 687
Date: Mon, 03 Aug 2009 10:31:34 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Handling big mailing lists
Message-ID: <1249320458-sup-6019@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from iny+dev's message of 2009-07-29:
> I guess so. How long it takes to index few months of ruby-talk?
Offhand I see index speeds of 50-80 messages/s depending on index size,
backend, etc.
> Could Sup use IMAP search features?
No, that would require a very different architecture and philosophy.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 688
Date: Mon, 03 Aug 2009 11:03:54 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] xapian question
Message-ID: <1249320789-sup-2608@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Rich Lane's message of 2009-07-31:
> I tried out using add_term/remove_term for immediate label changes.
> It's significantly faster than sync_message,
Excellent.
> but it still makes the interface feel laggy. There's known room for
> improvement in Xapian's replace_document. However, we'll still have a
> lot of latency when we start using remote sup-servers, so I don't
> think it's a good idea to do these index operations synchronously with
> the UI.
I agree, synchronous is not an option.
> We could queue up index writes and execute them in a background
> thread. We'd want label additions to show up immediately in a search,
> though. This is easy to do for inbox-mode and label-view-mode, which
> covers most of my daily usage.
I'm fine with queuing up index writes and letting the user continue
while they take effect in the background. I'm also fine with the easier
option of just blocking during a search until the writes are complete.
> If/when we support multiple clients connecting to a sup-server, we'll
> need a way to notify them that someone else modified a message.
I think this is more of a nice-to-have than a necessity, but it would be
nice to have, even if it was a "we've detected a change somewhere on the
internet; reload? (y/n)"-kinda thing.
> How is sup-server development going?
Well. I have a simple version that stores "items" to files on disk, and
uses Ferret to provide the search semantics. It's modular enough that
upgrading to Xapian shouldn't be as painful as it was with Sup. There
are even unit tests that enforce the semantics of the modules. Go me.
I'm going to make a couple internal API changes in Sup and then try
throwing the code together.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 689
Date: Tue, 4 Aug 2009 11:56:11 +0200
From: Tomas Carnecky <tom@dbservice.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup on opensolaris
Message-ID: <F8547FC4-8D0A-40AB-9604-7CB49BED27EC@dbservice.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
I hate mailing lists that force me to subscribe. Luckily I have a
friend who was already subscribed and forwarded me the emails.
>
>> I have an ugly patch for lib/sup/textfield.rb that uses its own
>> string
>> buffer instead of relying on field_buffer(). It's not perfect, but it
>> at least allows me to write emails and assign tags.
>
> If it's not too much work to clean up, I'd be interested in this
> patch.
> The field buffer stuff is broken in weird ways anyways (the history
> never seems to be quite right), and anything that reduces the reliance
> on ncurses is always the right approach.
I never programed in ruby before and I don't intend to learn it. Feel
free to look at the last commit in the solaris-fixes:curses-form-
buffer branch. It is the simplest possible solution to the problem at
hand that didn't require me to learn too much ruby. It still needs a
considerable amount of work before it is useful (like, being able to
delete characters in the stringio buffer etc). I'm not planing to work
on the patch in the foreseeable future, but someone else might find
the patch useful as a starting point.
>
>> - strftime("%P") is a GNU extension, I work around this by using
>> strftime("%p").downcase.
>
> Submit a patch! I'm fine with this.
>
>> - Iconv.iconv(target + "//IGNORE", charset, text + " ") <- the "//
>> IGNORE" is causing an InvalidEncoding exception, removing it didn't
>> seem to cause any regressions
>
> Hm, this is a trickier one. Allegedly the //IGNORE reduces the
> exceptions thrown by Iconv, but since we're catching them all anyways,
> we might be able to get away with removing this. Or we could
> special-case it to your arch.
Both patches are available in the solaris-fixes master branch.
tom
------------------------------
Message: 690
Date: Wed, 05 Aug 2009 06:55:47 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] xapian: drop excessively long terms
Message-ID: <1249480531-sup-9805@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Applied, thanks!
BTW I've merged the xapian stuff into master.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 691
Date: Wed, 05 Aug 2009 16:09:26 +0200
From: Adeodato Sim? <dato@net.com.org.es>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] sup ignoring SIGTERM?
Message-ID: <1249481294-sup-9967@chistera.yi.org>
Content-Type: text/plain; charset=UTF-8
Hello,
it is my impression that sup is ignoring SIGTERM, whereas I would be
expecting for sup to clean up (including removal of the lock file) and
exit normally upon receiving this signal.
Any clues about this? (I tried inserting a "trap", but it didn't seem to
help.)
Thanks,
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
------------------------------
Message: 692
Date: Wed, 05 Aug 2009 10:54:31 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] xapian: drop excessively long terms
Message-ID: <1249484040-sup-1879@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Wed Aug 05 09:55:47 -0400 2009:
> BTW I've merged the xapian stuff into master.
Exciting days we live in. :-) Maybe I'll wait another week and update my local
checkout.
Cheers,
Edward
------------------------------
Message: 693
Date: Wed, 05 Aug 2009 08:29:27 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup crashing after sending mail
Message-ID: <1249486021-sup-1246@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Hi Igor,
Reformatted excerpts from Igor Brkic's message of 2009-08-02:
> For mail sending I use sSMTP and my ISP's SMTP server. When I try to
> send mail from sup, after pressing y on keyboard, mail gets sent but
> sup crashes (exception-log_0.txt in attachment).
A few people have reported this and I'm trying to track it down. Would
you mind applying the following patch, and then running:
sup-sync -a sup://sent
Hopefully that will generate a little debugging output I can use. Thanks!
diff --git a/lib/sup/message.rb b/lib/sup/message.rb
index 5372fc7..fc9af59 100644
--- a/lib/sup/message.rb
+++ b/lib/sup/message.rb
@@ -92,11 +92,11 @@ class Message
begin
Time.parse date
rescue ArgumentError => e
- #Redwood::log "faking mangled date header for #{@id} (orig #{header['date']
+ Redwood::log "faking mangled date header for #{@id} (orig #{header['date'].
Time.now
end
else
- #Redwood::log "faking non-existent date header for #{@id}"
+ Redwood::log "faking non-existent date header for #{@id}"
Time.now
end
diff --git a/lib/sup/poll.rb b/lib/sup/poll.rb
index 354bd21..365f828 100644
--- a/lib/sup/poll.rb
+++ b/lib/sup/poll.rb
@@ -148,7 +148,9 @@ EOS
labels = labels + (source.archived? ? [] : [:inbox])
m = Message.new :source => source, :source_info => offset, :labels => label
+ Redwood::log "XX before load: #{m.date.inspect}"
m.load_from_source!
+ Redwood::log "XX after load: #{m.date.inspect}"
if m.source_marked_read?
m.remove_label :unread
@@ -157,7 +159,9 @@ EOS
docid, entry = Index.load_entry_for_id m.id
HookManager.run "before-add-message", :message => m
+ Redwood::log "XX after add-message: #{m.date.inspect}"
m = yield(m, offset, entry) or next if block_given?
+ Redwood::log "XX after yield: #{m.date.inspect}"
times = Index.sync_message m, false, docid, entry, opts
UpdateManager.relay self, :added, m unless entry
end
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 694
Date: Wed, 05 Aug 2009 11:36:19 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] xapian: drop excessively long terms
Message-ID: <1249485678-sup-4545@pion.club.cc.cmu.edu>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Wed Aug 05 09:55:47 -0400 2009:
> BTW I've merged the xapian stuff into master.
Let's not advertise this as stable just yet - I've got a patchset that
removes the GDBM databases which will break compatibility. Using just
Xapian means better consistency if your kernel panics and potentially
better performance. However, I have some Xapian bugs to squash before
it's usable.
------------------------------
Message: 695
Date: Wed, 05 Aug 2009 08:48:35 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] xapian: drop excessively long terms
Message-ID: <1249487110-sup-1824@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Rich Lane's message of 2009-08-05:
> Let's not advertise this as stable just yet - I've got a patchset that
> removes the GDBM databases which will break compatibility.
Since the xapian stuff is only enabled via an obscure environment
variable, I'm not too concerned about it being uber-stable. I've merged
this more for the internal API changes, which seem stable and which I'm
now building off of.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 696
Date: Wed, 05 Aug 2009 19:29:48 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: Rich Lane <rlane@club.cc.cmu.edu>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] xapian: drop excessively long terms
Message-ID: <1249493306-sup-4994@ausone.home>
Content-Type: text/plain; charset=UTF-8
Excerpts from Rich Lane's message of Wed Aug 05 17:36:19 +0200 2009:
> Excerpts from William Morgan's message of Wed Aug 05 09:55:47 -0400 2009:
> > BTW I've merged the xapian stuff into master.
>
> Let's not advertise this as stable just yet -
> I've got a patchset that
> removes the GDBM databases which will break compatibility.
I was planning to try a migration today, should I better wait a little?
--
Nicolas Pouillard
http://nicolaspouillard.fr
------------------------------
Message: 697
Date: Wed, 05 Aug 2009 13:48:11 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: Nicolas Pouillard <nicolas.pouillard@gmail.com>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] xapian: drop excessively long terms
Message-ID: <1249493896-sup-7335@pion.club.cc.cmu.edu>
Content-Type: text/plain; charset=UTF-8
Excerpts from Nicolas Pouillard's message of Wed Aug 05 13:29:48 -0400 2009:
> I was planning to try a migration today, should I better wait a little?
I'd say go for it, just be aware you'll need to reindex soon. For the
full experience compile svn xapian and export XAPIAN_PREFER_CHERT=1.
------------------------------
Message: 698
Date: Wed, 05 Aug 2009 19:58:43 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: Rich Lane <rlane@club.cc.cmu.edu>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] xapian: drop excessively long terms
Message-ID: <1249495000-sup-6057@ausone.home>
Content-Type: text/plain; charset=UTF-8
Excerpts from Rich Lane's message of Wed Aug 05 19:48:11 +0200 2009:
> Excerpts from Nicolas Pouillard's message of Wed Aug 05 13:29:48 -0400 2009:
> > I was planning to try a migration today, should I better wait a little?
>
> I'd say go for it, just be aware you'll need to reindex soon. For the
> full experience compile svn xapian and export XAPIAN_PREFER_CHERT=1.
When you say the svn version you mean the trunk or the 1.0-branch ?
--
Nicolas Pouillard
http://nicolaspouillard.fr
------------------------------
Message: 699
Date: Wed, 05 Aug 2009 14:06:39 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: Nicolas Pouillard <nicolas.pouillard@gmail.com>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] xapian: drop excessively long terms
Message-ID: <1249495530-sup-6312@pion.club.cc.cmu.edu>
Content-Type: text/plain; charset=UTF-8
Excerpts from Nicolas Pouillard's message of Wed Aug 05 13:58:43 -0400 2009:
> Excerpts from Rich Lane's message of Wed Aug 05 19:48:11 +0200 2009:
> > Excerpts from Nicolas Pouillard's message of Wed Aug 05 13:29:48 -0400 2009:
> > > I was planning to try a migration today, should I better wait a little?
> >
> > I'd say go for it, just be aware you'll need to reindex soon. For the
> > full experience compile svn xapian and export XAPIAN_PREFER_CHERT=1.
>
> When you say the svn version you mean the trunk or the 1.0-branch ?
Trunk.
------------------------------
Message: 700
Date: Wed, 05 Aug 2009 13:03:09 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup ignoring SIGTERM?
Message-ID: <1249502171-sup-8079@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Adeodato Sim?'s message of 2009-08-05:
> it is my impression that sup is ignoring SIGTERM, whereas I would be
> expecting for sup to clean up (including removal of the lock file) and
> exit normally upon receiving this signal.
Good point. I've fixed that in branch ncurses-fixes, which I've merged
into next. Let me know if it works for you.
I'm also happy to report that I've finally managed to get Sup to deal
with screen resizes, which, oddly enough, was a related problem. Go me!
Steps closer to curses-induced insanity: 4!
Available on next or ncurses-fixes branches.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 701
Date: Wed, 05 Aug 2009 22:25:49 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup ignoring SIGTERM?
Message-ID: <1249503870-sup-1415@ausone.home>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Wed Aug 05 22:03:09 +0200 2009:
> Reformatted excerpts from Adeodato Sim?'s message of 2009-08-05:
> > it is my impression that sup is ignoring SIGTERM, whereas I would be
> > expecting for sup to clean up (including removal of the lock file) and
> > exit normally upon receiving this signal.
>
> Good point. I've fixed that in branch ncurses-fixes, which I've merged
> into next. Let me know if it works for you.
>
> I'm also happy to report that I've finally managed to get Sup to deal
> with screen resizes, which, oddly enough, was a related problem. Go me!
> Steps closer to curses-induced insanity: 4!
>
> Available on next or ncurses-fixes branches.
With the ncurses-fixes branch (even with the last patch), when I launch sup
I get a blank screen (with the status bar saying "Searching for threads...".
--
Nicolas Pouillard
http://nicolaspouillard.fr
------------------------------
Message: 702
Date: Wed, 05 Aug 2009 16:35:51 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup ignoring SIGTERM?
Message-ID: <1249504381-sup-8445@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Wed Aug 05 16:03:09 -0400 2009:
> Good point. I've fixed that in branch ncurses-fixes, which I've merged
> into next. Let me know if it works for you.
I just pulled next and fired it up. It was _hoooooribly_,
_bruuuutallly_ slow to load the index. I git bisected between my
previous running ORIG_HEAD and HEAD. I came up with 75d9f5e3db as the
offender. It seems to do what you intend but (for me, anyway) at the
expense of really bad interactivity. [We're talking 10+ minutes to
load the index part way...]
This doesn't help identify the problem, but I'd be looking at the
Ncurses.nodelay bits...
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090805/b4062212/attachment-0001.bin>
------------------------------
Message: 703
Date: Wed, 05 Aug 2009 14:24:49 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup ignoring SIGTERM?
Message-ID: <1249507336-sup-7887@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Nicolas Pouillard's message of 2009-08-05:
> With the ncurses-fixes branch (even with the last patch), when I
> launch sup I get a blank screen (with the status bar saying "Searching
> for threads...".
Dammit. I see that too, on some computers. The problem is that
Ncurses.getch is actually blocking the background threads from working.
(You can tell because threads will start loading when you press lots of
keys.)
I've unmerged the branch from next for the time being.
The problem is the removal of the select() in nonblocking_getch
(buffer.rb circa line 25). With it in, resizes don't work right. With it
removed, background threads are blocked on some computers. Not sure what
makes the difference. Sigh...
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 704
Date: Wed, 05 Aug 2009 17:28:43 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup ignoring SIGTERM?
Message-ID: <1249507702-sup-8439@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Wed Aug 05 16:03:09 -0400 2009:
> I'm also happy to report that I've finally managed to get Sup to deal
> with screen resizes, which, oddly enough, was a related problem. Go me!
> Steps closer to curses-induced insanity: 4!
Sounds exciting. What was the fix?
Cheers,
Edward
------------------------------
Message: 705
Date: Thu, 06 Aug 2009 01:24:38 +0200
From: Igor Brkic <igor.brkic@fer.hr>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup crashing after sending mail
Message-ID: <1249514106-sup-9112@xps>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Sri Kol 05 17:29:27 +0200 2009:
> A few people have reported this and I'm trying to track it down. Would
> you mind applying the following patch, and then running:
> sup-sync -a sup://sent
>
> Hopefully that will generate a little debugging output I can use. Thanks!
I (partially) solved/hacked the problem. The problem was (I think) in wrong
set locale and Sup not being able to recognize and compare sending date
(which had croatian tags for month and day of the week) and Time.now (which
was whole in english/universal format).
I solved the problem by commenting out the "Time.parse time, 0" (line 15 in
file lib/sup/mbox.rb).
It's not perfect solution (if that line should be commented out, it would
be :D), but for me it works for now (I'm writing this mail from it).
Cheers!
Igor Brkic
------------------------------
Message: 706
Date: Thu, 06 Aug 2009 07:40:08 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup crashing after sending mail
Message-ID: <1249568949-sup-3922@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Igor Brkic's message of 2009-08-05:
> I solved the problem by commenting out the "Time.parse time, 0" (line
> 15 in file lib/sup/mbox.rb).
I'm glad that works, but I have a hard time understanding why.
That line is for parsing the mbox "From " separator line (which has a
date on it). It has nothing to do with the date field in the message,
which is what isn't being set (and thus raising the exception).
If the date parsing on that line is screwed up, then I would except to
see an out-of-sync error raised by Sup, since it would be expecting an
mbox "From " separator line and wouldn't detect the line as such.
If you feel like it, send me a small mbox file (possible your
~/.sup/sent.mbox after being censored) and I can take a look.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 707
Date: Thu, 06 Aug 2009 18:57:03 +0200
From: Igor Brkic <igor.brkic@fer.hr>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup crashing after sending mail
Message-ID: <1249576777-sup-3885@xps>
Content-Type: text/plain; charset=utf8
Excerpts from William Morgan's message of ?et Kol 06 16:40:08 +0200 2009:
>
> If you feel like it, send me a small mbox file (possible your
> ~/.sup/sent.mbox after being censored) and I can take a look.
This is weird... For the last hour and a half I've been trying to
reproduce the error I was having - I uncommented the line in mbox.rb,
returned locale settings to previous state - but everything is working
flawless. Whatever I make, it won't crash. I'll keep trying, though :)
I'm afraid I can't send you the mbox file that is causing sup to crash
because I deleted all logs and sent.mbox files the moment all started
to work.
------------------------------
Message: 708
Date: Thu, 06 Aug 2009 19:26:15 +0200
From: Igor Brkic <igor.brkic@fer.hr>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup crashing after sending mail
Message-ID: <1249579173-sup-573@xps>
Content-Type: text/plain; charset="utf8"
Excerpts from Igor Brkic's message of ?et Kol 06 18:57:03 +0200 2009:
> flawless. Whatever I make, it won't crash. I'll keep trying, though :)
Interestingly, I managed to crash sup with sending last mail (Time.parse
line in mbox.rb wasn't commented).
I attached output of "sup-sync -a sup://sent" with patch you sent me
applyed (sync-log.txt).
BTW I am using gem (0.8.1) version of sup, but the same happens eith git
version.
I also attached sent.mbox file that causes sup to crash (only if the
Time.parse line is not commented - I am writing this mail from sup with
that line commented and everything works ok).
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: sync-log.txt
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090806/fd1be639/attachment-0001.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sent.mbox-crash
Type: application/octet-stream
Size: 3561 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090806/fd1be639/attachment-0001.obj>
------------------------------
Message: 709
Date: Thu, 06 Aug 2009 10:45:50 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup crashing after sending mail
Message-ID: <1249580716-sup-6413@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Igor Brkic's message of 2009-08-06:
> I attached output of "sup-sync -a sup://sent" with patch you sent me
> applyed (sync-log.txt).
Awesome. This looks very juicy. Thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 710
Date: Thu, 06 Aug 2009 10:53:43 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup ignoring SIGTERM?
Message-ID: <1249581215-sup-2548@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from William Morgan's message of 2009-08-05:
> The problem is the removal of the select() in nonblocking_getch
> (buffer.rb circa line 25). With it in, resizes don't work right. With
> it removed, background threads are blocked on some computers. Not sure
> what makes the difference. Sigh...
Ok, I've tracked this down. FWIW, this is a problem that's been around
in ruby ncurses libraries since at least 2005, when I complained about
it on ruby-core.
In many ruby ncurses libraries, including the most recent gem,
Ncurses.getch blocks all Ruby threads from running. That's a bug. The
workaround is to wrap it in a select() call. But then you have to handle
sigwinch manually (i.e via Kernel#trap), because getch won't return a
resize "keystroke" until the user hits an actual key.
The libncurses-ruby library on modern Ubuntu systems actually doesn't
have this problem. You can set nodelay false, throw out the select call,
and everything works the way it's supposed to: background threads run,
and you get a resize keystroke when a sigwinch happens without you
having to install your own handler. And that's the library I had been
developing against, which is why everything worked on one computer but
didn't work on the others.
Anyways, for those who were having problems with this branch before,
please try the most recent version and confirm that:
1. Email threads load as normal, i.e. in the background.
2. Resizing the terminal refreshes the screen without you having to
press any keys.
3. Ctrl-l still works.
4. Ctrl-c still works (prompts you, and y/n do the right thing).
5. Killing Sup works.
If everyone's happy, I'll merge this branch into next.
If you're curious about whether you have a good or bad ncurses library,
run this program: (But either should work correctly with Sup.)
require 'rubygems'
require 'ncurses'
require 'thread'
Ncurses.initscr
Ncurses.noecho
Ncurses.cbreak
Ncurses.curs_set 0
Thread.new do
sleep 0.1
Ncurses.stdscr.mvaddstr 0, 0, "ncurses library is GOOD."
end
begin
Ncurses.stdscr.mvaddstr 0, 0, "ncurses library is BAD."
Ncurses.getch
ensure
Ncurses.curs_set 1
Ncurses.endwin
puts "bye"
end
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 711
Date: Thu, 06 Aug 2009 20:09:35 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup ignoring SIGTERM?
Message-ID: <1249582142-sup-9952@ausone.home>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Thu Aug 06 19:53:43 +0200 2009:
> Reformatted excerpts from William Morgan's message of 2009-08-05:
> > The problem is the removal of the select() in nonblocking_getch
> > (buffer.rb circa line 25). With it in, resizes don't work right. With
> > it removed, background threads are blocked on some computers. Not sure
> > what makes the difference. Sigh...
[...]
> If everyone's happy, I'll merge this branch into next.
Works just great! Thanks.
--
Nicolas Pouillard
http://nicolaspouillard.fr
------------------------------
Message: 712
Date: Thu, 6 Aug 2009 20:37:25 +0200
From: Adeodato Sim? <dato@net.com.org.es>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup ignoring SIGTERM?
Message-ID: <20090806183725.GA8363@chistera.yi.org>
Content-Type: text/plain; charset=utf-8
+ William Morgan (Wed, 05 Aug 2009 13:03:09 -0700):
> Reformatted excerpts from Adeodato Sim?'s message of 2009-08-05:
> > it is my impression that sup is ignoring SIGTERM, whereas I would be
> > expecting for sup to clean up (including removal of the lock file) and
> > exit normally upon receiving this signal.
> Good point. I've fixed that in branch ncurses-fixes, which I've merged
> into next. Let me know if it works for you.
Everything seems to work fine as of 3478e40, including sup terminating
upon SIGTERM. If I may, I'd suggest normal termination instead of
raising an exception. IMHO, it is expected that programs that capture
SIGTERM, will do cleanup and exit normally, rather than behave as if an
error had happened. (Perhaps it'd be difficult to exit sup cleanly from
the handler in any other way than an exception: that, I don't know.)
Thanks, in any case.
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
------------------------------
Message: 713
Date: Thu, 06 Aug 2009 19:56:51 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup ignoring SIGTERM?
Message-ID: <1249602985-sup-8547@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Thu Aug 06 13:53:43 -0400 2009:
> Ok, I've tracked this down. FWIW, this is a problem that's been around
> in ruby ncurses libraries since at least 2005, when I complained about
> it on ruby-core.
...yup, looks like you stuck the landing this time! :)
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090806/72c6f045/attachment-0001.bin>
------------------------------
Message: 714
Date: Thu, 06 Aug 2009 18:38:53 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup ignoring SIGTERM?
Message-ID: <1249609105-sup-5858@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Adeodato Sim?'s message of 2009-08-06:
> Everything seems to work fine as of 3478e40, including sup terminating
> upon SIGTERM. If I may, I'd suggest normal termination instead of
> raising an exception. IMHO, it is expected that programs that capture
> SIGTERM, will do cleanup and exit normally, rather than behave as if
> an error had happened.
Good idea. Try it now.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 715
Date: Fri, 7 Aug 2009 12:31:51 +0200
From: Adeodato Sim? <dato@net.com.org.es>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] sup ignoring SIGTERM?
Message-ID: <20090807103151.GA20799@chistera.yi.org>
Content-Type: text/plain; charset=utf-8
+ William Morgan (Thu, 06 Aug 2009 18:38:53 -0700):
> Reformatted excerpts from Adeodato Sim?'s message of 2009-08-06:
> > Everything seems to work fine as of 3478e40, including sup terminating
> > upon SIGTERM. If I may, I'd suggest normal termination instead of
> > raising an exception. IMHO, it is expected that programs that capture
> > SIGTERM, will do cleanup and exit normally, rather than behave as if
> > an error had happened.
> Good idea. Try it now.
Ah, excellent: works as suggested now.
Regarding 57dea7a (refactor index locking interaction and replace
suicidemanager), I'll note that at least on my system, and after having
moved to Xapian, those codepaths no longer execute. That is, if a sup is
running and a second one is started, it never gets to ask whether to
suggest dieing to the first one, because this second one dies with:
[Fri Aug 07 12:31:05 +0200 2009] using character set encoding "UTF-8"
[Fri Aug 07 12:31:05 +0200 2009] using index Redwood::XapianIndex
[Fri Aug 07 12:31:05 +0200 2009] dynamically loading setlocale() from libc.so.6
[Fri Aug 07 12:31:05 +0200 2009] setting locale...
.../lib/sup/xapian_index.rb:24:in `initialize': Resource temporarily unavailable - /home/adeodato/.sup/entries.db (Errno::EAGAIN)
from .../lib/sup/xapian_index.rb:24:in `new'
from .../lib/sup/xapian_index.rb:24:in `initialize'
from .../bin/sup:132:in `new'
from .../bin/sup:132
Thanks!
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
------------------------------
Message: 716
Date: Thu, 6 Aug 2009 12:32:44 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH] move xapian index loading into load_index
Message-ID: <1249587164-14080-1-git-send-email-rlane@club.cc.cmu.edu>
---
lib/sup/xapian_index.rb | 17 ++++++++---------
1 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
index 5a5dfc1..861c2a3 100644
--- a/lib/sup/xapian_index.rb
+++ b/lib/sup/xapian_index.rb
@@ -20,14 +20,16 @@ class XapianIndex < BaseIndex
super
@index_mutex = Monitor.new
+ end
- @entries = MarshalledGDBM.new File.join(dir, "entries.db")
- @docids = MarshalledGDBM.new File.join(dir, "docids.db")
- @thread_members = MarshalledGDBM.new File.join(dir, "thread_members.db")
- @thread_ids = MarshalledGDBM.new File.join(dir, "thread_ids.db")
- @assigned_docids = GDBM.new File.join(dir, "assigned_docids.db")
+ def load_index
+ @entries = MarshalledGDBM.new File.join(@dir, "entries.db")
+ @docids = MarshalledGDBM.new File.join(@dir, "docids.db")
+ @thread_members = MarshalledGDBM.new File.join(@dir, "thread_members.db")
+ @thread_ids = MarshalledGDBM.new File.join(@dir, "thread_ids.db")
+ @assigned_docids = GDBM.new File.join(@dir, "assigned_docids.db")
- @xapian = Xapian::WritableDatabase.new(File.join(dir, "xapian"), Xapian::DB_CREATE_OR_OPEN)
+ @xapian = Xapian::WritableDatabase.new(File.join(@dir, "xapian"), Xapian::DB_CREATE_OR_OPEN)
@term_generator = Xapian::TermGenerator.new()
@term_generator.stemmer = Xapian::Stem.new(STEM_LANGUAGE)
@enquire = Xapian::Enquire.new @xapian
@@ -35,9 +37,6 @@ class XapianIndex < BaseIndex
@enquire.docid_order = Xapian::Enquire::ASCENDING
end
- def load_index
- end
-
def save_index
end
--
1.6.4
------------------------------
Message: 717
Date: Fri, 07 Aug 2009 12:40:18 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup ignoring SIGTERM?
Message-ID: <1249662782-sup-638@pion.club.cc.cmu.edu>
Content-Type: text/plain; charset=UTF-8
Excerpts from Adeodato Sim?'s message of Fri Aug 07 06:31:51 -0400 2009:
> Regarding 57dea7a (refactor index locking interaction and replace
> suicidemanager), I'll note that at least on my system, and after having
> moved to Xapian, those codepaths no longer execute. That is, if a sup is
> running and a second one is started, it never gets to ask whether to
> suggest dieing to the first one, because this second one dies with:
>
> [Fri Aug 07 12:31:05 +0200 2009] using character set encoding "UTF-8"
> [Fri Aug 07 12:31:05 +0200 2009] using index Redwood::XapianIndex
> [Fri Aug 07 12:31:05 +0200 2009] dynamically loading setlocale() from libc.so.6
> [Fri Aug 07 12:31:05 +0200 2009] setting locale...
> .../lib/sup/xapian_index.rb:24:in `initialize': Resource temporarily
> unavailable - /home/adeodato/.sup/entries.db (Errno::EAGAIN)
> from .../lib/sup/xapian_index.rb:24:in `new'
> from .../lib/sup/xapian_index.rb:24:in `initialize'
> from .../bin/sup:132:in `new'
> from .../bin/sup:132
I've just posted a patch that should fix this.
------------------------------
Message: 718
Date: Sat, 08 Aug 2009 02:07:22 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Odd bug with lazy-loaded messages
Message-ID: <1249711570-sup-2277@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Mon Aug 03 13:18:50 -0400 2009:
> This is because we store a couple variants of the address in the index
> (e.g. the email address to the left of the @), so that a search on any
> of them will bring up the message. Without #load_from_source!, the
> message is loaded from the index, so it reflects those fields. So it's
> basically a hack at this point. You could further hack it by undoing
> that transformation. Or we could add the original version of the fields
> to the index in a separate, non-searchable field, incurring the
> associated storage penalties.
Great. I sprinkled a few extra load_from_source! calls and I think
I made the weird behavior go away. It's kind of sketchy though.
>From 6c539b9c0fb952b0cc10c121cb906b1aefd58c31 Mon Sep 17 00:00:00 2001
From: Edward Z. Yang <edwardzyang@thewritingpot.com>
Date: Mon, 8 Jun 2009 22:21:01 -0400
Subject: [PATCH 1/3] Remove message pre-loading; optimizes for the common case.
There are some load_from_source! calls to flush away extra
header info that we don't want displayed. We may need to add
this in more/less places.
Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
---
lib/sup/modes/thread-index-mode.rb | 1 -
lib/sup/modes/thread-view-mode.rb | 2 ++
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb
index b671119..5e58072 100644
--- a/lib/sup/modes/thread-index-mode.rb
+++ b/lib/sup/modes/thread-index-mode.rb
@@ -105,7 +105,6 @@ EOS
t.each_with_index do |(m, *o), i|
next unless m
BufferManager.say "#{message} (#{i}/#{num})", sid if t.size > 1
- m.load_from_source!
end
end
mode = ThreadViewMode.new t, @hidden_labels, self
diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb
index 737f6f1..94e3ed7 100644
--- a/lib/sup/modes/thread-view-mode.rb
+++ b/lib/sup/modes/thread-view-mode.rb
@@ -124,6 +124,7 @@ EOS
end
end
+ latest.load_from_source!
@layout[latest].state = :open if @layout[latest].state == :closed
@layout[earliest].state = :detailed if earliest.has_label?(:unread) || @thread.size == 1
@@ -555,6 +556,7 @@ private
def initial_state_for m
if m.has_label?(:starred) || m.has_label?(:unread)
+ m.load_from_source!
:open
else
:closed
--
1.6.3.3
------------------------------
Message: 719
Date: Sat, 8 Aug 2009 11:23:25 +0200
From: Adeodato Sim? <dato@net.com.org.es>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] sup ignoring SIGTERM?
Message-ID: <20090808092325.GA2392@chistera.yi.org>
Content-Type: text/plain; charset=us-ascii
+ Rich Lane (Fri, 07 Aug 2009 12:40:18 -0400):
> > [Fri Aug 07 12:31:05 +0200 2009] using character set encoding "UTF-8"
> > [Fri Aug 07 12:31:05 +0200 2009] using index Redwood::XapianIndex
> > [Fri Aug 07 12:31:05 +0200 2009] dynamically loading setlocale() from libc.so.6
> > [Fri Aug 07 12:31:05 +0200 2009] setting locale...
> > .../lib/sup/xapian_index.rb:24:in `initialize': Resource temporarily
> > unavailable - /home/adeodato/.sup/entries.db (Errno::EAGAIN)
> > from .../lib/sup/xapian_index.rb:24:in `new'
> > from .../lib/sup/xapian_index.rb:24:in `initialize'
> > from .../bin/sup:132:in `new'
> > from .../bin/sup:132
> I've just posted a patch that should fix this.
It works, thank you!
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
------------------------------
Message: 720
Date: Sun, 09 Aug 2009 04:40:33 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Odd bug with lazy-loaded messages
Message-ID: <1249807206-sup-55@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from Edward Z. Yang's message of Sat Aug 08 02:07:22 -0400 2009:
> Great. I sprinkled a few extra load_from_source! calls and I think
> I made the weird behavior go away. It's kind of sketchy though.
It looks like it's still a problem in some sporadic cases. Going to
submit a more thorough patch soon.
Cheers,
Edward
------------------------------
Message: 721
Date: Mon, 10 Aug 2009 09:22:43 -0400
From: Jason Stewart <jstewart@fusionary.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Starring messages in a hook
Message-ID: <1249910430-sup-4573@JasonsComputer-3.local>
Content-Type: text/plain; charset=UTF-8
Hello,
New sup user here and I have to say that I'm very impressed with it even
though I've only been using it for a few days.
I'm using a before-add-message to label messages, and was wondering if
there's a way to star them in this hook? Looking at the source for
message.rb I see an add_label, but no add_star.
------------------------------
Message: 722
Date: Mon, 10 Aug 2009 11:07:38 -0400
From: Ian Smith <ismith@MIT.EDU>
To: Jason Stewart <jstewart@fusionary.com>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Starring messages in a hook
Message-ID: <1249916791-sup-4269@baad>
Content-Type: text/plain; charset=UTF-8
Hi Jason,
Starred messages are labeled "Starred"; presumably just adding this
label to the message would do what you want.
Ian
Excerpts from Jason Stewart's message of Mon Aug 10 09:22:43 -0400 2009:
> Hello,
>
> New sup user here and I have to say that I'm very impressed with it even
> though I've only been using it for a few days.
>
> I'm using a before-add-message to label messages, and was wondering if
> there's a way to star them in this hook? Looking at the source for
> message.rb I see an add_label, but no add_star.
--
Ian Smith
ismith@mit.edu
ismith@bostonaccess.org
------------------------------
Message: 723
Date: Tue, 11 Aug 2009 13:14:44 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk mailing list <sup-talk@rubyforge.org>
Subject: [sup-talk] some internal api refactors
Message-ID: <1250021119-sup-4253@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Hi Rich, and others,
In the branch various-api-refactors I've made a couple significant
genotypic changes to the index and polling API that I want to make sure
are in line with your evil plans. Commit 8aa1370d in particular replaces
Index.sync_message with three methods, one for adding new messages, one
for updating existing messages, and one for just tweaking the labels.
The current implementation just calls the original sync_message
implementation for all three. The rest of the changes are tweaks in the
various consumers of these messages.
The intention is that this will be useful both for Xapian and Sup the
server, which may need to distinguish between these three methods of
index access (or may simply want to for speed).
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 724
Date: Tue, 11 Aug 2009 13:18:15 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] move xapian index loading into
load_index
Message-ID: <1250021889-sup-3224@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Applied, thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 725
Date: Tue, 11 Aug 2009 13:22:30 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Stack overflow in regexp matcher
Message-ID: <1250021966-sup-933@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Hi Mark,
Reformatted excerpts from Mark Drayton's message of 2009-08-03:
> ## read 440m (about 52%) @ 2.2m/s. 0:03:19 elapsed, about 0:03:03 remaining
> Stack overflow in regexp matcher:
> /,\s*(?=(?:[^"]*"[^"]*")*(?![^"]*"))/ (RegexpError)
Interesting. Looks like Sup is trying to split a header line into
multiple email addresses and something's causing it to bomb. Are you
able to identify the line that's causing this problem? That would be
helpful to know.
> This error seems to have cropped up in other software so I suspect
> it's a problem with Ruby, not sup. Anyone able to confirm this?
It's a problem with Ruby's regular expression implementation, I suppose,
but we've never seen it before. The solution is to either tweak the
regexp until it starts working, or implement a custom parsing solution,
neither of which sounds that entertaining...
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 726
Date: Tue, 11 Aug 2009 13:28:46 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] run-mailcap fix
Message-ID: <1250022259-sup-8328@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Hi Beno?t,
Reformatted excerpts from Beno?t PIERRE's message of 2009-08-02:
> The attached patch fix this by not redirecting stderr to /dev/null.
> It also restores the correct ncurses state (including arrow
> keypresses, thanks to Edward Z. Yang recent patch).
Thanks! Not redirecting stderr to /dev/null is probably fine. But how
about calling BufferManager.shell_out instead?
If you want to submit a proper git commit via git-format-email, I will
be happy to apply it and you can get your name in the illustrious Sup
contributor roster. Otherwise I will make this change for you.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 727
Date: Wed, 12 Aug 2009 00:09:40 +0200
From: Beno?t PIERRE <benoit.pierre@gmail.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH run-mailcap 1/2] Don't redirect stderr to
/dev/null when calling run-mailcap.
Message-ID:
<1250028581-15826-1-git-send-email-benoit.pierre@gmail.com>
Some programs will fail to work correctly if this is done, like for
example: w3m --dump, to view HTML files.
---
lib/sup/message-chunks.rb | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/sup/message-chunks.rb b/lib/sup/message-chunks.rb
index 0d742d9..4c947e1 100644
--- a/lib/sup/message-chunks.rb
+++ b/lib/sup/message-chunks.rb
@@ -131,7 +131,7 @@ EOS
def initial_state; :open end
def viewable?; @lines.nil? end
def view_default! path
- cmd = "/usr/bin/run-mailcap --action=view '#{@content_type}:#{path}' 2>/dev/null"
+ cmd = "/usr/bin/run-mailcap --action=view '#{@content_type}:#{path}'"
Redwood::log "running: #{cmd.inspect}"
system cmd
$? == 0
--
1.6.3.3
------------------------------
Message: 728
Date: Wed, 12 Aug 2009 00:09:41 +0200
From: Beno?t PIERRE <benoit.pierre@gmail.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH run-mailcap 2/2] Use
BufferManager.shell_out to call run-mailcap instead of system.
Message-ID:
<1250028581-15826-2-git-send-email-benoit.pierre@gmail.com>
This ensure ncurses state is correctly restored upon command completion.
---
lib/sup/message-chunks.rb | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/sup/message-chunks.rb b/lib/sup/message-chunks.rb
index 4c947e1..1910abd 100644
--- a/lib/sup/message-chunks.rb
+++ b/lib/sup/message-chunks.rb
@@ -133,7 +133,7 @@ EOS
def view_default! path
cmd = "/usr/bin/run-mailcap --action=view '#{@content_type}:#{path}'"
Redwood::log "running: #{cmd.inspect}"
- system cmd
+ BufferManager.shell_out(cmd)
$? == 0
end
--
1.6.3.3
------------------------------
Message: 729
Date: Wed, 12 Aug 2009 01:26:53 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] some internal api refactors
Message-ID: <1250054282-sup-9053@pion.club.cc.cmu.edu>
Content-Type: text/plain; charset=UTF-8
It's worth noting that update_message_state needs to handle modified
refs and snippets as well as labels. Maybe add a comment about this in
BaseIndex?
------------------------------
Message: 730
Date: Wed, 12 Aug 2009 09:45:01 +0100
From: Mark Drayton <mark@markdrayton.info>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Stack overflow in regexp matcher
Message-ID:
<92457f310908120145n453d6639mf22fe68b62054392@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi William
On Tue, Aug 11, 2009 at 9:22 PM, William Morgan<wmorgan-sup@masanjin.net> wrote:
> Interesting. Looks like Sup is trying to split a header line into
> multiple email addresses and something's causing it to bomb. Are you
> able to identify the line that's causing this problem? That would be
> helpful to know.
Sorry, I should have dug a bit deeper before reporting this. I was
naively assuming it was a known problem (though Google didn't know, so
I guess it's not) and that the answer would be "upgrade foo".
The line it's choking on is 284058 bytes long and contains ~6400
addresses. (gotta love mail from "internal communications"). If I
halve the number of addresses it works, so perhaps this isn't worth
fixing at all. If you do want to tackle it I'm happy to help off-list.
Cheers,
Mark
------------------------------
Message: 731
Date: Wed, 12 Aug 2009 15:05:35 +0200
From: Ingmar Vanhassel <ingmar@exherbo.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH 0/18] Xapian-based index
Message-ID: <1250082297-sup-6018@cannonball>
Content-Type: text/plain; charset=UTF-8
Excerpts from Rich Lane's message of Fri Jul 31 18:20:41 +0200 2009:
> Excerpts from Rich Lane's message of Mon Jul 27 13:06:34 -0400 2009:
> > Excerpts from William Morgan's message of Mon Jul 27 11:48:38 -0400 2009:
> > > Reformatted excerpts from Rich Lane's message of 2009-07-25:
> > > > One issue I've noticed is that removing labels from messages doesn't
> > > > always immediately work.
> > >
> > > Is this true even after you sync changes to the index? What about if you
> > > reload the label list buffer? ('@')
> >
> > Yes. This is looking like a Xapian bug - I've reproduced it without any
> > Sup code. I'm working on a fix.
>
> I've fixed this, it should be released in Xapian 1.0.15. Or, grab Xapian
> SVN and you can try out the Chert backend too (XAPIAN_PREFER_CHERT=1).
Could you point me to the SVN revision containing the fix? I'd like to
backport the fix to my Xapian 1.0.14 packages, pending 1.0.15 release.
Thanks!
--
Exherbo KDE, X.org maintainer
------------------------------
Message: 732
Date: Wed, 12 Aug 2009 16:32:04 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: Ingmar Vanhassel <ingmar@exherbo.org>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH 0/18] Xapian-based index
Message-ID: <1250087467-sup-6888@ausone.inria.fr>
Content-Type: text/plain; charset=UTF-8
Excerpts from Ingmar Vanhassel's message of Wed Aug 12 15:05:35 +0200 2009:
> Excerpts from Rich Lane's message of Fri Jul 31 18:20:41 +0200 2009:
> > Excerpts from Rich Lane's message of Mon Jul 27 13:06:34 -0400 2009:
> > > Excerpts from William Morgan's message of Mon Jul 27 11:48:38 -0400 2009:
> > > > Reformatted excerpts from Rich Lane's message of 2009-07-25:
> > > > > One issue I've noticed is that removing labels from messages doesn't
> > > > > always immediately work.
> > > >
> > > > Is this true even after you sync changes to the index? What about if you
> > > > reload the label list buffer? ('@')
> > >
> > > Yes. This is looking like a Xapian bug - I've reproduced it without any
> > > Sup code. I'm working on a fix.
> >
> > I've fixed this, it should be released in Xapian 1.0.15. Or, grab Xapian
> > SVN and you can try out the Chert backend too (XAPIAN_PREFER_CHERT=1).
BTW, does someone have successfully built Xapian under Mac OS X ?
--
Nicolas Pouillard
http://nicolaspouillard.fr
------------------------------
Message: 733
Date: Thu, 13 Aug 2009 10:32:02 +0300
From: Taru Karttunen <taruti@taruti.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Sup crashing
Message-ID: <1250148617-sup-6053@oz.taruti.net>
Content-Type: text/plain; charset=iso-8859-1
Hello
I am using Sup git master version and it started to crash today
when viewing messages with a label. Any hints how to fix this?
--- ArgumentError from thread: load threads for thread-index-mode
:93349 is out of range [0..93204] for IndexReader#[]
/usr/lib/ruby/1.8/ferret/index.rb:421:in `[]'
/usr/lib/ruby/1.8/ferret/index.rb:421:in `[]'
/usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
/usr/lib/ruby/1.8/ferret/index.rb:413:in `[]'
./lib/sup/ferret_index.rb:151:in `each_id_by_date'
/usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
./lib/sup/ferret_index.rb:151:in `each_id_by_date'
./lib/sup/ferret_index.rb:150:in `each'
./lib/sup/ferret_index.rb:150:in `each_id_by_date'
./lib/sup/thread.rb:328:in `load_n_threads'
./lib/sup/modes/thread-index-mode.rb:623:in `__unprotected_load_n_threads'
(eval):12:in `load_n_threads'
./lib/sup/modes/thread-index-mode.rb:607:in `load_n_threads_background'
./lib/sup.rb:77:in `reporting_thread'
./lib/sup.rb:75:in `initialize'
./lib/sup.rb:75:in `new'
./lib/sup.rb:75:in `reporting_thread'
./lib/sup/modes/thread-index-mode.rb:606:in `load_n_threads_background'
./lib/sup/modes/thread-index-mode.rb:676:in `__unprotected_load_threads'
(eval):12:in `load_threads'
./lib/sup/modes/label-search-results-mode.rb:33:in `spawn_nicely'
./lib/sup/modes/label-list-mode.rb:93:in `select_label'
./lib/sup/mode.rb:50:in `send'
./lib/sup/mode.rb:50:in `handle_input'
./lib/sup/buffer.rb:249:in `handle_input'
bin/sup:236
- Taru Karttunen
------------------------------
Message: 734
Date: Fri, 14 Aug 2009 01:23:21 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH 0/18] Xapian-based index
Message-ID: <1250227281-sup-8626@pion.club.cc.cmu.edu>
Content-Type: text/plain; charset=UTF-8
Excerpts from Ingmar Vanhassel's message of Wed Aug 12 09:05:35 -0400 2009:
> Could you point me to the SVN revision containing the fix? I'd like to
> backport the fix to my Xapian 1.0.14 packages, pending 1.0.15 release.
Revision 13219.
------------------------------
Message: 735
Date: Fri, 14 Aug 2009 12:18:25 +0200
From: Guillaume Quintard <guillaume.quintard@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Poll delay and states not really saved
Message-ID: <1250244850-sup-5869@altis>
Content-Type: text/plain; charset=UTF-8
Hi,
Two things:
- I'm using xapian (git) and it seems that staates are only saved during
exits. Meaning that if I clean my inbox with A, then save with $, and
then refresh with @., all the messages are still here (as read, though).
- Can we have a config options for the time between poll, currently it's
hardcoded to 300s but I like to hammer my gmail box with requests.
Apart from that, sup works pretty well with xapian.
Cheers,
--
Guillaume
------------------------------
Message: 736
Date: Fri, 14 Aug 2009 13:12:04 +0200
From: Ingmar Vanhassel <ingmar@exherbo.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Poll delay and states not really saved
Message-ID: <1250248287-sup-2973@cannonball>
Content-Type: text/plain; charset=UTF-8
Excerpts from Guillaume Quintard's message of Fri Aug 14 12:18:25 +0200 2009:
> Hi,
> Two things:
> - I'm using xapian (git) and it seems that staates are only saved during
> exits. Meaning that if I clean my inbox with A, then save with $, and
> then refresh with @., all the messages are still here (as read, though).
>
> - Can we have a config options for the time between poll, currently it's
> hardcoded to 300s but I like to hammer my gmail box with requests.
>
> Apart from that, sup works pretty well with xapian.
>
> Cheers,
>
See http://mid.gmane.org/1248710432-sup-1734@pion.club.cc.cmu.edu
--
Exherbo KDE, X.org maintainer
------------------------------
Message: 737
Date: Fri, 14 Aug 2009 13:18:44 +0200
From: Guillaume Quintard <guillaume.quintard@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Poll delay and states not really saved
Message-ID: <1250248660-sup-2819@altis>
Content-Type: text/plain; charset=UTF-8
Excerpts from Ingmar Vanhassel's message of Fri Aug 14 13:12:04 +0200 2009:
> See http://mid.gmane.org/1248710432-sup-1734@pion.club.cc.cmu.edu
>
ah thanks, didn't remember that mail.
but the poll delay still stands :-)
--
Guillaume
------------------------------
Message: 738
Date: Fri, 14 Aug 2009 13:17:38 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH run-mailcap 2/2] Use
BufferManager.shell_out to call run-mailcap instead of system.
Message-ID: <1250281039-sup-2788@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Beno?t PIERRE's message of 2009-08-11:
> This ensure ncurses state is correctly restored upon command completion.
Both patches applies to branch run-mailcap-fixes, merged into next.
Thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 739
Date: Fri, 14 Aug 2009 13:20:28 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup crashing
Message-ID: <1250281208-sup-4199@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Taru Karttunen's message of 2009-08-13:
> --- ArgumentError from thread: load threads for thread-index-mode
> :93349 is out of range [0..93204] for IndexReader#[]
Weird. Does sup-sync --optimize fix anything?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 740
Date: Sat, 15 Aug 2009 00:37:21 +0200
From: Beno?t PIERRE <benoit.pierre@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH run-mailcap 2/2] Use
BufferManager.shell_out to call run-mailcap instead of system.
Message-ID: <1250289386-sup-7331@localdomain>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Fri Aug 14 22:17:38 +0200 2009:
> Reformatted excerpts from Beno?t PIERRE's message of 2009-08-11:
> > This ensure ncurses state is correctly restored upon command completion.
>
> Both patches applies to branch run-mailcap-fixes, merged into next.
Great!
One problem though, I tested next, and 3478e400ae31b459b2875cc226796a6d4bba11f9
(rewrap getch in select, handle sigwinch manually) introduced a regression: I
get some 'key not handled' errors after run-mail has been called when sup is
getting back control if I press for example an arrow... ;(
Arrows become usable again after I press a "normal" key (like 'a').
Cheers,
--
A: Because it destroys the flow of conversation.
Q: Why is top posting dumb?
------------------------------
Message: 741
Date: Sat, 15 Aug 2009 01:08:48 +0200
From: Beno?t PIERRE <benoit.pierre@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] [PATCH] Restore keypad mode after we force ncurses
to refresh the whole screen.
Message-ID: <1250291137-sup-2796@localdomain>
Content-Type: text/plain; charset="utf-8"
This also happen to fix a regression after a call to run-mailcap, since
for some reason a screen resize event is triggered when we get control
back...
---
lib/sup/buffer.rb | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/lib/sup/buffer.rb b/lib/sup/buffer.rb
index b3a256f..09281e9 100644
--- a/lib/sup/buffer.rb
+++ b/lib/sup/buffer.rb
@@ -270,6 +270,7 @@ EOS
## this magic makes Ncurses get the new size of the screen
Ncurses.endwin
+ Ncurses.stdscr.keypad 1
Ncurses.refresh
@sigwinch_mutex.synchronize { @sigwinch_happened = false }
Redwood::log "new screen size is #{Ncurses.rows} x #{Ncurses.cols}"
--
1.6.3.3
--
A: Because it destroys the flow of conversation.
Q: Why is top posting dumb?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090815/a67dfe70/attachment-0001.bin>
------------------------------
Message: 742
Date: Fri, 14 Aug 2009 21:05:32 -0700
From: Carl Worth <cworth@cworth.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Introduction, thanks, and a tiny patch
Message-ID: <1250307036-sup-8890@yoom>
Content-Type: text/plain; charset="utf-8"
Hi. My name's Carl, and I've uh, been collecting email for 12 years.
First off, I want to thank William and all contributors for sup! I
just started using it this morning, and I'm amazed by it. I've long
been frustrated by wrong-headed email systems, and also long been
dreaming of one done right, (entirely label-and-search-based and
focused on threads as the primary unit, bonus points if the UI is 100%
keyboard-driven and integrates with emacs). What a dream come true to
find sup!
In my first use of sup, I was surprised by two things immediately:
1. Most text is white-on-white (invisible) if the default terminal
background color is white. I would suggest that the default
background color be changed from "default" to "black" to avoid
this trap.
2. All of the mail I imported from various maildir folders was
labelled as "unread", (in spite of the fact that a large
majority of it had the 'S' tag for "seen" in the maildir
filename). I tracked this down to my maildir filenames
containing ',' characters to the left of the ':' like so:
1250158845.M979457P4354V000000000000FE01I001B8B56_0.yoom,S=46114:2,S
I've attached a patch to fix this second issue, (a single-character
change).
As for my involvement with sup, here are a couple of things I'd like
to help with:
1. I love the NewUserGuide, but I've needed a ReferenceManual for
various issues already, (configuring colors, configuring SMTP,
understanding the sources.yaml file well enough to be able to
re-process mail that was mis-labelled the first time,
etc.).
The wiki has been useful for much of this already, but I'd like
to have some of this information more cleanly organized, and
perhaps distributed as plain-text in alongside the user
guide. So I'd like to try pulling some existing information
together, organizing things, and also identifying missing
sections.
One potential issue is that I don't see any explicit license
terms on the wiki. Can I assume that any text on the wiki is
suitable for putting into a document to be contributed to and
distributed with sup?
2. I really like the ideas William has posted on his blog about
separating the interface from the guts of sup, (to make the new
STS). I'd be happy to help with that as well if possible.
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-maildir-Allow-in-the-unique-name-portion-of-a-maildi.patch
Type: application/octet-stream
Size: 1097 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090814/bb1094e7/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090814/bb1094e7/attachment-0001.bin>
------------------------------
Message: 743
Date: Fri, 14 Aug 2009 21:14:46 -0700
From: Carl Worth <cworth@cworth.org>
To: sup-talk@rubyforge.org
Subject: [sup-talk] Introduction, thanks, and a small patch
Message-ID: <20090815041446.GA1249@yoom.home.cworth.org>
Content-Type: text/plain; charset="us-ascii"
Hi. My name's Carl, and I've uh, been collecting email for 12 years.
First off, I want to thank William and all contributors for sup! I
just started using it this morning, and I'm amazed by it. I've long
been frustrated by wrong-headed email systems, and also long been
dreaming of one done right, (entirely label-and-search-based and
focused on threads as the primary unit, bonus points if the UI is 100%
keyboard-driven and integrates with emacs). What a dream come true to
find sup!
In my first use of sup, I was surprised by two things immediately:
1. Most text is white-on-white (invisible) if the default terminal
background color is white. I would suggest that the default
background color be changed from "default" to "black" to avoid
this trap.
2. All of the mail I imported from various maildir folders was
labelled as "unread", (in spite of the fact that a large
majority of it had the 'S' tag for "seen" in the maildir
filename). I tracked this down to my maildir filenames
containing ',' characters to the left of the ':' like so:
1250158845.M979457P4354V000000000000FE01I001B8B56_0.yoom,S=46114:2,S
I've attached a patch to fix this second issue, (a single-character
change).
As for my involvement with sup, here are a couple of things I'd like
to help with:
1. I love the NewUserGuide, but I've needed a ReferenceManual for
various issues already, (configuring colors, configuring SMTP,
understanding the sources.yaml file well enough to be able to
re-process mail that was mis-labelled the first time,
etc.).
The wiki has been useful for much of this already, but I'd like
to have some of this information more cleanly organized, and
perhaps distributed as plain-text in alongside the user
guide. So I'd like to try pulling some existing information
together, organizing things, and also identifying missing
sections.
One potential issue is that I don't see any explicit license
terms on the wiki. Can I assume that any text on the wiki is
suitable for putting into a document to be contributed to and
distributed with sup?
2. I really like the ideas William has posted on his blog about
separating the interface from the guts of sup, (to make the new
STS). I'd be happy to help with that as well if possible.
-Carl
PS. I'm sending this message from mutt since sup crashed when I tried
to send the message (see exception output below). I think this is one
more reason to get STS separated. I love everything the "STS"
functionality that comes with sup, and it's a shame to have all these
distractions like sending mail tangled up with it.
(I did previously send a successful message with sup, so I think I've
got my mstmp stuff setup properly. Some of what was different this
time: Sending a message with an attachment, and ending a resumed
message (which is something that shows up in the stack trace)).
Personally, I'd love to just use an external client for sending the
mail, just like I use an external client for composing mail. All that
sup would really need to be informed about is successful sending of a
message, (so it can set replied-to status in the index, for example).
NoMethodError from thread: main
undefined method `to_indexable_s' for nil:NilClass
/usr/lib/ruby/1.8/sup/index.rb:243:in `sync_message'
/usr/lib/ruby/1.8/sup/util.rb:513:in `send'
/usr/lib/ruby/1.8/sup/util.rb:513:in `method_missing'
/usr/lib/ruby/1.8/sup/poll.rb:161:in `add_messages_from'
/usr/lib/ruby/1.8/sup/source.rb:100:in `each'
/usr/lib/ruby/1.8/sup/util.rb:552:in `send'
/usr/lib/ruby/1.8/sup/util.rb:552:in `__pass'
/usr/lib/ruby/1.8/sup/util.rb:539:in `method_missing'
/usr/lib/ruby/1.8/sup/poll.rb:141:in `add_messages_from'
/usr/lib/ruby/1.8/sup/util.rb:513:in `send'
/usr/lib/ruby/1.8/sup/util.rb:513:in `method_missing'
/usr/lib/ruby/1.8/sup/sent.rb:25:in `write_sent_message'
/usr/lib/ruby/1.8/sup/util.rb:513:in `send'
/usr/lib/ruby/1.8/sup/util.rb:513:in `method_missing'
/usr/lib/ruby/1.8/sup/modes/edit-message-mode.rb:313:in `send_message'
/usr/lib/ruby/1.8/sup/modes/resume-mode.rb:37:in `send_message'
/usr/lib/ruby/1.8/sup/mode.rb:50:in `send'
/usr/lib/ruby/1.8/sup/mode.rb:50:in `handle_input'
/usr/lib/ruby/1.8/sup/buffer.rb:249:in `handle_input'
/usr/bin/sup-mail:236
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090814/19a68710/attachment-0001.bin>
------------------------------
Message: 744
Date: Fri, 14 Aug 2009 21:29:43 -0700
From: Carl Worth <cworth@cworth.org>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH] maildir: Allow ', ' in the unique-name
portion of a maildir filename.
Message-ID: <20090815042943.GA2414@yoom.home.cworth.org>
Content-Type: text/plain; charset="us-ascii"
The maildir specification says the following about unique names:
A unique name can be anything that doesn't contain a colon (or
slash) and doesn't start with a dot.
[http://cr.yp.to/proto/maildir.html]
So disallowing a unique name to have a comma breaks maildir import on
systems where there is a comma in the names.
---
Argh! What's worse than Forgotten Attachment Syndrome (FAS),
(especially on my first post to a list)?
[For what it's worth, I *had* attached the patch to the message I had
composed in sup before it crashed. So copying the draft into mutt
defeated my two-rule technique for avoiding FAS:
1. Always write in the past tense, ("I've attached", never "I will
attach").
2. Never type a lie.
That usually does the trick, but did fail in this case. ;-)
lib/sup/maildir.rb | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/sup/maildir.rb b/lib/sup/maildir.rb
index c6577c1..a2dbae4 100644
--- a/lib/sup/maildir.rb
+++ b/lib/sup/maildir.rb
@@ -212,7 +212,7 @@ private
def maildir_data msg
fn = File.basename @ids_to_fns[msg]
- fn =~ %r{^([^:,]+):([12]),([DFPRST]*)$}
+ fn =~ %r{^([^:]+):([12]),([DFPRST]*)$}
[($1 || fn), ($2 || "2"), ($3 || "")]
end
--
1.6.3.3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090814/4b3aa562/attachment-0001.bin>
------------------------------
Message: 745
Date: Sat, 15 Aug 2009 12:18:33 +0200
From: Igor Brkic <igor.brkic@fer.hr>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Introduction, thanks, and a small patch
Message-ID: <1250331013-sup-3083@xps>
Content-Type: text/plain; charset=UTF-8
Excerpts from Carl Worth's message of Sub Kol 15 06:14:46 +0200 2009:
> PS. I'm sending this message from mutt since sup crashed when I tried
> to send the message (see exception output below). I think this is one
Hi Carl!
I had same problem with sup. Sup actually manages to send message before
crashing and then it crashes when indexing sent messages.
Solution that worked for me is to comment out line "Time.parse time, 0"
in mbox.rb file. This is not good solution, more like a hack, but for
some reason it works for me. Try it out.
I tried to find out why this is happening, but I'm not so familiar with
sup internals (and not so good in ruby too) and didn't come to any conclusion.
Igor
------------------------------
Message: 746
Date: Sat, 15 Aug 2009 13:03:00 +0200
From: Marc Weber <marco-oweber@gmx.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Introduction, thanks, and a small patch
Message-ID: <1250334013-sup-3733@nixos>
Content-Type: text/plain; charset=UTF-8
> 1. Most text is white-on-white (invisible) if the default terminal
> background color is white. I would suggest that the default
> background color be changed from "default" to "black" to avoid
> this trap.
The bg colour is set to black somewhere but for some reason it doesn't
work here. I've switched my terminal bg colour to light green so that I
can still read all text. It's a little bit annoying though. So if you
can tell me how to make sup background black I'd be happy.
I haven't taken the time yet to investigate the issue.
Sincerly
Marc Weber
------------------------------
Message: 747
Date: Sat, 15 Aug 2009 07:35:02 -0700
From: Carl Worth <cworth@cworth.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Introduction, thanks, and a small patch
Message-ID: <1250346449-sup-6703@yoom>
Content-Type: text/plain; charset="utf-8"
Excerpts from Igor Brkic's message of Sat Aug 15 03:18:33 -0700 2009:
> Hi Carl!
Hi Igor!
> I had same problem with sup. Sup actually manages to send message before
> crashing and then it crashes when indexing sent messages.
Ah, yes. I did notice afterwards that my original message did make it
to the list. So sorry for all the noise, (though my first send of the
patch did have some debug junk in it, so I suppose it's good I sent a
cleaner version).
> Solution that worked for me is to comment out line "Time.parse time, 0"
> in mbox.rb file. This is not good solution, more like a hack, but for
> some reason it works for me. Try it out.
Thanks. I gave this a try, but it didn't work for me. I'm also not
much for debugging ruby so I haven't made much progress here yet. (Is
there anything like gdb for ruby? If I could just march up the stack
and more easily find where m.date should be initialized to non-nil
then that might help).
But thanks for describing the bug more accurately for mo. At least
knowing that the crash is happening while indexing ~/.sup/sent.mb I
was able to just move that out of the way for now, so I can at least
run sup again.
And actually, this brings up another point for that missing reference
manual. How can I configure sup to deliver sent messages to a maildir
instead of an mbox? (I'd prefer that anyway, and it just might
workaround this bug.)
Thanks for the warm welcome,
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090815/849f4ac4/attachment-0001.bin>
------------------------------
Message: 748
Date: Sat, 15 Aug 2009 07:41:51 -0700
From: Carl Worth <cworth@cworth.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Introduction, thanks, and a small patch
Message-ID: <1250346921-sup-8888@yoom>
Content-Type: text/plain; charset="utf-8"
Excerpts from Marc Weber's message of Sat Aug 15 04:03:00 -0700 2009:
> The bg colour is set to black somewhere but for some reason it doesn't
> work here. I've switched my terminal bg colour to light green so that I
> can still read all text. It's a little bit annoying though. So if you
> can tell me how to make sup background black I'd be happy.
>
> I haven't taken the time yet to investigate the issue.
I did my color configuration according to the following page:
http://sup.rubyforge.org/wiki/wiki.pl?CustomizingColors
That provides this very useful command which reads all the default
color settings and puts them into a configuration file that you can
easily edit:
ruby -rubygems -rsup -e 'print Redwood::Colormap::DEFAULT_COLORS.to_yaml' > ~/.sup/colors.yaml
You know, I don't think it would be a crazy idea for sup to
automatically dump that there on its first run. Or perhaps better,
sup-config could do it, (and could even ask if the user would prefer a
black-on-white or a white-on-black default color scheme).
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090815/e3d7b777/attachment-0001.bin>
------------------------------
Message: 749
Date: Sun, 16 Aug 2009 12:35:30 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH 1/2] move all GDBM data into Xapian
Message-ID: <1250451331-16070-1-git-send-email-rlane@club.cc.cmu.edu>
Keeping everything in Xapian means much better consistency in case of a crash.
Thread killing is now supported.
---
lib/sup/xapian_index.rb | 177 +++++++++++++++++++++++++++++------------------
1 files changed, 110 insertions(+), 67 deletions(-)
diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
index 861c2a3..825e7a3 100644
--- a/lib/sup/xapian_index.rb
+++ b/lib/sup/xapian_index.rb
@@ -1,5 +1,4 @@
require 'xapian'
-require 'gdbm'
require 'set'
module Redwood
@@ -23,12 +22,6 @@ class XapianIndex < BaseIndex
end
def load_index
- @entries = MarshalledGDBM.new File.join(@dir, "entries.db")
- @docids = MarshalledGDBM.new File.join(@dir, "docids.db")
- @thread_members = MarshalledGDBM.new File.join(@dir, "thread_members.db")
- @thread_ids = MarshalledGDBM.new File.join(@dir, "thread_ids.db")
- @assigned_docids = GDBM.new File.join(@dir, "assigned_docids.db")
-
@xapian = Xapian::WritableDatabase.new(File.join(@dir, "xapian"), Xapian::DB_CREATE_OR_OPEN)
@term_generator = Xapian::TermGenerator.new()
@term_generator.stemmer = Xapian::Stem.new(STEM_LANGUAGE)
@@ -48,19 +41,19 @@ class XapianIndex < BaseIndex
end
def contains_id? id
- synchronize { @entries.member? id }
+ synchronize { find_docid(id) && true }
end
def source_for_id id
- synchronize { @entries[id][:source_id] }
+ synchronize { get_entry(id)[:source_id] }
end
def delete id
- synchronize { @xapian.delete_document @docids[id] }
+ synchronize { @xapian.delete_document mkterm(:msgid, id) }
end
def build_message id
- entry = synchronize { @entries[id] }
+ entry = synchronize { get_entry id }
return unless entry
source = SourceManager[entry[:source_id]]
@@ -88,7 +81,7 @@ class XapianIndex < BaseIndex
end
def sync_message m, opts={}
- entry = synchronize { @entries[m.id] }
+ entry = synchronize { get_entry m.id }
snippet = m.snippet
entry ||= {}
labels = m.labels
@@ -113,9 +106,7 @@ class XapianIndex < BaseIndex
m.labels.each { |l| LabelManager << l }
synchronize do
- index_message m, opts
- union_threads([m.id] + m.refs + m.replytos)
- @entries[m.id] = d
+ index_message m, d, opts
end
true
end
@@ -147,8 +138,26 @@ class XapianIndex < BaseIndex
def each_message_in_thread_for m, opts={}
# TODO thread by subject
# TODO handle killed threads
- ids = synchronize { @thread_members[@thread_ids[m.id]] } || []
- ids.select { |id| contains_id? id }.each { |id| yield id, lambda { build_message id } }
+ return unless doc = find_doc(m.id)
+ queue = doc.value(THREAD_VALUENO).split(',')
+ msgids = [m.id]
+ seen_threads = Set.new
+ seen_messages = Set.new [m.id]
+ while not queue.empty?
+ thread_id = queue.pop
+ next if seen_threads.member? thread_id
+ return false if thread_killed? thread_id
+ seen_threads << thread_id
+ docs = term_docids(mkterm(:thread, thread_id)).map { |x| @xapian.document x }
+ docs.each do |doc|
+ msgid = doc.value MSGID_VALUENO
+ next if seen_messages.member? msgid
+ msgids << msgid
+ seen_messages << msgid
+ queue.concat doc.value(THREAD_VALUENO).split(',')
+ end
+ end
+ msgids.each { |id| yield id, lambda { build_message id } }
true
end
@@ -297,11 +306,16 @@ class XapianIndex < BaseIndex
'label' => 'L',
'source_id' => 'I',
'attachment_extension' => 'O',
+ 'msgid' => 'Q',
+ 'thread' => 'H',
+ 'ref' => 'R',
}
PREFIX = NORMAL_PREFIX.merge BOOLEAN_PREFIX
- DATE_VALUENO = 0
+ MSGID_VALUENO = 0
+ THREAD_VALUENO = 1
+ DATE_VALUENO = 2
MAX_TERM_LENGTH = 245
@@ -317,14 +331,48 @@ class XapianIndex < BaseIndex
def assign_docid m, truncated_date
t = (truncated_date.to_i - MIDDLE_DATE.to_i).to_f
docid = (DOCID_SCALE - DOCID_SCALE/(Math::E**(-(t/TIME_SCALE)) + 1)).to_i
+ while docid > 0 and docid_exists? docid
+ docid -= 1
+ end
+ docid > 0 ? docid : nil
+ end
+
+ # XXX is there a better way?
+ def docid_exists? docid
begin
- while @assigned_docids.member? [docid].pack("N")
- docid -= 1
- end
- rescue
+ @xapian.doclength docid
+ true
+ rescue RuntimeError #Xapian::DocNotFoundError
+ raise unless $!.message =~ /DocNotFoundError/
+ false
end
- @assigned_docids[[docid].pack("N")] = ''
- docid
+ end
+
+ def term_docids term
+ @xapian.postlist(term).map { |x| x.docid }
+ end
+
+ def find_docid id
+ term_docids(mkterm(:msgid,id)).tap { |x| fail unless x.size <= 1 }.first
+ end
+
+ def find_doc id
+ return unless docid = find_docid(id)
+ @xapian.document docid
+ end
+
+ def get_id docid
+ return unless doc = @xapian.document(docid)
+ doc.value MSGID_VALUENO
+ end
+
+ def get_entry id
+ return unless doc = find_doc(id)
+ Marshal.load doc.data
+ end
+
+ def thread_killed? thread_id
+ not run_query(Q.new(Q::OP_AND, mkterm(:thread, thread_id), mkterm(:label, :Killed)), 0, 1).empty?
end
def synchronize &b
@@ -340,7 +388,7 @@ class XapianIndex < BaseIndex
def run_query_ids xapian_query, offset, limit
matchset = run_query xapian_query, offset, limit
- matchset.matches.map { |r| r.document.data }
+ matchset.matches.map { |r| r.document.value MSGID_VALUENO }
end
Q = Xapian::Query
@@ -371,7 +419,7 @@ class XapianIndex < BaseIndex
end
end
- def index_message m, opts
+ def index_message m, entry, opts
terms = []
text = []
@@ -394,6 +442,7 @@ class XapianIndex < BaseIndex
terms << mkterm(:date,m.date) if m.date
m.labels.each { |t| terms << mkterm(:label,t) }
terms << mkterm(:type, 'mail')
+ terms << mkterm(:msgid, m.id)
terms << mkterm(:source_id, m.source.id)
m.attachments.each do |a|
a =~ /\.(\w+)$/ or next
@@ -401,6 +450,23 @@ class XapianIndex < BaseIndex
terms << t
end
+ ## Thread membership
+ children = term_docids(mkterm(:ref, m.id)).map { |docid| @xapian.document docid }
+ parent_ids = m.refs + m.replytos
+ parents = parent_ids.map { |id| find_doc id }.compact
+ thread_members = SavingHash.new { [] }
+ (children + parents).each do |doc2|
+ thread_ids = doc2.value(THREAD_VALUENO).split ','
+ thread_ids.each { |thread_id| thread_members[thread_id] << doc2 }
+ end
+
+ thread_ids = thread_members.empty? ? [m.id] : thread_members.keys
+
+ thread_ids.each { |thread_id| terms << mkterm(:thread, thread_id) }
+ parent_ids.each do |ref|
+ terms << mkterm(:ref, ref)
+ end
+
# Full text search content
text << [subject_text, PREFIX['subject']]
text << [subject_text, PREFIX['body']]
@@ -424,17 +490,29 @@ class XapianIndex < BaseIndex
Xapian.sortable_serialise 0
end
- doc = Xapian::Document.new
- docid = @docids[m.id] || assign_docid(m, truncated_date)
+ docid = nil
+ unless doc = find_doc(m.id)
+ doc = Xapian::Document.new
+ if not docid = assign_docid(m, truncated_date)
+ # Could be triggered by spam
+ Redwood::log "warning: docid underflow, dropping #{m.id.inspect}"
+ return
+ end
+ else
+ doc.clear_terms
+ doc.clear_values
+ docid = doc.docid
+ end
@term_generator.document = doc
text.each { |text,prefix| @term_generator.index_text text, 1, prefix }
terms.each { |term| doc.add_term term if term.length <= MAX_TERM_LENGTH }
+ doc.add_value MSGID_VALUENO, m.id
+ doc.add_value THREAD_VALUENO, (thread_ids * ',')
doc.add_value DATE_VALUENO, date_value
- doc.data = m.id
+ doc.data = Marshal.dump entry
@xapian.replace_document docid, doc
- @docids[m.id] = docid
end
# Construct a Xapian term
@@ -457,48 +535,13 @@ class XapianIndex < BaseIndex
PREFIX['source_id'] + args[0].to_s.downcase
when :attachment_extension
PREFIX['attachment_extension'] + args[0].to_s.downcase
+ when :msgid, :ref, :thread
+ PREFIX[type.to_s] + args[0][0...(MAX_TERM_LENGTH-1)]
else
raise "Invalid term type #{type}"
end
end
- # Join all the given message-ids into a single thread
- def union_threads ids
- seen_threads = Set.new
- related = Set.new
-
- # Get all the ids that will be in the new thread
- ids.each do |id|
- related << id
- thread_id = @thread_ids[id]
- if thread_id && !seen_threads.member?(thread_id)
- thread_members = @thread_members[thread_id]
- related.merge thread_members
- seen_threads << thread_id
- end
- end
-
- # Pick a leader and move all the others to its thread
- a = related.to_a
- best, *rest = a.sort_by { |x| x.hash }
- @thread_members[best] = a
- @thread_ids[best] = best
- rest.each do |x|
- @thread_members.delete x
- @thread_ids[x] = best
- end
- end
end
end
-
-class MarshalledGDBM < GDBM
- def []= k, v
- super k, Marshal.dump(v)
- end
-
- def [] k
- v = super k
- v ? Marshal.load(v) : nil
- end
-end
--
1.6.4
------------------------------
Message: 750
Date: Sun, 16 Aug 2009 12:35:31 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH 2/2] xapian index format versioning
Message-ID: <1250451331-16070-2-git-send-email-rlane@club.cc.cmu.edu>
---
lib/sup/xapian_index.rb | 13 ++++++++++++-
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
index 825e7a3..c4989e4 100644
--- a/lib/sup/xapian_index.rb
+++ b/lib/sup/xapian_index.rb
@@ -8,6 +8,7 @@ module Redwood
# for searching due to precomputing thread membership.
class XapianIndex < BaseIndex
STEM_LANGUAGE = "english"
+ INDEX_VERSION = '1'
## dates are converted to integers for xapian, and are used for document ids,
## so we must ensure they're reasonably valid. this typically only affect
@@ -22,7 +23,17 @@ class XapianIndex < BaseIndex
end
def load_index
- @xapian = Xapian::WritableDatabase.new(File.join(@dir, "xapian"), Xapian::DB_CREATE_OR_OPEN)
+ path = File.join(@dir, 'xapian')
+ if File.exists? path
+ @xapian = Xapian::WritableDatabase.new(path, Xapian::DB_OPEN)
+ db_version = @xapian.get_metadata 'version'
+ if db_version != INDEX_VERSION
+ fail "Index version #{db_version.inspect} is different than Sup version #{INDEX_VERSION.inspect}"
+ end
+ else
+ @xapian = Xapian::WritableDatabase.new(path, Xapian::DB_CREATE)
+ @xapian.set_metadata 'version', INDEX_VERSION
+ end
@term_generator = Xapian::TermGenerator.new()
@term_generator.stemmer = Xapian::Stem.new(STEM_LANGUAGE)
@enquire = Xapian::Enquire.new @xapian
--
1.6.4
------------------------------
Message: 751
Date: Sun, 16 Aug 2009 12:35:59 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH] skip system buffers when rolling
Message-ID: <1250451359-16110-1-git-send-email-rlane@club.cc.cmu.edu>
---
lib/sup/buffer.rb | 16 +++++++++++-----
1 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/lib/sup/buffer.rb b/lib/sup/buffer.rb
index b3a256f..3fd2fe4 100644
--- a/lib/sup/buffer.rb
+++ b/lib/sup/buffer.rb
@@ -237,14 +237,20 @@ EOS
## have to change this. but it's not clear that we will ever actually
## do that.
def roll_buffers
- @buffers.last.force_to_top = false
- raise_to_front @buffers.first
+ bufs = rollable_buffers
+ bufs.last.force_to_top = false
+ raise_to_front bufs.first
end
def roll_buffers_backwards
- return unless @buffers.length > 1
- @buffers.last.force_to_top = false
- raise_to_front @buffers[@buffers.length - 2]
+ bufs = rollable_buffers
+ return unless bufs.length > 1
+ bufs.last.force_to_top = false
+ raise_to_front bufs[bufs.length - 2]
+ end
+
+ def rollable_buffers
+ @buffers.select { |b| !b.system? || @buffers.last == b }
end
def handle_input c
--
1.6.4
------------------------------
Message: 752
Date: Sun, 16 Aug 2009 12:36:08 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH] add 'I' keybinding to raise Inbox buffer
Message-ID: <1250451368-16150-1-git-send-email-rlane@club.cc.cmu.edu>
---
bin/sup | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/bin/sup b/bin/sup
index a9f0b95..d1eb163 100755
--- a/bin/sup
+++ b/bin/sup
@@ -78,6 +78,7 @@ global_keymap = Keymap.new do |k|
k.add :compose, "Compose new message", 'm', 'c'
k.add :nothing, "Do nothing", :ctrl_g
k.add :recall_draft, "Edit most recent draft message", 'R'
+ k.add :show_inbox, "Show the Inbox buffer", 'I'
end
## the following magic enables wide characters when used with a ruby
@@ -286,6 +287,8 @@ begin
b, new = BufferManager.spawn_unless_exists("All drafts") { LabelSearchResultsMode.new [:draft] }
b.mode.load_threads :num => b.content_height if new
end
+ when :show_inbox
+ BufferManager.raise_to_front ibuf
when :nothing, InputSequenceAborted
when :redraw
bm.completely_redraw_screen
--
1.6.4
------------------------------
Message: 753
Date: Sun, 16 Aug 2009 21:01:16 +0100
From: Adeodato Sim? <dato@net.com.org.es>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] [PATCH 2/2] xapian index format versioning
Message-ID: <20090816200116.GA17272@chistera.yi.org>
Content-Type: text/plain; charset=us-ascii
+ Rich Lane (Sun, 16 Aug 2009 12:35:31 -0700):
> + fail "Index version #{db_version.inspect} is different than Sup
> version #{INDEX_VERSION.inspect}"
The second part of the sentence seems to refer to Sup's version itself,
rather than what it really means (the index version expected by the
running version of Sup).
Maybe the following wording could work better?
| This Sup version expects a v#{INDEX_VERSION.inspect} index, whereas
| v#{db_version.inspect} is in the filesystem.
(And, perhaps, suggesting what to do next would be grea too.)
HTH,
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
------------------------------
Message: 754
Date: Sun, 16 Aug 2009 16:28:56 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] [PATCH 2/2] xapian index format versioning
Message-ID: <1250453934-sup-9651@zyrg.net>
Content-Type: text/plain; charset=UTF-8
---
How's this wording?
I've been thinking about a label log that would store every label
modification along with the timestamp, etc. This would make the awkward
downgrade-dump-upgrade step unnecessary. We could also flush it to disk
more often than the full index.
lib/sup/xapian_index.rb | 14 +++++++++++++-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
index 825e7a3..18b5050 100644
--- a/lib/sup/xapian_index.rb
+++ b/lib/sup/xapian_index.rb
@@ -8,6 +8,7 @@ module Redwood
# for searching due to precomputing thread membership.
class XapianIndex < BaseIndex
STEM_LANGUAGE = "english"
+ INDEX_VERSION = '1'
## dates are converted to integers for xapian, and are used for document ids,
## so we must ensure they're reasonably valid. this typically only affect
@@ -22,7 +23,18 @@ class XapianIndex < BaseIndex
end
def load_index
- @xapian = Xapian::WritableDatabase.new(File.join(@dir, "xapian"), Xapian::DB_CREATE_OR_OPEN)
+ path = File.join(@dir, 'xapian')
+ if File.exists? path
+ @xapian = Xapian::WritableDatabase.new(path, Xapian::DB_OPEN)
+ db_version = @xapian.get_metadata 'version'
+ db_version = '0' if db_version.empty?
+ if db_version != INDEX_VERSION
+ fail "This Sup version expects a v#{INDEX_VERSION} index, but you have an existing v#{db_version} index. Please downgrade to your previous version and dump your labels before upgrading to this version (then run sup-sync --restore)."
+ end
+ else
+ @xapian = Xapian::WritableDatabase.new(path, Xapian::DB_CREATE)
+ @xapian.set_metadata 'version', INDEX_VERSION
+ end
@term_generator = Xapian::TermGenerator.new()
@term_generator.stemmer = Xapian::Stem.new(STEM_LANGUAGE)
@enquire = Xapian::Enquire.new @xapian
--
1.6.4
------------------------------
Message: 755
Date: Sun, 16 Aug 2009 14:22:56 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Introduction, thanks, and a small patch
Message-ID: <1250456575-sup-4326@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Igor Brkic's message of 2009-08-15:
> Solution that worked for me is to comment out line "Time.parse time,
> 0" in mbox.rb file. This is not good solution, more like a hack, but
> for some reason it works for me. Try it out.
I've think I've fixed this in master. Thanks for your log; that was
helpful. The problem was that Sup was producing the date component of
the From_ lines in the sent mail mbox using the current locale, and
later on wouldn't necessarily recognize that as a date. (Particularly
for people with "funny locales".)
You will have to manually edit your ~/.sup/sent.mbox file and change all
the From_ line dates that are not in UTC to UTC. If there are just a
couple, you should be able to copy and paste from the Date: header a few
lines below.
Removing the Time.parse line you mention will work, but it has the side
effect of potentially splitting mbox files in mid-message. E.g. if you
ever have a line of text like "From xxx yyy\n", Sup will consider that
a message delimiter. This is fallout from the great mbox From_ line
misdesign of 1972.
Please let me know if it works for you.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 756
Date: Sun, 16 Aug 2009 14:38:31 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Introduction, thanks, and a small patch
Message-ID: <1250457809-sup-6784@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Carl Worth's message of 2009-08-14:
> Hi. My name's Carl, and I've uh, been collecting email for 12 years.
Hi Carl! Welcome.
> 1. Most text is white-on-white (invisible) if the default terminal
> background color is white. I would suggest that the default
> background color be changed from "default" to "black" to avoid
> this trap.
Complaining about the colors already? You're fitting right in around
here.
We recently changed it from black to default in order to make it work
for people with transparent terminals. Since there's clearly not a
setting that works for everyone, I think the best solution is your
suggestion in a later email: provide a few reasonable color schemes
directly in sup-sync.
> I've attached a patch to fix this second issue, (a single-character
> change).
Great, thanks. The patch looks good but I think you left a debugging
puts call in there. If you want to resubmit, I will apply this.
> I love the NewUserGuide, but I've needed a ReferenceManual for various
> issues already, (configuring colors, configuring SMTP, understanding
> the sources.yaml file well enough to be able to re-process mail that
> was mis-labelled the first time, etc.).
Agree. This would be very valuable and is currently a sore spot, IMO.
> One potential issue is that I don't see any explicit license terms on
> the wiki. Can I assume that any text on the wiki is suitable for
> putting into a document to be contributed to and distributed with sup?
I think it's fair to assume that anyone contributing to a wiki for an
open-source product knows what they're getting into. So, yes.
Of course, if anyone objects to their wiki content being distributed as
part of Sup (which is currently distributed under GPL v2), please speak
now!
> I really like the ideas William has posted on his blog about
> separating the interface from the guts of sup, (to make the new STS).
> I'd be happy to help with that as well if possible.
Although it's been over a year of vaporware promises, this is slowly
happening. I have a protocol defined and a simple server written. Recent
work on replacing Ferret with Xapian has actually been helpful in terms
of moving us away from Ferretisms. Expect something "soon".
> NoMethodError from thread: main
> undefined method `to_indexable_s' for nil:NilClass
This should now be fixed in git master; see my previous email in this
thread. (You will have to manually edit your sent.mbox a bit.)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 757
Date: Sun, 16 Aug 2009 14:43:03 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Stack overflow in regexp matcher
Message-ID: <1250458792-sup-9177@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Mark Drayton's message of 2009-08-12:
> The line it's choking on is 284058 bytes long and contains ~6400
> addresses. (gotta love mail from "internal communications").
Wow!
> If I halve the number of addresses it works, so perhaps this isn't
> worth fixing at all. If you do want to tackle it I'm happy to help
> off-list.
Well... it's clearly a weird case, but it would be nice to do something
besides barf. I suppose we could detect very long lines, emit a warning,
and just parse the first few kb. What do you think?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 758
Date: Sun, 16 Aug 2009 14:44:49 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] some internal api refactors
Message-ID: <1250459019-sup-6390@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Rich Lane's message of 2009-08-11:
> It's worth noting that update_message_state needs to handle modified
> refs and snippets as well as labels. Maybe add a comment about this in
> BaseIndex?
Different snippet, definitely. Good point. Modified refs: I'm tempted to
replace this with another API call, since we don't really care about the
refs; we just want the index to thread the messages together. Thoughts?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 759
Date: Sun, 16 Aug 2009 15:00:50 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Restore keypad mode after we force
ncurses to refresh the whole screen.
Message-ID: <1250460036-sup-9343@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Beno?t PIERRE's message of 2009-08-14:
> This also happen to fix a regression after a call to run-mailcap,
> since for some reason a screen resize event is triggered when we get
> control back...
Applied to ncurses-fixes, merged into next. Thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 760
Date: Sun, 16 Aug 2009 17:47:09 -0400
From: Kevin Riggle <kevinr@free-dissociation.com>
To: sup-talk@rubyforge.org
Cc: Kevin Riggle <kevinr@black-opal.mit.edu>
Subject: [sup-talk] [PATCH] Add an after-add-message hook
Message-ID:
<1250459229-4500-1-git-send-email-kevinr@free-dissociation.com>
From: Kevin Riggle <kevinr@black-opal.mit.edu>
I want to do some unrelated processing on each message I receive, but I
don't want to block the message being added to the index. This patch
adds a hook which runs /after/ the message is added to the index.
---
lib/sup/poll.rb | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/lib/sup/poll.rb b/lib/sup/poll.rb
index 8a9d218..e4b7e02 100644
--- a/lib/sup/poll.rb
+++ b/lib/sup/poll.rb
@@ -11,6 +11,12 @@ Variables:
message: the new message
EOS
+ HookManager.register "after-add-message", <<EOS
+Executes after a message is added to the index.
+Variables:
+ message: the new message
+EOS
+
HookManager.register "before-poll", <<EOS
Executes immediately before a poll for new messages commences.
No variables.
@@ -156,6 +162,7 @@ EOS
m_ret = yield(m_old, m_new, offset) or next if block_given?
Index.sync_message m_ret, opts
UpdateManager.relay self, :added, m_ret unless m_old
+ HookManager.run "after-add-message", :message => m_new
end
rescue SourceError => e
Redwood::log "problem getting messages from #{source}: #{e.message}"
--
1.6.0.4
------------------------------
Message: 761
Date: Sun, 16 Aug 2009 18:49:24 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] some internal api refactors
Message-ID: <1250461358-sup-7209@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Sun Aug 16 17:44:49 -0400 2009:
> Reformatted excerpts from Rich Lane's message of 2009-08-11:
> > It's worth noting that update_message_state needs to handle modified
> > refs and snippets as well as labels. Maybe add a comment about this in
> > BaseIndex?
>
> Different snippet, definitely. Good point. Modified refs: I'm tempted to
> replace this with another API call, since we don't really care about the
> refs; we just want the index to thread the messages together. Thoughts?
The ThreadSet still needs the ref to do the UI-level threading, right?
Making it another API call is good as long as that's still taken care of.
------------------------------
Message: 762
Date: Mon, 17 Aug 2009 01:18:22 +0200
From: Igor Brkic <igor.brkic@fer.hr>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Introduction, thanks, and a small patch
Message-ID: <1250464611-sup-5505@xps>
Content-Type: text/plain; charset=utf8
Excerpts from William Morgan's message of Sun Aug 16 23:22:56 +0200 2009:
> I've think I've fixed this in master. Thanks for your log; that was
> helpful. The problem was that Sup was producing the date component of
> the From_ lines in the sent mail mbox using the current locale, and
> later on wouldn't necessarily recognize that as a date. (Particularly
> for people with "funny locales".)
>
> ...
>
> Please let me know if it works for you.
I've made changes and for now it works like a charm. Thanks!
Igor
------------------------------
Message: 763
Date: Sun, 16 Aug 2009 23:38:43 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH] index log
Message-ID: <1250491123-19240-1-git-send-email-rlane@club.cc.cmu.edu>
Add a YAML logfile that records changes to the index and modify sup-dump to use
this rather than the normal database. The log is index format/version agnostic
so that users can switch between incompatible Sup versions without running
sup-dump first.
This should also make automated backups easier.
---
bin/sup-dump | 19 +++++++++++++------
lib/sup/ferret_index.rb | 7 +++++++
lib/sup/index.rb | 22 ++++++++++++++++++++++
lib/sup/xapian_index.rb | 7 ++++++-
lib/sup/yaml_log.rb | 25 +++++++++++++++++++++++++
5 files changed, 73 insertions(+), 7 deletions(-)
create mode 100644 lib/sup/yaml_log.rb
diff --git a/bin/sup-dump b/bin/sup-dump
index ba36b21..531a30a 100755
--- a/bin/sup-dump
+++ b/bin/sup-dump
@@ -2,7 +2,8 @@
require 'rubygems'
require 'trollop'
-require "sup"
+require 'sup' # Redwood::VERSION, Redwood::BASE_DIR
+require "sup/yaml_log"
$opts = Trollop::options do
version "sup-dump (sup #{Redwood::VERSION})"
@@ -21,10 +22,16 @@ No options.
EOS
end
-index = Redwood::Index.new
-Redwood::SourceManager.new
-index.load
+labels = {}
-index.each_message :load_spam => true, :load_deleted => true, :load_killed => true do |m|
- puts "#{m.id} (#{m.labels * ' '})"
+Redwood::log "processing index log"
+index_log = YamlLogReader.new File.join(Redwood::BASE_DIR, 'index_log.yaml')
+index_log.each do |h|
+ case h['type']
+ when 'add_message', 'update_message_state'
+ labels[h['id']] = h['labels']
+ end
end
+
+Redwood::log "dumping labels"
+labels.each { |msgid,labels| puts "#{msgid} (#{labels * ' '})" }
diff --git a/lib/sup/ferret_index.rb b/lib/sup/ferret_index.rb
index 98ea9b5..2cb9759 100644
--- a/lib/sup/ferret_index.rb
+++ b/lib/sup/ferret_index.rb
@@ -57,6 +57,7 @@ EOS
def sync_message m, opts={}
entry = @index[m.id]
+ existed = !entry.nil?
raise "no source info for message #{m.id}" unless m.source && m.source_info
@@ -131,6 +132,12 @@ EOS
}
@index_mutex.synchronize do
+ if existed
+ @log.update_message_state m.id, m.labels
+ else
+ @log.add_message m.id, m.labels
+ end
+
@index.delete m.id
@index.add_document d
end
diff --git a/lib/sup/index.rb b/lib/sup/index.rb
index 54ec843..7360cf5 100644
--- a/lib/sup/index.rb
+++ b/lib/sup/index.rb
@@ -1,6 +1,7 @@
## Index interface, subclassed by Ferret indexer.
require 'fileutils'
+require 'sup/yaml_log'
begin
require 'chronic'
@@ -65,6 +66,7 @@ class BaseIndex
def load
SourceManager.load_sources
+ @log = IndexLogWriter.new File.join(@dir, 'index_log.yaml')
load_index
end
@@ -176,6 +178,26 @@ class BaseIndex
def parse_query s
unimplemented
end
+
+ private
+
+ class IndexLogWriter < YamlLogWriter
+ def update_message_state id, labels
+ write_entry 'update_message_state', 'id' => id, 'labels' => labels.map { |x| x.to_s }
+ end
+
+ def add_message id, labels
+ write_entry 'add_message', 'id' => id, 'labels' => labels.map { |x| x.to_s }
+ end
+
+ def remove_message id
+ write_entry 'remove_message', 'id' => id
+ end
+
+ def write_entry type, hash
+ self << hash.merge('type' => type, 'time' => Time.now)
+ end
+ end
end
index_name = ENV['SUP_INDEX'] || $config[:index] || DEFAULT_INDEX
diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
index 18b5050..c4dbc5f 100644
--- a/lib/sup/xapian_index.rb
+++ b/lib/sup/xapian_index.rb
@@ -61,7 +61,10 @@ class XapianIndex < BaseIndex
end
def delete id
- synchronize { @xapian.delete_document mkterm(:msgid, id) }
+ synchronize do
+ @log.remove_message id
+ @xapian.delete_document mkterm(:msgid, id)
+ end
end
def build_message id
@@ -510,10 +513,12 @@ class XapianIndex < BaseIndex
Redwood::log "warning: docid underflow, dropping #{m.id.inspect}"
return
end
+ @log.add_message m.id, m.labels
else
doc.clear_terms
doc.clear_values
docid = doc.docid
+ @log.update_message_state m.id, m.labels
end
@term_generator.document = doc
diff --git a/lib/sup/yaml_log.rb b/lib/sup/yaml_log.rb
new file mode 100644
index 0000000..325cca9
--- /dev/null
+++ b/lib/sup/yaml_log.rb
@@ -0,0 +1,25 @@
+class YamlLogReader
+ include Enumerable
+
+ def initialize filename
+ @io = File.open(filename, 'r+')
+ end
+
+ def each &b
+ @io.rewind
+ YAML.each_document @io, &b
+ end
+end
+
+class YamlLogWriter
+ def initialize filename
+ @io = File.open(filename, 'a')
+ end
+
+ def <<(o)
+ YAML.dump o, @io
+
+ ## This only flushes to the OS. We may want to fsync occasionally too.
+ @io.flush
+ end
+end
--
1.6.4
------------------------------
Message: 764
Date: Sun, 16 Aug 2009 23:39:11 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH 1/5] console mode
Message-ID: <1250491155-19281-1-git-send-email-rlane@club.cc.cmu.edu>
---
bin/sup | 4 +++
lib/sup.rb | 1 +
lib/sup/modes/console-mode.rb | 42 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 47 insertions(+), 0 deletions(-)
create mode 100644 lib/sup/modes/console-mode.rb
diff --git a/bin/sup b/bin/sup
index a9f0b95..1dc322a 100755
--- a/bin/sup
+++ b/bin/sup
@@ -78,6 +78,7 @@ global_keymap = Keymap.new do |k|
k.add :compose, "Compose new message", 'm', 'c'
k.add :nothing, "Do nothing", :ctrl_g
k.add :recall_draft, "Edit most recent draft message", 'R'
+ k.add :show_console, "Show the Console buffer", '~'
end
## the following magic enables wide characters when used with a ruby
@@ -286,6 +287,9 @@ begin
b, new = BufferManager.spawn_unless_exists("All drafts") { LabelSearchResultsMode.new [:draft] }
b.mode.load_threads :num => b.content_height if new
end
+ when :show_console
+ b, new = bm.spawn_unless_exists("Console", :system => true) { ConsoleMode.new }
+ b.mode.run
when :nothing, InputSequenceAborted
when :redraw
bm.completely_redraw_screen
diff --git a/lib/sup.rb b/lib/sup.rb
index cfa93fc..9e0c33a 100644
--- a/lib/sup.rb
+++ b/lib/sup.rb
@@ -295,6 +295,7 @@ require "sup/modes/buffer-list-mode"
require "sup/modes/poll-mode"
require "sup/modes/file-browser-mode"
require "sup/modes/completion-mode"
+require "sup/modes/console-mode"
require "sup/sent"
$:.each do |base|
diff --git a/lib/sup/modes/console-mode.rb b/lib/sup/modes/console-mode.rb
new file mode 100644
index 0000000..d06d37b
--- /dev/null
+++ b/lib/sup/modes/console-mode.rb
@@ -0,0 +1,42 @@
+require 'pp'
+
+module Redwood
+
+class Console
+ def initialize mode
+ @mode = mode
+ end
+end
+
+class ConsoleMode < LogMode
+ def initialize
+ super
+ @binding = Console.new(self).instance_eval { binding }
+ end
+
+ def execute cmd
+ begin
+ self << ">> #{cmd}\n"
+ ret = eval cmd, @binding
+ self << "=> #{ret.pretty_inspect}\n"
+ rescue Exception
+ self << "#{$!.class}: #{$!.message}\n"
+ clean_backtrace = []
+ $!.backtrace.each { |l| break if l =~ /console-mode/; clean_backtrace << l }
+ clean_backtrace.each { |l| self << "#{l}\n" }
+ end
+ end
+
+ def prompt
+ BufferManager.ask :console, "eval: "
+ end
+
+ def run
+ while true
+ cmd = prompt or return
+ execute cmd
+ end
+ end
+end
+
+end
--
1.6.4
------------------------------
Message: 765
Date: Sun, 16 Aug 2009 23:39:13 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH 3/5] console: index internals accessor
Message-ID: <1250491155-19281-3-git-send-email-rlane@club.cc.cmu.edu>
---
lib/sup/modes/console-mode.rb | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/lib/sup/modes/console-mode.rb b/lib/sup/modes/console-mode.rb
index a91bbbf..c794a4c 100644
--- a/lib/sup/modes/console-mode.rb
+++ b/lib/sup/modes/console-mode.rb
@@ -18,6 +18,9 @@ class Console
def remove_labels(query, *labels)
query(query).each { |m| m.labels -= labels; m.save Index }
end
+
+ def xapian; Index.instance.instance_variable_get :@xapian; end
+ def ferret; Index.instance.instance_variable_get :@index; end
end
class ConsoleMode < LogMode
--
1.6.4
------------------------------
Message: 766
Date: Sun, 16 Aug 2009 23:39:12 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH 2/5] console: add/remove labels
Message-ID: <1250491155-19281-2-git-send-email-rlane@club.cc.cmu.edu>
---
lib/sup/modes/console-mode.rb | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/lib/sup/modes/console-mode.rb b/lib/sup/modes/console-mode.rb
index d06d37b..a91bbbf 100644
--- a/lib/sup/modes/console-mode.rb
+++ b/lib/sup/modes/console-mode.rb
@@ -6,6 +6,18 @@ class Console
def initialize mode
@mode = mode
end
+
+ def query(query)
+ Enumerable::Enumerator.new(Index, :each_message, Index.parse_query(query))
+ end
+
+ def add_labels(query, *labels)
+ query(query).each { |m| m.labels += labels; m.save Index }
+ end
+
+ def remove_labels(query, *labels)
+ query(query).each { |m| m.labels -= labels; m.save Index }
+ end
end
class ConsoleMode < LogMode
--
1.6.4
------------------------------
Message: 767
Date: Sun, 16 Aug 2009 23:39:14 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH 4/5] console: reload
Message-ID: <1250491155-19281-4-git-send-email-rlane@club.cc.cmu.edu>
---
lib/sup/modes/console-mode.rb | 30 ++++++++++++++++++++++++++++++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/lib/sup/modes/console-mode.rb b/lib/sup/modes/console-mode.rb
index c794a4c..c344fa6 100644
--- a/lib/sup/modes/console-mode.rb
+++ b/lib/sup/modes/console-mode.rb
@@ -21,6 +21,36 @@ class Console
def xapian; Index.instance.instance_variable_get :@xapian; end
def ferret; Index.instance.instance_variable_get :@index; end
+
+ ## files that won't cause problems when reloaded
+ ## TODO expand this list / convert to blacklist
+ RELOAD_WHITELIST = %w(sup/xapian_index.rb sup/modes/console-mode.rb)
+
+ def reload
+ old_verbose = $VERBOSE
+ $VERBOSE = nil
+ old_features = $".dup
+ begin
+ fs = $".grep(/^sup\//)
+ fs.reject! { |f| not RELOAD_WHITELIST.member? f }
+ fs.each { |f| $".delete f }
+ fs.each do |f|
+ @mode << "reloading #{f}\n"
+ begin
+ require f
+ rescue LoadError => e
+ raise unless e.message =~ /no such file to load/
+ end
+ end
+ rescue Exception
+ $".clear
+ $".concat old_features
+ raise
+ ensure
+ $VERBOSE = old_verbose
+ end
+ true
+ end
end
class ConsoleMode < LogMode
--
1.6.4
------------------------------
Message: 768
Date: Sun, 16 Aug 2009 23:39:15 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH 5/5] console: clear_hooks
Message-ID: <1250491155-19281-5-git-send-email-rlane@club.cc.cmu.edu>
---
lib/sup/hook.rb | 2 ++
lib/sup/modes/console-mode.rb | 5 +++++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/lib/sup/hook.rb b/lib/sup/hook.rb
index 33a97b2..099158d 100644
--- a/lib/sup/hook.rb
+++ b/lib/sup/hook.rb
@@ -130,6 +130,8 @@ EOS
def enabled? name; !hook_for(name).nil? end
+ def clear; @hooks.clear; end
+
private
def hook_for name
diff --git a/lib/sup/modes/console-mode.rb b/lib/sup/modes/console-mode.rb
index c344fa6..372a466 100644
--- a/lib/sup/modes/console-mode.rb
+++ b/lib/sup/modes/console-mode.rb
@@ -51,6 +51,11 @@ class Console
end
true
end
+
+ def clear_hooks
+ HookManager.clear
+ nil
+ end
end
class ConsoleMode < LogMode
--
1.6.4
------------------------------
Message: 769
Date: Sun, 16 Aug 2009 23:39:32 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH] cache results of Person.from_address
Message-ID: <1250491172-19317-1-git-send-email-rlane@club.cc.cmu.edu>
The regexes in this function are very expensive, so caching improves
performance significantly for queries and slightly for indexing.
---
lib/sup/cache.rb | 46 ++++++++++++++++++++++++++++++++++++++++++++++
lib/sup/person.rb | 7 ++++++-
2 files changed, 52 insertions(+), 1 deletions(-)
create mode 100644 lib/sup/cache.rb
diff --git a/lib/sup/cache.rb b/lib/sup/cache.rb
new file mode 100644
index 0000000..0836dbd
--- /dev/null
+++ b/lib/sup/cache.rb
@@ -0,0 +1,46 @@
+class Cache
+ def initialize n=128, i=3
+ @n = n
+ @i = i
+ @values = {}
+ @marks = {}
+ @delete_stack = []
+ end
+
+ def [](k)
+ if @values.member? k
+ @marks[k] = @i
+ @values[k]
+ else
+ nil
+ end
+ end
+
+ def []=(k,v)
+ if @values.size < @n
+ @values[k] = v
+ @marks[k] = @i
+ else
+ if @delete_stack.empty?
+ sweep
+ else
+ k2 = @delete_stack.pop
+ @values.delete k2
+ @marks.delete k2
+ self[k] = v
+ end
+ end
+ end
+
+ def sweep
+ @marks.each do |k,v|
+ v -= 1
+ if v == 0
+ @delete_stack.push k
+ @marks.delete k
+ else
+ @marks[k] = v
+ end
+ end
+ end
+end
diff --git a/lib/sup/person.rb b/lib/sup/person.rb
index c4f40a5..046eedc 100644
--- a/lib/sup/person.rb
+++ b/lib/sup/person.rb
@@ -1,3 +1,5 @@
+require 'sup/cache'
+
module Redwood
class Person
@@ -73,8 +75,11 @@ class Person
end.downcase
end
+ ## This method is expensive, so memoize it.
+ @from_address_cache = Cache.new
def self.from_address s
return nil if s.nil?
+ @from_address_cache[s].tap { |x| return x if x }
## try and parse an email address and name
name, email = case s
@@ -102,7 +107,7 @@ class Person
[nil, s]
end
- Person.new name, email
+ @from_address_cache[s] = Person.new name, email
end
def self.from_address_list ss
--
1.6.4
------------------------------
Message: 770
Date: Mon, 17 Aug 2009 10:22:35 +0300
From: Taru Karttunen <taruti@taruti.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup crashing
Message-ID: <1250493725-sup-5683@oz.taruti.net>
Content-Type: text/plain; charset=iso-8859-1
Excerpts from William Morgan's message of Fri Aug 14 23:20:28 +0300 2009:
>
> Weird. Does sup-sync --optimize fix anything?
Made things work again. Thanks.
- Taru Karttunen
------------------------------
Message: 771
Date: Mon, 17 Aug 2009 09:07:25 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] cache results of Person.from_address
Message-ID: <1250514421-sup-7564@Longbow>
Content-Type: text/plain; charset=utf8
Just want to say thanks again for your seemingly unending amount of good
work to improve Sup.
--
Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
------------------------------
Message: 772
Date: Mon, 17 Aug 2009 07:01:10 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup crashing
Message-ID: <1250517574-sup-940@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Taru Karttunen's message of 2009-08-17:
> Made things work again. Thanks.
Good. Let me know if it happens again. I'm not sure what would cause it
to get in that state.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 773
Date: Mon, 17 Aug 2009 17:08:57 +0100
From: Adeodato Sim? <dato@net.com.org.es>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] [PATCH 2/2] xapian index format versioning
Message-ID: <20090817160857.GA2496@chistera.yi.org>
Content-Type: text/plain; charset=us-ascii
+ Rich Lane (Sun, 16 Aug 2009 16:28:56 -0400):
> How's this wording?
> + fail "This Sup version expects a v#{INDEX_VERSION} index, but you
> have an existing v#{db_version} index. Please downgrade to your
> previous version and dump your labels before upgrading to this version
> (then run sup-sync --restore)."
Sounds much better, thanks!
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
------------------------------
Message: 774
Date: Mon, 17 Aug 2009 12:39:57 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] some internal api refactors
Message-ID: <1250537445-sup-4504@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Rich Lane's message of 2009-08-16:
> The ThreadSet still needs the ref to do the UI-level threading, right?
> Making it another API call is good as long as that's still taken care
> of.
I'm thinking about moving in the direction where the index is also
responsible for threading (so maybe "index" is not the right term
anymore), so the ThreadSet would just be a static representation of the
thread structure of a set of messages as returned by the index. We'll
see how it develops.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 775
Date: Mon, 17 Aug 2009 12:50:52 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk mailing list <sup-talk@rubyforge.org>
Subject: [sup-talk] logging and internal API changes in next
Message-ID: <1250538107-sup-7121@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Dear Suppers,
I've merged the aforementioned internal API changes, and a pretty big
rewrite of the logging system (branch "logging"), into next. It works
for me, but please report any problems you see.
All logging messages are now categorized by level (debug, info, warn,
error) and will only be output when the global logging level is <= the
message level. The global logging level is determined by the environment
variable SUP_LOG_LEVEL; when unset, the default is "info". You'll notice
that the majority of the messages you saw before are now "debug"
messages, so the log buffer is much quieter.
This change also applies to the various sup-* scripts.
If you use this code and then switch to a branch without these changes,
you may encounter errors because labels are now represented on disk as
Sets instead of arrays. The solution is to edit your sources.yaml file
and manually change the Sets back to arrays; it should be obvious how to
do this. I don't anticipate this affecting too many people. If it does,
we can transform labels to arrays before storing to make this easier,
but hopefully it's just a temporary issue.
I would like to merge these changes down to master sooner rather than
later, because they're so far-reaching.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 776
Date: Mon, 17 Aug 2009 15:54:45 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] ncurses hack
Message-ID: <1250538875-sup-2195@javelin>
Content-Type: text/plain; charset=UTF-8
Today, I decided to throw in the towel and patch my copy of ncurses
to have the appropriate fix for international characters + tabs. Does
anyone know of a list of instructions for carrying this out?
Cheers,
Edward
------------------------------
Message: 777
Date: Mon, 17 Aug 2009 16:31:22 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] logging and internal API changes in next
Message-ID: <1250541071-sup-7690@Longbow>
Content-Type: text/plain; charset=utf8
Excerpts from William Morgan's message of Mon Aug 17 15:50:52 -0400 2009:
> Dear Suppers,
>
> I've merged the aforementioned internal API changes, and a pretty big
> rewrite of the logging system (branch "logging"), into next. It works
> for me, but please report any problems you see.
>
> All logging messages are now categorized by level (debug, info, warn,
> error) and will only be output when the global logging level is <= the
> message level. The global logging level is determined by the environment
> variable SUP_LOG_LEVEL; when unset, the default is "info". You'll notice
> that the majority of the messages you saw before are now "debug"
> messages, so the log buffer is much quieter.
>
> This change also applies to the various sup-* scripts.
>
> If you use this code and then switch to a branch without these changes,
> you may encounter errors because labels are now represented on disk as
> Sets instead of arrays. The solution is to edit your sources.yaml file
> and manually change the Sets back to arrays; it should be obvious how to
> do this. I don't anticipate this affecting too many people. If it does,
> we can transform labels to arrays before storing to make this easier,
> but hopefully it's just a temporary issue.
>
> I would like to merge these changes down to master sooner rather than
> later, because they're so far-reaching.
Looking forward to it, thanks.
--
Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
------------------------------
Message: 778
Date: Mon, 17 Aug 2009 19:43:18 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] ncurses hack
Message-ID: <1250563136-sup-432@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Edward Z. Yang's message of 2009-08-17:
> Today, I decided to throw in the towel and patch my copy of ncurses to
> have the appropriate fix for international characters + tabs. Does
> anyone know of a list of instructions for carrying this out?
Try http://sup.rubyforge.org/wiki/wiki.pl?UTF8. If you're running Sup
git, I've made a nice branch for this:
$ git branch --track ncursesw origin/ncursesw
$ git checkout ncursesw
$ cd ncurses-0.9.1/
$ ./run-this-for-sup.sh
Which will generate an ncurses.so file in lib/. You can then switch back
to master or next and it should pick it up.
This should fix many wide-character issues but it won't fix all of them,
because there's still no way of determining the display width of a
unicode character (e.g. Chinese characters take two columns to display).
So the display still ends up funny.
Ruby 1.9 has better encoding support but I don't know if it fixes this.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 779
Date: Tue, 18 Aug 2009 09:42:48 +0200
From: Dusan <ef_dva@yahoo.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] ncurses hack
Message-ID: <1250580593-sup-1346@archpc>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Tue Aug 18 04:43:18 +0200 2009:
> Reformatted excerpts from Edward Z. Yang's message of 2009-08-17:
> > Today, I decided to throw in the towel and patch my copy of ncurses to
> > have the appropriate fix for international characters + tabs. Does
> > anyone know of a list of instructions for carrying this out?
>
> Try http://sup.rubyforge.org/wiki/wiki.pl?UTF8. If you're running Sup
> git, I've made a nice branch for this:
>
> $ git branch --track ncursesw origin/ncursesw
> $ git checkout ncursesw
> $ cd ncurses-0.9.1/
> $ ./run-this-for-sup.sh
>
> Which will generate an ncurses.so file in lib/. You can then switch back
> to master or next and it should pick it up.
>
> This should fix many wide-character issues but it won't fix all of them,
> because there's still no way of determining the display width of a
> unicode character (e.g. Chinese characters take two columns to display).
> So the display still ends up funny.
>
> Ruby 1.9 has better encoding support but I don't know if it fixes this.
I am new sup user and love it very much.
Not being able to fix search/save and other edits is huge show-stopper.
I do what I read somewhere:
-start search, get garbage results
-kill that buffer with 'x'
-start another search but instead of typing search term again first
repeat: press up, delete search garbage, press up, delete search
garbage, repeat until there is nothing to delete
-type another search term and search now works 100%
This works for searches but edits like save still fail (or save X((%^1X file
so if you can find it you can rename it).
Looks like fixable bug to simulate what I did for searches? Repeat in
code ten times 'up arrow', '50 x delete char'? Sorry if I am wrong.
Using sup and not being able to properly search or save is too wrong.
If there is any config/version I should report to get this fixed just
let me know. Without waiting for new ruby of course -- I do have proper
results when I repeat deleting ritual.
Thanks
------------------------------
Message: 780
Date: Tue, 18 Aug 2009 12:58:57 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: Sup Mailing List <sup-talk@rubyforge.org>
Subject: [sup-talk] xapian rpms
Message-ID: <1250614640-sup-8983@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Hi All,
I've built a set of rpms for xapian (1.0.14) for rhel5. If you're
interested in them, I'll share. I have both 32 and 64 bit versions.
The xapian site rpm collection doesn't offer the ruby bindings.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090818/aa04491f/attachment-0001.bin>
------------------------------
Message: 781
Date: Tue, 18 Aug 2009 10:33:33 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] maildir: Allow ', ' in the unique-name
portion of a maildir filename.
Message-ID: <1250616640-sup-2613@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Carl Worth's message of 2009-08-14:
> A unique name can be anything that doesn't contain a colon (or slash)
> and doesn't start with a dot.
I've applied this patch directly to master. (The one I complained about
was attached to your original email; I just noticed this one was
different now.)
> Argh! What's worse than Forgotten Attachment Syndrome (FAS),
> (especially on my first post to a list)?
Since Sup should now work for you, you'll be happy to know that it warns
you if you use the word "attachment" without attaching anything. :)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 782
Date: Tue, 18 Aug 2009 13:35:35 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: Sup Mailing List <sup-talk@rubyforge.org>
Subject: [sup-talk] crash when sup-syncing to xapian
Message-ID: <1250616603-sup-5612@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
I just tried to import my index to xapian and it crashed part way
through the import. I then discovered that I couldn't use ferret
either. There is something wonky with label handling, as per attached
exception log. I haven't had a chance to look at the code yet, but
I'll poke at it tonight.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: sup-exception-log.txt
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090818/28bccae3/attachment-0001.txt>
------------------------------
Message: 783
Date: Tue, 18 Aug 2009 10:36:27 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] skip system buffers when rolling
Message-ID: <1250616971-sup-7888@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Nice idea. Branch buffer-rolling, merged into next.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 784
Date: Tue, 18 Aug 2009 10:38:58 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] add 'I' keybinding to raise Inbox
buffer
Message-ID: <1250617129-sup-4194@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Applied to master, thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 785
Date: Tue, 18 Aug 2009 10:49:05 -0700
From: Carl Worth <cworth@cworth.org>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] maildir: Allow ', ' in the unique-name
portion of a maildir filename.
Message-ID: <1250617174-sup-2755@yoom>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Tue Aug 18 10:33:33 -0700 2009:
> I've applied this patch directly to master. (The one I complained about
> was attached to your original email; I just noticed this one was
> different now.)
Thanks for catching this.
> > Argh! What's worse than Forgotten Attachment Syndrome (FAS),
> > (especially on my first post to a list)?
>
> Since Sup should now work for you, you'll be happy to know that it warns
> you if you use the word "attachment" without attaching anything. :)
If it's just the word "attachment" I don't think it will affect me at
all. The wording I generally use is something like:
I've attached a test case to demonstrate the bug.
But in general this should be a nice feature, (except for a mail like
this one that will cause a false warning from the check). ;-)
Thanks again for all your work on sup,
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090818/26c6e1c6/attachment-0001.bin>
------------------------------
Message: 786
Date: Tue, 18 Aug 2009 10:54:20 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] maildir: Allow ', ' in the unique-name
portion of a maildir filename.
Message-ID: <1250617985-sup-2416@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Carl Worth's message of 2009-08-18:
> If it's just the word "attachment" I don't think it will affect me at
> all.
Don't worry, Sup uses sophisticated natural language technology to
induce message semantics.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 787
Date: Tue, 18 Aug 2009 10:56:15 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Add an after-add-message hook
Message-ID: <1250618123-sup-8797@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Kevin Riggle's message of 2009-08-16:
> I want to do some unrelated processing on each message I receive, but
> I don't want to block the message being added to the index. This
> patch adds a hook which runs /after/ the message is added to the
> index.
Won't this block subsequent emails from being added to the index, when
Sup gets multiple new emails during a poll?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 788
Date: Tue, 18 Aug 2009 20:20:41 +0200
From: Beno?t PIERRE <benoit.pierre@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] crash when sup-syncing to xapian
Message-ID: <1250619511-sup-2827@localdomain>
Content-Type: text/plain; charset="utf-8"
Excerpts from Ben Walton's message of Tue Aug 18 19:35:35 +0200 2009:
>
> I just tried to import my index to xapian and it crashed part way
> through the import. I then discovered that I couldn't use ferret
> either. There is something wonky with label handling, as per attached
> exception log. I haven't had a chance to look at the code yet, but
> I'll poke at it tonight.
I think I just ran into the same problem! For now I fixed it with
the following small patch:
diff --git a/lib/sup/label.rb b/lib/sup/label.rb
index 67474c2..59c0c0f 100644
--- a/lib/sup/label.rb
+++ b/lib/sup/label.rb
@@ -61,6 +61,7 @@ class LabelManager
end
def << t
+ t = t.to_sym if t.is_a? String
raise ArgumentError, "expecting a symbol" unless t.is_a? Symbol
unless @labels.member?(t) || RESERVED_LABELS.member?(t)
@labels[t] = true
--
A: Because it destroys the flow of conversation.
Q: Why is top posting dumb?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 289 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090818/4a4ab3f7/attachment-0001.bin>
------------------------------
Message: 789
Date: Tue, 18 Aug 2009 20:24:45 +0200
From: Beno?t PIERRE <benoit.pierre@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] ncurses hack
Message-ID: <1250619721-sup-91@localdomain>
Content-Type: text/plain; charset=UTF-8
Excerpts from Dusan's message of Tue Aug 18 09:42:48 +0200 2009:
>
> [...]
>
> Not being able to fix search/save and other edits is huge show-stopper.
> I do what I read somewhere:
>
> -start search, get garbage results
> -kill that buffer with 'x'
> -start another search but instead of typing search term again first
> repeat: press up, delete search garbage, press up, delete search
> garbage, repeat until there is nothing to delete
> -type another search term and search now works 100%
>
> This works for searches but edits like save still fail (or save X((%^1X file
> so if you can find it you can rename it).
>
> Looks like fixable bug to simulate what I did for searches? Repeat in
> code ten times 'up arrow', '50 x delete char'? Sorry if I am wrong.
>
> Using sup and not being able to properly search or save is too wrong.
>
> If there is any config/version I should report to get this fixed just
> let me know. Without waiting for new ruby of course -- I do have proper
> results when I repeat deleting ritual.
Hi, can you try the following patch and tell me if it fix the problem?
diff --git a/lib/sup/textfield.rb b/lib/sup/textfield.rb
index b8dec59..ccc8533 100644
--- a/lib/sup/textfield.rb
+++ b/lib/sup/textfield.rb
@@ -36,8 +36,9 @@ class TextField
@field = Ncurses::Form.new_field 1, @width - question.length, @y,
@x + question.length, 256, 0
@form = Ncurses::Form.new_form [@field]
@value = default
+ @value ||= ''
Ncurses::Form.post_form @form
- set_cursed_value default if default
+ set_cursed_value @value
end
def position_cursor
--
A: Because it destroys the flow of conversation.
Q: Why is top posting dumb?
------------------------------
Message: 790
Date: Tue, 18 Aug 2009 14:30:00 -0400
From: Alex Vandiver <alex@chmrr.net>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH] Fix a thread merging bug introduced by
refactoring in 59f8fc2
Message-ID: <1250620200-24319-1-git-send-email-alex@chmrr.net>
Signed-off-by: Alex Vandiver <alex@chmrr.net>
---
lib/sup/thread.rb | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/sup/thread.rb b/lib/sup/thread.rb
index d395c35..3ff4e7f 100644
--- a/lib/sup/thread.rb
+++ b/lib/sup/thread.rb
@@ -357,7 +357,7 @@ class ThreadSet
return if threads.size < 2
containers = threads.map do |t|
- c = @messages.member?(c) ? @messages[t.first.id] : nil
+ c = @messages.member?(t.first.id) ? @messages[t.first.id] : nil
raise "not in threadset: #{t.first.id}" unless c && c.message
c
end
--
1.6.3.3
------------------------------
Message: 791
Date: Tue, 18 Aug 2009 11:37:38 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH 1/5] console mode
Message-ID: <1250620017-sup-3445@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Cool idea. Branch console-mode, merged into next.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 792
Date: Tue, 18 Aug 2009 14:42:13 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] crash when sup-syncing to xapian
Message-ID: <1250620771-sup-1373@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from Beno?t PIERRE's message of Tue Aug 18 14:20:41 -0400 2009:
> Excerpts from Ben Walton's message of Tue Aug 18 19:35:35 +0200 2009:
> >
> > I just tried to import my index to xapian and it crashed part way
> > through the import. I then discovered that I couldn't use ferret
> > either. There is something wonky with label handling, as per attached
> > exception log. I haven't had a chance to look at the code yet, but
> > I'll poke at it tonight.
>
> I think I just ran into the same problem! For now I fixed it with
> the following small patch:
That's odd because the Xapian code passes the labels straight through
from the message to LabelManager. Try instrumenting Message#labels= to
raise an exception if any member of the set is not a Symbol.
------------------------------
Message: 793
Date: Tue, 18 Aug 2009 20:46:52 +0200
From: Dusan <ef_dva@yahoo.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] ncurses hack
Message-ID: <1250620908-sup-7463@archpc>
Content-Type: text/plain; charset=UTF-8
Excerpts from Beno?t PIERRE's message of Tue Aug 18 20:24:45 +0200 2009:
> Excerpts from Dusan's message of Tue Aug 18 09:42:48 +0200 2009:
> >
> > [...]
> >
> > Not being able to fix search/save and other edits is huge show-stopper.
> > I do what I read somewhere:
> >
> > -start search, get garbage results
> > -kill that buffer with 'x'
> > -start another search but instead of typing search term again first
> > repeat: press up, delete search garbage, press up, delete search
> > garbage, repeat until there is nothing to delete
> > -type another search term and search now works 100%
> >
> > This works for searches but edits like save still fail (or save X((%^1X file
> > so if you can find it you can rename it).
> >
> > Looks like fixable bug to simulate what I did for searches? Repeat in
> > code ten times 'up arrow', '50 x delete char'? Sorry if I am wrong.
> >
> > Using sup and not being able to properly search or save is too wrong.
> >
> > If there is any config/version I should report to get this fixed just
> > let me know. Without waiting for new ruby of course -- I do have proper
> > results when I repeat deleting ritual.
>
> Hi, can you try the following patch and tell me if it fix the problem?
>
> diff --git a/lib/sup/textfield.rb b/lib/sup/textfield.rb
> index b8dec59..ccc8533 100644
> --- a/lib/sup/textfield.rb
> +++ b/lib/sup/textfield.rb
> @@ -36,8 +36,9 @@ class TextField
> @field = Ncurses::Form.new_field 1, @width - question.length, @y,
> @x + question.length, 256, 0
> @form = Ncurses::Form.new_form [@field]
> @value = default
> + @value ||= ''
> Ncurses::Form.post_form @form
> - set_cursed_value default if default
> + set_cursed_value @value
> end
>
> def position_cursor
I will, just give me day or two. I am using gem version, not svn or git.
I did some stuff with them but never with ruby. Can you give me two
lines help what to install and where? Latest svn?
Sorry I am not _that_ helpful but ruby is new thing to me. I should be
able to test this soon enough with some help.
Thanks,
Dusan
------------------------------
Message: 794
Date: Tue, 18 Aug 2009 20:59:20 +0200
From: Beno?t PIERRE <benoit.pierre@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] ncurses hack
Message-ID: <1250621614-sup-5683@localdomain>
Content-Type: text/plain; charset="utf-8"
Excerpts from Dusan's message of Tue Aug 18 20:46:52 +0200 2009:
> Excerpts from Beno?t PIERRE's message of Tue Aug 18 20:24:45 +0200 2009:
> > Excerpts from Dusan's message of Tue Aug 18 09:42:48 +0200 2009:
>
> [...]
>
> I will, just give me day or two. I am using gem version, not svn or git.
> I did some stuff with them but never with ruby. Can you give me two
> lines help what to install and where? Latest svn?
You can probably directly patch the sources in the gem. For example on
Ubuntu, the sources should be somewhere in /var/lib/gems/1.8/gems/sup-xxx.
Use 'gem environment' to get the installation directory.
Another option is to follow the wiki to get the latest git version:
http://sup.rubyforge.org/wiki/wiki.pl?Contributing
--
A: Because it destroys the flow of conversation.
Q: Why is top posting dumb?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090818/302eaeb0/attachment-0001.bin>
------------------------------
Message: 795
Date: Tue, 18 Aug 2009 21:04:16 +0200
From: Dusan <ef_dva@yahoo.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] ncurses hack
Message-ID: <1250622060-sup-324@archpc>
Content-Type: text/plain; charset=UTF-8
Excerpts from Beno?t PIERRE's message of Tue Aug 18 20:59:20 +0200 2009:
> Excerpts from Dusan's message of Tue Aug 18 20:46:52 +0200 2009:
> > Excerpts from Beno?t PIERRE's message of Tue Aug 18 20:24:45 +0200 2009:
> > > Excerpts from Dusan's message of Tue Aug 18 09:42:48 +0200 2009:
> >
> > [...]
> >
> > I will, just give me day or two. I am using gem version, not svn or git.
> > I did some stuff with them but never with ruby. Can you give me two
> > lines help what to install and where? Latest svn?
>
> You can probably directly patch the sources in the gem. For example on
> Ubuntu, the sources should be somewhere in /var/lib/gems/1.8/gems/sup-xxx.
>
> Use 'gem environment' to get the installation directory.
>
> Another option is to follow the wiki to get the latest git version:
> http://sup.rubyforge.org/wiki/wiki.pl?Contributing
Everything but git, thanks :)
Of course, ruby is interpreter, I keep forgetting that.
I am using ArchLinux and should be fairly skilled to do some changing. Reporting
back tomorrow.
------------------------------
Message: 796
Date: Tue, 18 Aug 2009 21:17:03 +0200
From: Beno?t PIERRE <benoit.pierre@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] crash when sup-syncing to xapian
Message-ID: <1250622911-sup-2815@localdomain>
Content-Type: text/plain; charset="utf-8"
Excerpts from Rich Lane's message of Tue Aug 18 20:42:13 +0200 2009:
> Excerpts from Beno?t PIERRE's message of Tue Aug 18 14:20:41 -0400 2009:
> > Excerpts from Ben Walton's message of Tue Aug 18 19:35:35 +0200 2009:
> > >
> > > I just tried to import my index to xapian and it crashed part way
> > > through the import. I then discovered that I couldn't use ferret
> > > either. There is something wonky with label handling, as per attached
> > > exception log. I haven't had a chance to look at the code yet, but
> > > I'll poke at it tonight.
> >
> > I think I just ran into the same problem! For now I fixed it with
> > the following small patch:
>
> That's odd because the Xapian code passes the labels straight through
> from the message to LabelManager. Try instrumenting Message#labels= to
> raise an exception if any member of the set is not a Symbol.
I applied the following patch:
diff --git a/lib/sup/message.rb b/lib/sup/message.rb
index 965c10e..9156c02 100644
--- a/lib/sup/message.rb
+++ b/lib/sup/message.rb
@@ -1,4 +1,5 @@
require 'time'
+require 'pp'
module Redwood
@@ -183,6 +184,7 @@ class Message
def labels= l
raise ArgumentError, "not a set" unless l.is_a?(Set)
return if @labels == l
+ warn "labels=#{l.pretty_inspect}"
@labels = l
@dirty = true
end
And get this in the logs:
[Tue Aug 18 21:12:39 +0200 2009] WARNING: labels=#<Set: {:inbox, :unread, "aquarius", "music"}>
[Tue Aug 18 21:12:39 +0200 2009] WARNING: labels=#<Set: {:inbox, :unread, "metalblade", "music"}>
--
A: Because it destroys the flow of conversation.
Q: Why is top posting dumb?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090818/721494a9/attachment-0001.bin>
------------------------------
Message: 797
Date: Tue, 18 Aug 2009 21:24:44 +0200
From: Dusan <ef_dva@yahoo.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] ncurses hack
Message-ID: <1250623031-sup-6731@archpc>
Content-Type: text/plain; charset=UTF-8
Excerpts from Beno?t PIERRE's message of Tue Aug 18 20:59:20 +0200 2009:
> Excerpts from Dusan's message of Tue Aug 18 20:46:52 +0200 2009:
> > Excerpts from Beno?t PIERRE's message of Tue Aug 18 20:24:45 +0200 2009:
> > > Excerpts from Dusan's message of Tue Aug 18 09:42:48 +0200 2009:
> >
> > [...]
> >
> > I will, just give me day or two. I am using gem version, not svn or git.
> > I did some stuff with them but never with ruby. Can you give me two
> > lines help what to install and where? Latest svn?
>
> You can probably directly patch the sources in the gem. For example on
> Ubuntu, the sources should be somewhere in /var/lib/gems/1.8/gems/sup-xxx.
>
> Use 'gem environment' to get the installation directory.
>
> Another option is to follow the wiki to get the latest git version:
> http://sup.rubyforge.org/wiki/wiki.pl?Contributing
Bah, I could not wait till tomorrow and it's not _that_ late...
This fix WORKS :) Every time so far. Please include this into release
asap, this is what prevents a lot of people from using sup.
I patched source with vim, diff is too automatic :)
Here is func that works:
activate window, y, x, width, question, default=nil, &block
@w, @y, @x, @width = window, y, x, width
@question = question
@completion_block = block
@field = Ncurses::Form.new_field 1, @width - question.length, @y, @x
+ question.length, 256, 0
@form = Ncurses::Form.new_form [@field]
@value = default
@value ||= ''
Ncurses::Form.post_form @form
# set_cursed_value default if default
set_cursed_value @value
end
Probably @value=default can go too, not sure since I don't know ruby?
Thanks a lot!
------------------------------
Message: 798
Date: Tue, 18 Aug 2009 21:31:35 +0200
From: J?rg-Hendrik Bach <bachjh@googlemail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] ncurses hack
Message-ID:
<91de50e10908181231h2f8f4cbdr6ab546aa4a3466ca@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
2009/8/18 Beno?t PIERRE <benoit.pierre@gmail.com>:
> Hi, can you try the following patch and tell me if it fix the problem?
>
> diff --git a/lib/sup/textfield.rb b/lib/sup/textfield.rb
> index b8dec59..ccc8533 100644
> --- a/lib/sup/textfield.rb
> +++ b/lib/sup/textfield.rb
> @@ -36,8 +36,9 @@ class TextField
> ? ? @field = Ncurses::Form.new_field 1, @width - question.length, @y,
> @x + question.length, 256, 0
> ? ? @form = Ncurses::Form.new_form [@field]
> ? ? @value = default
> + ? ?@value ||= ''
> ? ? Ncurses::Form.post_form @form
> - ? ?set_cursed_value default if default
> + ? ?set_cursed_value @value
> ? end
>
> ? def position_cursor
Thanks a lot. I don't know what this does exactly, but the first added
line of that patch was sufficient to get searches with utf-8 running
well from startup, without the need to go for a dummy search each time
i restarted sup.
The full patch (including the replacement at line 41) broke searching
altogether, on hitting '\' it throws:
--- TypeError from thread: main
can't convert nil into String
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/textfield.rb:159:in
`set_field_buffer'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/textfield.rb:159:in
`set_cursed_value'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/textfield.rb:42:in `activate'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/buffer.rb:537:in `ask'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/buffer.rb:26:in `synchronize'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/buffer.rb:26:in `sync'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/buffer.rb:536:in `ask'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/util.rb:513:in `send'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/util.rb:513:in `method_missing'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/bin/sup:268
/usr/bin/sup:19:in `load'
/usr/bin/sup:19
- J?rg-Hendrik
------------------------------
Message: 799
Date: Tue, 18 Aug 2009 15:52:12 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] crash when sup-syncing to xapian
Message-ID: <1250624577-sup-4801@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from Beno?t PIERRE's message of Tue Aug 18 15:17:03 -0400 2009:
> Excerpts from Rich Lane's message of Tue Aug 18 20:42:13 +0200 2009:
> > Excerpts from Beno?t PIERRE's message of Tue Aug 18 14:20:41 -0400 2009:
> > > Excerpts from Ben Walton's message of Tue Aug 18 19:35:35 +0200 2009:
> > > >
> > > > I just tried to import my index to xapian and it crashed part way
> > > > through the import. I then discovered that I couldn't use ferret
> > > > either. There is something wonky with label handling, as per attached
> > > > exception log. I haven't had a chance to look at the code yet, but
> > > > I'll poke at it tonight.
> > >
> > > I think I just ran into the same problem! For now I fixed it with
> > > the following small patch:
> >
> > That's odd because the Xapian code passes the labels straight through
> > from the message to LabelManager. Try instrumenting Message#labels= to
> > raise an exception if any member of the set is not a Symbol.
>
> I applied the following patch:
>
> diff --git a/lib/sup/message.rb b/lib/sup/message.rb
> index 965c10e..9156c02 100644
> --- a/lib/sup/message.rb
> +++ b/lib/sup/message.rb
> @@ -1,4 +1,5 @@
> require 'time'
> +require 'pp'
>
> module Redwood
>
> @@ -183,6 +184,7 @@ class Message
> def labels= l
> raise ArgumentError, "not a set" unless l.is_a?(Set)
> return if @labels == l
> + warn "labels=#{l.pretty_inspect}"
> @labels = l
> @dirty = true
> end
>
> And get this in the logs:
>
> [Tue Aug 18 21:12:39 +0200 2009] WARNING: labels=#<Set: {:inbox, :unread,
> "aquarius", "music"}>
> [Tue Aug 18 21:12:39 +0200 2009] WARNING: labels=#<Set: {:inbox, :unread,
> "metalblade", "music"}>
>
It'd be nice to get a backtrace including the offending caller. I'd just
replace the warn with a fail.
------------------------------
Message: 800
Date: Tue, 18 Aug 2009 22:14:49 +0200
From: Beno?t PIERRE <benoit.pierre@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] crash when sup-syncing to xapian
Message-ID: <1250626302-sup-2408@localdomain>
Content-Type: text/plain; charset="utf-8"
Excerpts from Rich Lane's message of Tue Aug 18 21:52:12 +0200 2009:
> Excerpts from Beno?t PIERRE's message of Tue Aug 18 15:17:03 -0400 2009:
>
> [...]
>
> It'd be nice to get a backtrace including the offending caller. I'd just
> replace the warn with a fail.
The problem comes from my ~/.sup/sources.yaml file, the labels for a source
are not symbols:
hash:
relapse: true
music: true
After converting them to symbols it works:
hash:
:relapse: true
:music: true
--
A: Because it destroys the flow of conversation.
Q: Why is top posting dumb?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090818/94c721f9/attachment-0001.bin>
------------------------------
Message: 801
Date: Tue, 18 Aug 2009 14:02:05 -0700
From: Carl Worth <cworth@cworth.org>
To: Sup Mailing List <sup-talk@rubyforge.org>
Subject: [sup-talk] What's your sup workflow (and a spew of ideas)
Message-ID: <1250629282-sup-8521@yoom>
Content-Type: text/plain; charset="utf-8"
I'm now a few days into using sup, and it's clearly helped me to be
more productive at processing mail, (inbox is down to 0 from *lots* of
messages), so thanks!
However, I still don't feel like I'm experiencing the zen of sup
yet. So I'm interested in hearing from others:
What is your typical workflow with sup? That is:
What different modes of task do you find yourself doing with sup?
Precisely what keystrokes do you use for those tasks?
Where, if anywhere, does sup get in your way rather than help?
What follows is my (rather long) answer to those questions, and more
or less a todo list of things I'd like to help improve in sup.
My desired workflow
===================
I think there's a basic two-level approach I take to processing new
email. Fortunately, these two modes correspond well with sup's
inbox-mode and thread-view-mode. Here's what I'd like to do:
Identify "unimportant" threads (no need to read)
------------------------------------------------
This is a quick scan of the thread titles in my inbox. The goal here
is to identify as quickly as possible threads that I will never need
to read at all, (so that they can be immediately removed from my
inbox). Ideally, I will make a decision in one or two seconds, and
issue a single character command to indicate the decision.
Dealing with remaining "important" threads
------------------------------------------
After having eliminated as many threads as possible during the scan of
the inbox, I now switch to a mode where I'm actually looking at mail
messages. The goal here is to identify whether I need to do anything,
and how much time that will take. There are three possible outcomes:
* No action needed
* Quick action, (less than two minutes)
* Longer action required (to assign to some project)
(Any similarity to a method proposed by David Allen in Getting Things
Done is not accidental, and he deserves credit as such.)
Regardless of the three results, I will be quickly archiving the
thread so that it's gone from my inbox. That will be either immediate
archiving, archiving after a quick action (such as a reply), or
archiving after tagging the thread with a label for the appropriate
project.
How sup could support my workflow better
========================================
So sup obviously fits in quite well with the above model---which is
why I immediately fell in love with it. So first of all I have to
again say thank you. And I apologize that I will go into more detail
on the things I'd like to change in sup as opposed to the things that
already work so well. This isn't a criticism of the tool, just an
expression of my desire to improve it.
I'll phrase the list below as feature requests. Some of these things
may already exist in sup, and I just missed them. In such cases, I'll
be glad to hear pointers to the things I missed. Otherwise, I plan to
work on developing patches for these, and I'll be glad for any help.
I'll give each feature a name in [square-brackets] for easy reference in followup messages.
inbox-mode
-----------
* [black-on-white-color-scheme]
We've talked in another thread about adding support for a
black-text-on-white-background color scheme to sup-config. Before I
can write a patch for that, does somebody have an example
black-on-white color scheme that works well? I've been trying to
come up with one but I've been unable to find how to change some
colors, specifically:
+ [change-color-of-thread-selector]
The selector for the current thread in thread-mode appears as
black-foreground-on-cyan right now. I haven't been able to find
the setting to make that a more easy-to-read background color, and
this is the only line in the view that isn't bold when unread,
(which is not ideal since it's the only line I'm trying to read
and process).
+ [change-color-of-tag-markers]
The tag markers are yellow, which is hard to see on white. I also
couldn't find the setting to change this.
* [import-read-messages-as-archived-from-initial-sup-config-based-sync]
When I very first started using sup, (running sup-config which setup
sources and ran sup-sync) I was surprised to find my inbox with
thousands of unread messages in it. Now that I'm using sup more I
love that sup treats inbox and unread as separate labels, (far too
many email programs fail to separate those notions). But for that
initial import, I think it would have been much more useful to have
only given the inbox tag to unread messages.
* [sort-priority-labels-before-date]
The default sorting for the inbox is reverse-chronological which is
a reasonable-enough default, (and works fine for me when I keep my
inbox small). But when I get behind and my inbox gets large, (say
after a few days away from email), I do have some tags that I would
like to be sorted to the top, regardless of date. How about support
for a configurable list of "priority" tags that would provide a
primary sort before the date-based sort?
* [save-all-state-changes-immediately]
The 'a' and 'd' commands do almost exactly what I expect, (by
immediately making the current thread disappear and advancing the
selector to the next thread). That's perfect for fast
processing. One thing missing here is that they don't actually save
this state, (requiring me to hit '$' at some point). Perhaps that
safety feature was more important before undo was implemented, but
now that it exists, would immediate state saving make sense?
The two bad side effects I've experienced due to lack of immediate
saving are: 1. Seeing confusingly inconsistent results after
processing a bunch of my inbox and then doing a search based on
label:unread or label:inbox (Why am I seeing all these messages
again?). 2. Losing a bunch of processing state due to crashes. (The
crashes have been due to the mbox-processing bug which has since
been fixed, but being immune to state loss for any future crashes
would be beneficial.)
search-results-mode
-------------------
* [provide-commands-to-refine-the-current-search]
I mentioned above wanting to sort priority labels before
date. Similarly, when processing a very large email I sometimes want
to process related messages together, (to reduce mental context
switches). So I want variants of both "\, F: Search all messages"
and "L: list labels" search commands that refine the current search
rather than doing a new global search. That is, the new commands
would simply append new search terms to the current search rather
than starting a new search.
* [allow-for-inbox-mode-magic-elsewhere]
Another way to reword this one would be to "eliminate any magic of
inbox mode". My question is, "What makes inbox-mode different than
search-results-mode and how can I get the behavior of inbox-mode in
my searches?".
Without commands to refine the current search as described above,
I've been trying to achieve results like "inbox refined to
label:foo" with a search as follows:
label:inbox -label:killed label:foo
This gives me the set of threads that I want, but now my standard
processing commands no longer work. For example, the 'a' key still
removes the inbox label, but it doesn't make the tag then disappear
immediately.
One approach to fix this would be that when adding the commands to
refine the inbox search, the new search results would also be in
inbox-mode with all necessary magic.
A more general fix would be to process the current thread after any
changes, (such as the addition or removal of a label), and removing
it from the current search results if it no longer meets those
criteria.
* [fix-handling-of-kill-thread-outside-inbox]
The handling of the "&: kill thread" command when applied outside of
the inbox, (such as in search-results-mode), is currently very
confusing. What it currently seems to do is to add the killed label
and make the thread disappear from the current view. But then,
running "@: Refresh view" will make it reappear, (whereupon one can
make it disappear again with &, ad infinitum). The removal of the
thread from the current view seems to be magic associated with the
kill-thread command, (leading to inconsistent behavior). I would
again suggest to instead implement the general fix described above,
(always reprocessing a thread after label changes to see if it still
meets the current search). That way, trying to kill a thread without
-label:killed in the current search would simply add the "killed"
label and the user would learn to add the necessary search terms,
(or to do searches based on refining the searches of existing views
to inherit this term).
thread-view-mode
----------------
* [override-arrow-keys-to-jump-to-next-actionable-line]
In thread-view-mode the up and down arrows currently advance a
selector by one line at a time, (inherited from line-cursor-mode),
all the way into message bodies. As far as I can tell, this is not a
useful behavior. I propose that the down arrow key should instead
advance the selector to the next line which would cause a context
change for the various operations that can be performed based on the
selector, (or scroll to the next page if there are no such lines on
the current or next page).
* [be-less-overzealous-in-moving-text-to-the-left-column]
I tend to use sup in a very wide terminal, (200+ columns). And I'm
glad to see that the inbox-mode takes advantage of this by showing a
preview of the message body (that's a nice touch!) where many
console-based clients just cut things off at 80 columns.
However, in thread-view-mode, sup always pushes the current message
all the way over to the left-hand column. This does mean that the
"current" message is visible, but I have a tendency to read much
more than the current message, (even before advancing), and
subsequent messages are often scrolled such that the first several
columns of text are scrolled off to the left. Meanwhile, I have
acres of terminal real-estate to the right that sup isn't using.
I would propose that messages only be scrolled to the left if
necessary to avoid the 80th column of the message body not being
visible, (assuming the terminal is at least 80 columns wide).
compose-mode
------------
* [repeated-postponing-shouldnt-make-additional-drafts]
I find that while composing a message I often want to go look at
some other messages for reference. This is currently quite awkward
with sup. It would be easier if sup could be run multiple times. It
would also be easier if sup could somehow fire off an editor as an
external process, while still allowing for sup to be operated.
As it stands, instead, I have to save and quit from my editor,
postpone the message within sup, and then later come back to edit it
again, and find where I was in the editor. It's an expensive context
switch with a lot of keystrokes and lost state, (such as where point
was inside emacs, my kill ring, etc.). I'm currently finding myself
sometimes just drafting messages in emacs sessions unrelated to sup,
and then doing "M-x insert-file" once sup has launched emacs for
me. (This does relate a bit to the point I made in a previous thread
where I would love to find a way to keep all the mail-composition
tasks very separate from sup, but not lose things like replied-to
bits.)
Anyway, the current misfeature I'm hitting is that if I do postpone
a draft, then return to edit it more, then postpone it again,
etc. eventually when I send the message I'll have several
partially-composed drafts in various states that I need to go and
manually clean up. It seems like most email programs avoid this
problem by removing the draft as soon as its selected for editing
again, and I propose that sup do the same.
Anyway, I've probably run into several other little things that I
didn't capture in this email, but I'll hopefully remember them
later. If anyone has feedback on any of the above, (and actually read
this far!), then I'll appreciate getting it.
Otherwise, like I said, I hope to start trying to implement some of
these ideas, and when I do, I'll of course come back with separate new
threads for each.
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090818/43f15a25/attachment-0001.bin>
------------------------------
Message: 802
Date: Tue, 18 Aug 2009 13:30:34 -0400
From: Mike Kelly <pioto@pioto.org>
To: <sup-talk@rubyforge.org>
Subject: [sup-talk] Crash w/ current 'next'
Message-ID: <aeb4682e1581f7534cb1c81bd143dbc6@pioto.org>
Content-Type: text/plain; charset="utf-8"
Hi,
I just built from the current next branch, and now whenever I load sup, it
gives me the attached crash.
I'm guessing this is related to the Set thing William mentioned, but I have
just gone from an older 'next' to a newer one, which I thought was supposed
to not have this problem.
Any suggestions?
--
Mike Kelly
-------------- next part --------------
--- ArgumentError from thread: poll after loading inbox
expecting a symbol
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/label.rb:64:in `<<'
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:149:in `each_message_from'
/usr/local/lib/ruby/1.8/set.rb:195:in `each'
/usr/local/lib/ruby/1.8/set.rb:195:in `each_key'
/usr/local/lib/ruby/1.8/set.rb:195:in `each'
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:149:in `each_message_from'
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/source.rb:104:in `each'
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:560:in `send'
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:560:in `__pass'
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:547:in `method_missing'
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:140:in `each_message_from'
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:93:in `do_poll'
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:81:in `each'
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:81:in `do_poll'
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:80:in `synchronize'
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:80:in `do_poll'
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/poll-mode.rb:15:in `poll'
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:48:in `poll'
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/bin/sup:190
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:77:in `reporting_thread'
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:75:in `initialize'
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:75:in `new'
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:75:in `reporting_thread'
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/bin/sup:190
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:666:in `call'
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:666:in `__unprotected_load_threads'
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:608:in `call'
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background'
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:77:in `reporting_thread'
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:75:in `initialize'
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:75:in `new'
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:75:in `reporting_thread'
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:606:in `load_n_threads_background'
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:676:in `__unprotected_load_threads'
(eval):12:in `load_threads'
/usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/bin/sup:190
/usr/home/staff/mike/lib/ruby/gems/1.8/bin/sup:19:in `load'
/usr/home/staff/mike/lib/ruby/gems/1.8/bin/sup:19
------------------------------
Message: 803
Date: Tue, 18 Aug 2009 14:46:41 -0700
From: Carl Worth <cworth@cworth.org>
To: Sup Mailing List <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] What's your sup workflow (and a spew of ideas)
Message-ID: <1250631221-sup-8993@yoom>
Content-Type: text/plain; charset="utf-8"
Excerpts from Carl Worth's message of Tue Aug 18 14:02:05 -0700 2009:
> Anyway, I've probably run into several other little things that I
> didn't capture in this email, but I'll hopefully remember them
> later.
And of course, here are a few:
inbox-mode
----------
* [dont-perturb-selected-thread-when-new-mail-arrives]
I think I just saw the following race condition:
1. I have the top-most thread selected and I identify it as spam
2. I start moving to press the d key to delete it
3. Before I get their, new mail arrives and becomes selected
4. I delete mail I really care about
I propose that new mail arriving should not cause the selector to
move from the thread currently selected.
label-list-mode
---------------
* [allow-for-limiting-to-interesting-labels]
In the workflow I described earlier, I process all mail mercilessly
and get it archived and out of my inbox as quickly as possible. But
some of those threads I identified as needing some significant time
to deal with, so I labelled them to assign them to a particular
"project".
So, later, I'd like to look at my list of projects, choose one, and
then choose the first task to be done.
The label-list-mode is *almost* the perfect thing for this. The
only problem is that it displays several labels, (with *lots* of
messages each) that are not interesting to me at all in this
sense. For example, killed and unread, for example, as well as
several other labels that I use in ways other than my "project"
labels.
What I'd like here is a feature much like 'u' which toggles to
display of only labels with unread messages, but insteads toggles
to display only the labels that I've somehow marked as my "project"
labels. (I'm not sure exactly how to name this feature for general
use. The "project" sense is something personal to my usage. Maybe,
"todo" or something?)
inbox-mode/search-result-mode
-----------------------------
* [display-number-of-unread-messages]
In my ruthless scan while processing new messages, I want to be able
to make split-second, yet accurate, decisions on whether I need to
read messages, (and if so, how much time it will take). The current
thread display shows a total number of messages within a thread, but
that leads to me making an inaccurate estimate of how "expensive" it
would be to read a thread. I'd much rather see the number of unread
messages in the thread. Perhaps best would be to diplay both numbers
such as: (1/64) with the 1 in bold to indicate that a thread with 64
total messages has 1 unread message.
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090818/5f65c5b3/attachment-0001.bin>
------------------------------
Message: 804
Date: Tue, 18 Aug 2009 18:07:28 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] What's your sup workflow (and a spew of ideas)
Message-ID: <1250632714-sup-9910@Longbow>
Content-Type: text/plain; charset=utf8
Excerpts from Carl Worth's message of Tue Aug 18 17:02:05 -0400 2009:
> * [sort-priority-labels-before-date]
>
> The default sorting for the inbox is reverse-chronological which is
> a reasonable-enough default, (and works fine for me when I keep my
> inbox small). But when I get behind and my inbox gets large, (say
> after a few days away from email), I do have some tags that I would
> like to be sorted to the top, regardless of date. How about support
> for a configurable list of "priority" tags that would provide a
> primary sort before the date-based sort?
Yeah, I'd really really like this also. This has been discussed, and in
general, it'd be lovely to be able to sort by hook or something. I think
grouping by labels first and then by time would be a good default.
> * [save-all-state-changes-immediately]
>
> The 'a' and 'd' commands do almost exactly what I expect, (by
> immediately making the current thread disappear and advancing the
> selector to the next thread). That's perfect for fast
> processing. One thing missing here is that they don't actually save
> this state, (requiring me to hit '$' at some point). Perhaps that
> safety feature was more important before undo was implemented, but
> now that it exists, would immediate state saving make sense?
>
> The two bad side effects I've experienced due to lack of immediate
> saving are: 1. Seeing confusingly inconsistent results after
> processing a bunch of my inbox and then doing a search based on
> label:unread or label:inbox (Why am I seeing all these messages
> again?). 2. Losing a bunch of processing state due to crashes. (The
> crashes have been due to the mbox-processing bug which has since
> been fixed, but being immune to state loss for any future crashes
> would be beneficial.)
I assume here that part of the problem is the time it takes to write
changes. If I read all my morning e-mails and then press $, it usually
takes a few seconds for this to finish. If it's just one e-mail, there
is still usually a noticeable-ish delay.
However, perhaps Xapian will improve this speed also, and if this is the
case, I'd love an "autosave" option at least in the config.
> * [repeated-postponing-shouldnt-make-additional-drafts]
>
> I find that while composing a message I often want to go look at
> some other messages for reference. This is currently quite awkward
> with sup. It would be easier if sup could be run multiple times. It
> would also be easier if sup could somehow fire off an editor as an
> external process, while still allowing for sup to be operated.
>
> As it stands, instead, I have to save and quit from my editor,
> postpone the message within sup, and then later come back to edit it
> again, and find where I was in the editor. It's an expensive context
> switch with a lot of keystrokes and lost state, (such as where point
> was inside emacs, my kill ring, etc.). I'm currently finding myself
> sometimes just drafting messages in emacs sessions unrelated to sup,
> and then doing "M-x insert-file" once sup has launched emacs for
> me. (This does relate a bit to the point I made in a previous thread
> where I would love to find a way to keep all the mail-composition
> tasks very separate from sup, but not lose things like replied-to
> bits.)
>
> Anyway, the current misfeature I'm hitting is that if I do postpone
> a draft, then return to edit it more, then postpone it again,
> etc. eventually when I send the message I'll have several
> partially-composed drafts in various states that I need to go and
> manually clean up. It seems like most email programs avoid this
> problem by removing the draft as soon as its selected for editing
> again, and I propose that sup do the same.
I think I agree there, and vaguely recall someone attempting to
implement being able to switch buffers even when an external editor is
in effect.
Anyway, impressive post there. You seem to really abuse your e-mail
client and know what you're on about. Good stuff.
--
Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
------------------------------
Message: 805
Date: Tue, 18 Aug 2009 15:16:08 -0700
From: Carl Worth <cworth@cworth.org>
To: Andrei Thorp <garoth@gmail.com>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] What's your sup workflow (and a spew of ideas)
Message-ID: <1250633501-sup-3981@yoom>
Content-Type: text/plain; charset="utf-8"
Excerpts from Andrei Thorp's message of Tue Aug 18 15:07:28 -0700 2009:
> Excerpts from Carl Worth's message of Tue Aug 18 17:02:05 -0400 2009:
> > Anyway, the current misfeature I'm hitting is that if I do postpone
> > a draft, then return to edit it more, then postpone it again,
> > etc. eventually when I send the message I'll have several
> > partially-composed drafts in various states that I need to go and
> > manually clean up. It seems like most email programs avoid this
> > problem by removing the draft as soon as its selected for editing
> > again, and I propose that sup do the same.
>
> I think I agree there, and vaguely recall someone attempting to
> implement being able to switch buffers even when an external editor is
> in effect.
That would be nice. In the meantime, I have realized that I don't need
to actually postpone my messages to do what I want---I can just exit
the editor and then switch buffers from compose-mode/reply-mode. So
that at least avoids the multiple-drafts issue, (but still leaves the
I-lose-my-state-when-I-quit-the-editor issue).
> Anyway, impressive post there. You seem to really abuse your e-mail
> client and know what you're on about. Good stuff.
Thanks. I have had a lot of ideas cooking for years about what my
dream email-system would look like. I think the impressive bit is that
of the half-dozen programs I've used in the last decade, sup is the
first one to get me to write up a post like that. (All other programs
were so far away from what I wanted as to make it infeasible to fix
them incrementally.)
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090818/6e240f41/attachment-0001.bin>
------------------------------
Message: 806
Date: Tue, 18 Aug 2009 19:02:01 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] What's your sup workflow (and a spew of ideas)
Message-ID: <1250634897-sup-4631@zyrg.net>
Content-Type: text/plain; charset=UTF-8
provide-commands-to-refine-the-current-search:
'|' exists for search-results-mode (and it should be implemented for
label-results-mode if it doesn't exist there).
sort-priority-labels-before-date:
This isn't entirely easy for large numbers of messages. We've optimized
the index (especially Xapian) for reverse chronological order. You could
either do the sorting entirely in the UI, but just on the subset of
results currently loaded, or you could create a new mode that merges and
prioritizes the results of multiple queries.
allow-for-limiting-to-interesting-labels:
I have a hack for this. I reopen Redwood::Mode in the startup hook, then
add a keybinding to spawn a SearchResultsMode for a set of interesting
labels. Same for starred messages. A better solution would be good.
save-all-state-changes-immediately,
allow-for-inbox-mode-magic-elsewhere,
fix-handling-of-kill-thread-outside-inbox:
These are related - saving label changes immediately means we can use
the index to decide which threads are relevant. The new index api
methods unblock this, and now that they're in next I plan to implement
this soon.
be-less-overzealous-in-moving-text-to-the-left-column,
dont-perturb-selected-thread-when-new-mail-arrives:
+1 to these.
------------------------------
Message: 807
Date: Tue, 18 Aug 2009 19:36:15 -0400
From: Kevin Riggle <kevinr@free-dissociation.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Add an after-add-message hook
Message-ID: <1250638381-sup-2952@black-opal.mit.edu>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Tue Aug 18 13:56:15 -0400 2009:
> Reformatted excerpts from Kevin Riggle's message of 2009-08-16:
> > I want to do some unrelated processing on each message I receive, but
> > I don't want to block the message being added to the index. This
> > patch adds a hook which runs /after/ the message is added to the
> > index.
>
> Won't this block subsequent emails from being added to the index, when
> Sup gets multiple new emails during a poll?
I don't /think/ so, unless I misunderstand the way hooks work. I assumed
the hook would execute and then execution of the loop would resume, and
I don't think I throw anything in the hook which should cause that either.
- Kevin
--
Kevin Riggle (kevinr@free-dissociation.com)
http://free-dissociation.com
------------------------------
Message: 808
Date: Tue, 18 Aug 2009 20:03:49 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] crash when sup-syncing to xapian
Message-ID: <1250640188-sup-7551@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Beno?t PIERRE's message of Tue Aug 18 16:14:49 -0400 2009:
> After converting them to symbols it works:
>
> hash:
> :relapse: true
> :music: true
I have labels setup to import as an array (of strings)...is this not
the way it's supposed to be?
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090818/9e8e3a03/attachment-0001.bin>
------------------------------
Message: 809
Date: Tue, 18 Aug 2009 17:49:03 -0700
From: Carl Worth <cworth@cworth.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Exception trying to run git source
Message-ID: <1250642676-sup-2244@yoom>
Content-Type: text/plain; charset="utf-8"
Until now I've been running sup 0.8.1 from a Debian package. But in an
effort to get to where I can actually start implementing some of the
features I want, (and to get to where I can actually send a message
without triggering sent.mbox crashes), I'm trying to move to running
sup from a git checkout. But whenever I try, I get the following
exception:
--- NoMethodError from thread: main
undefined method `source_uri' for #<Redwood::SentManager:0xb74f1160 @source=nil, @fn="sup://sent">
./lib/sup/util.rb:519:in `send'
./lib/sup/util.rb:519:in `method_missing'
bin/sup:171
I bisected this down to the following commit:
commit 5057149d9c3b57c6b5c4d0964a0aae9d490aaa38
Author: Ben Walton <bwalton@artsci.utoronto.ca>
Date: Wed May 6 22:44:24 2009 -0400
SentManager: rework handling to allow for user specified source
That looks like an awfully nice commit since I'd like my sent messages
to go into a maildir anyway. So I tried configuring this by adding a
line to my ~/.sup/config.yaml as follows:
:sent_source: maildir:/home/cworth/mail/sent
That didn't actually help too much, it just changed the stack trace
slightly:
--- NoMethodError from thread: main
undefined method `source_uri' for #<Redwood::SentManager:0xb73ce404>
./lib/sup/util.rb:519:in `send'
./lib/sup/util.rb:519:in `method_missing'
bin/sup:171
So what am I actually missing here?
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090818/a004f5e4/attachment-0001.bin>
------------------------------
Message: 810
Date: Tue, 18 Aug 2009 18:58:55 -0700
From: Carl Worth <cworth@cworth.org>
To: Rich Lane <rlane@club.cc.cmu.edu>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] What's your sup workflow (and a spew of ideas)
Message-ID: <1250646478-sup-4064@yoom>
Content-Type: text/plain; charset="utf-8"
Excerpts from Rich Lane's message of Tue Aug 18 16:02:01 -0700 2009:
> provide-commands-to-refine-the-current-search:
>
> '|' exists for search-results-mode (and it should be implemented for
> label-results-mode if it doesn't exist there).
Ah, thanks for pointing this out. I totally missed it somehow.
This doesn't exist for inbox-mode, which is where I think I would like
it the most. And conceptually, the inbox is just a search, right? It
seems to me that inbox-mode should be at most a very slight tweak of
search-results-mode. I'll go digging in the code to see how far away
that would be.
For what it's worth, | doesn't exist for search-results mode.
And also, the shortcuts to refine the search by adding a label would
be nice too, (so one wouldn't need to type "label:"). So now I at
least know what already exists.
> sort-priority-labels-before-date:
>
> This isn't entirely easy for large numbers of messages. We've optimized
> the index (especially Xapian) for reverse chronological order. You could
> either do the sorting entirely in the UI, but just on the subset of
> results currently loaded, or you could create a new mode that merges and
> prioritizes the results of multiple queries.
I think the former would be fine. The UI encourages only a small number of
results to be loaded already, so just sorting there should work find I
thin.
> allow-for-limiting-to-interesting-labels:
>
> I have a hack for this. I reopen Redwood::Mode in the startup hook, then
> add a keybinding to spawn a SearchResultsMode for a set of interesting
> labels. Same for starred messages. A better solution would be good.
While waiting for a better solution, would you mind sharing your code
for this? I'm quite new to ruby, so even if what you described should
be trivial for me to replicate, it's not yet. :-)
Maybe a page on the wiki?
> save-all-state-changes-immediately,
> allow-for-inbox-mode-magic-elsewhere,
> fix-handling-of-kill-thread-outside-inbox:
>
> These are related - saving label changes immediately means we can use
> the index to decide which threads are relevant. The new index api
> methods unblock this, and now that they're in next I plan to implement
> this soon.
Excellent. It did seem that things were moving this direction, and I'm
glad to hear that they are.
> be-less-overzealous-in-moving-text-to-the-left-column,
> dont-perturb-selected-thread-when-new-mail-arrives:
>
> +1 to these.
Great. And those don't sound too complicated, so maybe I'll try
cutting my teeth on those first.
Meanwhile, I thought of another race condition. If new mail arrives
for the current thread when in thread-view-mode, does it get added to
the view? It might seem nice for it to show up, but it might also lead
to it getting accidentally archived away if I "knew" that there were
only 4 messages, say, when I entered the thread view, then I hit ".a"
and archived away 5 messages.
It seems a silly thing, but it's the kind of thing that makes me start
distrusting ".a" and instead using "x", double-checking, then "a"
which is obviously less efficient. (Oh, and there's another place
where the current selector needs to not be perturbed. After I hit "x"
from thread-view-mode I find that a different thread can be selected
than the one I was just viewing if new mail arrived.)
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090818/ab65d341/attachment-0001.bin>
------------------------------
Message: 811
Date: Tue, 18 Aug 2009 22:47:40 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Exception trying to run git source
Message-ID: <1250649988-sup-9079@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Carl Worth's message of Tue Aug 18 20:49:03 -0400 2009:
>
> --- NoMethodError from thread: main
> undefined method `source_uri' for #<Redwood::SentManager:0xb74f1160
> @source=nil, @fn="sup://sent">
> ./lib/sup/util.rb:519:in `send'
> ./lib/sup/util.rb:519:in `method_missing'
> bin/sup:171
Hmm...I think that's likely an easy fix. I'll look tomorrow morning.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090818/2ef0d45e/attachment-0001.bin>
------------------------------
Message: 812
Date: Tue, 18 Aug 2009 23:02:57 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] What's your sup workflow (and a spew of ideas)
Message-ID: <1250649270-sup-2166@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from Carl Worth's message of Tue Aug 18 21:58:55 -0400 2009:
> > allow-for-limiting-to-interesting-labels:
> >
> > I have a hack for this. I reopen Redwood::Mode in the startup hook, then
> > add a keybinding to spawn a SearchResultsMode for a set of interesting
> > labels. Same for starred messages. A better solution would be good.
>
> While waiting for a better solution, would you mind sharing your code
> for this? I'm quite new to ruby, so even if what you described should
> be trivial for me to replicate, it's not yet. :-)
>
> Maybe a page on the wiki?
Sure, I added an example to the end of the Hooks page.
> Meanwhile, I thought of another race condition. If new mail arrives
> for the current thread when in thread-view-mode, does it get added to
> the view? It might seem nice for it to show up, but it might also lead
> to it getting accidentally archived away if I "knew" that there were
> only 4 messages, say, when I entered the thread view, then I hit ".a"
> and archived away 5 messages.
>
> It seems a silly thing, but it's the kind of thing that makes me start
> distrusting ".a" and instead using "x", double-checking, then "a"
> which is obviously less efficient. (Oh, and there's another place
> where the current selector needs to not be perturbed. After I hit "x"
> from thread-view-mode I find that a different thread can be selected
> than the one I was just viewing if new mail arrived.)
I'm glad to know there are other people annoyed by UI race conditions :).
Even after a quick look at the code I'm not sure what ThreadViewMode
will do when a thread is added to. It might actually archive/read/etc
new messages but not display them.
I'd like a keybinding to reload/redisplay the thread and a status bar
note if there are new messages. Any label changes should only affect
messages that have been displayed. What do you think?
------------------------------
Message: 813
Date: Wed, 19 Aug 2009 10:03:49 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] What's your sup workflow (and a spew of ideas)
Message-ID: <1250690604-sup-4154@Longbow>
Content-Type: text/plain; charset=utf8
Excerpts from Rich Lane's message of Tue Aug 18 23:02:57 -0400 2009:
> I'm glad to know there are other people annoyed by UI race conditions :).
> Even after a quick look at the code I'm not sure what ThreadViewMode
> will do when a thread is added to. It might actually archive/read/etc
> new messages but not display them.
>
> I'd like a keybinding to reload/redisplay the thread and a status bar
> note if there are new messages. Any label changes should only affect
> messages that have been displayed. What do you think?
Ooh, I like it. I guess gmail does this.
--
Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
------------------------------
Message: 814
Date: Wed, 19 Aug 2009 11:59:12 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Exception trying to run git source
Message-ID: <1250697503-sup-1083@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Carl Worth's message of Tue Aug 18 20:49:03 -0400 2009:
> line to my ~/.sup/config.yaml as follows:
>
> :sent_source: maildir:/home/cworth/mail/sent
Here is my configuration:
maildir:///u/bwalton/Maildir/.sent-mail/
I think you just need to fix the URI. I'm looking into the code
though to see why it bombed out on you.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090819/f9f554ee/attachment-0001.bin>
------------------------------
Message: 815
Date: Wed, 19 Aug 2009 09:19:44 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Exception trying to run git source
Message-ID: <1250698636-sup-6732@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Carl Worth's message of 2009-08-18:
> --- NoMethodError from thread: main
> undefined method `source_uri' for #<Redwood::SentManager:0xb74f1160
> @source=nil, @fn="sup://sent">
Very curious. SentManager most definitely has a source_uri method. If
you look at lib/sup/sent.rb, does it include the line "attr_reader
:source, :source_uri"? If so, is there a line in the log that says
"SentManager initialized with source uri: xxx"?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 816
Date: Wed, 19 Aug 2009 09:33:10 -0700
From: Carl Worth <cworth@cworth.org>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Exception trying to run git source
Message-ID: <1250699408-sup-9579@yoom>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Wed Aug 19 09:19:44 -0700 2009:
> Reformatted excerpts from Carl Worth's message of 2009-08-18:
> > --- NoMethodError from thread: main
> > undefined method `source_uri' for #<Redwood::SentManager:0xb74f1160
> > @source=nil, @fn="sup://sent">
>
> Very curious. SentManager most definitely has a source_uri method. If
> you look at lib/sup/sent.rb, does it include the line "attr_reader
> :source, :source_uri"?
Yes, that is there.
> If so, is there a line in the log that says
> "SentManager initialized with source uri: xxx"?
No, I don't think so. At least, that is, if I'm looking at the right
place. Is the "log" anything other than the output on stdout/err when
I run sup? Do I need to turn on any additional verbosity somehow?
Below you can see the entire output I get when running sup from git
master.
-Carl (wishing he had any skills for debugging ruby...)
0:~/src/sup:(master)$ ruby -I lib -w bin/sup
./lib/sup/util.rb:8: warning: method redefined; discarding old
gen_lock_id
./lib/sup/util.rb:19: warning: method redefined; discarding old
dump_lock_id
[Wed Aug 19 09:22:55 -0700 2009] using character set encoding "UTF-8"
./lib/sup/message-chunks.rb:36: warning: method redefined; discarding
old make_tmpname
./lib/sup/imap.rb:117: warning: ambiguous first argument; put
parentheses or even spaces
/usr/lib/ruby/1.8/chronic/repeaters/repeater_month_name.rb:13:
warning: useless use of > in void context
/usr/lib/ruby/1.8/chronic/repeaters/repeater_month_name.rb:19:
warning: useless use of > in void context
/usr/lib/ruby/1.8/chronic/repeaters/repeater_month_name.rb:25:
warning: useless use of < in void context
[Wed Aug 19 09:22:55 -0700 2009] using index Redwood::FerretIndex
Warning: $KCODE is NONE.
[Wed Aug 19 09:22:55 -0700 2009] dynamically loading setlocale() from
libc.so.6
[Wed Aug 19 09:22:55 -0700 2009] setting locale...
[Wed Aug 19 09:22:55 -0700 2009] locking /home/cworth/.sup/lock...
[Wed Aug 19 09:22:55 -0700 2009] crypto: detected gpg binary in
/usr/bin/gpg
[Wed Aug 19 09:22:55 -0700 2009] loading index...
[Wed Aug 19 09:22:55 -0700 2009] loaded index of 557361 messages
./lib/sup/index.rb:53: warning: instance variable @lock_update_thread
not initialized
bin/sup:126: warning: global variable `$cursing' not initialized
[Wed Aug 19 09:22:55 -0700 2009] stopped cursing
[Wed Aug 19 09:22:55 -0700 2009] oh crap, an exception
[Wed Aug 19 09:22:55 -0700 2009] unlocking /home/cworth/.sup/lock...
----------------------------------------------------------------
I'm very sorry. It seems that an error occurred in Sup. Please
accept my sincere apologies. If you don't mind, please send the
contents of ~/.sup/exception-log.txt and a brief report of the
circumstances to sup-talk at rubyforge dot orgs so that I might
address this problem. Thank you!
Sincerely,
William
----------------------------------------------------------------
--- NoMethodError from thread: main
undefined method `source_uri' for #<Redwood::SentManager:0xb75441a8
@source=nil, @fn="sup://sent">
./lib/sup/util.rb:519:in `send'
./lib/sup/util.rb:519:in `method_missing'
bin/sup:171
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090819/9feb1415/attachment-0001.bin>
------------------------------
Message: 817
Date: Wed, 19 Aug 2009 12:34:09 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Exception trying to run git source
Message-ID: <1250699596-sup-8133@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Wed Aug 19 12:19:44 -0400 2009:
> Reformatted excerpts from Carl Worth's message of 2009-08-18:
> > --- NoMethodError from thread: main
> > undefined method `source_uri' for #<Redwood::SentManager:0xb74f1160
> > @source=nil, @fn="sup://sent">
>
> Very curious. SentManager most definitely has a source_uri method. If
> you look at lib/sup/sent.rb, does it include the line "attr_reader
> :source, :source_uri"? If so, is there a line in the log that says
> "SentManager initialized with source uri: xxx"?
Also, is bin/sup part of your git checkout (meaning it lines up with
the rest of your lib/, etc)? Are you running from the next branch?
I'm looking at bin/sup here (5f393122), and the line numbers don't
"add up." Line 152 is where I see the call into
SentManager.source_uri, not 171.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090819/4c299b1e/attachment-0001.bin>
------------------------------
Message: 818
Date: Wed, 19 Aug 2009 10:53:54 -0700
From: Carl Worth <cworth@cworth.org>
To: Ben Walton <bwalton@artsci.utoronto.ca>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Exception trying to run git source
Message-ID: <1250704257-sup-3308@yoom>
Content-Type: text/plain; charset=UTF-8
Excerpts from Ben Walton's message of Wed Aug 19 09:34:09 -0700 2009:
> Also, is bin/sup part of your git checkout (meaning it lines up with
> the rest of your lib/, etc)?
Yes.
> Are you running from the next branch?
> I'm looking at bin/sup here (5f393122), and the line numbers don't
> "add up." Line 152 is where I see the call into
> SentManager.source_uri, not 171.
No, I was running from master, (so line 171 does make sense there).
I tried running from next and got a different failure (see below). I
suspected I might have something just broken in my configuration, so I
moved ~/.sup away for the run below, (which didn't seem to change
anything).
This new failure seems to be occurring earlier, so I bisected,
(labelling the previous source_uri exception as "good" and the new
no-SentManager-instance as "bad"), and that pointed at the following
commit:
9dd4f50b9f62ab5642241359bf6f7c291ccfa738 is first bad commit
commit 9dd4f50b9f62ab5642241359bf6f7c291ccfa738
Author: William Morgan <wmorgan-sup@masanjin.net>
Date: Wed Aug 12 13:14:34 2009 -0400
rewrite Singleton to not require i_am_the_instance
The flip side is that you have to use .init instead of .new.
I'm really wondering why I'm getting what appear to be unique crashes
compared to others. Is it my ruby version:
$ ruby --version
ruby 1.8.7 (2009-06-12 patchlevel 174) [i486-linux]
Any ideas?
-Carl
0:~/src/sup:(next)$ ruby -I lib -w ./bin/sup
./lib/sup/util.rb:9: warning: method redefined; discarding old gen_lock_id
./lib/sup/util.rb:20: warning: method redefined; discarding old dump_lock_id
./lib/sup/message-chunks.rb:36: warning: method redefined; discarding old make_tmpname
./lib/sup/imap.rb:118: warning: ambiguous first argument; put parentheses or even spaces
/usr/lib/ruby/1.8/chronic/repeaters/repeater_month_name.rb:13: warning: useless use of > in void context
/usr/lib/ruby/1.8/chronic/repeaters/repeater_month_name.rb:19: warning: useless use of > in void context
/usr/lib/ruby/1.8/chronic/repeaters/repeater_month_name.rb:25: warning: useless use of < in void context
[Wed Aug 19 10:26:50 -0700 2009] WARNING: Warning: $KCODE is NONE.
./lib/sup/index.rb:54: warning: instance variable @lock_update_thread not initialized
./bin/sup:127: warning: global variable `$cursing' not initialized
./bin/sup:329: warning: global variable `$die' not initialized
[Wed Aug 19 10:26:50 -0700 2009] ERROR: oh crap, an exception
----------------------------------------------------------------
I'm very sorry. It seems that an error occurred in Sup. Please
accept my sincere apologies. If you don't mind, please send the
contents of ~/.sup/exception-log.txt and a brief report of the
circumstances to sup-talk at rubyforge dot orgs so that I might
address this problem. Thank you!
Sincerely,
William
----------------------------------------------------------------
--- RuntimeError from thread: main
no Redwood::SentManager instance defined in method call to i_am_the_instance!
./lib/sup/util.rb:512:in `method_missing'
/usr/lib/ruby/1.8/sup/sent.rb:10:in `initialize'
./lib/sup/util.rb:524:in `new'
./lib/sup/util.rb:524:in `init'
./lib/sup.rb:110:in `start'
./bin/sup:138
------------------------------
Message: 819
Date: Wed, 19 Aug 2009 14:08:19 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Exception trying to run git source
Message-ID: <1250705105-sup-7923@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Carl Worth's message of Wed Aug 19 13:53:54 -0400 2009:
> $ ruby --version
> ruby 1.8.7 (2009-06-12 patchlevel 174) [i486-linux]
I'm running the (now fossilized):
$ ruby --version
ruby 1.8.5 (2006-08-25) [i386-linux]
(as shipped with rhel5).
> Any ideas?
Not right now, but I'll think about it.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090819/cd6d7c32/attachment-0001.bin>
------------------------------
Message: 820
Date: Wed, 19 Aug 2009 11:39:56 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] crash when sup-syncing to xapian
Message-ID: <1250707129-sup-7698@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Walton's message of 2009-08-18:
> There is something wonky with label handling, as per attached
> exception log.
This should be fixed in next. It was a result of some of the API
refactoring I've been doing recently. Everyone's source.yaml should now
automagically revert to the format from the good ol' days.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 821
Date: Wed, 19 Aug 2009 11:52:26 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Exception trying to run git source
Message-ID: <1250707794-sup-6173@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Carl Worth's message of 2009-08-19:
> ruby 1.8.7 (2009-06-12 patchlevel 174) [i486-linux]
Fine.
> no Redwood::SentManager instance defined in method call to i_am_the_instance!
> ./lib/sup/util.rb:512:in `method_missing'
> /usr/lib/ruby/1.8/sup/sent.rb:10:in `initialize'
> ./lib/sup/util.rb:524:in `new'
> ./lib/sup/util.rb:524:in `init'
> ./lib/sup.rb:110:in `start'
> ./bin/sup:138
Do you get this error in next head, and in the "first bad commit" you
reported? Neither of those should have any calls to i_am_the_instance!
anywhere in the code.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 822
Date: Wed, 19 Aug 2009 11:52:56 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash w/ current 'next'
Message-ID: <1250707961-sup-5229@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Mike Kelly's message of 2009-08-18:
> I just built from the current next branch, and now whenever I load
> sup, it gives me the attached crash.
Should be fixed. Sorry about that.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 823
Date: Wed, 19 Aug 2009 11:55:03 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Add an after-add-message hook
Message-ID: <1250707991-sup-5429@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Kevin Riggle's message of 2009-08-18:
> I don't /think/ so, unless I misunderstand the way hooks work. I
> assumed the hook would execute and then execution of the loop would
> resume, and I don't think I throw anything in the hook which should
> cause that either.
What I'm saying is that this hook will execute *after* each message is
added to the index, so if Sup found several new messages, all except the
first one will wait on this hook to execute before being added to the
index. Or do you mean block in some sense besides "wait for completion"?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 824
Date: Wed, 19 Aug 2009 12:40:15 -0700
From: Carl Worth <cworth@cworth.org>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Exception trying to run git source
Message-ID: <1250710221-sup-925@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Wed Aug 19 11:52:26 -0700 2009:
> > no Redwood::SentManager instance defined in method call to i_am_the_instance!
> > ./lib/sup/util.rb:512:in `method_missing'
> > /usr/lib/ruby/1.8/sup/sent.rb:10:in `initialize'
> > ./lib/sup/util.rb:524:in `new'
> > ./lib/sup/util.rb:524:in `init'
> > ./lib/sup.rb:110:in `start'
> > ./bin/sup:138
>
> Do you get this error in next head, and in the "first bad commit" you
> reported?
Yes.
> Neither of those should have any calls to i_am_the_instance!
> anywhere in the code.
Thanks. That confirms that I'm not running the code I think I am, and
the above stack trace makes that obvious, (see
/usr/lib/ruby/1.8/sup/sent.rb). So I was running some unholy mixture
of the installed Debian sup and the from-git sup and it worked no
better than one would expect.
My previously reported crashes didn't happen to fail in a way that
made /usr/lib show up in the stack trace, but both crashes are fixed
by just moving /usr/lib/ruby/1.8/sup out of the way.
So I'm glad to have things working now, but I'm still curious to know
why ruby goes digging into /usr/lib/ruby/1.8 to find sup/sent.rb when
there's a ./lib/sub/sent.rb present and I've passed a "-I ./lib"
option to ruby, (and plainly, ruby is interpreting other files from
./lib).
And I'd be glad if someone could recommend a ruby-esque way to debug a
situation like this. I mean, I could obviously have just run ruby
under strace and looked for the paths of various *.rb files getting
loaded, but surely there's some more ruby-specific way to list files
that are being used?
-Carl
PS. I'm intrigued by the following mention:
You?ve got the same sort of command-line debugger available.
[http://www.ruby-lang.org/en/documentation/ruby-from-other-languages/to-ruby-from-c-and-c-/]
so that's clearly something I'm going to have to learn to use.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090819/b7de0a71/attachment-0001.bin>
------------------------------
Message: 825
Date: Wed, 19 Aug 2009 13:02:26 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Exception trying to run git source
Message-ID: <1250712045-sup-3506@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Carl Worth's message of 2009-08-19:
> Thanks. That confirms that I'm not running the code I think I am,
Good, that explains a lot.
> So I'm glad to have things working now, but I'm still curious to know
> why ruby goes digging into /usr/lib/ruby/1.8 to find sup/sent.rb when
> there's a ./lib/sub/sent.rb present and I've passed a "-I ./lib"
> option to ruby, (and plainly, ruby is interpreting other files from
> ./lib).
I find it surprising too. I haven't seen taht behavior before. FWIW, Sup
does try and detect if bin/sup and lib/sup have mismatched versions, and
that didn't fire... I wonder if it's just sent.rb that's been loaded.
Did you somehow delete sent.rb from your git directory, or something
like that?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 826
Date: Wed, 19 Aug 2009 22:56:55 +0200
From: Beno?t PIERRE <benoit.pierre@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] [PATCH] fix garbaged text in textfield when using
ncursesw
Message-ID: <1250715278-sup-1941@localdomain>
Content-Type: text/plain; charset="utf-8"
Apparently, field_buffer content is not initialized to blanks when using
the wide-character version of ncurses. Forcing a call to
set_field_buffer fix the problem.
---
lib/sup/textfield.rb | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/sup/textfield.rb b/lib/sup/textfield.rb
index b8dec59..76803bf 100644
--- a/lib/sup/textfield.rb
+++ b/lib/sup/textfield.rb
@@ -35,9 +35,9 @@ class TextField
@completion_block = block
@field = Ncurses::Form.new_field 1, @width - question.length, @y, @x + question.length, 256, 0
@form = Ncurses::Form.new_form [@field]
- @value = default
+ @value = default || ''
Ncurses::Form.post_form @form
- set_cursed_value default if default
+ set_cursed_value @value
end
def position_cursor
--
1.6.3.3
--
A: Because it destroys the flow of conversation.
Q: Why is top posting dumb?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090819/95de5c6f/attachment-0001.bin>
------------------------------
Message: 827
Date: Wed, 19 Aug 2009 22:22:09 +0100
From: Adeodato Sim? <dato@net.com.org.es>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] [PATCH] mime-decode hook: provide a "charset"
variable with the attachment charset
Message-ID: <20090819212209.GA10883@chistera.yi.org>
Content-Type: text/plain; charset=utf-8
Ping?
+ Adeodato Sim? (Thu, 30 Jul 2009 17:56:56 +0200):
> + William Morgan (Mon, 27 Jul 2009 09:51:17 -0700):
> > Reformatted excerpts from Adeodato Sim?'s message of 2009-07-23:
> > > + Adeodato Sim? (Fri, 10 Jul 2009 17:00:29 +0200):
> > > > + :charset => encoded_content.charset,
> > > Hm, so apparently encoded_content doesn't always have a charset
> > > member...
> > In which case that value of that variable is nil, right? Is that a
> > problem? The patch still seems useful.
> Yes, I took a closer look and you're right the result of
> encoded_content.charset is nil in that case. I also saw (I think) where
> the traceback I was seeing is coming from: apparently it's not possible
> to pass to HookContext a local that is nil, since then "super" will get
> called in HookContext::method_missing() as far as I can see.
> So, perhaps, to fix this patch, one could do:
> :charset => encoded_content.charset || ''
> But then, I think it would be better to fix HookContext to allow for
> @__locals to contain nil. I'm not very familiar with that class, but it
> seems easy enough to fix, see upcoming patch (also found in
> ~dato/sup/sup-dato:fixes at Gitorious, if you prefer that). With it,
> this improvement to mime-decode seems to work without any further
> trouble.
> Cheers,
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
------------------------------
Message: 828
Date: Wed, 19 Aug 2009 14:37:15 -0700
From: Carl Worth <cworth@cworth.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Exception trying to run git source
Message-ID: <1250717434-sup-4489@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Wed Aug 19 13:02:26 -0700 2009:
> I find it surprising too. I haven't seen taht behavior before. FWIW, Sup
> does try and detect if bin/sup and lib/sup have mismatched versions, and
> that didn't fire... I wonder if it's just sent.rb that's been loaded.
> Did you somehow delete sent.rb from your git directory, or something
> like that?
Nope. The git checkout is entirely intact, and it was quite a large
number of modules getting misloaded.
I ran an strace on the ruby process[*] and was able to plainly see
that modules were being correctly loaded from ./lib until after
/usr/lib/ruby/1.8/chronic.rb was loaded. After that, ruby would look
for modules in /usr/lib/ruby/1.8 before ./lib. And sure enough, the
first line of my chronic.rb has:
$:.unshift File.dirname(__FILE__) # For use/testing when no gem is installed
I'll go ahead and find the right place to file that bug, but at least
the mystery is solved now.
-Carl
[*] http://cworth.org/~cworth/tmp/ruby-sup.strace
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090819/5e1ba854/attachment-0001.bin>
------------------------------
Message: 829
Date: Wed, 19 Aug 2009 14:41:54 -0600
From: Wirt Wolff <wirtwolff@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] In next: thread-view-mode labelling No method join
for Set
Message-ID: <1250714501-sup-3033@chigamba>
Content-Type: text/plain; charset=UTF-8
Lots of great improvements in next. Love the utf8.
When I try to 'l'abel in thread view mode, however, sup crashes with
--- NoMethodError from thread: main
undefined method `join' for #<Set: {:list, :xm}>
./lib/sup/buffer.rb:506:in `ask_for_labels'
./lib/sup/util.rb:520:in `send'
./lib/sup/util.rb:520:in `method_missing'
./lib/sup/modes/thread-view-mode.rb:253:in `edit_labels'
./lib/sup/mode.rb:50:in `send'
./lib/sup/mode.rb:50:in `handle_input'
./lib/sup/buffer.rb:260:in `handle_input'
----------------------------------------
Most recent commit is
Merge branch 'various-api-refactors' into next
commit 3de96fb9b308afe600c7ccfcee75913f039ef4f6
run with % ruby -Ilib bin/sup
----------------------------------------
Advice how to fix?
thanks,
--
wmw
------------------------------
Message: 830
Date: Wed, 19 Aug 2009 16:21:08 -0700
From: Carl Worth <cworth@cworth.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] What's your sup workflow (and a spew of ideas)
Message-ID: <1250723746-sup-4632@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
Excerpts from Rich Lane's message of Tue Aug 18 20:02:57 -0700 2009:
> Excerpts from Carl Worth's message of Tue Aug 18 21:58:55 -0400 2009:
> > Maybe a page on the wiki?
>
> Sure, I added an example to the end of the Hooks page.
Excellent. That looks very helpful.
And looking closer at the hooks wiki page, I see that it shows me how
to label incoming mail with ruby code, (which I've been wanting to
switch to instead of using maildrop to deliver mail to different
maildirs, and sup adding labels based on the source).
The hooks page also shows me how to display the number of unread
messages in a thread like I wanted, (though I'll still propose that
for sup itself rather than relying on a user hook for this).
So thanks for the encouragement to take a closer look at this page.
> I'm glad to know there are other people annoyed by UI race conditions :).
> Even after a quick look at the code I'm not sure what ThreadViewMode
> will do when a thread is added to. It might actually archive/read/etc
> new messages but not display them.
That was definitely my fear.
> I'd like a keybinding to reload/redisplay the thread and a status bar
> note if there are new messages. Any label changes should only affect
> messages that have been displayed. What do you think?
Only affecting messages that have been displayed is the critical
piece, yes. Adding a status bar notice would be a nice addition.
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090819/62013666/attachment-0001.bin>
------------------------------
Message: 831
Date: Wed, 19 Aug 2009 17:31:12 -0700
From: Carl Worth <cworth@cworth.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] In next: thread-view-mode labelling No method
join for Set
Message-ID: <1250727630-sup-3112@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
Excerpts from Wirt Wolff's message of Wed Aug 19 13:41:54 -0700 2009:
> Lots of great improvements in next. Love the utf8.
Agreed. These are very nice.
> When I try to 'l'abel in thread view mode, however, sup crashes with
>
> --- NoMethodError from thread: main
> undefined method `join' for #<Set: {:list, :xm}>
> ./lib/sup/buffer.rb:506:in `ask_for_labels'
I'm getting that too. It bisected down to the following which is not
so surprising:
commit 7aea418a8a62b7070eee764475fcfc0bdd8d58dd
Author: William Morgan <wmorgan-sup@masanjin.net>
Date: Tue Aug 11 16:00:52 2009 -0400
maintain labels as Sets rather than arrays
I've attached a patch that at least makes the crashes I was able ro
reproduce go away. But I have no idea if I got them all of course[*].
And please let me know if I'm doing anything wrong. I'm new to ruby as
well as sup here, so go easy on me, please! :-)
-Carl
[*] Totally off-topic: This is one of the things about "dynamically
typed" languages that I've never been able to wrap my brain around. I
really like that with static typing I can trust the compiler to help
me be very thorough if I make a type change like this, (and catch all
the cases before shipping any code). Instead, here, there's a hard
task of exercising every possible code path (at run time) before we
know if there are any type errors still lingering. I've seen some
proponents of dynamically-typed languages argue that unit testing
should provide the same coverage that a statically-typed compiler
would, but I haven't seen that in practice.
You all definitely have a lot more experience with ruby than I do, so
I'm honestly interested in learning form your experience. What do you
do to deal with cases like this?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Convert-a-couple-of-arrays-to-sets-for-labels.patch
Type: application/octet-stream
Size: 1685 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090819/c4120e6d/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090819/c4120e6d/attachment-0001.bin>
------------------------------
Message: 832
Date: Wed, 19 Aug 2009 22:57:25 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] In next: thread-view-mode labelling No method
join for Set
Message-ID: <1250734085-sup-2162@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Carl Worth's message of Wed Aug 19 20:31:12 -0400 2009:
> [*] Totally off-topic: This is one of the things about "dynamically
> typed" languages that I've never been able to wrap my brain around. I
> really like that with static typing I can trust the compiler to help
> me be very thorough if I make a type change like this, (and catch all
> the cases before shipping any code). Instead, here, there's a hard
> task of exercising every possible code path (at run time) before we
> know if there are any type errors still lingering. I've seen some
> proponents of dynamically-typed languages argue that unit testing
> should provide the same coverage that a statically-typed compiler
> would, but I haven't seen that in practice.
The term you'll see bandied about in ruby circles/books/etc is 'duck
typing' which coming from strongly typed languages is definitely
something that takes some getting used to. Basically, instead of
caring about the type of the object, you case about what the object
does. If it walks like a duck and quacks like a duck, treat it like a
duck.
A very simple example is a function that expects to append data to
another object. You could pass it a string (which uses << to append)
or an array (which uses << to push elements on the end). If you
originally passed a string, but found performance (memory ->
realloc()) issues, you could swap the string object for an array
object and do array.join when everything is collected into array
elements.
Then, you'll see many examples where there is code like:
raise SomeException, "blah" unless someobject.respond_to?(:somemethod)
Your code doesn't care _what kind_ of object it gets as long as it
knows _how_ to talk to it.
Personally, I really like this. Ruby isn't perfect by any stretch,
but of all the languages I've used, it's hands down the most fun to
write.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090819/a644ea46/attachment-0001.bin>
------------------------------
Message: 833
Date: Wed, 19 Aug 2009 21:03:08 -0700
From: Carl Worth <cworth@cworth.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] In next: thread-view-mode labelling No method
join for Set
Message-ID: <1250740488-sup-1624@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
Excerpts from Ben Walton's message of Wed Aug 19 19:57:25 -0700 2009:
> Excerpts from Carl Worth's message of Wed Aug 19 20:31:12 -0400 2009:
>
> > [*] Totally off-topic: This is one of the things about "dynamically
> > typed" languages that I've never been able to wrap my brain around. I
> > really like that with static typing I can trust the compiler to help
> > me be very thorough if I make a type change like this, (and catch all
> > the cases before shipping any code).
...
> The term you'll see bandied about in ruby circles/books/etc is 'duck
> typing' which coming from strongly typed languages is definitely
> something that takes some getting used to. Basically, instead of
> caring about the type of the object, you case about what the object
> does. If it walks like a duck and quacks like a duck, treat it like a
> duck.
Yes, I understand that just fine. But two points:
1. That's not actually helping in the current case where we're trying
to do simple things like '+' and the distinction between Set and
Array is causing problems. (See the patch where we're having to add
.to_a and Set.new to coerce things.) So, here, at least things are
falling down. So somehow something in ruby isn't living up to the
concept here.
> Then, you'll see many examples where there is code like:
>
> raise SomeException, "blah" unless someobject.respond_to?(:somemethod)
>
> Your code doesn't care _what kind_ of object it gets as long as it
> knows _how_ to talk to it.
2. Even with the "duck typing" I'd still like to express this
constraint in a way that is decidable statically. I've definitely
failed as a programmer if a user sees a runtime exception like
that. Sytems with sophisticated runtimes are very interesting to
me. It's just discouraging to me that so many such systems fail to
actually help me avoid problems like this before the user is
running my code.
> Personally, I really like this. Ruby isn't perfect by any stretch,
> but of all the languages I've used, it's hands down the most fun to
> write.
That could still be the case for me here. I haven't tried much with it
yet, so I don't have any strong opinion there yet. :-)
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090819/aae17dcd/attachment-0001.bin>
------------------------------
Message: 834
Date: Wed, 19 Aug 2009 22:25:39 -0700
From: Carl Worth <cworth@cworth.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] [PATCH] Make SUP_LOG_LEVEL self-documenting.
Message-ID: <1250745799-sup-6607@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
The idea here is that if someone is looking at the log and not seeing
the information of interest, then the log itself should tell them
how to get more information, (by suggesting to set SUP_LOG_LEVEL
to the next lower level).
---
I'm probably still off as far as standard ruby idioms, (and I'm
probably committing some sup layer violations as well). But hopefully
you get the idea. I went to the log looking for details, couldn't find
them, and had to resort to searching the mailing list for the exact
name of the SUP_LOG_LEVEL variable.
bin/sup | 3 +++
lib/sup/logger.rb | 2 ++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/bin/sup b/bin/sup
index 3d5b6c1..afe2233 100755
--- a/bin/sup
+++ b/bin/sup
@@ -169,6 +169,9 @@ begin
lmode.on_kill { Logger.clear! }
Logger.add_sink lmode
Logger.force_message "Welcome to Sup! Log level is set to #{Logger.level}."
+ if Logger.LEVELS.index(Logger.level) > 0
+ Logger.force_message "For more verbose logging, restart with SUP_LOG_LEVEL=#{Logger.LEVELS[Logger.LEVELS.index(Logger.level)-1]}."
+ end
debug "initializing inbox buffer"
imode = InboxMode.new
diff --git a/lib/sup/logger.rb b/lib/sup/logger.rb
index ccaeae0..8567174 100644
--- a/lib/sup/logger.rb
+++ b/lib/sup/logger.rb
@@ -12,6 +12,8 @@ class Logger
LEVELS = %w(debug info warn error) # in order!
+ def LEVELS; LEVELS end
+
def initialize level=nil
level ||= ENV["SUP_LOG_LEVEL"] || "info"
@level = LEVELS.index(level) or raise ArgumentError, "invalid log level #{level.inspect}: should be one of #{LEVELS * ', '}"
--
1.6.3.3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090819/8eb1635a/attachment-0001.bin>
------------------------------
Message: 835
Date: Wed, 19 Aug 2009 23:31:25 -0700
From: Carl Worth <cworth@cworth.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] [PATCH] Be less overzealous in moving text to the
left column
Message-ID: <1250749447-sup-1744@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
Specifically, scroll as little as possible to get the current message
to just fit on the right side.
---
This seems to work quite nicely and I think is ready to be comitted as
is. It's still not perfect in a few ways though, which I think we can
leave for subsequent commits:
1. I *think* that with this change the loose_alignment mode is
unnecessary. But I confess that I didn't totally understand the
calculation it is making, so I tried to just preserve its behavior
rather than ripping it out.
2. In deep threads of short messages, (so that lots of nesting is
visible in one screenful), it's easier than it was before for
messages other than the current message to be scrolled off to the
right, (though the current message is always made to fit if
possible). I can imagine someone finding the current patch
unacceptable based on this.
The fix for this would be to consider the total width of all
visible messages when making the calculation made here, rather than
just the width of the current message. I'm not sure how readily
available that number is.
3. It's still easy to get stuff scrolled off to the left, (which was a
symptom of the original bug I'm trying to fix), when doing
something like (E: Expand all messages). This command should
recompute a left column, so perhaps we should abstract the
left-column calculation out to some shared place.
Anyway, all feedback is quite welcome,
-Carl (happy to finally be running code from git and contributing patches)
lib/sup/modes/thread-view-mode.rb | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb
index dfe30ff..678b841 100644
--- a/lib/sup/modes/thread-view-mode.rb
+++ b/lib/sup/modes/thread-view-mode.rb
@@ -423,6 +423,9 @@ EOS
0
end
+ ## scroll as little as possible to make the message fit
+ ideal_left = (-(buffer.content_width - l.width - left - 1)).clamp(0, ideal_left)
+
jump_to_col [ideal_left, 0].max
## either way, move the cursor to the first line
--
1.6.3.3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090819/16ea9c2d/attachment-0001.bin>
------------------------------
Message: 836
Date: Thu, 20 Aug 2009 10:07:16 -0700
From: Carl Worth <cworth@cworth.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] On making kill-thread easier
Message-ID: <1250785604-sup-5488@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
I wrote a long post that started out talking about workflows, but then
went on into just a dump of feature requests. I'd like to get back to
talking about workflows again a bit.
I find that when processing my mail in inbox-mode I do a first pass
with one of two different actions on each thread:
1. 'a' to archive the thread without reading
or:
2. <down-arrow> to leave the thread in my inbox for reading on
a later pass.
But this misses out on the killer-feature that was one of the things
that made me most interested in sup: kill-thread.
So I can currently decide to kill a thread instead of archiving it,
but this requires extra effort on my part, (deciding that I need to do
something more than just archiving it, and then using a different
key---currently with a keybinding that requires two keys).
What I find is that I end up using kill-thread much less frequently
than I should. Basically what ends up happening is that when a thread
comes up several times (and I keep just archiving it) before I finally
make the mental effort to kill it instead of just archiving it. And I
keep trying to train myself to not be afraid to use kill-thread more
frequently.
But then thought occurs to me, "Shouldn't sup just see that I'm not
ever reading this thread when it reappears?".
So I think what I actually want is a single keybinding that either
archives or kills a thread based on whether I've actually read any of
it or not. Does anybody else agree that that would be useful? Perhaps
even as the default?
I think a first pass that only does kill-thread if the entire thread
is unread will likely be enough. I can imagine a more clever version
that kills a thread even if it's partially read but no new messages
have been read since the last time this thread was labelled as
inbox. But that's perhaps more complexity than appropriate[*] and an
explicit kill-thread command will work just fine here.
-Carl
[*] By the way, my concern with complexity has nothing to do with the
state management in the code---that shouldn't be bad. It's more a
matter of making the user-interface easy to explain and understand. If
a tool violates that, then it can lose a user's trust, (which can be
quite fatal for a mail client).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090820/aefd9813/attachment-0001.bin>
------------------------------
Message: 837
Date: Thu, 20 Aug 2009 14:19:19 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] On making kill-thread easier
Message-ID: <1250792255-sup-4740@Longbow>
Content-Type: text/plain; charset=utf8
Excerpts from Carl Worth's message of Thu Aug 20 13:07:16 -0400 2009:
> I wrote a long post that started out talking about workflows, but then
> went on into just a dump of feature requests. I'd like to get back to
> talking about workflows again a bit.
>
> I find that when processing my mail in inbox-mode I do a first pass
> with one of two different actions on each thread:
>
> 1. 'a' to archive the thread without reading
> or:
> 2. <down-arrow> to leave the thread in my inbox for reading on
> a later pass.
>
> But this misses out on the killer-feature that was one of the things
> that made me most interested in sup: kill-thread.
>
> So I can currently decide to kill a thread instead of archiving it,
> but this requires extra effort on my part, (deciding that I need to do
> something more than just archiving it, and then using a different
> key---currently with a keybinding that requires two keys).
>
> What I find is that I end up using kill-thread much less frequently
> than I should. Basically what ends up happening is that when a thread
> comes up several times (and I keep just archiving it) before I finally
> make the mental effort to kill it instead of just archiving it. And I
> keep trying to train myself to not be afraid to use kill-thread more
> frequently.
>
> But then thought occurs to me, "Shouldn't sup just see that I'm not
> ever reading this thread when it reappears?".
>
> So I think what I actually want is a single keybinding that either
> archives or kills a thread based on whether I've actually read any of
> it or not. Does anybody else agree that that would be useful? Perhaps
> even as the default?
>
> I think a first pass that only does kill-thread if the entire thread
> is unread will likely be enough. I can imagine a more clever version
> that kills a thread even if it's partially read but no new messages
> have been read since the last time this thread was labelled as
> inbox. But that's perhaps more complexity than appropriate[*] and an
> explicit kill-thread command will work just fine here.
>
> -Carl
>
> [*] By the way, my concern with complexity has nothing to do with the
> state management in the code---that shouldn't be bad. It's more a
> matter of making the user-interface easy to explain and understand. If
> a tool violates that, then it can lose a user's trust, (which can be
> quite fatal for a mail client).
Seems like making it the default is a bit cavalier. It's not good to
assume what the user wants, I think. Maybe a separate key if we want to
spare it, but I think the better solution is "learn to kill threads
already and use an explicit command for it."
--
Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
------------------------------
Message: 838
Date: Thu, 20 Aug 2009 21:01:10 +0100
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Carl Worth <cworth@cworth.org>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] On making kill-thread easier
Message-ID: <1250797598-sup-5105@tiger.alporthouse.com>
Content-Type: text/plain; charset=UTF-8
Hi everybody! I've just started using sup after Carl told me he'd found
a fantastic new mail client. And, as usual, he was right.
Excerpts from Carl Worth's message of Thu Aug 20 18:07:16 +0100 2009:
> But then thought occurs to me, "Shouldn't sup just see that I'm not
> ever reading this thread when it reappears?".
I have a very similar inbox pattern to Carl, a quick pass to remove
uninteresting material before acting upon the rest. To this end, I use
'&' far less frequently than I should, because it's an awkward key
combination to use in conjunction with scrolling + archiving, and so I
am irritated by repeatedly archiving a thread which I have never read.
The behaviour I would like here is exactly: "Shouldn't sup just see that
I'm not ever reading this thread when it reappears?".
I'd be happy to have sup automatically kill a thread that I have
archived twice without reading.
-ickle
------------------------------
Message: 839
Date: Thu, 20 Aug 2009 16:36:15 -0400
From: Andrei Thorp <garoth@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] On making kill-thread easier
Message-ID: <1250800492-sup-136@Longbow>
Content-Type: text/plain; charset=utf8
Excerpts from Chris Wilson's message of Thu Aug 20 16:01:10 -0400 2009:
> Hi everybody! I've just started using sup after Carl told me he'd found
> a fantastic new mail client. And, as usual, he was right.
If you're half as verbose as he is, I'll never have time to read it all!
;)
--
Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
------------------------------
Message: 840
Date: Thu, 20 Aug 2009 16:43:08 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] On making kill-thread easier
Message-ID: <1250800965-sup-4218@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Chris Wilson's message of Thu Aug 20 16:01:10 -0400 2009:
> I have a very similar inbox pattern to Carl, a quick pass to remove
> uninteresting material before acting upon the rest. To this end, I use
> '&' far less frequently than I should, because it's an awkward key
> combination to use in conjunction with scrolling + archiving, and so I
> am irritated by repeatedly archiving a thread which I have never read.
> The behaviour I would like here is exactly: "Shouldn't sup just see that
> I'm not ever reading this thread when it reappears?".
I have a similar pattern where there are lots of list messages that I
don't care about (based on subject). I skim the inbox using 't' to
tag all messages I don't care about. When I've tagged a bunch of
items, after the scan, I simply to '=' followed by either 'A'
(archive, mark read) or '&'. It saves lots of shift key use and
allows me to quickly tackle a lot of mail.
> I'd be happy to have sup automatically kill a thread that I have
> archived twice without reading.
I think this kind of heuristic is a) hard to get right b) not required
if you do batch operations as described above. Part b) is subject to
personal opinion, of course! :)
HTH.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090820/1dbd06f5/attachment-0001.bin>
------------------------------
Message: 841
Date: Thu, 20 Aug 2009 14:07:28 -0700
From: Carl Worth <cworth@cworth.org>
To: Andrei Thorp <garoth@gmail.com>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] On making kill-thread easier
Message-ID: <1250802401-sup-2516@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
Excerpts from Andrei Thorp's message of Thu Aug 20 13:36:15 -0700 2009:
> Excerpts from Chris Wilson's message of Thu Aug 20 16:01:10 -0400 2009:
> > Hi everybody! I've just started using sup after Carl told me he'd found
> > a fantastic new mail client. And, as usual, he was right.
>
> If you're half as verbose as he is, I'll never have time to read it all!
> ;)
Yeah, sorry about that. I will try to be terse when I can. :-)
Welcome, Chris!
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090820/481671be/attachment-0001.bin>
------------------------------
Message: 842
Date: Thu, 20 Aug 2009 14:11:49 -0700
From: Carl Worth <cworth@cworth.org>
To: Ben Walton <bwalton@artsci.utoronto.ca>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] On making kill-thread easier
Message-ID: <1250802452-sup-4348@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
Excerpts from Ben Walton's message of Thu Aug 20 13:43:08 -0700 2009:
> Excerpts from Chris Wilson's message of Thu Aug 20 16:01:10 -0400 2009:
> I have a similar pattern where there are lots of list messages that I
> don't care about (based on subject). I skim the inbox using 't' to
> tag all messages I don't care about. When I've tagged a bunch of
> items, after the scan, I simply to '=' followed by either 'A'
> (archive, mark read) or '&'. It saves lots of shift key use and
> allows me to quickly tackle a lot of mail.
Thanks, Ben!
This is just the kind of workflow report I've been hoping to read.
I wonder, though, what happens when you want to archive some and kill
others. Do you end up making two passes? Executing the '=' operation
partway through and then start tagging again? A quick, non-tag 'A' or
'&' for the exceptional thread? Or maybe just let a few slip by the
"wrong" direction.
> > I'd be happy to have sup automatically kill a thread that I have
> > archived twice without reading.
>
> I think this kind of heuristic is a) hard to get right b) not required
> if you do batch operations as described above. Part b) is subject to
> personal opinion, of course! :)
I plan to try a single keybinding for archive-or-kill-if-unread for a
while and see how I like it, (I'll obviously share it when I code it
up).. Of course, the failure mode is hiding messages from me, so it
might be hard for me to know if it fails. :-)
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090820/cec04ef5/attachment-0001.bin>
------------------------------
Message: 843
Date: Thu, 20 Aug 2009 18:56:52 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] On making kill-thread easier
Message-ID: <1250808931-sup-3198@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Carl Worth's message of Thu Aug 20 17:11:49 -0400 2009:
> I wonder, though, what happens when you want to archive some and kill
> others. Do you end up making two passes? Executing the '=' operation
> partway through and then start tagging again? A quick, non-tag 'A' or
> '&' for the exceptional thread? Or maybe just let a few slip by the
> "wrong" direction.
I typically do a big pass to 'A' or '&' large numbers of things. That
knocks the list to a point where I can either do another smaller pass
where I'll apply labels and skim things. My last pass is for things I
actually read, many of which get archived right away too. I don't
completely practice 'inbox 0' but I do follow many of its tenets.
My own personal habits are such that an archived thread has to really
bug me before I kill it, so much of the first (morning) pass is for
'A.' Part of this is because while I don't want to necessarily follow
a thread, there is potential for interesting things to pop in late in
the game (many of these are on the git ml)...so, after I see a lot of
activity on it, I may scan the thread or possibly read it.
Bike shedding gets killed quickly! :)
> I plan to try a single keybinding for archive-or-kill-if-unread for a
> while and see how I like it, (I'll obviously share it when I code it
> up).. Of course, the failure mode is hiding messages from me, so it
> might be hard for me to know if it fails. :-)
If you get into adding code, consider writing it such that there is an
available Hook that overrides the default behaviour. This may get you
the best of all outcomes. It'd be useful for you and more likely to
be useful for others.
HTH.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090820/0226132d/attachment-0001.bin>
------------------------------
Message: 844
Date: Thu, 20 Aug 2009 17:09:30 -0700
From: Carl Worth <cworth@cworth.org>
To: Ben Walton <bwalton@artsci.utoronto.ca>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] On making kill-thread easier
Message-ID: <1250812689-sup-2614@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
Excerpts from Ben Walton's message of Thu Aug 20 15:56:52 -0700 2009:
> My own personal habits are such that an archived thread has to really
> bug me before I kill it, so much of the first (morning) pass is for
> 'A.' Part of this is because while I don't want to necessarily follow
> a thread, there is potential for interesting things to pop in late in
> the game (many of these are on the git ml)...so, after I see a lot of
> activity on it, I may scan the thread or possibly read it.
Thanks. Those are good points. I've definitely seen some interesting
stuff on the git mailing list where threads start off looking
worthless, but then Linus comes in with some gem of insight and things
take off again.
See Joey's post on thread patterns for some examples here:
http://joey.kitenet.net/blog/entry/thread_patterns/
> Bike shedding gets killed quickly! :)
Yes! Bike shedding without kill-thread available is a lot more painful.
I guess part of what I'm getting at with the idea of merging "archive"
and "kill-thread" is that I think the distinction between these two
commands forces the user to get a little too chummy with details of
the mail store.
I wrote a long post about sup and mail in general here:
http://cworth.org/sup/a-mail-client-for-geeks/ [*]
and one of the ideas I start talking about there is that I'd like my
mail client to present me with "Here's what you should find most
interesting right now", and I can implicitly give the system feedback
by either reading it or not. So "archive" vs. "kill" feels like manual
tuning of what would ideally be an automated process.
Of course, getting that process automated and working well is likely
an open research topic. I'd love for the system to take tags into
account, authors of messages, my history of reading (or not) posts by
given authors, etc. Obviously, sup's not going to acquire that kind of
functionality instantly, but it likely makes a good basis already for
someone who wants to explore that kind of thing.
So, ideas of mine like "sort certain tags before sorting by date", and
"merge archive and thread into a single key" I think are both just
baby steps toward the Big Idea I'd love to see someone tackle. Anyone
looking for a good M.S. thesis around here? (So much research has been
dedicated to spam, but has there been as much to sorting out the ham?
I should ask my C.S-professor-friend---he'd be up on the current state
of the literature here.)
-Carl
[*] See, I'm keeping some of my verbosity off the list at least. ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090820/3ed0cc42/attachment-0001.bin>
------------------------------
Message: 845
Date: Thu, 20 Aug 2009 20:16:23 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] In next: thread-view-mode labelling No method
join for Set
Message-ID: <1250813245-sup-6519@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Carl Worth's message of Thu Aug 20 00:03:08 -0400 2009:
> 1. That's not actually helping in the current case where we're trying
> to do simple things like '+' and the distinction between Set and
> Array is causing problems. (See the patch where we're having to add
> .to_a and Set.new to coerce things.) So, here, at least things are
> falling down. So somehow something in ruby isn't living up to the
> concept here.
You're correct. The difference between fixing this in Ruby vs fixing
this in a strongly typed language though is that you could implement
Set#join such that the code expecting an array wouldn't know the
difference _or_ you could have that code use kind_of?(Array) to ensure
it was getting the type of argument it was expecting. Both are
technically correct.
In a strongly typed language, you'd have to modify the acceptable
arguments (function definition) and ensure everything that called the
function passed something acceptable or provide an overloaded version
(if you're working with a language that supports it).
Those are correct solutions too.
> > Your code doesn't care _what kind_ of object it gets as long as it
> > knows _how_ to talk to it.
>
> 2. Even with the "duck typing" I'd still like to express this
> constraint in a way that is decidable statically. I've definitely
> failed as a programmer if a user sees a runtime exception like
> that. Sytems with sophisticated runtimes are very interesting to
> me. It's just discouraging to me that so many such systems fail to
> actually help me avoid problems like this before the user is
> running my code.
Bugs are bugs! :) Static typing only goes so far to prevent some of
this stuff...just look what you can make a C compiler do with funky
casts. I take your point though.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090820/575e53e4/attachment-0001.bin>
------------------------------
Message: 846
Date: Thu, 20 Aug 2009 18:36:28 -0700
From: Carl Worth <cworth@cworth.org>
To: Ben Walton <bwalton@artsci.utoronto.ca>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] On making kill-thread easier
Message-ID: <1250817987-sup-7256@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
Excerpts from Ben Walton's message of Thu Aug 20 13:43:08 -0700 2009:
> Excerpts from Chris Wilson's message of Thu Aug 20 16:01:10 -0400 2009:
>
> > I'd be happy to have sup automatically kill a thread that I have
> > archived twice without reading.
>
> I think this kind of heuristic is a) hard to get right b) not required
> if you do batch operations as described above. Part b) is subject to
> personal opinion, of course! :)
[Here's one last thought from me in this thread before I come back
next time with actual code and maybe some experience in using it.]
Since, by nature of being a heuristic, this kind of thing can't be
perfect, and since the cost of a false positive is high, (an important
message being killed and never seen), here's another idea:
First, leave killing to the user as an explicit action.
Second, use the heuristics not for killing messages, but merely for
prioritizing them in the inbox. But since the inbox might often be
small, it's not adequate to move the "uninteresting" messages to the
bottom. Instead threads that the heuristic identifies as "likely
uninteresting" could have a delay attached to them before they are
presented again in the inbox, (not too unlike throttling proposed for
mailing-list servers to keep flamewars in check).
This way instead of pestering the user with the bikeshedding until the
user finally kills the thread in frustration, the bikeshedding could
get delayed until the next morning's sweep where a day's worth of
bikeshedding would be easy to identify and easy to kill.
So maybe something like "Once I archive a thread twice without
reading, don't show it to me again until tomorrow" or so. That might
be interesting to try out.
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090820/aefb8350/attachment-0001.bin>
------------------------------
Message: 847
Date: Thu, 20 Aug 2009 21:57:42 -0400
From: Kevin Riggle <kevinr@free-dissociation.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH] Add an after-add-message hook
Message-ID:
<1250819862-4858-1-git-send-email-kevinr@free-dissociation.com>
This time the loop stores messages in an array as they're added to the
index, and passes that array to the hook.
I want to do some unrelated processing on each message I receive, but I
don't want to block the message being added to the index. This patch
adds a hook which runs /after/ the message is added to the index.
---
lib/sup/poll.rb | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/lib/sup/poll.rb b/lib/sup/poll.rb
index 8a9d218..fb3aacf 100644
--- a/lib/sup/poll.rb
+++ b/lib/sup/poll.rb
@@ -11,6 +11,12 @@ Variables:
message: the new message
EOS
+ HookManager.register "after-add-message", <<EOS
+Executes after all messages are added to the index.
+Variables:
+ messages: an array of the new messages added
+EOS
+
HookManager.register "before-poll", <<EOS
Executes immediately before a poll for new messages commences.
No variables.
@@ -138,6 +144,7 @@ EOS
begin
return if source.done? || source.has_errors?
+ messages = []
source.each do |offset, default_labels|
if source.has_errors?
Redwood::log "error loading messages from #{source}: #{source.error.message}"
@@ -145,6 +152,7 @@ EOS
end
m_new = Message.build_from_source source, offset
+ messages.push(m_new)
m_old = Index.build_message m_new.id
m_new.labels += default_labels + (source.archived? ? [] : [:inbox])
@@ -157,6 +165,8 @@ EOS
Index.sync_message m_ret, opts
UpdateManager.relay self, :added, m_ret unless m_old
end
+ HookManager.run "after-add-message", :messages => messages
+
rescue SourceError => e
Redwood::log "problem getting messages from #{source}: #{e.message}"
Redwood::report_broken_sources :force_to_top => true
--
1.6.0.4
------------------------------
Message: 848
Date: Thu, 20 Aug 2009 22:07:17 -0400
From: Kevin Riggle <kevinr@free-dissociation.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Add an after-add-message hook
Message-ID: <1250820245-sup-2250@black-opal.mit.edu>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Wed Aug 19 14:55:03 -0400 2009:
> Reformatted excerpts from Kevin Riggle's message of 2009-08-18:
> > I don't /think/ so, unless I misunderstand the way hooks work. I
> > assumed the hook would execute and then execution of the loop would
> > resume, and I don't think I throw anything in the hook which should
> > cause that either.
>
> What I'm saying is that this hook will execute *after* each message is
> added to the index, so if Sup found several new messages, all except the
> first one will wait on this hook to execute before being added to the
> index. Or do you mean block in some sense besides "wait for completion"?
Oh, duh. I take your point -- I've sent a new patch.
- Kevin
--
Kevin Riggle (kevinr@free-dissociation.com)
http://free-dissociation.com
------------------------------
Message: 849
Date: Thu, 20 Aug 2009 19:09:15 -0700
From: Carl Worth <cworth@cworth.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] 'next' crash: wrong id called on nil
(thread.rb:264:in `thread_for')
Message-ID: <1250820431-sup-8159@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
I'm running sup next, (3de96fb9b308afe600c7ccfcee75913f039ef4f6 + 3
patches that I've posted to this list, but which I hope are not
relevant here), and I got the following crash.
My best recollection is that I had just sent a reply, and then hit
".a".
Anything here look like an obvious fix for someone?
-Carl
--- RuntimeError from thread: main
wrong id called on nil
./lib/sup.rb:17:in `id'
./lib/sup/thread.rb:264:in `thread_for'
./lib/sup/modes/thread-index-mode.rb:702:in `thread_containing'
./lib/sup/modes/thread-index-mode.rb:702:in `synchronize'
./lib/sup/modes/thread-index-mode.rb:702:in `thread_containing'
./lib/sup/modes/thread-index-mode.rb:173:in `handle_simple_update'
./lib/sup/modes/thread-index-mode.rb:180:in `handle_archived_update'
./lib/sup/update.rb:26:in `send'
./lib/sup/update.rb:26:in `relay'
./lib/sup/update.rb:26:in `each'
./lib/sup/update.rb:26:in `relay'
./lib/sup/util.rb:520:in `send'
./lib/sup/util.rb:520:in `method_missing'
./lib/sup/modes/thread-view-mode.rb:481:in `archive_and_then'
./lib/sup/modes/thread-view-mode.rb:515:in `dispatch'
./lib/sup/modes/thread-view-mode.rb:525:in `call'
./lib/sup/modes/thread-view-mode.rb:525:in `dispatch'
./lib/sup/modes/thread-view-mode.rb:479:in `archive_and_then'
./lib/sup/modes/thread-view-mode.rb:461:in `archive_and_kill'
./lib/sup/mode.rb:50:in `send'
./lib/sup/mode.rb:50:in `handle_input'
./lib/sup/buffer.rb:260:in `handle_input'
./bin/sup:237
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090820/c9929115/attachment-0001.bin>
------------------------------
Message: 850
Date: Fri, 21 Aug 2009 16:16:26 +0100
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Ben Walton <bwalton@artsci.utoronto.ca>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] On making kill-thread easier
Message-ID: <1250867140-sup-2558@tiger.alporthouse.com>
Content-Type: text/plain; charset=UTF-8
Excerpts from Ben Walton's message of Thu Aug 20 21:43:08 +0100 2009:
> I skim the inbox using 't' to
> tag all messages I don't care about. When I've tagged a bunch of
> items, after the scan, I simply to '=' followed by either 'A'
> (archive, mark read) or '&'.
This works very nicely, thanks. Though I miss the subtly of why you
use 'A' rather than 'a'. Could you explain the difference this makes?
-ickle
------------------------------
Message: 851
Date: Fri, 21 Aug 2009 11:19:35 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] On making kill-thread easier
Message-ID: <1250867926-sup-4258@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from Chris Wilson's message of Fri Aug 21 11:16:26 -0400 2009:
> This works very nicely, thanks. Though I miss the subtly of why you
> use 'A' rather than 'a'. Could you explain the difference this makes?
> -ickle
A -> mark as read and archive
a -> just archive
This means you can have unread messages that are archived. I use this
to great effect with my mailing list messages (which I have filters
to archive but not to mark read).
Cheers,
Edward
------------------------------
Message: 852
Date: Fri, 21 Aug 2009 11:20:23 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] On making kill-thread easier
Message-ID: <1250867933-sup-5786@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Chris Wilson's message of Fri Aug 21 11:16:26 -0400 2009:
> This works very nicely, thanks. Though I miss the subtly of why you
> use 'A' rather than 'a'. Could you explain the difference this makes?
'A' marks the mail as read in addition to archiving it. This makes
'U' (unread view) mode better for my use.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090821/9b947b49/attachment-0001.bin>
------------------------------
Message: 853
Date: Fri, 21 Aug 2009 18:00:29 +0200
From: Guillaume Quintard <guillaume.quintard@gmail.com>
To: "Sup-talk@rubyforge.org" <sup-talk@rubyforge.org>
Subject: [sup-talk] Crashing ssh + sup, bad combo
Message-ID:
<1e5fdab70908210900y5b51722agf33487b3d4dafcf4@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Sooooo, here's what happened: I was running sup through ssh, minding
my own business, when suddenly, my local machine crashed. I reboot,
reconnect, sup is somehow still running, I kill it (with a good ol'
kill, because the lock file was empty so sup could ask for a seppuku),
and no I have this:
[Fri Aug 21 17:54:54 +0200 2009] ERROR: oh crap, an exception
----------------------------------------------------------------
I'm very sorry. It seems that an error occurred in Sup. Please
accept my sincere apologies. If you don't mind, please send the
contents of ~/.sup/exception-log.txt and a brief report of the
circumstances to sup-talk at rubyforge dot orgs so that I might
address this problem. Thank you!
Sincerely,
William
----------------------------------------------------------------
--- RuntimeError from thread: load threads for thread-index-mode
wrong id called on nil
./lib/sup.rb:17:in `id'
./lib/sup/xapian_index.rb:155:in `each_message_in_thread_for'
/usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
./lib/sup/xapian_index.rb:336:in `synchronize'
./lib/sup/xapian_index.rb:155:in `each_message_in_thread_for'
./lib/sup/thread.rb:341:in `load_thread_for_message'
./lib/sup/thread.rb:333:in `load_n_threads'
./lib/sup/xapian_index.rb:149:in `each_id_by_date'
./lib/sup/xapian_index.rb:142:in `each_id'
./lib/sup/xapian_index.rb:142:in `each'
./lib/sup/xapian_index.rb:142:in `each_id'
./lib/sup/xapian_index.rb:149:in `each_id_by_date'
./lib/sup/thread.rb:328:in `load_n_threads'
./lib/sup/modes/thread-index-mode.rb:623:in `__unprotected_load_n_threads'
(eval):12:in `load_n_threads'
./lib/sup/modes/thread-index-mode.rb:607:in `load_n_threads_background'
./lib/sup.rb:77:in `reporting_thread'
./lib/sup.rb:75:in `initialize'
./lib/sup.rb:75:in `new'
./lib/sup.rb:75:in `reporting_thread'
./lib/sup/modes/thread-index-mode.rb:606:in `load_n_threads_background'
./lib/sup/modes/thread-index-mode.rb:676:in `__unprotected_load_threads'
(eval):12:in `load_threads'
bin/sup:192
me no likey :-(
--
Guillaume
------------------------------
Message: 854
Date: Fri, 21 Aug 2009 14:57:10 -0400
From: Mark Alexander <marka@pobox.com>
To: Guillaume Quintard <guillaume.quintard@gmail.com>
Cc: "Sup-talk@rubyforge.org" <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crashing ssh + sup, bad combo
Message-ID:
<a412e2a70908211157vcd73cc6r4b401fd38f50902@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
This isn't directly related, and you may already know about this, and
apologies if that's the case... but I highly recommend running screen
on the machine where you're running sup. That way you don't lose any
work when your ssh connection drops for any reason.
------------------------------
Message: 855
Date: Fri, 21 Aug 2009 21:29:22 +0200
From: Guillaume Quintard <guillaume.quintard@gmail.com>
To: Mark Alexander <marka@pobox.com>
Cc: "Sup-talk@rubyforge.org" <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crashing ssh + sup, bad combo
Message-ID:
<1e5fdab70908211229w2f11d11h4db7500a340b923b@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Fri, Aug 21, 2009 at 8:57 PM, Mark Alexander<marka@pobox.com> wrote:
> This isn't directly related, and you may already know about this, and
> apologies if that's the case... but I highly recommend running screen
> on the machine where you're running sup. ?That way you don't lose any
> work when your ssh connection drops for any reason.
>
Yup, I know, but screen isn't yet natural to me, and I tend to forgot
to use it :-)
--
Guillaume
------------------------------
Message: 856
Date: Fri, 21 Aug 2009 16:57:55 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crashing ssh + sup, bad combo
Message-ID: <1250887753-sup-7844@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from Guillaume Quintard's message of Fri Aug 21 12:00:29 -0400 2009:
> Sooooo, here's what happened: I was running sup through ssh, minding
> my own business, when suddenly, my local machine crashed. I reboot,
> reconnect, sup is somehow still running, I kill it (with a good ol'
> kill, because the lock file was empty so sup could ask for a seppuku),
> and no I have this:
I'm guessing this is an inconsistency between your xapian and entries.db
databases. A sup-sync -a might fix it.
I posted a patch a few days ago that moves all index data into Xapian to
prevent this sort of issue. William, could you take a look at / merge that
patch?
------------------------------
Message: 857
Date: Sat, 22 Aug 2009 11:45:18 +0200
From: Contzen Laurent <lcontzen@gmail.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] Sup crashed at launch
Message-ID:
<49454bf60908220245w52764765rdbd111dfd446896f@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hello,
I've heard about sup and it sounded great so I decided to give it a
try following http://www.brainyautomation.com/blog/post/Reading-Gmail-with-Sup.aspx
.
I installed everything, configured ssmtp and got it working, etc. I
then launched sup for a first time to let it create my ~/.sup and exit
whithout any troubles. I then configured my .sup/sources.yaml as shown
in the webpage mentionned above and then launched sup. It crashed with
that output :
[Sat Aug 22 11:41:56 +0200 2009] using character set encoding "utf8"
[Sat Aug 22 11:41:56 +0200 2009] dynamically loading setlocale() from libc.so.6
[Sat Aug 22 11:41:56 +0200 2009] setting locale...
[Sat Aug 22 11:41:56 +0200 2009] locking /home/laurent/.sup/lock...
[Sat Aug 22 11:41:56 +0200 2009] crypto: detected gpg binary in /usr/bin/gpg
[Sat Aug 22 11:41:56 +0200 2009] stopped cursing
[Sat Aug 22 11:41:56 +0200 2009] oh crap, an exception
[Sat Aug 22 11:41:56 +0200 2009] unlocking /home/laurent/.sup/lock...
----------------------------------------------------------------
I'm very sorry. It seems that an error occurred in Sup. Please
accept my sincere apologies. If you don't mind, please send the
contents of ~/.sup/exception-log.txt and a brief report of the
circumstances to sup-talk at rubyforge dot orgs so that I might
address this problem. Thank you!
Sincerely,
William
----------------------------------------------------------------
--- ArgumentError from thread: main
username and password must be specified
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/imap.rb:60:in `initialize'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:30:in `new'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:30:in `yaml_properties'
/usr/lib/ruby/1.8/yaml.rb:133:in `call'
/usr/lib/ruby/1.8/yaml.rb:133:in `transfer'
/usr/lib/ruby/1.8/yaml.rb:133:in `node_import'
/usr/lib/ruby/1.8/yaml.rb:133:in `load'
/usr/lib/ruby/1.8/yaml.rb:133:in `load'
/usr/lib/ruby/1.8/yaml.rb:144:in `load_file'
/usr/lib/ruby/1.8/yaml.rb:143:in `open'
/usr/lib/ruby/1.8/yaml.rb:143:in `load_file'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:98:in `load_yaml_obj'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/index.rb:473:in `load_sources'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/index.rb:121:in `load'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/util.rb:513:in `send'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/util.rb:513:in `method_missing'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/bin/sup:162
/usr/bin/sup:19:in `load'
/usr/bin/sup:19
The ouput asked to send this mail so I decided to try to help you by doing it.
Don't hesitate to ask for details, ...
Laurent
------------------------------
Message: 858
Date: Sat, 22 Aug 2009 01:04:15 +0200
From: Ulrik Sverdrup <ulrik.sverdrup@gmail.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] Bug: Log printing with encoding problems
Message-ID:
<a1b6cb1b0908211604p4c0e94bk87134933f45e6f73@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
My locale is sv_SE.UTF-8, log is truncated since the date string is
longer than expected.
The date should print "l?r" (from L?rdag = Saturday)
Sat Aug 22 00:55:52 +0200 2009: using character set encoding "UTF-8"
Sat Aug 22 00:55:52 +0200 2009: dynamically loading setlocale() from libc.so.6
Sat Aug 22 00:55:52 +0200 2009: setting locale...
lM-CM-6r aug 22 00:55:52 +0200 2009: locking /home/ulrik/.sup/lo
lM-CM-6r aug 22 00:55:52 +0200 2009: crypto: detected gpg binary in /usr/bi
lM-CM-6r aug 22 00:55:52 +0200 2009: loading ind
lM-CM-6r aug 22 00:55:52 +0200 2009: loaded index of 0 mes
lM-CM-6r aug 22 00:55:52 +0200 2009: starting c
Regards,
ulrik
------------------------------
Message: 859
Date: Sat, 22 Aug 2009 01:08:30 +0200
From: Ulrik Sverdrup <ulrik.sverdrup@gmail.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] Bug: Quits on unbound(?) keys
Message-ID:
<a1b6cb1b0908211608u40e3ab67h9ff7373a4a686062@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Sup seems to crash if you press a key not bound(?)
Sup version: 0.8.1 (debian unstable)
start sup-mail.
press 'c'
sup will crash with following message:
uby: symbol lookup error:
/usr/lib/ruby/1.8/powerpc-linux/ncurses_bin.so: undefined symbol:
funcall
Regards,
ulrik
------------------------------
Message: 860
Date: Sat, 22 Aug 2009 06:46:27 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] index log
Message-ID: <1250948551-sup-2052@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Rich Lane's message of 2009-08-16:
> Add a YAML logfile that records changes to the index and modify
> sup-dump to use this rather than the normal database.
I like this. I'm going to wait to apply it until the api refactoring
stuff is merged down to master though. Should be soon.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 861
Date: Sat, 22 Aug 2009 07:10:04 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] cache results of Person.from_address
Message-ID: <1250949615-sup-1773@masanjin.net>
Content-Type: text/plain; charset=UTF-8
This looks good. Two minor questions before I apply:
Reformatted excerpts from Rich Lane's message of 2009-08-16:
> The regexes in this function are very expensive, so caching improves
> performance significantly for queries and slightly for indexing.
When you say this affects query performance, is it just the contact-list
query, or is there some other mechanism by which this is slowing down
regular queries?
Also in this method:
> + def []=(k,v)
> + if @values.size < @n
> + @values[k] = v
> + @marks[k] = @i
> + else
> + if @delete_stack.empty?
> + sweep
> + else
> + k2 = @delete_stack.pop
> + @values.delete k2
> + @marks.delete k2
> + self[k] = v
> + end
> + end
> + end
Wouldn't it be better to do this?
else
if @delete_stack.empty?
sweep
end
unless @delete_stack.empty?
k2 = @delete_stack.pop
@values.delete k2
@marks.delete k2
self[k] = v
end
So we check the delete stack even after calling sweep, and we allow for
the value to be nil.
Thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 862
Date: Sat, 22 Aug 2009 07:10:20 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] cache results of Person.from_address
Message-ID: <1250950211-sup-1042@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Andrei Thorp's message of 2009-08-17:
> Just want to say thanks again for your seemingly unending amount of
> good work to improve Sup.
Agreed!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 863
Date: Sat, 22 Aug 2009 07:35:37 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH 2/2] xapian index format versioning
Message-ID: <1250951723-sup-3859@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Branch xapian-updates, merged into next. Thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 864
Date: Sat, 22 Aug 2009 07:50:58 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Fix a thread merging bug introduced by
refactoring in 59f8fc2
Message-ID: <1250952651-sup-2682@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Applied to master. Thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 865
Date: Sat, 22 Aug 2009 08:01:30 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] fix garbaged text in textfield when
using ncursesw
Message-ID: <1250952979-sup-9364@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Beno?t PIERRE's message of 2009-08-19:
> Apparently, field_buffer content is not initialized to blanks when
> using the wide-character version of ncurses. Forcing a call to
> set_field_buffer fix the problem.
Awesome. Applied to master. I hope this clears up the problems that
people have been having with newer ncurses ruby libraries and utf8. If
you've been seeing garbage characters when searching, please let us know
if this fixes it.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 866
Date: Sat, 22 Aug 2009 16:49:17 +0200
From: Carlos Franke <carlos_franke@gmx.de>
To: sup-talk@rubyforge.org
Subject: [sup-talk] sup crash
Message-ID: <20090822164917.0a84a749@gmx.de>
Content-Type: text/plain; charset="utf-8"
Hi!
sup 0.8.1 crashed being started after sup-config and sup-sync. Mail
source: Local IMAP server (Courier) that works with other clients.
sup's output asked me to send you the appended file. Have fun with it!
Carlos
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: exception-log.txt
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090822/fc801d3c/attachment-0001.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090822/fc801d3c/attachment-0001.bin>
------------------------------
Message: 867
Date: Sat, 22 Aug 2009 09:26:36 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup crashed at launch
Message-ID: <1250958276-sup-9140@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Contzen Laurent's message of 2009-08-22:
> username and password must be specified
Sounds like your sources.yaml file doesn't have a username and password
for that entry, or isn't have the correct format. You may want to delete
it and run sup-add (or sup-config) instead to generate it automatically.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 868
Date: Sat, 22 Aug 2009 09:31:47 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup crash
Message-ID: <1250958467-sup-381@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Carlos Franke's message of 2009-08-22:
> invalid source 1
Sup is saying it has messages in its index that claim they're from
source 1, but your sources.yaml doesn't have such a source. Did you
remove something from sources.yaml?
The easiest way to fix this is to delete your ~/.sup/ferret/ directory
and run sup-sync --all --all-sources to rebuild the index, but you'll
lose all messages state. If that's not acceptable, you can re-add source
1, or you can delete all such messages from the index with some effort
and devel/console.sh.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 869
Date: Sat, 22 Aug 2009 09:34:40 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup crashed at launch
Message-ID: <1250958837-sup-947@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from William Morgan's message of 2009-08-22:
> Sounds like your sources.yaml file doesn't have a username and password
> for that entry, or isn't have the correct format.
In particular, that webpage doesn't preserve spacing for its example
sources.yaml, and yaml is space-sensitive.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 870
Date: Sat, 22 Aug 2009 11:15:15 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] mime-decode hook: provide a "charset"
variable with the attachment charset
Message-ID: <1250964880-sup-7106@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Adeodato Sim?'s message of 2009-08-19:
> Ping?
Sorry, working on a fix for the hook variables issue. Bug me again in a
few days if I haven't gotten to this.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 871
Date: Sat, 22 Aug 2009 11:28:15 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH] add Message#load_from_index! shortcut
Message-ID: <1250965695-31073-1-git-send-email-rlane@club.cc.cmu.edu>
Message#parse_header is slow, taking up to 2/3 of the time spent loading
threads in thread-index-mode. This patch adds a shortcut method that the index
can use to efficiently initialize a message.
---
lib/sup/message.rb | 25 +++++++++++++++++++++++++
lib/sup/xapian_index.rb | 30 +++++++++++-------------------
2 files changed, 36 insertions(+), 19 deletions(-)
diff --git a/lib/sup/message.rb b/lib/sup/message.rb
index 965c10e..56e66de 100644
--- a/lib/sup/message.rb
+++ b/lib/sup/message.rb
@@ -127,6 +127,31 @@ class Message
@list_unsubscribe = header["list-unsubscribe"]
end
+ ## Expected index entry format:
+ ## :message_id, :subject => String
+ ## :date => Time
+ ## :refs, :replytos => Array of String
+ ## :from => Person
+ ## :to, :cc, :bcc => Array of Person
+ def load_from_index! entry
+ @id = entry[:message_id]
+ @from = entry[:from]
+ @date = entry[:date]
+ @subj = entry[:subject]
+ @to = entry[:to]
+ @cc = entry[:cc]
+ @bcc = entry[:bcc]
+ @refs = (@refs + entry[:refs]).uniq
+ @replytos = entry[:replytos]
+
+ @replyto = nil
+ @list_address = nil
+ @recipient_email = nil
+ @source_marked_read = false
+ @list_subscribe = nil
+ @list_unsubscribe = nil
+ end
+
def add_ref ref
@refs << ref
@dirty = true
diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
index 85f6ef0..c260728 100644
--- a/lib/sup/xapian_index.rb
+++ b/lib/sup/xapian_index.rb
@@ -71,25 +71,17 @@ class XapianIndex < BaseIndex
source = SourceManager[entry[:source_id]]
raise "invalid source #{entry[:source_id]}" unless source
- mk_addrs = lambda { |l| l.map { |e,n| "#{n} <#{e}>" } * ', ' }
- mk_refs = lambda { |l| l.map { |r| "<#{r}>" } * ' ' }
- fake_header = {
- 'message-id' => entry[:message_id],
- 'date' => Time.at(entry[:date]),
- 'subject' => entry[:subject],
- 'from' => mk_addrs[[entry[:from]]],
- 'to' => mk_addrs[entry[:to]],
- 'cc' => mk_addrs[entry[:cc]],
- 'bcc' => mk_addrs[entry[:bcc]],
- 'reply-tos' => mk_refs[entry[:replytos]],
- 'references' => mk_refs[entry[:refs]],
- }
-
- m = Message.new :source => source, :source_info => entry[:source_info],
- :labels => entry[:labels],
- :snippet => entry[:snippet]
- m.parse_header fake_header
- m
+ m = Message.new :source => source, :source_info => entry[:source_info],
+ :labels => entry[:labels], :snippet => entry[:snippet]
+
+ mk_person = lambda { |x| Person.new(*x.reverse!) }
+ entry[:from] = mk_person[entry[:from]]
+ entry[:to].map!(&mk_person)
+ entry[:cc].map!(&mk_person)
+ entry[:bcc].map!(&mk_person)
+
+ m.load_from_index! entry
+ m
end
def add_message m; sync_message m end
--
1.6.4
------------------------------
Message: 872
Date: Sat, 22 Aug 2009 14:28:39 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] cache results of Person.from_address
Message-ID: <1250964897-sup-2990@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Sat Aug 22 10:10:04 -0400 2009:
> This looks good. Two minor questions before I apply:
>
> Reformatted excerpts from Rich Lane's message of 2009-08-16:
> > The regexes in this function are very expensive, so caching improves
> > performance significantly for queries and slightly for indexing.
>
> When you say this affects query performance, is it just the contact-list
> query, or is there some other mechanism by which this is slowing down
> regular queries?
Actually, your question prompted me to wonder why we're calling
Person.from_address on this path at all. With a little support from
Message we can completely avoid Message#parse_header. I've just sent in
a patch that does this. Please apply that rather than the from_address
cache.
The performance improvement from the new patch is slightly better than
that of the cache. Depending on the benchmark I see the time taken by
ThreadIndexMode#load_n_threads decrease by 1/2 to 2/3.
------------------------------
Message: 873
Date: Sat, 22 Aug 2009 11:54:23 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH] add xapian-specific hack to quickly create
a Person
Message-ID: <1250967263-31292-1-git-send-email-rlane@club.cc.cmu.edu>
Another 10% query performance boost.
---
lib/sup/xapian_index.rb | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
index c260728..3a23951 100644
--- a/lib/sup/xapian_index.rb
+++ b/lib/sup/xapian_index.rb
@@ -74,7 +74,7 @@ class XapianIndex < BaseIndex
m = Message.new :source => source, :source_info => entry[:source_info],
:labels => entry[:labels], :snippet => entry[:snippet]
- mk_person = lambda { |x| Person.new(*x.reverse!) }
+ mk_person = lambda { |x| QuickPerson.new(*x) }
entry[:from] = mk_person[entry[:from]]
entry[:to].map!(&mk_person)
entry[:cc].map!(&mk_person)
@@ -84,6 +84,14 @@ class XapianIndex < BaseIndex
m
end
+ class QuickPerson < Person
+ def initialize email, name
+ raise ArgumentError, "email can't be nil" unless email
+ @email = email
+ @name = name
+ end
+ end
+
def add_message m; sync_message m end
def update_message m; sync_message m end
def update_message_state m; sync_message m end
--
1.6.4
------------------------------
Message: 874
Date: Sat, 22 Aug 2009 21:12:30 +0200
From: Ingmar Vanhassel <ingmar@exherbo.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Bug: Quits on unbound(?) keys
Message-ID: <1250968143-sup-3847@cannonball>
Content-Type: text/plain; charset=UTF-8
Excerpts from Ulrik Sverdrup's message of Sat Aug 22 01:08:30 +0200 2009:
> sup will crash with following message:
> ruby: symbol lookup error:
> /usr/lib/ruby/1.8/powerpc-linux/ncurses_bin.so: undefined symbol:
> funcall
I bet you're using ncurses-ruby-1.2.2? What you're seeing is an
ncurses-ruby bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532431
Update to 1.2.3 or 1.2.4 & you'll be find. If that's not an option,
downgrade to a 1.1 release.
--
Exherbo KDE, X.org maintainer
------------------------------
Message: 875
Date: Sat, 22 Aug 2009 20:16:17 +0100
From: Adeodato Sim? <dato@net.com.org.es>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] [PATCH] mime-decode hook: provide a "charset"
variable with the attachment charset
Message-ID: <20090822191617.GA26897@chistera.yi.org>
Content-Type: text/plain; charset=utf-8
+ William Morgan (Sat, 22 Aug 2009 11:15:15 -0700):
> Reformatted excerpts from Adeodato Sim?'s message of 2009-08-19:
> > Ping?
> Sorry, working on a fix for the hook variables issue. Bug me again in a
> few days if I haven't gotten to this.
Only in case it needs saying: you mean a fix other than the patch I sent
for that as well? (Perhaps my proposed fix was not completed, I just
want to make sure the patch got noticed.)
Thanks,
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
------------------------------
Message: 876
Date: Sat, 22 Aug 2009 13:23:17 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Exception trying to run git source
Message-ID: <1250964942-sup-8625@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Carl Worth's message of 2009-08-19:
> I ran an strace on the ruby process[*] and was able to plainly see
> that modules were being correctly loaded from ./lib until after
> /usr/lib/ruby/1.8/chronic.rb was loaded. After that, ruby would look
> for modules in /usr/lib/ruby/1.8 before ./lib. And sure enough, the
> first line of my chronic.rb has:
>
> $:.unshift File.dirname(__FILE__) # For use/testing when no gem is installed
I'd call that a bug in chronic. It shouldn't be screwing with the load
path. Nice debug work.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 877
Date: Sat, 22 Aug 2009 13:25:22 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Make SUP_LOG_LEVEL self-documenting.
Message-ID: <1250972634-sup-6871@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Carl Worth's message of 2009-08-19:
> I'm probably still off as far as standard ruby idioms, (and I'm
> probably committing some sup layer violations as well).
It all looks good except you can use Logger::LEVELS to access the
constants. Then there's no need to write a LEVELS method. If you fix
that I will apply. Thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 878
Date: Sun, 23 Aug 2009 13:44:29 +0100
From: Chris Wilson <chris@chris-wilson.co.uk>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] How to edit attachments in reply?
Message-ID: <1251031062-sup-4617@tiger.alporthouse.com>
Content-Type: text/plain; charset=UTF-8
Just a simple plea to make my life easier... Given an email with a
couple of attached patches, what is the easiest way to reply including
inline comments on the attached patches? At the moment I'm saving the
attachments to /tmp and then manually including them whilst replying.
Can anyone give me any clues on how to automatically include the
attachments in a reply?
Thanks.
-Chris
------------------------------
Message: 879
Date: Sun, 23 Aug 2009 10:34:10 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] mime-decode hook: provide a "charset"
variable with the attachment charset
Message-ID: <1251048347-sup-5075@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Adeodato Sim?'s message of 2009-08-22:
> Only in case it needs saying: you mean a fix other than the patch I
> sent for that as well? (Perhaps my proposed fix was not completed, I
> just want to make sure the patch got noticed.)
Hm, I don't remember seeing it and can't find it now. Can you resend,
please?
I do see a previous patch that did miss from you, about a crypto+mime
fix. Is that still something that should be applied? It looks good to
me.
Anyways, I just merged my hook changes into next, on the branch
hook-local-vars. Take a look and tell me what you think. This should
also fix Edward Z. Yang's problems with hook locals not being useable in
statements like "x = x.foo()".
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 880
Date: Sun, 23 Aug 2009 10:55:59 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Be less overzealous in moving text to
the left column
Message-ID: <1251050007-sup-9740@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Carl Worth's message of 2009-08-19:
> Specifically, scroll as little as possible to get the current message
> to just fit on the right side.
Is this the same as setting loose_alignment to true, and the
IDEAL_*_CONTENTs to 0?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 881
Date: Sun, 23 Aug 2009 11:36:59 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH] sup-sync: restore state on messages that
dont already exist
Message-ID: <1251052619-9915-1-git-send-email-rlane@club.cc.cmu.edu>
---
bin/sup-sync | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/bin/sup-sync b/bin/sup-sync
index 2aa00c3..003a72d 100755
--- a/bin/sup-sync
+++ b/bin/sup-sync
@@ -174,7 +174,12 @@ begin
## decide what to do based on message labels and the operation we're performing
dothis, new_labels = case
when (op == :restore) && restored_state[m.id] && old_m && (old_m.labels != restored_state[m.id])
+ num_restored += 1
[:update_message_state, restored_state[m.id]]
+ when (op == :restore) && restored_state[m.id] && !old_m
+ num_restored += 1
+ m.labels = restored_state[m.id]
+ :add_message
when op == :discard
if old_m && (old_m.labels != m.labels)
[:update_message_state, m.labels]
--
1.6.4
------------------------------
Message: 882
Date: Sun, 23 Aug 2009 11:46:10 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH 1/2] preemptively load messages when
scrolling
Message-ID: <1251053171-11450-1-git-send-email-rlane@club.cc.cmu.edu>
---
lib/sup/modes/line-cursor-mode.rb | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/sup/modes/line-cursor-mode.rb b/lib/sup/modes/line-cursor-mode.rb
index 246f2b5..0b1fd1d 100644
--- a/lib/sup/modes/line-cursor-mode.rb
+++ b/lib/sup/modes/line-cursor-mode.rb
@@ -77,7 +77,7 @@ protected
end
def cursor_down
- call_load_more_callbacks buffer.content_height if @curpos == lines - 1
+ call_load_more_callbacks buffer.content_height if @curpos >= lines - [buffer.content_height/2,1].max
return false unless @curpos < lines - 1
if @curpos >= botline - 1
--
1.6.4
------------------------------
Message: 883
Date: Sun, 23 Aug 2009 11:46:11 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH 2/2] ui responsiveness tweaks
Message-ID: <1251053171-11450-2-git-send-email-rlane@club.cc.cmu.edu>
---
bin/sup | 1 +
lib/sup/modes/thread-index-mode.rb | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/bin/sup b/bin/sup
index 3d5b6c1..f3c6771 100755
--- a/bin/sup
+++ b/bin/sup
@@ -58,6 +58,7 @@ if $opts[:list_hooks]
end
Thread.abort_on_exception = true # make debugging possible
+Thread.current.priority = 1 # keep ui responsive
module Redwood
diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb
index fb6b2ce..177431b 100644
--- a/lib/sup/modes/thread-index-mode.rb
+++ b/lib/sup/modes/thread-index-mode.rb
@@ -76,8 +76,7 @@ EOS
@last_load_more_size = nil
to_load_more do |size|
next if @last_load_more_size == 0
- load_threads :num => 1, :background => false
- load_threads :num => (size - 1),
+ load_threads :num => size,
:when_done => lambda { |num| @last_load_more_size = num }
end
end
@@ -627,6 +626,7 @@ EOS
BufferManager.draw_screen
last_update = Time.now
end
+ ::Thread.pass
break if @interrupt_search
end
@ts.threads.each { |th| th.labels.each { |l| LabelManager << l } }
--
1.6.4
------------------------------
Message: 884
Date: Sun, 23 Aug 2009 11:49:02 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH] reply all keybindings
Message-ID: <1251053342-11859-1-git-send-email-rlane@club.cc.cmu.edu>
---
lib/sup/modes/reply-mode.rb | 6 ++++--
lib/sup/modes/thread-index-mode.rb | 7 +++++--
lib/sup/modes/thread-view-mode.rb | 7 +++++--
3 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/lib/sup/modes/reply-mode.rb b/lib/sup/modes/reply-mode.rb
index 700dfc1..3d39a8a 100644
--- a/lib/sup/modes/reply-mode.rb
+++ b/lib/sup/modes/reply-mode.rb
@@ -40,7 +40,7 @@ Return value:
The reply mode you desire, or nil to use the default behavior.
EOS
- def initialize message
+ def initialize message, type_arg=nil
@m = message
## it's important to put this early because it forces a read of
@@ -138,7 +138,9 @@ EOS
hook_reply = HookManager.run "reply-to", :modes => types
@type_selector.set_to(
- if types.include? hook_reply
+ if types.include? type_arg
+ type_arg
+ elsif types.include? hook_reply
hook_reply
elsif @m.is_list_message?
:list
diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb
index fb6b2ce..d1b7fdb 100644
--- a/lib/sup/modes/thread-index-mode.rb
+++ b/lib/sup/modes/thread-index-mode.rb
@@ -40,6 +40,7 @@ EOS
k.add :save, "Save changes now", '$'
k.add :jump_to_next_new, "Jump to next new thread", :tab
k.add :reply, "Reply to latest message in a thread", 'r'
+ k.add :reply_all, "Reply to all participants of the latest message in a thread", 'G'
k.add :forward, "Forward latest message in a thread", 'f'
k.add :toggle_tagged, "Tag/untag selected thread", 't'
k.add :toggle_tagged_all, "Tag/untag all threads", 'T'
@@ -584,15 +585,17 @@ EOS
end
end
- def reply
+ def reply type_arg=nil
t = cursor_thread or return
m = t.latest_message
return if m.nil? # probably won't happen
m.load_from_source!
- mode = ReplyMode.new m
+ mode = ReplyMode.new m, type_arg
BufferManager.spawn "Reply to #{m.subj}", mode
end
+ def reply_all; reply :all; end
+
def forward
t = cursor_thread or return
m = t.latest_message
diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb
index bac4792..98145cc 100644
--- a/lib/sup/modes/thread-view-mode.rb
+++ b/lib/sup/modes/thread-view-mode.rb
@@ -53,6 +53,7 @@ EOS
k.add :toggle_new, "Toggle unread/read status of message", 'N'
# k.add :collapse_non_new_messages, "Collapse all but unread messages", 'N'
k.add :reply, "Reply to a message", 'r'
+ k.add :reply_all, "Reply to all participants of this message", 'G'
k.add :forward, "Forward a message or attachment", 'f'
k.add :bounce, "Bounce message to other recipient(s)", '!'
k.add :alias, "Edit alias/nickname for a person", 'i'
@@ -161,12 +162,14 @@ EOS
update
end
- def reply
+ def reply type_arg=nil
m = @message_lines[curpos] or return
- mode = ReplyMode.new m
+ mode = ReplyMode.new m, type_arg
BufferManager.spawn "Reply to #{m.subj}", mode
end
+ def reply_all; reply :all; end
+
def subscribe_to_list
m = @message_lines[curpos] or return
if m.list_subscribe && m.list_subscribe =~ /<mailto:(.*?)\?(subject=(.*?))>/
--
1.6.4
------------------------------
Message: 885
Date: Mon, 24 Aug 2009 14:20:20 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] index log
Message-ID: <1251116226-sup-1373@peray>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Sat Aug 22 15:46:27 +0200 2009:
> Reformatted excerpts from Rich Lane's message of 2009-08-16:
> > Add a YAML logfile that records changes to the index and modify
> > sup-dump to use this rather than the normal database.
>
> I like this. I'm going to wait to apply it until the api refactoring
> stuff is merged down to master though. Should be soon.
I'm wondering if a simpler format would not be better, I've patch
in my sup copy do feed a file called ~/.sup/labels-mapping.log with
lines like those:
000e0cd20f80143822047118693d@google.com (unread inbox -> )
20090813213654.GA30223@community.haskell.org (unread inbox patch -> patch)
1250148617-sup-6053@oz.taruti.net (unread inbox sup -> sup)
1250281208-sup-4199@masanjin.net (unread inbox sup -> sup)
Their are in the style of sup-dump output and there are pretty easy to manage
by any tools.
Not to say that I don't like YAML, I am a pretty big fan of it; but here it
seems overkill.
Best regards,
--
Nicolas Pouillard
http://nicolaspouillard.fr
------------------------------
Message: 886
Date: Mon, 24 Aug 2009 14:41:03 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH 2/2] xapian index format versioning
Message-ID: <1251117610-sup-9144@peray>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Sat Aug 22 16:35:37 +0200 2009:
> Branch xapian-updates, merged into next. Thanks!
What is the updating procedure please ?
--
Nicolas Pouillard
http://nicolaspouillard.fr
------------------------------
Message: 887
Date: Mon, 24 Aug 2009 11:13:43 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] In next: thread-view-mode labelling No method
join for Set
Message-ID: <1251137007-sup-3974@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Carl Worth's message of 2009-08-19:
> I've attached a patch that at least makes the crashes I was able ro
> reproduce go away.
Applied, thanks!
> [*] Totally off-topic: This is one of the things about "dynamically
> typed" languages that I've never been able to wrap my brain around. I
> really like that with static typing I can trust the compiler to help
> me be very thorough if I make a type change like this, (and catch all
> the cases before shipping any code). Instead, here, there's a hard
> task of exercising every possible code path (at run time) before we
> know if there are any type errors still lingering. I've seen some
> proponents of dynamically-typed languages argue that unit testing
> should provide the same coverage that a statically-typed compiler
> would, but I haven't seen that in practice.
You're right, this is a classic example of the type of bug that would be
caught with static typing. Unit tests are the canonical answer. I'd
argue that unit tests provide better error checking than static typing,
since they allow you to capture the exact set of errors you're
interested in, rather than the set of type mismatches that a
type-checker can detect. (IMO the two sets rarely have more than a very
small overlap.)
Unit tests are only useful, of course, if you write them. Sup doesn't
have very many. I've made an explicit choice to spend my oh-so-limited
Sup time adding new features rather than ensuring a rock-solid platform.
The occasional bug like this is the price we all pay. But it's a matter
of tradeoffs---I do believe that if I were using a statically-typed
language, development would be significantly slower, and Sup would be
nowhere near the point it is now. I have no proof of this statement, of
course.
And if anyone wants to retrofit some unit tests, I'm more than happy to
accept them!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 888
Date: Mon, 24 Aug 2009 21:54:35 +0100
From: Lars Kotthoff <lists@larsko.org>
To: sup-talk@rubyforge.org
Subject: [sup-talk] Encrypted password in configuration file
Message-ID: <20090824215435.182e0007@ronin.larsko.net>
Content-Type: text/plain; charset=US-ASCII
Hi list,
is it possible to store the account password encrypted in the configuration
file?
Thanks,
Lars
------------------------------
Message: 889
Date: Mon, 24 Aug 2009 15:38:42 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Bug: Quits on unbound(?) keys
Message-ID: <1251153498-sup-1707@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ingmar Vanhassel's message of 2009-08-22:
> I bet you're using ncurses-ruby-1.2.2? What you're seeing is an
> ncurses-ruby bug:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532431
Wow, Sup is really giving the ncurses-ruby maintainer a workout. Nice!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 890
Date: Mon, 24 Aug 2009 15:44:58 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Add an after-add-message hook
Message-ID: <1251153881-sup-1538@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Kevin Riggle's message of 2009-08-20:
> I want to do some unrelated processing on each message I receive, but
> I don't want to block the message being added to the index. This
> patch adds a hook which runs /after/ the message is added to the
> index.
Branch after-add-message-hook, merged into next. Thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 891
Date: Mon, 24 Aug 2009 15:45:37 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] 'next' crash: wrong id called on nil
(thread.rb:264:in `thread_for')
Message-ID: <1251153912-sup-5105@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Carl Worth's message of 2009-08-20:
> --- RuntimeError from thread: main
> wrong id called on nil
I think this should be fixed in recent nexts. Can you confirm?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 892
Date: Mon, 24 Aug 2009 15:46:12 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crashing ssh + sup, bad combo
Message-ID: <1251153959-sup-7992@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Guillaume Quintard's message of 2009-08-21:
> --- RuntimeError from thread: load threads for thread-index-mode
> wrong id called on nil
Let me know if this is still a problem.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 893
Date: Mon, 24 Aug 2009 15:48:05 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Bug: Log printing with encoding problems
Message-ID: <1251154017-sup-4599@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ulrik Sverdrup's message of 2009-08-21:
> My locale is sv_SE.UTF-8, log is truncated since the date string is
> longer than expected.
Are you running with the ncursesw-enabled ncurses.so? If so, this should
work, assuming your terminal is otherwise capable of displaying utf8.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 894
Date: Mon, 24 Aug 2009 16:23:32 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] add Message#load_from_index! shortcut
Message-ID: <1251156117-sup-2313@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Rich Lane's message of 2009-08-22:
> Message#parse_header is slow, taking up to 2/3 of the time spent
> loading threads in thread-index-mode. This patch adds a shortcut
> method that the index can use to efficiently initialize a message.
Yes, great catch. I've applied this to xapian-updates branch and
remerged into next.
BTW can you base your patches off master instead of next? It will save
me a couple keystrokes.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 895
Date: Mon, 24 Aug 2009 16:24:19 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] add xapian-specific hack to quickly
create a Person
Message-ID: <1251156216-sup-5563@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Rich Lane's message of 2009-08-22:
> - mk_person = lambda { |x| Person.new(*x.reverse!) }
> + mk_person = lambda { |x| QuickPerson.new(*x) }
What about lambda { |x| Person.new x[1], x[0] }. Surely that must be
even faster?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 896
Date: Mon, 24 Aug 2009 16:29:40 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] How to edit attachments in reply?
Message-ID: <1251156446-sup-143@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Chris Wilson's message of 2009-08-23:
> Can anyone give me any clues on how to automatically include the
> attachments in a reply?
There's no way to do this currently. The best option might be to add a
hook that sets the reply body at the beginning of reply-mode. Then you
could add the attachments (if the mime type were appropriate) and do
whatever other transformations you wanted on the message.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 897
Date: Mon, 24 Aug 2009 21:03:29 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH 2/2] xapian index format versioning
Message-ID: <1251161843-sup-2990@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from Nicolas Pouillard's message of Mon Aug 24 08:41:03 -0400 2009:
> Excerpts from William Morgan's message of Sat Aug 22 16:35:37 +0200 2009:
> > Branch xapian-updates, merged into next. Thanks!
>
> What is the updating procedure please ?
>
sup-dump and sup-sync. Sorry for the inconvenience, but I don't
currently have plans to break compatibility again so you should be safe
for a while.
------------------------------
Message: 898
Date: Tue, 25 Aug 2009 09:44:11 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] In next: thread-view-mode labelling No method
join for Set
Message-ID: <1251185965-sup-6316@peray>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Mon Aug 24 20:13:43 +0200 2009:
> Reformatted excerpts from Carl Worth's message of 2009-08-19:
> > I've attached a patch that at least makes the crashes I was able ro
> > reproduce go away.
>
> Applied, thanks!
>
> > [*] Totally off-topic: This is one of the things about "dynamically
> > typed" languages that I've never been able to wrap my brain around. I
> > really like that with static typing I can trust the compiler to help
> > me be very thorough if I make a type change like this, (and catch all
> > the cases before shipping any code). Instead, here, there's a hard
> > task of exercising every possible code path (at run time) before we
> > know if there are any type errors still lingering. I've seen some
> > proponents of dynamically-typed languages argue that unit testing
> > should provide the same coverage that a statically-typed compiler
> > would, but I haven't seen that in practice.
[...]
> I do believe that if I were using a statically-typed
> language, development would be significantly slower, and Sup would be
> nowhere near the point it is now. I have no proof of this statement, of
> course.
I don't really want to start troll on this subject... However it depends
on what kind of statically-typed language to talk about, if you mean Java
or C++ then I agree with you, the development would be much sloooower.
Although if we take a language like Haskell (or OCaml, or Scala...) the
development become really competitive.
Best regards,
--
Nicolas Pouillard
http://nicolaspouillard.fr
------------------------------
Message: 899
Date: Tue, 25 Aug 2009 11:29:01 +0200
From: Israel Herraiz <israel.herraiz@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] [PATCH] Add UTF-8 encoding string for ArchLinux
systems
Message-ID: <1251192382-sup-2350@elly>
Content-Type: text/plain; charset=utf8
Hi,
in ArchLinux, UTF-8 encoding is identified by "utf8" instead of
"UTF-8".
Cheers,
Israel
---
lib/sup/util.rb | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/sup/util.rb b/lib/sup/util.rb
index 068ce6b..f99e1c1 100644
--- a/lib/sup/util.rb
+++ b/lib/sup/util.rb
@@ -177,7 +177,7 @@ class String
## nasty multibyte hack for ruby 1.8. if it's utf-8, split into chars using
## the utf8 regex and count those. otherwise, use the byte length.
def display_length
- if $encoding == "UTF-8"
+ if $encoding == "UTF-8" || $encoding == "utf8"
scan(/./u).size
else
size
--
1.6.4
------------------------------
Message: 900
Date: Tue, 25 Aug 2009 11:31:55 +0200
From: Israel Herraiz <israel.herraiz@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] [PATCH] Identify list messages by list-id if
list-post is not present
Message-ID: <1251192579-sup-1849@elly>
Content-Type: text/plain; charset=utf8
Hi,
I am subscribed to some lists that do not fill the list-post header,
but have a list-id header. I am not sure how standard-compliant is
that, but it would nice if Sup could identify those messages as list
messages.
Cheers,
Israel
---
lib/sup/message.rb | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/lib/sup/message.rb b/lib/sup/message.rb
index 56e66de..67f928c 100644
--- a/lib/sup/message.rb
+++ b/lib/sup/message.rb
@@ -34,7 +34,7 @@ class Message
attr_reader :id, :date, :from, :subj, :refs, :replytos, :to, :source,
:cc, :bcc, :labels, :attachments, :list_address, :recipient_email, :replyto,
- :source_info, :list_subscribe, :list_unsubscribe
+ :source_info, :list_subscribe, :list_unsubscribe, :list_id
bool_reader :dirty, :source_marked_read, :snippet_contains_encrypted_content
@@ -120,6 +120,13 @@ class Message
else
nil
end
+
+ @list_id =
+ if header["list-id"]
+ @list_id = header["list-id"].gsub(/^<|>$/, "")
+ else
+ nil
+ end
@recipient_email = header["envelope-to"] || header["x-original-to"] || header["delivered-to"]
@source_marked_read = header["status"] == "RO"
@@ -162,7 +169,7 @@ class Message
end
def snippet; @snippet || (chunks && @snippet); end
- def is_list_message?; !@list_address.nil?; end
+ def is_list_message?; !@list_address.nil? || !@list_id.nil?; end
def is_draft?; @source.is_a? DraftLoader; end
def draft_filename
raise "not a draft" unless is_draft?
--
1.6.4
------------------------------
Message: 901
Date: Tue, 25 Aug 2009 07:16:44 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk mailing list <sup-talk@rubyforge.org>
Subject: [sup-talk] lots of branches merged down to master
Message-ID: <1251209432-sup-766@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Just FYI, I've merged the following branches down to master:
buffer-rolling, run-mailcap-fixes, locking-refactor, logging,
various-api-tweaks, and ncurses-fixes. If you're running master, you
should see some fun improvements.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 902
Date: Tue, 25 Aug 2009 21:50:48 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] add xapian-specific hack to quickly
create a Person
Message-ID: <1251250991-sup-3593@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Mon Aug 24 19:24:19 -0400 2009:
> Reformatted excerpts from Rich Lane's message of 2009-08-22:
> > - mk_person = lambda { |x| Person.new(*x.reverse!) }
> > + mk_person = lambda { |x| QuickPerson.new(*x) }
>
> What about lambda { |x| Person.new x[1], x[0] }. Surely that must be
> even faster?
The slow part is the processing in Person#initialize, which QuickPerson
overrides. You might also be able to avoid that by moving the
initialize() code into Person.from_address.
------------------------------
Message: 903
Date: Wed, 26 Aug 2009 13:26:34 -0700
From: Carl Worth <cworth@cworth.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] 'next' crash: wrong id called on nil
(thread.rb:264:in `thread_for')
Message-ID: <1251318332-sup-4953@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Mon Aug 24 15:45:37 -0700 2009:
> Reformatted excerpts from Carl Worth's message of 2009-08-20:
> > --- RuntimeError from thread: main
> > wrong id called on nil
>
> I think this should be fixed in recent nexts. Can you confirm?
I don't think I'll be able to, (since I don't have a good recipe for
reproducing the bug). But I'll certainly start running rom newer next
and I'll let you know if I run into any further problems.
Thanks for everything,
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090826/e9ada9c1/attachment-0001.bin>
------------------------------
Message: 904
Date: Wed, 26 Aug 2009 14:15:36 -0700
From: Carl Worth <cworth@cworth.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH 2/2] ui responsiveness tweaks
Message-ID: <1251318620-sup-3031@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
My message here really has nothing to do with Rich's patches
specifically, (so sorry about that), but his patches happened to
provide the perfect context for an issue I wanted to bring up. As is
typical of git-formatted patches, Rich's emails have subject lines
from his commit messages:
[sup-talk] [PATCH 1/2] preemptively load messages when scrolling
[sup-talk] [PATCH 2/2] ui responsiveness tweaks
As far as the git commits go, this subject line is one of the most
essential pieces of metadata to accompany the patch. Yet by default
sup doesn't display it at all, (requiring keypresses to display the
header and find the subject line). I think what I would like is for
sup to display the subject line everytime it changes significantly in
a thread, (specifically not regarding things like an initial "Re: "
getting added as significant).
I think I'd be willing to spend an entire line's worth of screen real
estate for this information---it's quite useful when people do
meaningful subject changes for sub-threads.
-Carl
Excerpts from Rich Lane's message of Sun Aug 23 11:46:11 -0700 2009:
> ---
> bin/sup | 1 +
> lib/sup/modes/thread-index-mode.rb | 4 ++--
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/bin/sup b/bin/sup
> index 3d5b6c1..f3c6771 100755
> --- a/bin/sup
> +++ b/bin/sup
> @@ -58,6 +58,7 @@ if $opts[:list_hooks]
> end
>
> Thread.abort_on_exception = true # make debugging possible
> +Thread.current.priority = 1 # keep ui responsive
>
> module Redwood
>
> diff --git a/lib/sup/modes/thread-index-mode.rb
> b/lib/sup/modes/thread-index-mode.rb
> index fb6b2ce..177431b 100644
> --- a/lib/sup/modes/thread-index-mode.rb
> +++ b/lib/sup/modes/thread-index-mode.rb
> @@ -76,8 +76,7 @@ EOS
> @last_load_more_size = nil
> to_load_more do |size|
> next if @last_load_more_size == 0
> - load_threads :num => 1, :background => false
> - load_threads :num => (size - 1),
> + load_threads :num => size,
> :when_done => lambda { |num| @last_load_more_size = num }
> end
> end
> @@ -627,6 +626,7 @@ EOS
> BufferManager.draw_screen
> last_update = Time.now
> end
> + ::Thread.pass
> break if @interrupt_search
> end
> @ts.threads.each { |th| th.labels.each { |l| LabelManager << l } }
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090826/5b3011d5/attachment-0001.bin>
------------------------------
Message: 905
Date: Wed, 26 Aug 2009 14:26:18 -0700
From: Carl Worth <cworth@cworth.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Exception trying to run git source
Message-ID: <1251321606-sup-7393@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
Reformatted excerpts from William Morgan's message of Sat Aug 22 13:23:17 -0700 2009:
> Reformatted excerpts from Carl Worth's message of 2009-08-19:
> > $:.unshift File.dirname(__FILE__) # For use/testing when no gem is installed
>
> I'd call that a bug in chronic. It shouldn't be screwing with the load
> path.
That's what I thought too. I filed a Debian bug against the
libchronic-ruby package here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542491
But I reall only did that because I didn't find any contact
information for how to submit an upstream bug against chronic
(http://chronic.rubyforge.net didn't have any details that I could
find).
So if someone knows a better place to file the bug, I'd be glad to do
that.
> Nice debug work.
Thanks.
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090826/41bd963c/attachment-0001.bin>
------------------------------
Message: 906
Date: Wed, 26 Aug 2009 14:35:25 -0700
From: Carl Worth <cworth@cworth.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Make SUP_LOG_LEVEL self-documenting.
Message-ID: <1251322427-sup-9184@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
The idea here is that if someone is looking at the log and not seeing
the information of interest, then the log itself should tell them
how to get more information, (by suggesting to set SUP_LOG_LEVEL
to the next lower level).
---
Excerpts from William Morgan's message of Sat Aug 22 13:25:22 -0700 2009:
> It all looks good except you can use Logger::LEVELS to access the
> constants. Then there's no need to write a LEVELS method. If you fix
> that I will apply. Thanks!
Thanks. I had the distinct feeling I was doing something wrong
there. Here's a corrected version.
-Carl
bin/sup | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/bin/sup b/bin/sup
index 3d5b6c1..cdf1ff2 100755
--- a/bin/sup
+++ b/bin/sup
@@ -169,6 +169,9 @@ begin
lmode.on_kill { Logger.clear! }
Logger.add_sink lmode
Logger.force_message "Welcome to Sup! Log level is set to #{Logger.level}."
+ if Logger::LEVELS.index(Logger.level) > 0
+ Logger.force_message "For more verbose logging, restart with SUP_LOG_LEVEL=#{Logger::LEVELS[Logger::LEVELS.index(Logger.level)-1]}."
+ end
debug "initializing inbox buffer"
imode = InboxMode.new
--
1.6.3.3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090826/3686da0d/attachment-0001.bin>
------------------------------
Message: 907
Date: Wed, 26 Aug 2009 14:53:32 -0700
From: Carl Worth <cworth@cworth.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Be less overzealous in moving text to
the left column
Message-ID: <1251323127-sup-5162@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Sun Aug 23 10:55:59 -0700 2009:
> Reformatted excerpts from Carl Worth's message of 2009-08-19:
> > Specifically, scroll as little as possible to get the current message
> > to just fit on the right side.
>
> Is this the same as setting loose_alignment to true, and the
> IDEAL_*_CONTENTs to 0?
I don't think so.
Doing that, (at least as in the below patch, for example), always puts
the current message flush left. And that can result in later messages
in the threads, (not descendants of the current thread though), being
cut off on the left. (And all this with dozens of empty columns on the
right of my terminal.) That's precisely the behavior I was getting
before my patch and which I'm trying to change.
What I want instead is for the message to appear in its "natural"
position (according to the threading), unless that would cause the
message to be cut off on the right. In which case, we jump to the
minimum column such that:
1. We don't cut any of the current message off on the left
2. We display all of the message on the right, (if possible
without violating point 1).
I believe that what I've coded achieves that. The two open questions I
still have are:
A. Is there some simpler way to achieve the result I want with
some of the existing code?
B. If not, is some of the existing code rendered obsolete with
my code in place?
As for (B), for example, with my code in place I don't think there's
any need for a notion of "ideal context". The ideal context is the
natural position of the thread.
And I still haven't figured out what loose_alignment means and which
actions will cause loose vs. non-loose layout.
-Carl
diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb
index dfe30ff..b7bbc7c 100644
--- a/lib/sup/modes/thread-view-mode.rb
+++ b/lib/sup/modes/thread-view-mode.rb
@@ -401,9 +401,9 @@ EOS
end
end
- IDEAL_TOP_CONTEXT = 3 # try and give 3 rows of top context
- IDEAL_LEFT_CONTEXT = 4 # try and give 4 columns of left context
- def jump_to_message m, loose_alignment=false
+ IDEAL_TOP_CONTEXT = 0 # don't bother trying to give any rows of top context
+ IDEAL_LEFT_CONTEXT = 0 # don't bother trying to give any columns of left context
+ def jump_to_message m, loose_alignment=true
l = @layout[m]
left = l.depth * INDENT_SPACES
right = left + l.width
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090826/8c5c013c/attachment-0001.bin>
------------------------------
Message: 908
Date: Wed, 26 Aug 2009 15:24:36 -0700
From: Carl Worth <cworth@cworth.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] On making inbox-mode and search-results-mode more
similar
Message-ID: <1251323747-sup-1595@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
[Argh! I ended up getting really verbose again with this one. Thanks
to anyone patient enough to wade through all of this. There is a patch
here for one issue at least. See below.]
I spent about 4 days away from email which gave me my first case of a
large inbox after switching to sup. And there are definitely a few
things I'd like to convince sup to do to make it easier for me to deal
with this.
Most important, with a large inbox, my mail falls into different
"classes", some of which are more important than others, and I'd like
to deal with the most important things first. I also often want to
deal with a single "class" of mail as a whole to avoid mental context
switches.
Fortunately, I've got sup labels capturing these classes quite
well. I've got some future ideas for having a prioritized (partial
order) list of labels so that inbox-mode will present messages
according to that priority. But for now, it would be good enough to be
able to easily filter my inbox down to just a single class of messages
at a time.
To this end, I started using the patch below, which adds a
refine_search keybinding to inbox-mode much like the same function in
search-result-mode. This is useful already and might be considered for
inclusion as is, (another feature I'd like for both modes is "restrict
to label" which would act like refine-search but save me from having
to type "label:" much like the 'L' command avoids having to type
"label:" compared to the 'F' command).
Beyond this patch as is, though, I'd like to talk a bit about how to
better achieve what I want. There's obviously some code duplication in
this patch which is not ideal. It would be better if InboxMode could
be a derived class from SearchResultsMode. Not only would this reduce
code-duplication, but there are features currently in InboxMode that I
think belong in all searches.
For example, if I use the refine_search command below to get a view of
my inbox restricted to a particular label, it no longer acts like my
inbox does. One of the most noticeable cases is the archive
command[*]. In both inbox-mode and search-result-mode this command
removes the "inbox" label from a thread, but in inbox-mode the thread
is immediately removed from the results, while in search-results-mode
the thread remains in the results.
One annoying side effect of this is that when I'm reading and
archiving many threads in some class, then I happen to reply to one
thread, that thread gets bumped to the top of my search so when I
navigate to the "next" thread I start cycling through threads that I
just got finished reading and archiving. To fix this I end up having
to notice I'm seeing repeated messages, remember why, then save my
current changes and refresh the search. And I have to do this after
every reply.
[Note: Even if archiving messages made them immediately disappear from
my search results, there could still be problems with "next" causing
me to re-cycle through messages I had already read but decided to
leave in my inbox. I think this is just another general race-condition
bug. I think the fix would be for the transition from
search-results-mode to thread-view-mode to somehow snapshot the
current search results so that future modifications due to newly
arriving messages don't modify the meaning of "next thread" within
thread-view-mode.]
So what I want is for anytime a message is changed such that it no
longer meets the current search criteria, it is immediately removed
from the search results. I think that means simply implementing the
is_relevant? method for SearcResultsMode where there is currently just
the following comment:
## a proper is_relevant? method requires some way of asking ferret
## if an in-memory object satisfies a query. i'm not sure how to do
## that yet. in the worst case i can make an in-memory index, add
## the message, and search against it to see if i have > 0 results,
## but that seems pretty insane.
That single-message index and search sounds exactly like what I want,
and not insane at all. Has someone attempted this and found a
performance issue? (In which case, I would think we just need to fix
that performance bug.) Or is it simply a matter of nobody having tried
to code this up yet? (In which case, I'll try, and I'll be glad for
any pointers that anyone can give me on how to go about creating an
in-memory index and searching on it.)
Thanks,
-Carl
[*] I'll ignore for now the fact that 'a' is a toggle of the inbox
label in SearchResultsMode and a one-way removal of the label in
InboxMode. I haven't found any need to ever put a thread _back_ into
the inbox, (except perhaps in the case of accidental archiving, and
there an immediate undo works fine). So I would imagine the use is
rare enough to not need a single-character command. The command I
would find natural for putting a thread back into the inbox would be
to simply add the inbox label to the thread. Oddly this is currently
not allowed as "inbox" is a reserved label. I don't
>From d37eca31aaddee80f05357d6a4ed896f39bbad16 Mon Sep 17 00:00:00 2001
From: Carl Worth <cworth@cworth.org>
Date: Wed, 26 Aug 2009 10:17:20 -0700
Subject: [PATCH] Add a refine_search command to InboxMode
This is just a copy of SearchResultsMode's refine_search command.
A much cleaner, but more involved, approach would be to rework
InboxMode to derive from SearchResultsMode in the first place.
---
lib/sup/modes/inbox-mode.rb | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/lib/sup/modes/inbox-mode.rb b/lib/sup/modes/inbox-mode.rb
index ba095da..c8072cd 100644
--- a/lib/sup/modes/inbox-mode.rb
+++ b/lib/sup/modes/inbox-mode.rb
@@ -7,6 +7,7 @@ class InboxMode < ThreadIndexMode
## overwrite toggle_archived with archive
k.add :archive, "Archive thread (remove from inbox)", 'a'
k.add :read_and_archive, "Archive thread (remove from inbox) and mark read", 'A'
+ k.add :refine_search, "Refine search", '|'
end
def initialize
@@ -17,6 +18,12 @@ class InboxMode < ThreadIndexMode
def is_relevant? m; (m.labels & [:spam, :deleted, :killed, :inbox]) == Set.new([:inbox]) end
+ def refine_search
+ text = BufferManager.ask :search, "refine query: ", "label:inbox -label:spam -label:deleted -label:killed "
+ return unless text && text !~ /^\s*$/
+ SearchResultsMode.spawn_from_query text
+ end
+
## label-list-mode wants to be able to raise us if the user selects
## the "inbox" label, so we need to keep our singletonness around
def self.instance; @@instance; end
--
1.6.3.3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090826/0ec68a3f/attachment-0001.bin>
------------------------------
Message: 909
Date: Wed, 26 Aug 2009 15:40:34 -0700
From: Carl Worth <cworth@cworth.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] [PATCH] Add 'a' and 'd' keybindings to
thread-view-mode to archive/delete current thread
Message-ID: <1251325542-sup-3105@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
These behave identically to the existing ",a" and ",d" commands, (that
is they archive or delete the current thread and then view the next).
---
I appreciate that within thread-view-mode, sup already supports
explicitly selecting one of three different actions for what do after
the user is done with a thread. And the choice is determined by one of
three different prefix characters. For example:
. -> return to previous buffer (likely something like
inbox-mode/search-result-mode)
, -> advance to next thread (into thread-view-mode)
] -> advance to previous thread (into thread-view-mode)
I'm lazy enough to want a single-character command for efficient
processing of mail in thread-view-mode, (just like I already have
while in inbox-mode and search-results-mode). And for two of the
different actions, (archive and delete), the obvious/consistent
keybinding is available. So this patch assigns those, ('a' as a
shortcut for ',a' and 'd' as a shortcut for ',d').
If I seem too lazy here, and it doesn't seem sane to add these
keybindingd by default, just let me know. In that case I'll consign
myself to just using a hook to setup these keybindings for myself
personally.
The perhaps-not-as-obvious piece is what the exit action should be for
these shortcut commands. For my own use, I've found it best to advance
to the next thread. (This supports a workflow where there's one pass
through the inbox to archive as much as possible without reading, and
then another pass through thread-view-mode for everything that's
left.)
One thing this patch doesn't provide is shortcuts for the other three
exit actions, (',s' for mark-as-spam-then-next, ',N' for
mark-as-unread-then-next, and ',n' for simply advancing to the next
thread without changing the current thread).
Of those, the only one I really care about personally is ',n'. It's
obviously not a simple matter of just making 'n' a shortcut for ',n'
since the 'n' keybinding is already used. But actually, I think I
would like the 'n' keybinding to advance to the next thread once I'm
viewing the last open message in the current thread. This would make
for very efficient sessions of just reading mail, where I'd only need
to keep hitting 'n', (and I could hit 'a' whenever bored with any
particular thread). So perhaps I'll look into coding that up next.
lib/sup/modes/thread-view-mode.rb | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb
index 678b841..0706757 100644
--- a/lib/sup/modes/thread-view-mode.rb
+++ b/lib/sup/modes/thread-view-mode.rb
@@ -64,6 +64,9 @@ EOS
k.add :unsubscribe_from_list, "Subscribe to/unsubscribe from mailing list", ")"
k.add :pipe_message, "Pipe message or attachment to a shell command", '|'
+ k.add :archive_and_next, "Archive this thread, kill buffer, and view next", 'a'
+ k.add :delete_and_next, "Delete this thread, kill buffer, and view next", 'd'
+
k.add_multi "(a)rchive/(d)elete/mark as (s)pam/mark as u(N)read:", '.' do |kk|
kk.add :archive_and_kill, "Archive this thread and kill buffer", 'a'
kk.add :delete_and_kill, "Delete this thread and kill buffer", 'd'
--
1.6.3.3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090826/ac261bb3/attachment-0001.bin>
------------------------------
Message: 910
Date: Wed, 26 Aug 2009 15:47:54 -0700
From: Carl Worth <cworth@cworth.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Should '/' trigger the loading of more messages?
Message-ID: <1251326494-sup-2328@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
It seems to me that the "search in current buffer" command should
automatically trigger the loading of additional messages when no
results are found so that it can continue searching.
What just happened to me is that I *knew* my inbox contained a message
with a particular string in the subject, but I couldn't find it with
'/'. The problem was that enough new threads had arrived that the
message of interest wasn't loaded yet.
The fact that the various ThreadIndexModes don't load all relevant
threads is just an optimization, but I don't think it should change
the semantics of a search operation. (My thread *is* still in my inbox
even if it hasn't been loaded.)
Of course, for the feature I want to work well there needs to be an
easy way to interrupt the searching and loading if it's going on too
long, (say, I mistyped the search string and I know it's likely to
load a million messages without ever finding the string I typed).
Does sup already have a notion like emacs' "C-g" which is used to
cancel or interrupt any ongoing command?
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090826/5445e913/attachment-0001.bin>
------------------------------
Message: 911
Date: Wed, 26 Aug 2009 15:52:38 -0700
From: Carl Worth <cworth@cworth.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] On making inbox-mode and search-results-mode
more similar
Message-ID: <1251327030-sup-7342@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
Excerpts from Carl Worth's message of Wed Aug 26 15:24:36 -0700 2009:
> + text = BufferManager.ask :search, "refine query: ", "label:inbox
> -label:spam -label:deleted -label:killed "
Is that even the right syntax for searching for threads with the inbox
label but excluding threades with the spam, deleted, or killed labels?
I took a guess at the syntax and I thought I saw it working, but it
doesn't appear to be now. Can someone tell me the actual syntax? (Or
better, is there a writeup somewhere of the general search syntax
accepted by sup?)
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090826/c0c5ef5d/attachment-0001.bin>
------------------------------
Message: 912
Date: Thu, 27 Aug 2009 04:37:57 +0200
From: Ingmar Vanhassel <ingmar@exherbo.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Should '/' trigger the loading of more
messages?
Message-ID: <1251340454-sup-3773@cannonball>
Content-Type: text/plain; charset=UTF-8
Excerpts from Carl Worth's message of Thu Aug 27 00:47:54 +0200 2009:
> It seems to me that the "search in current buffer" command should
> automatically trigger the loading of additional messages when no
> results are found so that it can continue searching.
I'd expect a "search in current buffer" to do exactly that, no more no
less.
> What just happened to me is that I *knew* my inbox contained a message
> with a particular string in the subject, but I couldn't find it with
> '/'. The problem was that enough new threads had arrived that the
> message of interest wasn't loaded yet.
If you know it's in your inbox, why not search with '\', for
'label:inbox foo'?
> The fact that the various ThreadIndexModes don't load all relevant
> threads is just an optimization, but I don't think it should change
> the semantics of a search operation. (My thread *is* still in my inbox
> even if it hasn't been loaded.)
>
> Of course, for the feature I want to work well there needs to be an
> easy way to interrupt the searching and loading if it's going on too
> long, (say, I mistyped the search string and I know it's likely to
> load a million messages without ever finding the string I typed).
>
> Does sup already have a notion like emacs' "C-g" which is used to
> cancel or interrupt any ongoing command?
Try C-g. :-)
(Documented as ^G on the help page)
> -Carl
--
Exherbo KDE, X.org maintainer
------------------------------
Message: 913
Date: Thu, 27 Aug 2009 04:54:36 +0200
From: Ingmar Vanhassel <ingmar@exherbo.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH 2/2] ui responsiveness tweaks
Message-ID: <1251341498-sup-428@cannonball>
Content-Type: text/plain; charset=UTF-8
Excerpts from Carl Worth's message of Wed Aug 26 23:15:36 +0200 2009:
> My message here really has nothing to do with Rich's patches
> specifically, (so sorry about that), but his patches happened to
> provide the perfect context for an issue I wanted to bring up. As is
> typical of git-formatted patches, Rich's emails have subject lines
> from his commit messages:
>
> [sup-talk] [PATCH 1/2] preemptively load messages when scrolling
> [sup-talk] [PATCH 2/2] ui responsiveness tweaks
>
> As far as the git commits go, this subject line is one of the most
> essential pieces of metadata to accompany the patch. Yet by default
> sup doesn't display it at all, (requiring keypresses to display the
> header and find the subject line). I think what I would like is for
> sup to display the subject line everytime it changes significantly in
> a thread, (specifically not regarding things like an initial "Re: "
> getting added as significant).
>
> I think I'd be willing to spend an entire line's worth of screen real
> estate for this information---it's quite useful when people do
> meaningful subject changes for sub-threads.
Yeah, I completely agree. That would make sup even better for me.
Maybe this could be implemented as a 3-way toggle, toggling between
- don't show subjects (current default?)
- only show interesting subject changes
- always show subject
in a threadview.
-Ingmar
--
Exherbo KDE, X.org maintainer
------------------------------
Message: 914
Date: Thu, 27 Aug 2009 02:50:29 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] On making inbox-mode and search-results-mode
more similar
Message-ID: <1251341286-sup-9400@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from Carl Worth's message of Wed Aug 26 18:24:36 -0400 2009:
> So what I want is for anytime a message is changed such that it no
> longer meets the current search criteria, it is immediately removed
> from the search results. I think that means simply implementing the
> is_relevant? method for SearcResultsMode where there is currently just
> the following comment:
>
> ## a proper is_relevant? method requires some way of asking ferret
> ## if an in-memory object satisfies a query. i'm not sure how to do
> ## that yet. in the worst case i can make an in-memory index, add
> ## the message, and search against it to see if i have > 0 results,
> ## but that seems pretty insane.
>
> That single-message index and search sounds exactly like what I want,
> and not insane at all. Has someone attempted this and found a
> performance issue? (In which case, I would think we just need to fix
> that performance bug.) Or is it simply a matter of nobody having tried
> to code this up yet? (In which case, I'll try, and I'll be glad for
> any pointers that anyone can give me on how to go about creating an
> in-memory index and searching on it.)
We had a thread a while back about applying label changes immediately
and I think the consensus was that that's a good idea. Doing this could
simplify a great deal of thread-index-mode code because a fast
is_relevant? could be implemented using existing index operations
without the special cases for archiving/etc and without creating an
inmemory database. I have a patch I plan to mail out soon that makes
changing labels with Xapian much quicker, so that should help. It'd be
great if you decide to tackle this.
------------------------------
Message: 915
Date: Thu, 27 Aug 2009 10:05:13 +0100
From: Marcus Williams <marcus-sup@bar-coded.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Should '/' trigger the loading of more
messages?
Message-ID: <1251363903-sup-2197@bar-coded.net>
Content-Type: text/plain; charset=UTF-8
On 27.8.2009, Ingmar Vanhassel wrote:
> > What just happened to me is that I *knew* my inbox contained a message
> > with a particular string in the subject, but I couldn't find it with
> > '/'. The problem was that enough new threads had arrived that the
> > message of interest wasn't loaded yet.
>
> If you know it's in your inbox, why not search with '\', for
> 'label:inbox foo'?
... coupled with '!!' to load all threads in the search (ctrl-g works
to stop search) this would do what you want.
HTH
Marcus
------------------------------
Message: 916
Date: Thu, 27 Aug 2009 05:17:12 -0700
From: Carl Worth <cworth@cworth.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Should '/' trigger the loading of more
messages?
Message-ID: <1251375048-sup-403@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
Excerpts from Ingmar Vanhassel's message of Wed Aug 26 19:37:57 -0700 2009:
> Excerpts from Carl Worth's message of Thu Aug 27 00:47:54 +0200 2009:
> > It seems to me that the "search in current buffer" command should
> > automatically trigger the loading of additional messages when no
> > results are found so that it can continue searching.
>
> I'd expect a "search in current buffer" to do exactly that, no more no
> less.
You obviously know well what the current buffer is doing,
(incrementally loading threads only as you page down to them). But I
don't think it's reasonable to expect all users to understand things
that well in order to use sup correctly.
Imagine the near future where we get the thread-loading performance
bugs all worked out, (see nearby threads making good progress). If a
user starts sup and sees a screenful of threads instantly, hits page
down a couple of times and sees another couple of screensful
instantly, then wouldn't it be reasonable for such a user to expect
that all of that instantly-appearing content does exist in the current
buffer?
> If you know it's in your inbox, why not search with '\', for
> 'label:inbox foo'?
I'm searching locally, because I already performed a global search and
don't want to repeat the terms of it. Or else why does sup have a
local search command independent of the global search?
> Try C-g. :-)
> (Documented as ^G on the help page)
Ah, thanks. Now this one was just me being stupid. (I think I was
already using this in sup naturally.)
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090827/cb5aaa58/attachment-0001.bin>
------------------------------
Message: 917
Date: Thu, 27 Aug 2009 14:18:53 +0200
From: Guillaume Quintard <guillaume.quintard@gmail.com>
To: "Sup-talk@rubyforge.org" <sup-talk@rubyforge.org>
Subject: [sup-talk] Nobody told me
Message-ID:
<1e5fdab70908270518k3f349191jb5e780e0e0555461@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Playing the dumb newbie here, but when did that happened?
./lib/sup/xapian_index.rb:32:in `load_index': This Sup version expects
a v1 index, but you have an existing v0 index. Please downgrade to
your previous version and dump your labels before upgrading to this
version (then run sup-sync --restore). (RuntimeError)
from ./lib/sup/index.rb:67:in `load'
from bin/sup-sync:117
--
Guillaume
------------------------------
Message: 918
Date: Thu, 27 Aug 2009 11:36:28 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Ignore killed messages in U screen
Message-ID: <1251387376-sup-7180@javelin>
Content-Type: text/plain; charset=UTF-8
>From e01820e5914c4fb8deb5836473aa37553e5a6234 Mon Sep 17 00:00:00 2001
From: Edward Z. Yang <ezyang@mit.edu>
Date: Wed, 26 Aug 2009 10:45:26 -0400
Subject: [PATCH] Do not display killed messages in unread screen.
Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
---
bin/sup | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/bin/sup b/bin/sup
index bbb6c17..645a9a1 100755
--- a/bin/sup
+++ b/bin/sup
@@ -263,7 +263,7 @@ begin
next unless query && query !~ /^\s*$/
SearchResultsMode.spawn_from_query query
when :search_unread
- SearchResultsMode.spawn_from_query "is:unread"
+ SearchResultsMode.spawn_from_query "is:unread !label:killed"
when :list_labels
labels = LabelManager.all_labels.map { |l| LabelManager.string_for l }
user_label = bm.ask_with_completions :label, "Show threads with label (enter for listing): ", labels
--
1.6.4
------------------------------
Message: 919
Date: Thu, 27 Aug 2009 11:50:08 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Ignore killed messages in U screen
Message-ID: <1251388133-sup-2253@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Edward Z. Yang's message of Thu Aug 27 11:36:28 -0400 2009:
> Subject: [PATCH] Do not display killed messages in unread screen.
+1 for this.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090827/95eba3ab/attachment-0001.bin>
------------------------------
Message: 920
Date: Thu, 27 Aug 2009 11:56:32 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Ignore killed messages in U screen
Message-ID: <1251388546-sup-7744@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from Edward Z. Yang's message of Thu Aug 27 11:36:28 -0400 2009:
> - SearchResultsMode.spawn_from_query "is:unread"
> + SearchResultsMode.spawn_from_query "is:unread !label:killed"
I might have one legitimate objection to this patch, which is
that searches should ignore killed tags unless explicitly told
not to.
Cheers,
Edward
------------------------------
Message: 921
Date: Thu, 27 Aug 2009 15:44:02 -0400
From: Joe Shaw <joe@joeshaw.org>
To: sup-talk@rubyforge.org
Subject: [sup-talk] sent and draft sources
Message-ID:
<f8203010908271244p1d296d9dw3d2d989b6d48a2ee@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi,
I'd like to use existing maildir folders I have for Sup's sent and
draft folders, but I couldn't find a way how. Is this possible? I am
surprised this is not a FAQ. :)
Apologies for the total noob question. I'm liking what I see in Sup so far.
Thanks,
Joe
------------------------------
Message: 922
Date: Thu, 27 Aug 2009 15:49:17 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sent and draft sources
Message-ID: <1251402318-sup-4655@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Joe Shaw's message of Thu Aug 27 15:44:02 -0400 2009:
> I'd like to use existing maildir folders I have for Sup's sent and
> draft folders, but I couldn't find a way how. Is this possible? I am
> surprised this is not a FAQ. :)
For sent, yes. For drafts, not yet. Using sup-config you can select
the sent source, or you could edit config.yaml by hand. The line in
my config is this:
:sent_source: maildir:///u/bwalton/Maildir/.sent-mail/
I defined a source with that URI and then set the value in
config.yaml. My outbound mail is then stored in that Maildir folder.
Only some sources work for mail storage. These are mbox, Maildir and
IMAP. I'd advise against having anything else write to the same mbox
(eg: don't have new mail delivered to the same source) if you go with
an mbox URI.
I'm not sure whether the official release includes this functionality
yet or not as I run from git:next. I _think_ 0.8.1 included it, but
would have to actually check.
HTH
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090827/f78fafa2/attachment-0001.bin>
------------------------------
Message: 923
Date: Thu, 27 Aug 2009 15:58:29 -0400
From: Joe Shaw <joe@joeshaw.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sent and draft sources
Message-ID:
<f8203010908271258m32cbaacfked4ec80969ce3034@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi,
Thanks for the info.
On Thu, Aug 27, 2009 at 3:49 PM, Ben Walton<bwalton@artsci.utoronto.ca> wrote:
> I'm not sure whether the official release includes this functionality
> yet or not as I run from git:next. ?I _think_ 0.8.1 included it, but
> would have to actually check.
It doesn't appear to. At least, setting sup-config didn't give me any
option to, and setting it in my config.yaml didn't seem to work
either.
How safe is building and running from git master? Is there a general
philosophy about its stability? I'm a hacker, but I'm not strong in
Ruby and I am not sure yet that I want to hack on my mailer. ;)
Joe
------------------------------
Message: 924
Date: Thu, 27 Aug 2009 13:03:17 -0700
From: Sean Escriva <sean.escriva@gmail.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] sup crashed: NoMethodError
Message-ID: <20090827200317.GA3065@gmail.com>
Content-Type: text/plain; charset=us-ascii
I broke my sup!
I wanted to play with the git version so I did:
git pull, rake gem, gem install pkg/sup-999.gem
well that broke it all, and I don't know how to fix it.
so far I have tried a gem cleanup, gem uninstall sup, gem install -r
sup, all to no avail. It still always crashes with the following:
--- NoMethodError from thread: main
undefined method `[]' for false:FalseClass
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:107:in `start'
/usr/lib/ruby/gems/1.8/gems/sup-0.8.1/bin/sup:161
/usr/bin/sup:19:in `load'
/usr/bin/sup:19
Any tips on how to fix/figure out what I did wrong are greatly
appreciated!
-sme
------------------------------
Message: 925
Date: Thu, 27 Aug 2009 21:00:53 +0100
From: Adeodato Sim? <dato@net.com.org.es>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] sent and draft sources
Message-ID: <20090827200053.GA17416@chistera.yi.org>
Content-Type: text/plain; charset=us-ascii
+ Ben Walton (Thu, 27 Aug 2009 15:49:17 -0400):
> For sent, yes. For drafts, not yet. Using sup-config you can select
> the sent source, or you could edit config.yaml by hand. The line in
> my config is this:
> :sent_source: maildir:///u/bwalton/Maildir/.sent-mail/
I tried that, but then all messages got tagged "sent", even old ones and
threads in which I didn't participate.
> I'd advise against having anything else write to the same mbox
> (eg: don't have new mail delivered to the same source) if you go with
> an mbox URI.
Why? Would sup not lock the mbox properly?
Thanks,
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
------------------------------
Message: 926
Date: Thu, 27 Aug 2009 19:39:20 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sent and draft sources
Message-ID: <1251416206-sup-4808@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Adeodato Sim?'s message of Thu Aug 27 16:00:53 -0400 2009:
> > I'd advise against having anything else write to the same mbox
> > (eg: don't have new mail delivered to the same source) if you go with
> > an mbox URI.
>
> Why? Would sup not lock the mbox properly?
No, it wouldn't. I've got a half-baked LockManager branch sitting
around, but I haven't touched it for some time now. I don't use any
mbox here myself so it's not a personal itch.
As it stands, the LockManager code has the basic ability to do
locking using three lock types. I haven't worked out the nicest way
to stack them (ala dovecot) though in a way that will play nicely with
threads _and_ allow for non-block-wrapped calling.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090827/28664d43/attachment-0001.bin>
------------------------------
Message: 927
Date: Thu, 27 Aug 2009 20:43:56 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sent and draft sources
Message-ID: <1251420193-sup-4823@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Adeodato Sim?'s message of Thu Aug 27 16:00:53 -0400 2009:
> > :sent_source: maildir:///u/bwalton/Maildir/.sent-mail/
>
> I tried that, but then all messages got tagged "sent", even old ones and
> threads in which I didn't participate.
This is interesting. It might have happened to me too, but since all
of the mail in that folder was historically sent, I either didn't
notice (since it was already archived) or this is a new issue.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090827/312b5433/attachment-0001.bin>
------------------------------
Message: 928
Date: Fri, 28 Aug 2009 14:37:48 +1200
From: Jim Cheetham <jim@gonzul.net>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Encrypted password in configuration file
Message-ID:
<f4cc59760908271937t764e61aeh7f105c7195fec1ce@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Tue, Aug 25, 2009 at 8:54 AM, Lars Kotthoff<lists@larsko.org> wrote:
> Hi list,
>
> ?is it possible to store the account password encrypted in the configuration
> file?
It's possible, but slightly pointless.
Have a read of Eric Raymond's discussions about Fetchmail, which has
the same configuration data :-
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s09.html
"Another lesson is about security by obscurity. Some fetchmail users
asked me to change the software to store passwords encrypted in the rc
file, so snoopers wouldn't be able to casually see them.
I didn't do it, because this doesn't actually add protection. Anyone
who's acquired permissions to read your rc file will be able to run
fetchmail as you anyway?and if it's your password they're after,
they'd be able to rip the necessary decoder out of the fetchmail code
itself to get it.
All .fetchmailrc password encryption would have done is give a false
sense of security to people who don't think very hard. The general
rule here is:
17. A security system is only as secure as its secret. Beware of
pseudo-secrets."
-jim
------------------------------
Message: 929
Date: Fri, 28 Aug 2009 19:07:02 +1200
From: Jim Cheetham <jim@gonzul.net>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Encrypted password in configuration file
Message-ID:
<f4cc59760908280007i3b226f0egd063126476e6ea3d@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Fri, Aug 28, 2009 at 5:25 PM, <wagnerdm@seas.upenn.edu> wrote:
> I can imagine all kinds of situations with "benevolent" attackers. ?For
> example, what about a girlfriend that pokes around your hard drive looking
> for lolcats when she's bored? ?One glance at .fetchmailrc would show it's
> not a lolcat; but that same glance could show a password that you don't
> really want her to know.
It took over 7 years before I would even tell my wife my login
password; I've since changed it and won't share it. And I trust her
implicitly with my machine -- there is nothing on there that I'm not
happy for her to see :-)
So, how does the putative bored girlfriend poke around your hard-drive
in the first place, in this scenario? If you are letting her use your
account and poke around your machine in the first place, how does her
seeing a password cause a problem?
If you don't want someone to know something, don't put them is a
situation where they might find it. You shouldn't expect a program to
employ a pointless encryption/obscuration scheme just because you
don't look after your other data. You are increasing the complexity of
the code, increasing the complexity of the testing environment,
increasing the opportunity for bugs to occur (possibly causing data
loss?), and protecting against nothing.
Now, there is an approach used by mutt that sup doesn't seem to use,
which is to prompt the user at the beginning of a session for the
various source passwords; this way they are only held in memory (and
swap files, probably). That may be a way out of the situation; as a
mail client is inherently an interactive program, there's no harm in
prompting for things missing from the config, I think.
-jim
------------------------------
Message: 930
Date: Fri, 28 Aug 2009 21:28:28 +1200
From: Jim Cheetham <jim@gonzul.net>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Encrypted password in configuration file
Message-ID:
<f4cc59760908280228i47bbd52dy87a5695e3a2361c0@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Fri, Aug 28, 2009 at 7:23 PM, Lars Kotthoff<lars@larsko.org> wrote:
>> It's possible, but slightly pointless.
>
> Not if the user supplies the passphrase, e.g. it could be encrypted with the
> user's GPG key and ask for the passphrase at startup.
Why not just ask for the IMAP password itself? There's no functional
difference between that secret, and the secret that unlocks the secret
... indeed, if sup were to accidentally expose the passphrase you
provided, would you rather lose your GPG key or your IMAP key?
If you are really determined to allow others to read your private
files, why not just encrypt the whole .sup directory with a separate
tool (TrueCrypt, loopback, rot13, encfs, ecryptfs, or whatever else
your distribution provides).
That way, you are also protecting the ferret index collection, and the
default sent box, which all contain data of the same level of
sensitivity as your mailbox. Given your concern, I assume that you
will be remembering to terminate sup and dismount the .sup directory
every time you walk away from the keyboard.
(Many schemes these days encrypt the whole of $HOME, which makes the
whole screensaver/away from the keyboard thing even more difficult).
Security must be appropriate to be actual security. Otherwise it's
just an expensive fa?ade.
-jim
------------------------------
Message: 931
Date: Wed, 26 Aug 2009 19:59:46 +0000
From: Stan Heckman <stan@stanheckman.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] an error occurred in Sup
Message-ID: <1251316321-sup-8091@clover.schedar.com>
Content-Type: text/plain; charset="utf-8"
While setting up sup I received the error below.
I attach the exception-log requested.
I had told sup-config about my existing maildirs. This produced a large inbox.
I attempted to archive all but 15 recent messages from this inbox by loading
all messages with "!!" and archiving them all by holding down the "a" key for
several seconds.
After several minutes of archiving, I received the error below.
[Wed Aug 26 19:38:08 +0000 2009] stopped cursing
[Wed Aug 26 19:38:08 +0000 2009] oh crap, an exception
[Wed Aug 26 19:38:08 +0000 2009] unlocking /home/stan/.sup/lock...
----------------------------------------------------------------
I'm very sorry. It seems that an error occurred in Sup. Please
accept my sincere apologies. If you don't mind, please send the
contents of ~/.sup/exception-log.txt and a brief report of the
circumstances to sup-talk at rubyforge dot orgs so that I might
address this problem. Thank you!
Sincerely,
William
----------------------------------------------------------------
--- NoMethodError from thread: periodic poll
undefined method `+' for nil:NilClass
/home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/maildir.rb:141:in `end_offset'
/home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/source.rb:87:in `done?'
/home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:552:in `send'
/home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:552:in `__pass'
/home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:539:in `method_missing'
/usr/lib/ruby/1.8/sup/poll.rb:89:in `do_poll'
/usr/lib/ruby/1.8/sup/poll.rb:86:in `each'
/usr/lib/ruby/1.8/sup/poll.rb:86:in `do_poll'
/usr/lib/ruby/1.8/sup/poll.rb:85:in `synchronize'
/usr/lib/ruby/1.8/sup/poll.rb:85:in `do_poll'
/home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:513:in `send'
/home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:513:in `method_missing'
/usr/lib/ruby/1.8/sup/modes/poll-mode.rb:17:in `poll'
/usr/lib/ruby/1.8/sup/poll.rb:53:in `poll'
/usr/lib/ruby/1.8/sup/poll.rb:70:in `start'
/home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup.rb:71:in `reporting_thread'
/home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup.rb:69:in `initialize'
/home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup.rb:69:in `new'
/home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup.rb:69:in `reporting_thread'
/usr/lib/ruby/1.8/sup/poll.rb:67:in `start'
/home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:513:in `send'
/home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:513:in `method_missing'
/home/stan/.gem/ruby/1.8/gems/sup-0.8.1/bin/sup:213
/home/stan/.gem/ruby/1.8/bin/sup:19:in `load'
/home/stan/.gem/ruby/1.8/bin/sup:19
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: exception-log.txt
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090826/6de40820/attachment-0001.txt>
------------------------------
Message: 932
Date: Fri, 28 Aug 2009 08:23:49 +0100
From: Lars Kotthoff <lars@larsko.org>
To: Jim Cheetham <jim@gonzul.net>
Cc: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Encrypted password in configuration file
Message-ID: <20090828082349.61bfc91b@ronin.larsko.net>
Content-Type: text/plain; charset=US-ASCII
> It's possible, but slightly pointless.
Not if the user supplies the passphrase, e.g. it could be encrypted with the
user's GPG key and ask for the passphrase at startup.
Lars
------------------------------
Message: 933
Date: Fri, 28 Aug 2009 13:29:03 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Encrypted password in configuration file
Message-ID: <1251491240-sup-1148@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Lars Kotthoff's message of 2009-08-24:
> is it possible to store the account password encrypted in the
> configuration file?
Despite generally agreeing with Jim's argument, I'm happy to accept a
patch to do this.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 934
Date: Fri, 28 Aug 2009 13:31:26 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sent and draft sources
Message-ID: <1251491386-sup-7354@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Joe Shaw's message of 2009-08-27:
> How safe is building and running from git master?
Pretty safe. I merge all changes into next first, which is where people
see breakage, and only merge them into master when they've baked long
enough.
> Is there a general philosophy about its stability?
"Stability is good". :)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 935
Date: Fri, 28 Aug 2009 13:35:06 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sent and draft sources
Message-ID: <1251491567-sup-2126@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Adeodato Sim?'s message of 2009-08-27:
> Why? Would sup not lock the mbox properly?
Sup doesn't lock the sent mbox currently. It wouldn't be too hard to
add. I'm still waiting for Ben to provide a nice refactoring patch for
me. :)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 936
Date: Fri, 28 Aug 2009 13:37:12 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Nobody told me
Message-ID: <1251491725-sup-284@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Guillaume Quintard's message of 2009-08-27:
> Playing the dumb newbie here, but when did that happened?
If anyone else has this problem (and anyone who's running next with the
Xapian index will): after the dump and before sup-sync, I believe you
need to remove your ~/.sup/xapian directory and ~/.sup/*.db. Life on the
bleeding edge!
> ./lib/sup/xapian_index.rb:32:in `load_index': This Sup version expects
> a v1 index, but you have an existing v0 index. Please downgrade to
> your previous version and dump your labels before upgrading to this
> version (then run sup-sync --restore). (RuntimeError)
> from ./lib/sup/index.rb:67:in `load'
> from bin/sup-sync:117
>
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 937
Date: Fri, 28 Aug 2009 13:38:59 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] an error occurred in Sup
Message-ID: <1251491856-sup-4902@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Stan Heckman's message of 2009-08-26:
> I had told sup-config about my existing maildirs. This produced a
> large inbox. I attempted to archive all but 15 recent messages from
> this inbox by loading all messages with "!!" and archiving them all by
> holding down the "a" key for several seconds.
Definitely the slow an painful way to do this, and also the way to
trigger one of the display threading heisenbugs.
I recommend instead using sup-tweak-labels, or starting over and using
--archive when you sup-add the source (and then just adding the inbox
label back to the first 15).
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 938
Date: Fri, 28 Aug 2009 13:41:41 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup crashed: NoMethodError
Message-ID: <1251492008-sup-6128@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Sean Escriva's message of 2009-08-27:
> so far I have tried a gem cleanup, gem uninstall sup, gem install -r
> sup, all to no avail. It still always crashes with the following:
>
> --- NoMethodError from thread: main
> undefined method `[]' for false:FalseClass
> /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:107:in `start'
> /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/bin/sup:161
> /usr/bin/sup:19:in `load'
> /usr/bin/sup:19
>
> Any tips on how to fix/figure out what I did wrong are greatly
> appreciated!
Hm, is your ~/.sup/config.yaml file empty for some reason? If so, delete
it and retry, and I will add some code to catch this case.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 939
Date: Fri, 28 Aug 2009 23:01:04 +0200
From: Guillaume Quintard <guillaume.quintard@gmail.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Nobody told me
Message-ID:
<1e5fdab70908281401k7f0b59ectb38ce7dfe7280569@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Fri, Aug 28, 2009 at 10:37 PM, William
Morgan<wmorgan-sup@masanjin.net> wrote:
arg, when I try to restore, I get this:
./lib/sup/crypto.rb:157:in ``': Cannot allocate memory - /usr/bin/gpg
--quiet --batch --no-verbose --logger-fd 1 --use-agent --verify
/tmp/31666-0-redwood.signature /tmp/31666-0-redwood.payload 2>
/dev/null (Errno::ENOMEM)
from ./lib/sup/crypto.rb:157:in `run_gpg'
from ./lib/sup/crypto.rb:92:in `verify'
from ./lib/sup/util.rb:520:in `send'
from ./lib/sup/util.rb:520:in `method_missing'
from ./lib/sup/message.rb:385:in `multipart_signed_to_chunks'
from ./lib/sup/message.rb:421:in `message_to_chunks'
from ./lib/sup/message.rb:236:in `load_from_source!'
from ./lib/sup/message.rb:332:in `build_from_source'
from ./lib/sup/poll.rb:153:in `each_message_from'
from ./lib/sup/source.rb:104:in `each'
from ./lib/sup/util.rb:560:in `send'
from ./lib/sup/util.rb:560:in `__pass'
from ./lib/sup/util.rb:547:in `method_missing'
from ./lib/sup/poll.rb:147:in `each_message_from'
from ./lib/sup/util.rb:520:in `send'
from ./lib/sup/util.rb:520:in `method_missing'
from bin/sup-sync:146
from bin/sup-sync:141:in `each'
from bin/sup-sync:141
is it leaking, or is my huge mbox just too big for it?
cheers
--
Guillaume
------------------------------
Message: 940
Date: Fri, 28 Aug 2009 15:50:41 -0700
From: Sean Escriva <sean.escriva@gmail.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup crashed: NoMethodError
Message-ID: <20090828225041.GA22963@gmail.com>
Content-Type: text/plain; charset=us-ascii
On Fri, Aug 28, 2009 at 01:41:41PM -0700, William Morgan wrote:
> Reformatted excerpts from Sean Escriva's message of 2009-08-27:
> > so far I have tried a gem cleanup, gem uninstall sup, gem install -r
> > sup, all to no avail. It still always crashes with the following:
> >
> > --- NoMethodError from thread: main
> > undefined method `[]' for false:FalseClass
> > /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:107:in `start'
> > /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/bin/sup:161
> > /usr/bin/sup:19:in `load'
> > /usr/bin/sup:19
> >
> > Any tips on how to fix/figure out what I did wrong are greatly
> > appreciated!
>
> Hm, is your ~/.sup/config.yaml file empty for some reason? If so, delete
> it and retry, and I will add some code to catch this case.
That may have been it. I just clobbered my whole setup and started
over, now it's working Although now I'm using the gem and not the git
next branch. I don't want to loose my 8K+ message index again.
was my install process wrong for switching to the git -next branch?
-sme
ps: i'll consider switching fully to sup as soon as I figure out how to manage
multiple email accounts :)
------------------------------
Message: 941
Date: Fri, 28 Aug 2009 18:48:59 -0400
From: Mike Kelly <pioto@pioto.org>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Encrypted password in configuration file
Message-ID: <20090828184859.59b7f825@aether.home.pioto.org>
Content-Type: text/plain; charset=US-ASCII
On Mon, 24 Aug 2009 21:54:35 +0100
Lars Kotthoff <lists@larsko.org> wrote:
> is it possible to store the account password encrypted in the
> configuration file?
Along the lines of what Jim said, doing any sort of two-way encryption
on the password is a wasted effort. There are other sort of
authentication mechanisms which are probably more appropriate
(certificate-based, Kerberos/GSSAPI, ...).
--
Mike Kelly
------------------------------
Message: 942
Date: Sat, 29 Aug 2009 11:18:52 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] Crash while syncing
Message-ID:
<cd67f63a0908290218g30a737a9pd46d902cdf5399bb@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hello,
While doing a from scratch sup-sync to benefit for the new version of
the xapian index, sup-sync
crashed like this:
/usr/lib/ruby/site_ruby/1.8/xapian.rb:240:in `doclength':
DocNotFoundError: Document 3318104838 not found (RuntimeError)
from /usr/lib/ruby/site_ruby/1.8/xapian.rb:240:in `postlist'
from /usr/lib/ruby/site_ruby/1.8/xapian.rb:60:in `_safelyIterate'
from /usr/lib/ruby/site_ruby/1.8/xapian.rb:238:in `postlist'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:365:in
`term_docids'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:369:in
`find_docid'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:373:in
`find_doc'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:469:in
`index_message'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:469:in
`map'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:469:in
`index_message'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:118:in
`sync_message'
from /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:392:in
`synchronize'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:117:in
`sync_message'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:87:in
`add_message'
from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:202
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:152:in
`each_message_from'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/source.rb:104:in `each'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:560:in `send'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:560:in `__pass'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:547:in
`method_missing'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:140:in
`each_message_from'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:520:in
`method_missing'
from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:146
from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:141:in `each'
from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:141
from /usr/bin/sup-sync:19:in `load'
from /usr/bin/sup-sync:19
The last status message was:
## read 9996m (about 30%) @ 11.1m/s. 0:15:03 elapsed, about 0:35:00 remaining
And it was processing a 500MB mbox.
I would like to know what are my options from here?
Best regards,
--
Nicolas Pouillard aka Ertai
------------------------------
Message: 943
Date: Sat, 29 Aug 2009 14:03:04 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Crash while syncing
Message-ID:
<cd67f63a0908290503g37ab5575ibb6162d06f7528af@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Sat, Aug 29, 2009 at 11:18 AM, Nicolas
Pouillard<nicolas.pouillard@gmail.com> wrote:
> Hello,
>
> While doing a from scratch sup-sync to benefit for the new version of
> the xapian index, sup-sync
> crashed like this:
>
I've lauched sup-sync on another bunch of mboxes and got this crash at the end:
Deleting missing messages from the index...
/usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:17:in `id': wrong id
called on nil (RuntimeError)
from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:237
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/index.rb:150:in
`each_message'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:141:in
`each_id'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:141:in
`each'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:141:in
`each_id'
from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/index.rb:149:in
`each_message'
from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:235
from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:233:in `each'
from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:233
from /usr/bin/sup-sync:19:in `load'
from /usr/bin/sup-sync:19
--
Nicolas Pouillard aka Ertai
------------------------------
Message: 944
Date: Sat, 29 Aug 2009 12:25:33 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash while syncing
Message-ID: <1251563082-sup-3525@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from Nicolas Pouillard's message of Sat Aug 29 08:03:04 -0400 2009:
> On Sat, Aug 29, 2009 at 11:18 AM, Nicolas
> Pouillard<nicolas.pouillard@gmail.com> wrote:
> > Hello,
> >
> > While doing a from scratch sup-sync to benefit for the new version of
> > the xapian index, sup-sync
> > crashed like this:
> >
>
> I've lauched sup-sync on another bunch of mboxes and got this crash at the end:
>
> Deleting missing messages from the index...
> /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:17:in `id': wrong id
> called on nil (RuntimeError)
> from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:237
> from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/index.rb:150:in
> `each_message'
> from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:141:in
> `each_id'
> from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:141:in
> `each'
> from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:141:in
> `each_id'
> from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/index.rb:149:in
> `each_message'
> from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:235
> from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:233:in `each'
> from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:233
> from /usr/bin/sup-sync:19:in `load'
> from /usr/bin/sup-sync:19
>
Are you using the Flint or Chert Xapian backend?
------------------------------
Message: 945
Date: Sat, 29 Aug 2009 18:45:29 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: Rich Lane <rlane@club.cc.cmu.edu>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash while syncing
Message-ID:
<cd67f63a0908290945j2007c75cyc56ab6c1dcfdbbb1@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Sat, Aug 29, 2009 at 6:25 PM, Rich Lane<rlane@club.cc.cmu.edu> wrote:
> Excerpts from Nicolas Pouillard's message of Sat Aug 29 08:03:04 -0400 2009:
>> On Sat, Aug 29, 2009 at 11:18 AM, Nicolas Pouillard<nicolas.pouillard@gmail.com> wrote:
>> > Hello,
>> >
>> > While doing a from scratch sup-sync to benefit for the new version of
>> > the xapian index, sup-sync
>> > crashed like this:
>> >
[...]
> Are you using the Flint or Chert Xapian backend?
The Chert one.
--
Nicolas Pouillard aka Ertai
------------------------------
Message: 946
Date: Sat, 29 Aug 2009 12:59:59 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: Nicolas Pouillard <nicolas.pouillard@gmail.com>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash while syncing
Message-ID: <1251564961-sup-5855@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from Nicolas Pouillard's message of Sat Aug 29 12:45:29 -0400 2009:
> > Are you using the Flint or Chert Xapian backend?
>
> The Chert one.
Could you try it with Flint? I've seen this (nondeterministic) bug when
using Chert.
------------------------------
Message: 947
Date: Sat, 29 Aug 2009 19:05:33 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: Rich Lane <rlane@club.cc.cmu.edu>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash while syncing
Message-ID:
<cd67f63a0908291005m5a53b2cei71bfa48e4bc1d658@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Sat, Aug 29, 2009 at 6:59 PM, Rich Lane<rlane@club.cc.cmu.edu> wrote:
> Excerpts from Nicolas Pouillard's message of Sat Aug 29 12:45:29 -0400 2009:
>> > Are you using the Flint or Chert Xapian backend?
>>
>> The Chert one.
>
> Could you try it with Flint? I've seen this (nondeterministic) bug when
> using Chert.
I was currently running it again with no problems so far.
Are the nondeterministic bugs only during sync?
Chert is supposed to faster?
Thanks for your help,
--
Nicolas Pouillard
------------------------------
Message: 948
Date: Sat, 29 Aug 2009 14:35:03 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: Sup Mailing List <sup-talk@rubyforge.org>
Subject: [sup-talk] exception while importing to xapian
Message-ID: <1251570765-sup-4265@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
I just tried again to switch to xapian and I got the following:
$ SUP_INDEX=xapian ruby -Ilib bin/sup-sync --all --all-sources --restore ~/.sup/dumpfile
Loading state dump from /cquest/roger/staff0/systems/bwalton/.sup/dumpfile...
Read 72360 entries from dump file.
Scanning maildir:///u/bwalton/Maildir/...
[Sat Aug 29 14:29:11 -0400 2009] hook: read 'before-add-message' from
/cquest/roger/staff0/systems/bwalton/.sup/hooks/before-add-message.rb
./lib/sup/xapian_index.rb:365:in `find_docid': undefined method `tap'
for []:Array (NoMethodError)
from ./lib/sup/xapian_index.rb:369:in `find_doc'
from ./lib/sup/xapian_index.rb:379:in `get_entry'
from ./lib/sup/xapian_index.rb:68:in `build_message'
from /usr/lib/ruby/1.8/monitor.rb:238:in `synchronize'
from ./lib/sup/xapian_index.rb:388:in `synchronize'
from ./lib/sup/xapian_index.rb:68:in `build_message'
from bin/sup-sync:149
from ./lib/sup/poll.rb:160:in `each_message_from'
... 8 levels...
from ./lib/sup/util.rb:520:in `method_missing'
from bin/sup-sync:146
from bin/sup-sync:141:in `each'
from bin/sup-sync:141
This happened with 806a067 (the current tip of next). Exception log
attached.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: sup-exception-log.txt
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090829/c6d25c82/attachment-0001.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090829/c6d25c82/attachment-0001.bin>
------------------------------
Message: 949
Date: Sat, 29 Aug 2009 20:22:15 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: Nicolas Pouillard <nicolas.pouillard@gmail.com>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash while syncing
Message-ID: <1251565999-sup-7892@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from Nicolas Pouillard's message of Sat Aug 29 13:05:33 -0400 2009:
> Are the nondeterministic bugs only during sync?
I've only seen it during sup-sync, but I'd guess if you ran sup long
enough you'd see it there too (after changing labels / polling).
> Chert is supposed to faster?
Yes, and more space efficient.
------------------------------
Message: 950
Date: Sun, 30 Aug 2009 15:14:56 -0500
From: Blake Burkhart <bburky@bburky.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] exception while importing to xapian
Message-ID: <1251662840-sup-4363@Backspace.local>
Content-Type: text/plain; charset=UTF-8
Excerpts from Ben Walton's message of Sat Aug 29 13:35:03 -0500 2009:
>
> I just tried again to switch to xapian and I got the following:
>
> $ SUP_INDEX=xapian ruby -Ilib bin/sup-sync --all --all-sources --restore
> ~/.sup/dumpfile
> Loading state dump from /cquest/roger/staff0/systems/bwalton/.sup/dumpfile...
> Read 72360 entries from dump file.
> Scanning maildir:///u/bwalton/Maildir/...
> [Sat Aug 29 14:29:11 -0400 2009] hook: read 'before-add-message' from
> /cquest/roger/staff0/systems/bwalton/.sup/hooks/before-add-message.rb
> ./lib/sup/xapian_index.rb:365:in `find_docid': undefined method `tap'
> for []:Array (NoMethodError)
>
> [...]
>
I am getting this same error myself. I'm running Mac OS 10.5 with ruby 1.8.6.
Are you also using ruby 1.8.6? I think the tap method is in ruby 1.8.7 and
later. Actually a quick google shows it may even be ruby 1.9 only, or 1.9 and
backported from there.
Is it necessary to use this method? Is there an alternate way to do this?
-- Blake Burkhart
------------------------------
Message: 951
Date: Sun, 30 Aug 2009 16:21:30 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] exception while importing to xapian
Message-ID: <1251663644-sup-5538@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Blake Burkhart's message of Sun Aug 30 16:14:56 -0400 2009:
> I am getting this same error myself. I'm running Mac OS 10.5 with ruby 1.8.6.
> Are you also using ruby 1.8.6? I think the tap method is in ruby 1.8.7 and
> later. Actually a quick google shows it may even be ruby 1.9 only, or 1.9 and
> backported from there.
Actually, I'm on 1.8.5 (the version shipped with rhel5). Sup may
finally force me to update it though.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090830/fa051bea/attachment-0001.bin>
------------------------------
Message: 952
Date: Sun, 30 Aug 2009 13:28:55 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH] remove use of Object#tap
Message-ID: <1251664135-1383-1-git-send-email-rlane@club.cc.cmu.edu>
---
lib/sup/xapian_index.rb | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
index c260728..1395601 100644
--- a/lib/sup/xapian_index.rb
+++ b/lib/sup/xapian_index.rb
@@ -362,7 +362,9 @@ class XapianIndex < BaseIndex
end
def find_docid id
- term_docids(mkterm(:msgid,id)).tap { |x| fail unless x.size <= 1 }.first
+ docids = term_docids(mkterm(:msgid,id))
+ fail unless docids.size <= 1
+ docids.first
end
def find_doc id
--
1.6.0.4
------------------------------
Message: 953
Date: Sun, 30 Aug 2009 15:45:48 -0500
From: Blake Burkhart <bburky@bburky.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] remove use of Object#tap
Message-ID: <1251664798-sup-8169@Backspace.local>
Content-Type: text/plain; charset=UTF-8
Excerpts from Rich Lane's message of Sun Aug 30 15:28:55 -0500 2009:
> ---
> lib/sup/xapian_index.rb | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
> index c260728..1395601 100644
> --- a/lib/sup/xapian_index.rb
> +++ b/lib/sup/xapian_index.rb
> @@ -362,7 +362,9 @@ class XapianIndex < BaseIndex
> end
>
> def find_docid id
> - term_docids(mkterm(:msgid,id)).tap { |x| fail unless x.size <= 1 }.first
> + docids = term_docids(mkterm(:msgid,id))
> + fail unless docids.size <= 1
> + docids.first
> end
>
> def find_doc id
After applying this on next in hopes it lets me run sup on ruby 1.8.6, it
doesn't work.
It crashed with this log:
$ SUP_INDEX=xapian ruby -Ilib bin/sup-sync --all --all-sources --restore ~/dumpfile
Loading state dump from /Users/blake/dumpfile...
Read 6790 entries from dump file.
Scanning maildir:/Users/blake/Mail/bburky/INBOX...
[Sun Aug 30 15:38:57 -0500 2009] hook: read 'before-add-message' from /Users/blake/.sup/hooks/before-add-message.rb
[Sun Aug 30 15:38:57 -0500 2009] hook[before-add-message]: Marking message 1234774373-sup-1128@zo as suptalk, subject is 'Re: [sup-talk] (no subject)'
./lib/sup/label.rb:64:in `<<': expecting a symbol (ArgumentError)
from ./lib/sup/util.rb:520:in `send'
from ./lib/sup/util.rb:520:in `method_missing'
from ./lib/sup/xapian_index.rb:114:in `sync_message'
from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/set.rb:189:in `each'
from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/set.rb:189:in `each_key'
from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/set.rb:189:in `each'
from ./lib/sup/xapian_index.rb:114:in `sync_message'
from ./lib/sup/xapian_index.rb:87:in `add_message'
... 10 levels...
from ./lib/sup/util.rb:520:in `method_missing'
from bin/sup-sync:146
from bin/sup-sync:141:in `each'
from bin/sup-sync:141
However, I'm having other odd problems too with labels anyway. On the ferret
version of sup, I'm not able to apply labels with the 'l' command. However, I
have a hook for applying a label from the List-ID that does still work. So
this patch may or may not work, I think I'm possibly having problems of my
own.
Actually, I haven't tried to restore from a dumpfile for ferret. I'll do that
later and see if it works.
-- Blake Burkhart
------------------------------
Message: 954
Date: Sun, 30 Aug 2009 16:47:59 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: Blake Burkhart <bburky@bburky.com>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] exception while importing to xapian
Message-ID: <1251664201-sup-9803@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from Blake Burkhart's message of Sun Aug 30 16:14:56 -0400 2009:
> I am getting this same error myself. I'm running Mac OS 10.5 with ruby 1.8.6.
> Are you also using ruby 1.8.6? I think the tap method is in ruby 1.8.7 and
> later. Actually a quick google shows it may even be ruby 1.9 only, or 1.9 and
> backported from there.
>
> Is it necessary to use this method? Is there an alternate way to do this?
Yeah, this was just a 1.8.7-ism. I've sent a patch to fix it.
------------------------------
Message: 955
Date: Sun, 30 Aug 2009 16:50:09 -0500
From: Blake Burkhart <bburky@bburky.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] remove use of Object#tap
Message-ID: <1251668806-sup-7253@Backspace.local>
Content-Type: text/plain; charset=UTF-8
Excerpts from Blake Burkhart's message of Sun Aug 30 15:45:48 -0500 2009:
> After applying this on next in hopes it lets me run sup on ruby 1.8.6, it
> doesn't work.
>
> It crashed with this log:
> $ SUP_INDEX=xapian ruby -Ilib bin/sup-sync --all --all-sources --restore
> ~/dumpfile
> Loading state dump from /Users/blake/dumpfile...
> Read 6790 entries from dump file.
> Scanning maildir:/Users/blake/Mail/bburky/INBOX...
> [Sun Aug 30 15:38:57 -0500 2009] hook: read 'before-add-message' from
> /Users/blake/.sup/hooks/before-add-message.rb
> [Sun Aug 30 15:38:57 -0500 2009] hook[before-add-message]: Marking message
> 1234774373-sup-1128@zo as suptalk, subject is 'Re: [sup-talk] (no subject)'
> ./lib/sup/label.rb:64:in `<<': expecting a symbol (ArgumentError)
> from ./lib/sup/util.rb:520:in `send'
> from ./lib/sup/util.rb:520:in `method_missing'
> from ./lib/sup/xapian_index.rb:114:in `sync_message'
> from
> /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/set.rb:1
> 89:in `each'
> from
> /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/set.rb:1
> 89:in `each_key'
> from
> /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/set.rb:1
> 89:in `each'
> from ./lib/sup/xapian_index.rb:114:in `sync_message'
> from ./lib/sup/xapian_index.rb:87:in `add_message'
> ... 10 levels...
> from ./lib/sup/util.rb:520:in `method_missing'
> from bin/sup-sync:146
> from bin/sup-sync:141:in `each'
> from bin/sup-sync:141
>
> However, I'm having other odd problems too with labels anyway. On the ferret
> version of sup, I'm not able to apply labels with the 'l' command. However, I
> have a hook for applying a label from the List-ID that does still work. So
> this patch may or may not work, I think I'm possibly having problems of my
> own.
I got it to work. Mostly a least. What does a sup-dump file actually store? I
lost all read/unread statuses and all labels (including the spam label thing,
I assume it's just a normal label).
To get it to work, I removed my before-add-message hook. It has worked for a
long time, through different versions of sup, etc. However, It doesn't seem to
be working with xapian.
I don't actually know where this code came from, possibly this list, or maybe
else where. I may have even modified it, I don't really remember. The hook is
this:
listIdMatch = message.raw_header.match(/List-Id:.*?<(.*?)>\s*$/i)
if(listIdMatch)
listIdLabel = listIdMatch[1].split(/\./).first.sub(/[^0-9A-Za-z]/, "")
message.add_label listIdLabel
log "Marking message #{message.id} as #{listIdLabel}, subject is '#{message.subj}'"
end
> Actually, I haven't tried to restore from a dumpfile for ferret. I'll do that
> later and see if it works.
I did try a restore from dumpfile with ferret. It worked except it didn't
remember the labels the same way xapian didn't. However, the hook did work,
and created labels on all mailing list messages.
I think this isn't a xapian problem, because ferret is acting the same.
If I want to recreate the sup files from scratch, what do I need to have? My
config.yaml, sources.yaml, sent.mbox and a dumpfile? Is that all?
------------------------------
Message: 956
Date: Sun, 30 Aug 2009 19:55:56 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] remove use of Object#tap
Message-ID: <1251676342-sup-7038@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Blake Burkhart's message of Sun Aug 30 17:50:09 -0400 2009:
> I got it to work. Mostly a least. What does a sup-dump file actually store? I
> lost all read/unread statuses and all labels (including the spam label thing,
> I assume it's just a normal label).
I also lost labels on my first attempt at switching to xapian. I gave
up for a few days as there were other issues with labels at the time.
Losing labels during the switch would be a deal breaker, but I assume
this isn't intended (as that would be madness, madness, I say)...is
there a step I'm missing in the following (assuming HEAD of next)?
4. cp ~/.sup/sources.yaml{,.bak}
5. ruby -Ilib bin/sup-dump > dumpfile
6. SUP_INDEX=xapian ruby -Ilib bin/sup-sync --all --all-sources
--restore dumpfile
7. SUP_INDEX=xapian ruby -Ilib bin/sup -o
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090830/1955cef2/attachment-0001.bin>
------------------------------
Message: 957
Date: Sun, 30 Aug 2009 17:50:34 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH] sup-sync: restore state on messages that
dont already exist
Message-ID: <1251679834-5313-1-git-send-email-rlane@club.cc.cmu.edu>
---
bin/sup-sync | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/bin/sup-sync b/bin/sup-sync
index 2aa00c3..003a72d 100755
--- a/bin/sup-sync
+++ b/bin/sup-sync
@@ -174,7 +174,12 @@ begin
## decide what to do based on message labels and the operation we're performing
dothis, new_labels = case
when (op == :restore) && restored_state[m.id] && old_m && (old_m.labels != restored_state[m.id])
+ num_restored += 1
[:update_message_state, restored_state[m.id]]
+ when (op == :restore) && restored_state[m.id] && !old_m
+ num_restored += 1
+ m.labels = restored_state[m.id]
+ :add_message
when op == :discard
if old_m && (old_m.labels != m.labels)
[:update_message_state, m.labels]
--
1.6.4
------------------------------
Message: 958
Date: Sun, 30 Aug 2009 20:50:46 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] remove use of Object#tap
Message-ID: <1251677009-sup-2661@zyrg.net>
Content-Type: text/plain; charset="utf-8"
Excerpts from Ben Walton's message of Sun Aug 30 19:55:56 -0400 2009:
> Excerpts from Blake Burkhart's message of Sun Aug 30 17:50:09 -0400 2009:
>
> > I got it to work. Mostly a least. What does a sup-dump file actually store? I
> > lost all read/unread statuses and all labels (including the spam label thing,
> > I assume it's just a normal label).
>
> I also lost labels on my first attempt at switching to xapian. I gave
> up for a few days as there were other issues with labels at the time.
> Losing labels during the switch would be a deal breaker, but I assume
> this isn't intended (as that would be madness, madness, I say)...is
> there a step I'm missing in the following (assuming HEAD of next)?
>
> 4. cp ~/.sup/sources.yaml{,.bak}
> 5. ruby -Ilib bin/sup-dump > dumpfile
> 6. SUP_INDEX=xapian ruby -Ilib bin/sup-sync --all --all-sources
> --restore dumpfile
> 7. SUP_INDEX=xapian ruby -Ilib bin/sup -o
>
> Thanks
> -Ben
>
This is an issue that was introduced in 906ab35e. I've just resent a
patch for it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: restore-state-fix
Type: application/octet-stream
Size: 3534 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090830/5be2a745/attachment-0001.obj>
------------------------------
Message: 959
Date: Sun, 30 Aug 2009 20:48:50 -0500
From: Blake Burkhart <bburky@bburky.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] sup-sync: restore state on messages
that dont already exist
Message-ID: <1251683226-sup-7685@Backspace.local>
Content-Type: text/plain; charset=UTF-8
Excerpts from Rich Lane's message of Sun Aug 30 19:50:34 -0500 2009:
> ---
> bin/sup-sync | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/bin/sup-sync b/bin/sup-sync
> index 2aa00c3..003a72d 100755
> --- a/bin/sup-sync
> +++ b/bin/sup-sync
> @@ -174,7 +174,12 @@ begin
> ## decide what to do based on message labels and the operation we're
> performing
> dothis, new_labels = case
> when (op == :restore) && restored_state[m.id] && old_m && (old_m.labels
> != restored_state[m.id])
> + num_restored += 1
> [:update_message_state, restored_state[m.id]]
> + when (op == :restore) && restored_state[m.id] && !old_m
> + num_restored += 1
> + m.labels = restored_state[m.id]
> + :add_message
> when op == :discard
> if old_m && (old_m.labels != m.labels)
> [:update_message_state, m.labels]
Yay, thank you. Everything works now I think. I now have xapian working correctly I think.
------------------------------
Message: 960
Date: Mon, 31 Aug 2009 00:16:03 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] index log
Message-ID: <1251691269-sup-246@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from Nicolas Pouillard's message of Mon Aug 24 08:20:20 -0400 2009:
> Excerpts from William Morgan's message of Sat Aug 22 15:46:27 +0200 2009:
> > Reformatted excerpts from Rich Lane's message of 2009-08-16:
> > > Add a YAML logfile that records changes to the index and modify
> > > sup-dump to use this rather than the normal database.
> >
> > I like this. I'm going to wait to apply it until the api refactoring
> > stuff is merged down to master though. Should be soon.
>
> I'm wondering if a simpler format would not be better, I've patch
> in my sup copy do feed a file called ~/.sup/labels-mapping.log with
> lines like those:
>
> 000e0cd20f80143822047118693d@google.com (unread inbox -> )
> 20090813213654.GA30223@community.haskell.org (unread inbox patch -> patch)
> 1250148617-sup-6053@oz.taruti.net (unread inbox sup -> sup)
> 1250281208-sup-4199@masanjin.net (unread inbox sup -> sup)
>
> Their are in the style of sup-dump output and there are pretty easy to manage
> by any tools.
>
> Not to say that I don't like YAML, I am a pretty big fan of it; but here it
> seems overkill.
>
> Best regards,
>
I agree that YAML is overkill for what we're currently storing in the
log. The intention was to make this as foolproof for future expansion as
possible, but after some time thinking about it I haven't come up with
more fields to add (not that there still couldn't be, but I think it's
unlikely). I'll submit a simpler patch.
What do people think about replacing the current undo system with one
based on the label log? This would only be possible once we have
immediate label changes. I think it would simplify a lot of code.
------------------------------
Message: 961
Date: Mon, 31 Aug 2009 07:42:21 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] index log
Message-ID: <1251718898-sup-2772@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Rich Lane's message of Mon Aug 31 00:16:03 -0400 2009:
> What do people think about replacing the current undo system with one
> based on the label log? This would only be possible once we have
> immediate label changes. I think it would simplify a lot of code.
+1 for this. I find that more often than not, undo doesn't work as
expected anyway. It's been suggested that this is a threading bug,
which is quite likely...
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090831/8111b611/attachment-0001.bin>
------------------------------
Message: 962
Date: Mon, 31 Aug 2009 19:41:06 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] sup-sync: restore state on messages
that dont already exist
Message-ID: <1251772852-sup-5207@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Applied, thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 963
Date: Mon, 31 Aug 2009 19:51:20 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] reply all keybindings
Message-ID: <1251773465-sup-3081@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Branch reply-all-keybindings, merged into next. Thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 964
Date: Mon, 31 Aug 2009 19:57:54 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Add UTF-8 encoding string for
ArchLinux systems
Message-ID: <1251773862-sup-2194@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Israel Herraiz's message of 2009-08-25:
> in ArchLinux, UTF-8 encoding is identified by "utf8" instead of
> "UTF-8".
Applied to master. Thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 965
Date: Mon, 31 Aug 2009 19:58:47 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Identify list messages by list-id if
list-post is not present
Message-ID: <1251773879-sup-5227@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Israel Herraiz's message of 2009-08-25:
> I am subscribed to some lists that do not fill the list-post header,
> but have a list-id header. I am not sure how standard-compliant is
> that, but it would nice if Sup could identify those messages as list
> messages.
Does this patch work for you?
diff --git a/lib/sup/message.rb b/lib/sup/message.rb
index ed27d3d..472b9dc 100644
--- a/lib/sup/message.rb
+++ b/lib/sup/message.rb
@@ -114,12 +114,11 @@ class Message
@replytos = (header["in-reply-to"] || "").scan(/<(.+?)>/).map { |x| sanitize_me
@replyto = Person.from_address header["reply-to"]
- @list_address =
- if header["list-post"]
- @list_address = Person.from_address header["list-post"].gsub(/^<mailto:|>$/
- else
- nil
- end
+ @list_address = if header["list-post"]
+ Person.from_address header["list-post"].gsub(/^<mailto:|>$/, "")
+ elsif header["list-id"]
+ Person.from_address header["list-id"].gsub(/^<:|>$/, "")
+ end
@recipient_email = header["envelope-to"] || header["x-original-to"] || header["
@source_marked_read = header["status"] == "RO"
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 966
Date: Mon, 31 Aug 2009 20:06:05 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Make SUP_LOG_LEVEL self-documenting.
Message-ID: <1251774349-sup-4067@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Applied, thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 967
Date: Mon, 31 Aug 2009 20:17:36 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] remove use of Object#tap
Message-ID: <1251774958-sup-5853@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Applied. Sup does define a #returning function which is equivalent to
#tap, FWIW.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 968
Date: Tue, 01 Sep 2009 10:07:27 +0200
From: Ingmar Vanhassel <ingmar@exherbo.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH 0/18] Xapian-based index
Message-ID: <1251792282-sup-2057@cannonball>
Content-Type: text/plain; charset=UTF-8
Excerpts from Ingmar Vanhassel's message of Mon Jul 27 18:56:28 +0200 2009:
> Excerpts from William Morgan's message of Mon Jul 27 17:48:38 +0200 2009:
> > Reformatted excerpts from Rich Lane's message of 2009-07-25:
> > > One issue I've noticed is that removing labels from messages doesn't
> > > always immediately work.
> >
> > Is this true even after you sync changes to the index? What about if you
> > reload the label list buffer? ('@')
>
> It's true in both cases. Even after a sync, 'U' still produces read
> messages (among unread), and a search for label:foo has threads without
> that label. If you quit sup & restart it things work as expected for a
> while.
I can still reproduce this for a more specific case, with xapian 1.0.15.
Searching for is:unread (hit U), works as expected. When I filter
that with threads having a second label (hit |, label:foo), then it
shows threads with label:foo, but it loses the is:unread constraint.
Same for immediately doing is:unread label:foo, which gives me unread
threads, but not always with the foo label.
--
Exherbo KDE, X.org maintainer
------------------------------
Message: 969
Date: Tue, 01 Sep 2009 10:51:28 +0200
From: Israel Herraiz <israel.herraiz@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Identify list messages by list-id if
list-post is not present
Message-ID: <1251794935-sup-3802@elly>
Content-Type: text/plain; charset=utf8
Excerpts from William Morgan's message of Tue Sep 01 04:58:47 +0200 2009:
> Does this patch work for you?
Yes, although list-id is not an address (it does not contain the "@"
symbol for instance). But I am happy with that patch :-).
Cheers,
Israel
------------------------------
Message: 970
Date: Tue, 01 Sep 2009 13:59:56 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] add xapian-specific hack to quickly
create a Person
Message-ID: <1251838745-sup-376@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Rich Lane's message of 2009-08-25:
> The slow part is the processing in Person#initialize, which
> QuickPerson overrides. You might also be able to avoid that by moving
> the initialize() code into Person.from_address.
Yeah, I think that's a better approach. There's no need for the
constructor to do all that work. I'll work on this when I get a chance,
or feel free to beat me to it.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 971
Date: Tue, 01 Sep 2009 23:59:57 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>, William Morgan
<wmorgan-sup@masanjin.net>
Subject: Re: [sup-talk] [PATCH 2/2] ui responsiveness tweaks
Message-ID: <1251863327-sup-8206@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Just making sure these patches don't drop off your radar. I know
searching is supposed to make scrolling obsolete, but some Mutt users
asked for this. They'll see the light eventually.
------------------------------
Message: 972
Date: Wed, 02 Sep 2009 06:50:13 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Nobody told me
Message-ID: <1251899343-sup-1025@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Guillaume Quintard's message of 2009-08-28:
> arg, when I try to restore, I get this:
> ./lib/sup/crypto.rb:157:in ``': Cannot allocate memory - /usr/bin/gpg --quiet --batch --no-verbose --logger-fd 1 --use-agent --verify /tmp/31666-0-redwood.signature /tmp/31666-0-redwood.payload 2> /dev/null (Errno::ENOMEM)
If anyone else has been having memory usage problems on the next branch
recently (probably when sup-syncing a large mbox file), they should be
fixed now. I've unmerged the after-add hook, which was the culprit.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 973
Date: Wed, 02 Sep 2009 06:53:17 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Add an after-add-message hook
Message-ID: <1251899447-sup-1658@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from William Morgan's message of 2009-08-24:
> Branch after-add-message-hook, merged into next. Thanks!
I've had to unmerge this, because keeping all the messages around led to
memory problems with large mailboxes.
What about just using the before-add hook and either backgrounding the
process (if it's a separate process) or doing the processing in a Thread
(if it's Ruby code)?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 974
Date: Thu, 03 Sep 2009 16:24:32 +0200
From: Marc Weber <marco-oweber@gmx.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Trouble loading dump into Xapian index
Message-ID: <1251987692-sup-9940@nixos>
Content-Type: text/plain; charset=UTF-8
I've used this sh script to get a new SUP_BASE using xapian only:
However somehow i couldn't import the tags? What have I done wrong?
dump2: The dump file created from the xapian index.
set -x
OLD=~/.sup-old/
NEW=~/.sup-new-test
DUMP=/tmp/dump-file-new
DUMP2=/tmp/dump-file-new2
SYNC_LOG=/tmp/sup-sync-log
GIT_REPO=~/managed_repos/sup_mainline
rm -fr $NEW
export SUP_BASE=$OLD
sup-dump > $DUMP
# from now on operate on the new base only
export SUP_BASE=$NEW
cp -r $OLD $NEW
rm -fr $NEW/ferret
mv $NEW/{hooks,hooks-disabled}
# echo loading stuff..
export SUP_INDEX=xapian
cd $GIT_REPO
echo "syncing.. this will take long. use tail -f $SYNC_LOG to watch progress"
ruby -Ilib bin/sup-sync --all --all-sources --restore $DUMP &> $SYNC_LOG
echo "writing dump"
ruby -Ilib bin/sup-dump > $DUMP2
dump: (first line after sorting)
000001c9fe57$346bf530$9d43df90$@com.au (unread openeeg)
dump2: (first line after sorting)
000001c9fe57$346bf530$9d43df90$@com.au (inbox unread)
Marc Weber
------------------------------
Message: 975
Date: Thu, 3 Sep 2009 17:26:40 +0300
From: Amit Kucheria <amit.kucheria@gmail.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] Dynamic list of maildir folders as sources
Message-ID: <20090903142640.GB4465@matterhorn.verdurent.com>
Content-Type: text/plain; charset=utf-8
Hi,
I've been watching sup for a while and finally decided to take the plunge
today. Apologies for the long-winded explanation before the real question,
but I guess if something in my workflow could be optimised, someone might be
able to point it out here.
I'll be running sup on a bunch of maildir folders downloaded via offlineimap.
All my mail comes as IMAP from 3 gmail accounts. When I subscribe to a new
mailing list, I simply create a new filter in gmail to add a new tag to email
from that list and skip the inbox. This shows up as a new maildir folder on my
local machine.
Mutt finds this new folder using the following folder-hook hack I have in my
.muttrc:
folder-hook +foo.* mailboxes `find ~/Mail/foo -type d
-name cur -type d -printf '%h\n' | sort | tr '\012' ' '`
, where foo is one of my mailboxes. So I have ~/Mail/bar and ~/Mail/foobar for
my other accounts. Each of these have several maildir folder in them.
I've run sup-config and it seems to expect that I list every maildir folder
I've got. Is there a way to generate this dynamically?
Regards,
Amit
p.s. sup-sync has been at it on my lkml folder with ~40K mail messages for
30mins now.
--
------------------------------------------------------------
Amit Kucheria
------------------------------------------------------------
------------------------------
Message: 976
Date: Thu, 03 Sep 2009 08:25:50 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Trouble loading dump into Xapian index
Message-ID: <1251991420-sup-3869@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Marc Weber's message of 2009-09-03:
> I've used this sh script to get a new SUP_BASE using xapian only:
> However somehow i couldn't import the tags? What have I done wrong?
This *might* be related to a patch that Rich sent that I thought I had
applied, but apparently did not. Can you try once more with the latest
master? If it still doesn't work we'll take it from there. (Also, check
that the number of messages sup-sync reports it has restored state on is
the number of messages you'd expect, e.g. roughly the number of lines in
the dumpfile.)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 977
Date: Thu, 03 Sep 2009 08:37:50 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Dynamic list of maildir folders as sources
Message-ID: <1251991617-sup-9735@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Amit Kucheria's message of 2009-09-03:
> I've been watching sup for a while and finally decided to take the
> plunge today.
Welcome!
> I've run sup-config and it seems to expect that I list every maildir
> folder I've got. Is there a way to generate this dynamically?
If you can generate the list (e.g. with the find command you cited), you
can add maildir sources with sup-add directly, instead of having to go
through sup-config.
If you want to automatically detect and add new folders, we could d
something similar in the startup hook. Something like (completely
untested):
dirs = `find ~/Mail/whatever...`
dirs.each do |d|
uri = "maildir:#{d}"
log "trying #{uri}..."
unless SourceManager.source_for uri
source = Maildir.new uri
SourceManager.add_source source
log "Added #{uri}"
end
end
> p.s. sup-sync has been at it on my lkml folder with ~40K mail messages
> for 30mins now.
Yep, indexing stuff is slow. FWIW, you only have to do it once, and
there are new index backends that are significantly faster. (But still
far from instantaneous.)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 978
Date: Thu, 03 Sep 2009 18:21:31 +0200
From: Marc Weber <marco-oweber@gmx.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Trouble loading dump into Xapian index
Message-ID: <1251994802-sup-8575@nixos>
Content-Type: text/plain; charset=UTF-8
Hi William.
I guess it was.
The second dump looks very similar to the first one now.
Only the order of flags is different now which doesn't matter.
However threads which have been killed do show up in inbox:
http://mawercer.de/~marc/sup.png
All seven mails of the first thread are labeled by
killed inbox deleted
So they shouldn't appear, should they?
Same happens to thread where all mails are labeled by
killed, inbox
Did the view behaviour change here?
Sincerly
Marc
------------------------------
Message: 979
Date: Thu, 3 Sep 2009 12:38:53 -0400
From: Matt Zulak <mzulak@gmail.com>
To: sup-talk@rubyforge.org
Cc: Matt Zulak <mzulak@gmail.com>
Subject: [sup-talk] [PATCH] decrypt returns 3 elem array if gpg is
unavailable
Message-ID: <1251995933-2252-1-git-send-email-mzulak@gmail.com>
CryptoManager's decrypt method returns a CryptoNotice if the GPG binary
can't be found on the path; however, the Message class expects a 3
element array with either a RMail::Message or nil at index 0.
This patch ensures sup plays nice when importing encrypted messages from
a mail-store on an environment that does not have GPG.
---
lib/sup/crypto.rb | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/sup/crypto.rb b/lib/sup/crypto.rb
index 7f044b9..afbc445 100644
--- a/lib/sup/crypto.rb
+++ b/lib/sup/crypto.rb
@@ -105,7 +105,7 @@ class CryptoManager
## returns decrypted_message, status, desc, lines
def decrypt payload # a RubyMail::Message object
- return unknown_status(cant_find_binary) unless @cmd
+ return [nil, nil, unknown_status(cant_find_binary)] unless @cmd
payload_fn = Tempfile.new "redwood.payload"
payload_fn.write payload.to_s
--
1.6.2.1
------------------------------
Message: 980
Date: Thu, 03 Sep 2009 12:42:55 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Trouble loading dump into Xapian index
Message-ID: <1251995984-sup-7983@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from Marc Weber's message of Thu Sep 03 12:21:31 -0400 2009:
> However threads which have been killed do show up in inbox:
> http://mawercer.de/~marc/sup.png
> All seven mails of the first thread are labeled by
> killed inbox deleted
>
> So they shouldn't appear, should they?
>
> Same happens to thread where all mails are labeled by
> killed, inbox
>
> Did the view behaviour change here?
I added support for thread killing in 4d82ef88, which hasn't been merged
to master yet. If you'd like to use the Xapian index I suggest using
next for now.
------------------------------
Message: 981
Date: Thu, 03 Sep 2009 12:52:27 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH 0/18] Xapian-based index
Message-ID: <1251996241-sup-5112@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from Ingmar Vanhassel's message of Tue Sep 01 04:07:27 -0400 2009:
> Excerpts from Ingmar Vanhassel's message of Mon Jul 27 18:56:28 +0200 2009:
> > Excerpts from William Morgan's message of Mon Jul 27 17:48:38 +0200 2009:
> > > Reformatted excerpts from Rich Lane's message of 2009-07-25:
> > > > One issue I've noticed is that removing labels from messages doesn't
> > > > always immediately work.
> > >
> > > Is this true even after you sync changes to the index? What about if you
> > > reload the label list buffer? ('@')
> >
> > It's true in both cases. Even after a sync, 'U' still produces read
> > messages (among unread), and a search for label:foo has threads without
> > that label. If you quit sup & restart it things work as expected for a
> > while.
>
> I can still reproduce this for a more specific case, with xapian 1.0.15.
>
> Searching for is:unread (hit U), works as expected. When I filter
> that with threads having a second label (hit |, label:foo), then it
> shows threads with label:foo, but it loses the is:unread constraint.
>
> Same for immediately doing is:unread label:foo, which gives me unread
> threads, but not always with the foo label.
I've reproduced this and it looks like a query parsing problem. Multiple
terms on the same field are OR'd together instead of AND [1]. Adding an
explicit AND works. I'll see if Xapian::QueryParser can be convinced to
do what we want here.
[1] http://trac.xapian.org/ticket/157
------------------------------
Message: 982
Date: Thu, 03 Sep 2009 10:12:25 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Be less overzealous in moving text to
the left column
Message-ID: <1251997795-sup-8368@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Carl Worth's message of 2009-08-26:
> And I still haven't figured out what loose_alignment means and which
> actions will cause loose vs. non-loose layout.
Yeah, it's not really clear where I was going with that. The whole thing
was in need of some rethinking and additional comments. I've made a
branch 'alignment-tweaks', merged into next, which I think has the
behavior you were looking for: left-column movement is minimized when
using 'n' and 'p' to jump between messages. You can also use 'z' to
align the left column with the current message.
Check it out and let me know what you think. If this bugs people, also
let me know. :)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 983
Date: Thu, 03 Sep 2009 10:13:59 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup crashed: NoMethodError
Message-ID: <1251997975-sup-8342@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Sean Escriva's message of 2009-08-28:
> was my install process wrong for switching to the git -next branch?
Nope, it was fine. Transitioning between master and next should
generally be painless.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 984
Date: Thu, 03 Sep 2009 10:16:41 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Trouble loading dump into Xapian index
Message-ID: <1251998177-sup-3432@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Rich Lane's message of 2009-09-03:
> I added support for thread killing in 4d82ef88, which hasn't been
> merged to master yet. If you'd like to use the Xapian index I suggest
> using next for now.
If you feel it's reasonably stable, I can merge it into master.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 985
Date: Thu, 03 Sep 2009 19:26:59 +0200
From: Marc Weber <marco-oweber@gmx.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Trouble loading dump into Xapian index
Message-ID: <1251998504-sup-6794@nixos>
Content-Type: text/plain; charset=UTF-8
> I added support for thread killing in 4d82ef88, which hasn't been merged
> to master yet. If you'd like to use the Xapian index I suggest using
> next for now.
Hi Rich, using next I get the following error:
+ ruby -Ilib bin/sup-sync --all --all-sources --restore /tmp/dump-file-new
./lib/sup/crypto.rb:17: warning: Insecure world writable dir /pr/webkos
in PATH, mode 040777
Loading state dump from /tmp/dump-file-new...
Read 39048 entries from dump file.
./lib/sup/xapian_index.rb:32:in `load_index': This Sup version expects a
v1 index, but you have an existing v0 index. Please downgrade to your
previous version and dump your labels before upgrading to this version
(then run sup-sync --restore). (RuntimeError)
from ./lib/sup/index.rb:67:in `load'
from bin/sup-sync:117
I looked at strace to and noticed that sup only accessed the new
~/.sup-new-test direcotry which was empty. So there is no v0 at all)
Marc Weber
------------------------------
Message: 986
Date: Thu, 03 Sep 2009 10:58:16 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH 2/2] ui responsiveness tweaks
Message-ID: <1252000456-sup-1452@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Both of these patches are on the branch preemptive-loading, merged into
next. Thanks! It's a nice touch.
I didn't really notice any differe from thread prioritization and
Thread.pass call, but maybe that's my setup. Regardless, it can't hurt.
I also reworked the load-more callback mechanism to be a little more
thread safe and a little less insane. Now it uses a queue and has a
dedicated loader thread pulling things off of it. Message thread loading
is currently configured to just drop concurrent calls, so it should work
fine.
Now, all we need is a faster cursor in thread-index-mode. I will grant a
Sup medal to anyone who can make that happen!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 987
Date: Thu, 03 Sep 2009 11:06:55 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Add 'a' and 'd' keybindings to
thread-view-mode to archive/delete current thread
Message-ID: <1252000831-sup-9922@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Carl Worth's message of 2009-08-26:
> These behave identically to the existing ",a" and ",d" commands, (that
> is they archive or delete the current thread and then view the next).
Sorry it's taken me so long to look at this. Thanks for the patch!
I'm curious what other people think about this. On the one hand, it's
only additional keybindings, so it's not going to adversely affect
anyone. On the other hand, there is a nice balance with the ".", ","
and "]" commands which this disrupts, and it can't be extended to the
other commands from thread-index-mode. And on the third hand, I'm happy
to have keybinding hooks.
I guess if most people primarily closes their thread-view-modes using
",a" and ",d", then I'm fine with this.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 988
Date: Thu, 03 Sep 2009 11:32:54 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] On making inbox-mode and search-results-mode
more similar
Message-ID: <1252002193-sup-3879@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Carl Worth's message of 2009-08-26:
> So what I want is for anytime a message is changed such that it no
> longer meets the current search criteria, it is immediately removed
> from the search results. I think that means simply implementing the
> is_relevant? method for SearcResultsMode
is_relevant? is currently only used for determining when to add messages
to a thread-index-mode (e.g. when a new message is picked up during a
poll). Determining whether to drop a message is currently done
"manually" by inbox-mode, and not at all by search-results-mode.
> That single-message index and search sounds exactly like what I want,
> and not insane at all.
Hm. Well, you could certainly try it. I've assumed it would be too slow,
but it's possible it'd be fast enough. I think it's the only option
though, if you want this to work with arbitrary queries.
> (In which case, I'll try, and I'll be glad for any pointers that
> anyone can give me on how to go about creating an in-memory index and
> searching on it.)
Excellent, ask Rich. :)
> The command I would find natural for putting a thread back into the
> inbox would be to simply add the inbox label to the thread. Oddly this
> is currently not allowed as "inbox" is a reserved label.
Yeah, there's no good reason for this. I was just being overly
protective. :)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 989
Date: Thu, 03 Sep 2009 14:35:05 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Trouble loading dump into Xapian index
Message-ID: <1252002797-sup-6522@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from Marc Weber's message of Thu Sep 03 13:26:59 -0400 2009:
>
> > I added support for thread killing in 4d82ef88, which hasn't been merged
> > to master yet. If you'd like to use the Xapian index I suggest using
> > next for now.
>
> Hi Rich, using next I get the following error:
>
> + ruby -Ilib bin/sup-sync --all --all-sources --restore /tmp/dump-file-new
> ./lib/sup/crypto.rb:17: warning: Insecure world writable dir /pr/webkos
> in PATH, mode 040777
> Loading state dump from /tmp/dump-file-new...
> Read 39048 entries from dump file.
> ./lib/sup/xapian_index.rb:32:in `load_index': This Sup version expects a
> v1 index, but you have an existing v0 index. Please downgrade to your
> previous version and dump your labels before upgrading to this version
> (then run sup-sync --restore). (RuntimeError)
> from ./lib/sup/index.rb:67:in `load'
> from bin/sup-sync:117
>
> I looked at strace to and noticed that sup only accessed the new
> ~/.sup-new-test direcotry which was empty. So there is no v0 at all)
That's strange, because this codepath (xapian_index.rb:32) is only hit
when the xapian directory already exists. Can you add a log message to
output the "path" variable and see if it looks correct?
------------------------------
Message: 990
Date: Thu, 03 Sep 2009 11:36:42 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] On making inbox-mode and search-results-mode
more similar
Message-ID: <1252002783-sup-3659@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Rich Lane's message of 2009-08-26:
> We had a thread a while back about applying label changes immediately
> and I think the consensus was that that's a good idea. Doing this
> could simplify a great deal of thread-index-mode code because a fast
> is_relevant? could be implemented using existing index operations
> without the special cases for archiving/etc and without creating an
> inmemory database.
But it's not just a label issue. Determining whether a given message
belongs in a general search buffer requires the full engine. And even if
the query is just on labels, it can contain arbitrary boolean
expressions, and I don't want to be the one having to parse that, and
parse it in such a way that it matches what the search engine is doing.
> I have a patch I plan to mail out soon that makes changing labels with
> Xapian much quicker, so that should help.
This is definitely good, either way.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 991
Date: Thu, 03 Sep 2009 11:39:58 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] On making inbox-mode and search-results-mode
more similar
Message-ID: <1252003008-sup-8596@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Carl Worth's message of 2009-08-26:
> Excerpts from Carl Worth's message of Wed Aug 26 15:24:36 -0700 2009:
> > + text = BufferManager.ask :search, "refine query: ", "label:inbox
> > -label:spam -label:deleted -label:killed "
>
> Is that even the right syntax for searching for threads with the inbox
> label but excluding threades with the spam, deleted, or killed labels?
Instead of -label:killed, you want to specify :skip_killed to
#load_thread. Killed messages require special semantics.
> I took a guess at the syntax and I thought I saw it working, but it
> doesn't appear to be now. Can someone tell me the actual syntax? (Or
> better, is there a writeup somewhere of the general search syntax
> accepted by sup?)
There is not a consistent one, though there might be something useful on
the wiki. The general answer is, whatever Ferret/Xapian supports, plus
the tweaks in #parse_query.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 992
Date: Thu, 03 Sep 2009 14:44:06 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] On making inbox-mode and search-results-mode
more similar
Message-ID: <1252003316-sup-2379@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Thu Sep 03 14:36:42 -0400 2009:
> Reformatted excerpts from Rich Lane's message of 2009-08-26:
> > We had a thread a while back about applying label changes immediately
> > and I think the consensus was that that's a good idea. Doing this
> > could simplify a great deal of thread-index-mode code because a fast
> > is_relevant? could be implemented using existing index operations
> > without the special cases for archiving/etc and without creating an
> > inmemory database.
>
> But it's not just a label issue. Determining whether a given message
> belongs in a general search buffer requires the full engine. And even if
> the query is just on labels, it can contain arbitrary boolean
> expressions, and I don't want to be the one having to parse that, and
> parse it in such a way that it matches what the search engine is doing.
You're right that it require the full engine. If we're immediately
saving the label changes to the (on-disk) index, we can simply query it
and get the correct answer.
------------------------------
Message: 993
Date: Thu, 03 Sep 2009 14:37:34 -0400
From: Mark Alexander <marka@pobox.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Add 'a' and 'd' keybindings to
thread-view-mode to archive/delete current thread
Message-ID: <1252002852-sup-8688@r50p>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Thu Sep 03 14:06:55 -0400 2009:
> I guess if most people primarily closes their thread-view-modes using
> ",a" and ",d", then I'm fine with this.
Those are perhaps my most-commonly used commands in sup, so having
them shortened is a very nice improvement.
------------------------------
Message: 994
Date: Thu, 03 Sep 2009 11:47:19 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Ignore killed messages in U screen
Message-ID: <1252003380-sup-272@masanjin.net>
Content-Type: text/plain; charset=UTF-8
I'm not sure how I feel about this patch. The semantics of being killed
are very tied to the inbox. I'm reluctant to start spreading them to
other types of buffers.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 995
Date: Thu, 03 Sep 2009 11:50:25 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] On making inbox-mode and search-results-mode
more similar
Message-ID: <1252003719-sup-1602@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Rich Lane's message of 2009-09-03:
> You're right that it require the full engine. If we're immediately
> saving the label changes to the (on-disk) index, we can simply query
> it and get the correct answer.
Oh, as opposed to a new in-memory index. Yeah.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 996
Date: Thu, 03 Sep 2009 14:57:14 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Ignore killed messages in U screen
Message-ID: <1252004144-sup-6662@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Thu Sep 03 14:47:19 -0400 2009:
> I'm not sure how I feel about this patch. The semantics of being killed
> are very tied to the inbox. I'm reluctant to start spreading them to
> other types of buffers.
The reason why I request this is because I have a distinction between
unread messages in my inbox and unread messages not in my inbox and
unread messages that are killed. The 1st is for messages that I
should read (or at least ack), the second is for mailing list messages
and the third is for "I don't actually ever want to see this again,
no really".
Cheers,
Edward
------------------------------
Message: 997
Date: Thu, 03 Sep 2009 14:58:45 -0400
From: Nicholas Bergson-Shilcock <me@nicholasbs.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Add 'a' and 'd' keybindings to
thread-view-mode to archive/delete current thread
Message-ID: <1252004295-sup-6234@twoface>
Content-Type: text/plain; charset=UTF-8
Excerpts from Mark Alexander's message of Thu Sep 03 14:37:34 -0400 2009:
> Excerpts from William Morgan's message of Thu Sep 03 14:06:55 -0400 2009:
> > I guess if most people primarily closes their thread-view-modes using
> > ",a" and ",d", then I'm fine with this.
>
> Those are perhaps my most-commonly used commands in sup, so having
> them shortened is a very nice improvement.
+1. These would be quite helpful for me.
------------------------------
Message: 998
Date: Thu, 03 Sep 2009 11:58:55 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Ignore killed messages in U screen
Message-ID: <1252004285-sup-476@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Edward Z. Yang's message of 2009-09-03:
> The 1st is for messages that I should read (or at least ack), the
> second is for mailing list messages and the third is for "I don't
> actually ever want to see this again, no really".
What if you just delete messages in the the third condition?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 999
Date: Thu, 03 Sep 2009 15:01:55 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Ignore killed messages in U screen
Message-ID: <1252004504-sup-3189@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Thu Sep 03 14:58:55 -0400 2009:
> Reformatted excerpts from Edward Z. Yang's message of 2009-09-03:
> > The 1st is for messages that I should read (or at least ack), the
> > second is for mailing list messages and the third is for "I don't
> > actually ever want to see this again, no really".
>
> What if you just delete messages in the the third condition?
Then replies show up. :-)
Cheers,
Edward
------------------------------
Message: 1000
Date: Thu, 03 Sep 2009 15:13:15 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Ignore killed messages in U screen
Message-ID: <1252005121-sup-3946@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Thu Sep 03 14:47:19 -0400 2009:
> I'm not sure how I feel about this patch. The semantics of being killed
> are very tied to the inbox. I'm reluctant to start spreading them to
> other types of buffers.
The 'U' key binding just drives a preset search. This wouldn't be
spreading the special status of killed into other buffer types more
than a manual search using the same terms.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090903/e97c30e8/attachment-0001.bin>
------------------------------
Message: 1001
Date: Thu, 03 Sep 2009 15:25:03 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Ignore killed messages in U screen
Message-ID: <1252005520-sup-9555@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from Edward Z. Yang's message of Thu Aug 27 11:56:32 -0400 2009:
> Excerpts from Edward Z. Yang's message of Thu Aug 27 11:36:28 -0400 2009:
> > - SearchResultsMode.spawn_from_query "is:unread"
> > + SearchResultsMode.spawn_from_query "is:unread !label:killed"
>
> I might have one legitimate objection to this patch, which is
> that searches should ignore killed tags unless explicitly told
> not to.
By default Index#load_messages_in_thread_for does skip killed threads,
so you should already have the behavior you want without modifying the
query (unless you're using an old xapian-index version that doesn't
support killed threads). Adding a !label:killed term will actually cause
threads that are "killed" (have at least one message labeled killed) but
also have a message not labeled killed that matches the query to be
displayed, which I don't think is the behavior you're looking for.
------------------------------
Message: 1002
Date: Thu, 03 Sep 2009 16:06:50 -0700
From: Carl Worth <cworth@cworth.org>
To: Rich Lane <rlane@club.cc.cmu.edu>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Ignore killed messages in U screen
Message-ID: <1252010283-sup-4453@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
Excerpts from Rich Lane's message of Thu Sep 03 12:25:03 -0700 2009:
> By default Index#load_messages_in_thread_for does skip killed threads,
> so you should already have the behavior you want without modifying the
> query (unless you're using an old xapian-index version that doesn't
> support killed threads). Adding a !label:killed term will actually cause
> threads that are "killed" (have at least one message labeled killed) but
> also have a message not labeled killed that matches the query to be
> displayed, which I don't think is the behavior you're looking for.
Wow, that's surprising!
But thanks for explaining that since that's the exact behavior I've
been getting since I starting using queries with "!label:killed" in
them, (I'm trying to get views that act like filtered versions of the
inbox).
Excerpts from William Morgan's message of Thu Sep 03:
> I'm not sure how I feel about this patch. The semantics of being killed
> are very tied to the inbox. I'm reluctant to start spreading them to
> other types of buffers.
William, perhaps you can take this chance to explain something to
me. I've been trying to figure out the philosophy and the mechanics of
sup labels and searching.
>From the point-of-view of a naive user it has seemed to me like the
philosophy is that threads are the primary objects so all labels apply
to a thread as a whole, and all searches return results consisting of
entire threads. And this all seems very good to me.
But the above discussion of "killed" suggests that the mechanics
aren't at all like that. But that instead, labels are applied to
individual messages, and searches match individual messages and then
construct threads from the results. Is that more or less how things
work?
So is there a mismatch between the philosophy and the mechanics, or
did I just misunderstand the philosophy?
That is, do current users of sup ever distinguish between searching
for messages with specific labels as opposed to searching for threads
that contain messages with specific labels?
If not, it seems like it would be possible for a query like
"!label:killed" to do exactly what is wanted without needing any
special treatment for killed internally. And I'd like this, because I
would sometimes want to do a similar negative filter based on my own
custom labels.
Does that make sense?
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090903/b204c976/attachment-0001.bin>
------------------------------
Message: 1003
Date: Fri, 4 Sep 2009 09:08:11 +1000
From: Richard Sandilands <richard@infoarts.info>
To: sup-talk@rubyforge.org
Subject: [sup-talk] Can't add source when tracking next
Message-ID: <20090903230808.GA2983@114.73.135.126.optusnet.com.au>
Content-Type: text/plain; charset=us-ascii
Hi there
I'm tracking next via git and am having trouble adding a mail source.
I've removed any existing ~/.sup directory, then run sup-config and
all is OK until sup-config runs sup-add maildir when I get this
message:
"Ok, trying to run "/Users/richard/src/sup/bin/sup-add
maildir:/Users/richard/mail/gmail/INBOX"...
/Users/richard/src/sup/lib/sup/index.rb:177: undefined method `[]' for
false:FalseClass (NoMethodError)
from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in
`gem_original_require'
from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in `require'
from /Users/richard/src/sup/lib/sup.rb:277
from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in
`gem_original_require'
from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in `require'
from /Users/richard/src/sup/bin/sup-add:7
So I'm thinking this might have something to do with my environment
setup on OS X.
I'm running sup from ~/src/sup and am mirroring my gmail mail to
~/mail/gmail via offlineimap - this all seems fine.
I've added: 'export RUBYLIB="~/src/sup/lib" ' to my .bash_profile but
it still fails on the 'require "sup"' line in sup-add
I've checked that I have all the required gem dependencies and that
seems fine too.
And I installed the sup-999 gems.
What could I be missing here?
Any clues appreciated...
--
Richard
------------------------------
Message: 1004
Date: Thu, 03 Sep 2009 22:13:11 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: Sup Mailing List <sup-talk@rubyforge.org>
Subject: [sup-talk] more xapian/label woes
Message-ID: <1252030139-sup-6351@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Hi All,
I've tried the xapian conversion again and am now back in ferret
land. In this case, I don't think the issues are xapian related...it
seems to the labels that are biting me again.
I get exceptions with non-Symbol labels being passed around again. To
finish the import of my ferret dumpfile, I had to do the following:
--snip--
diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
index 1395601..4b3b022 100644
--- a/lib/sup/xapian_index.rb
+++ b/lib/sup/xapian_index.rb
@@ -111,7 +111,7 @@ class XapianIndex < BaseIndex
:replytos => (entry[:replytos] || m.replytos),
}
- labels.each { |l| LabelManager << l }
+ labels.each { |l| LabelManager << l.to_sym }
--snip--
This got me to the point where I could fire up sup with
SUP_INDEX=xapian, but the initial poll caused the attached exception.
I wonder if LabelManager should simply call .to_sym (.intern) on
everything passed to it? That's a big hammer, I realize...maybe
.to_sym/.intern in cases where the unexpected object is a String?
Thoughts?
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: exception-log.txt
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090903/48d07caf/attachment-0001.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090903/48d07caf/attachment-0001.bin>
------------------------------
Message: 1005
Date: Fri, 04 Sep 2009 06:56:41 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Identify list messages by list-id if
list-post is not present
Message-ID: <1252072500-sup-8128@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Israel Herraiz's message of 2009-09-01:
> Yes, although list-id is not an address (it does not contain the "@"
> symbol for instance). But I am happy with that patch :-).
Actually you're right. I think I prefer your patch. But based on the
code, it seems like reply-mode would crash if it got a message that
claims it's a list message but doesn't have a list address. Does it
actually work?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1006
Date: Fri, 04 Sep 2009 07:34:11 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] decrypt returns 3 elem array if gpg is
unavailable
Message-ID: <1252074791-sup-9657@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Matt Zulak's message of 2009-09-03:
> CryptoManager's decrypt method returns a CryptoNotice if the GPG
> binary can't be found on the path; however, the Message class expects
> a 3 element array with either a RMail::Message or nil at index 0.
Thanks. I've fixed this in a slightly different way, by returning the
notice as the first element. I think the code is a little easier to read
that way. Let me know if it doesn't work.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1007
Date: Fri, 04 Sep 2009 07:41:49 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Ignore killed messages in U screen
Message-ID: <1252074924-sup-1994@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Carl Worth's message of 2009-09-03:
> But the above discussion of "killed" suggests that the mechanics
> aren't at all like that. But that instead, labels are applied to
> individual messages, and searches match individual messages and then
> construct threads from the results. Is that more or less how things
> work?
Yes. That's why killed is special; it requires work at threading time to
drop threads in which any message has a killed label, regardless of
whether that's the message that matched the query.
> So is there a mismatch between the philosophy and the mechanics, or
> did I just misunderstand the philosophy?
Not sure. Maybe both. :) The philosophy is more about the UI, IMO, than
specific implementation details (though obviosuly there's some
trickle-up).
The other way to implement this, FWIW, is to have labels automatically
spread to all messages in a thread when they're applied. I think that is
probably a better implementation, though it increases the cost at
labeling time. I've been toying with this idea in the sup server code.
> If not, it seems like it would be possible for a query like
> "!label:killed" to do exactly what is wanted without needing any
> special treatment for killed internally.
I think the above implementation would allow this.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1008
Date: Fri, 04 Sep 2009 08:12:01 -0700
From: Carl Worth <cworth@cworth.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Ignore killed messages in U screen
Message-ID: <1252076900-sup-274@yoom.home.cworth.org>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Fri Sep 04 07:41:49 -0700 2009:
> Yes. That's why killed is special; it requires work at threading time to
> drop threads in which any message has a killed label, regardless of
> whether that's the message that matched the query.
Good. I'm glad I'm at least understanding how things work here.
> The other way to implement this, FWIW, is to have labels automatically
> spread to all messages in a thread when they're applied. I think that is
> probably a better implementation, though it increases the cost at
> labeling time. I've been toying with this idea in the sup server code.
>
> > If not, it seems like it would be possible for a query like
> > "!label:killed" to do exactly what is wanted without needing any
> > special treatment for killed internally.
>
> I think the above implementation would allow this.
Yes, that would do the trick. It would require extra work both at the
time a label is attached to a message and then again at the time a new
message is associated with an existing thread. But it would give me
the behavior I want "for free" after that.
If such an implementation would be acceptable, then it would seem that
a better long-term solution would be to apply labels only to "thread
objects" and to index and search for those rather than individuals
messages (at least as far as label searching goes). Of course, I'm
talking from an entirely naive point-of-view with regard to the
implementation impact of such a change, but I would imagine it
wouldn't be trivial.
-Carl
------------------------------
Message: 1009
Date: Fri, 04 Sep 2009 08:22:21 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Can't add source when tracking next
Message-ID: <1252077695-sup-9520@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Richard Sandilands's message of 2009-09-03:
> "Ok, trying to run "/Users/richard/src/sup/bin/sup-add
> maildir:/Users/richard/mail/gmail/INBOX"...
> /Users/richard/src/sup/lib/sup/index.rb:177: undefined method `[]' for
> false:FalseClass (NoMethodError)
Whoops, this was a bug. I've fixed it in next, if you want to try again.
You may have to delete your ~/.sup/config.yaml file (it will yell at you
if so.)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1010
Date: Fri, 04 Sep 2009 08:30:11 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] more xapian/label woes
Message-ID: <1252077954-sup-8898@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Walton's message of 2009-09-03:
> I get exceptions with non-Symbol labels being passed around again. To
> finish the import of my ferret dumpfile, I had to do the following:
Is this with a recent next, and after deleting any vestigal
~/.sup/xapian directory and .db files? If so, there really shouldn't be
any label issues. If there are, can you attach the original exception?
Also, does your sources.yaml file have something weird for labels?
> This got me to the point where I could fire up sup with
> SUP_INDEX=xapian, but the initial poll caused the attached exception.
> I wonder if LabelManager should simply call .to_sym (.intern) on
> everything passed to it?
Certainly an option, but I'm hoping to keep the "fail fast" behavior for
now since it is revealing underlying problems.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1011
Date: Fri, 04 Sep 2009 08:53:12 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: Kornilios Kourtis <kkourt@cslab.ece.ntua.gr>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] handle malformed multiplart messages
Message-ID: <1252079569-sup-6888@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Kornilios Kourtis's message of 2009-07-28:
> I've tried to use sup-mail, but sup-sync blows up due to some malformed
> messages I keep in my mailbox. Below is a quick patch that seems to fix the
> above issue for me.
Sorry for the delay. I think this is good. Applied. Thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1012
Date: Fri, 04 Sep 2009 18:25:39 +0200
From: Marc Weber <marco-oweber@gmx.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Trouble loading dump into Xapian index
Message-ID: <1252081334-sup-213@nixos>
Content-Type: text/plain; charset=UTF-8
Sorry.
It was my fault. I had a ~/.sup/xapian I forgot about. That made the
trouble causing the correct error message.
So I think it's safe to switch to Xapian. You may use this script.
It will copy the existing ~/.sup and create a new directory $NEW with
the xapian index. You cane set SUP_BASE to run the new sup to try it
out. Next feels so much better in various ways (speed, search in threads etc.)
Thanks for your all this work!
set -x
set -e
OLD=~/.sup
NEW=/pr/sup-new-test
DUMP=/tmp/dump-file-new
DUMP2=/tmp/dump-file-new2
SYNC_LOG=/tmp/sup-sync-log
GIT_REPO=~/managed_repos/sup_mainline
rm -fr $NEW
export SUP_BASE=$OLD
sup-dump > $DUMP
# from now on operate on the new base only
export SUP_BASE=$NEW
cp -r $OLD $NEW
rm -fr $NEW/ferret
rm -fr $NEW/xapian # remove old xapian cruft!
mv $NEW/{hooks,hooks-disabled}
# echo loading stuff..
export SUP_INDEX=xapian
cd $GIT_REPO
echo "syncing.. this will take long. use tail -f $SYNC_LOG to watch progress"
ruby -Ilib bin/sup-sync --all --all-sources --restore $DUMP &> $SYNC_LOG
echo "writing dump"
ruby -Ilib bin/sup-dump # > $DUMP2
Marc Weber
------------------------------
Message: 1013
Date: Fri, 04 Sep 2009 13:00:57 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Trouble loading dump into Xapian index
Message-ID: <1252083532-sup-2011@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Thu Sep 03 13:16:41 -0400 2009:
> Reformatted excerpts from Rich Lane's message of 2009-09-03:
> > I added support for thread killing in 4d82ef88, which hasn't been
> > merged to master yet. If you'd like to use the Xapian index I suggest
> > using next for now.
>
> If you feel it's reasonably stable, I can merge it into master.
I think it's ok to merge.
------------------------------
Message: 1014
Date: Fri, 04 Sep 2009 10:29:23 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Trouble loading dump into Xapian index
Message-ID: <1252085325-sup-2315@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Rich Lane's message of 2009-09-04:
> I think it's ok to merge.
Merged!
If you're running a Xapian from master (weird!) you will have to rebuild
your index after removing ~/.sup/{xapian,*.db}.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1015
Date: Fri, 4 Sep 2009 12:13:32 -0700
From: Sean Escriva <sean.escriva@gmail.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] a few questions on mail handling with sup
Message-ID: <20090904191332.GA5525@gmail.com>
Content-Type: text/plain; charset=us-ascii
I've got sup working with the exchange server at work thanks to
offlineimap, but I have a few questions I was hope to get some input
on.
Currently I have no way to way move messages out of my inbox on the
imap server, since I'm accessing a local maildir created by
offlineimap. This is only an issue since mailboxes have a limit of
800mb in size on the server and given the volume of mail I have that
will be reached every other month. I've looked at imap filter and this
could possibly work, but anyone have experience with this sort of
sitatuation?
Additionally, since sup doesn't actually change the
maildir, messages in the maildir do not seem be getting marked as not
new when reading them with sup and offlineimap then doesn't update the
message state on the server. Is there any way to addess this?
thanks!
------------------------------
Message: 1016
Date: Fri, 04 Sep 2009 16:47:39 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] more xapian/label woes
Message-ID: <1252081294-sup-4119@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Fri Sep 04 11:30:11 -0400 2009:
> Is this with a recent next, and after deleting any vestigal
> ~/.sup/xapian directory and .db files? If so, there really shouldn't be
> any label issues. If there are, can you attach the original exception?
> Also, does your sources.yaml file have something weird for labels?
It was with cdb1017, but I likely did have a ~/.sup/xapian directory
from previous attempts. I'll try again tonight with that cleared out.
> > This got me to the point where I could fire up sup with
> > SUP_INDEX=xapian, but the initial poll caused the attached exception.
> > I wonder if LabelManager should simply call .to_sym (.intern) on
> > everything passed to it?
>
> Certainly an option, but I'm hoping to keep the "fail fast" behavior for
> now since it is revealing underlying problems.
Ok, I think this is likely the best approach too. Strings and symbols
have a somewhat special relationship in ruby though, so I thought it
might be ok to force a coercion in that case. Lets make it the last
resort as you suggest.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090904/aa7e19d8/attachment-0001.bin>
------------------------------
Message: 1017
Date: Fri, 04 Sep 2009 17:01:11 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] a few questions on mail handling with sup
Message-ID: <1252098027-sup-4487@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Sean Escriva's message of Fri Sep 04 15:13:32 -0400 2009:
> Currently I have no way to way move messages out of my inbox on the
> imap server, since I'm accessing a local maildir created by
> offlineimap. This is only an issue since mailboxes have a limit of
> 800mb in size on the server and given the volume of mail I have that
> will be reached every other month. I've looked at imap filter and this
> could possibly work, but anyone have experience with this sort of
> sitatuation?
Could you pull it down with fetchmail into a local MTA setup that only
handles local delivery? Fetchmail has the 'delete on server' option
if offlineimap doesn't.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090904/7e4f505a/attachment-0001.bin>
------------------------------
Message: 1018
Date: Sat, 05 Sep 2009 15:08:52 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: Sup Mailing List <sup-talk@rubyforge.org>
Subject: [sup-talk] new exception
Message-ID: <1252177626-sup-316@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
This attached exception log was generated after sending a reply,
before the inbox buffer was redisplayed.
I have the following small modifications to 99e62d55 included (still
required for importing to xapian in my case):
--snip--
- raise ArgumentError, "expecting a symbol" unless t.is_a? Symbol
+ t = t.intern if t.is_a? String
+
+ unless t.is_a? Symbol
+ m = "expecting a symbol, got a #{t.class} (#{t.to_s})"
+ raise ArgumentError, m
+ end
+
--snip--
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: exception-log.txt
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090905/ef8749ed/attachment-0001.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090905/ef8749ed/attachment-0001.bin>
------------------------------
Message: 1019
Date: Sat, 05 Sep 2009 15:30:04 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] new exception
Message-ID: <1252178309-sup-7297@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from Ben Walton's message of Sat Sep 05 15:08:52 -0400 2009:
> --- RuntimeError from thread: main
> DocNotFoundError: No termlist found for document 2478134195
> /usr/lib/ruby/site_ruby/1.8/xapian.rb:239:in `doclength'
> /usr/lib/ruby/site_ruby/1.8/xapian.rb:239:in `postlist'
> /usr/lib/ruby/site_ruby/1.8/xapian.rb:59:in `_safelyIterate'
> /usr/lib/ruby/site_ruby/1.8/xapian.rb:237:in `postlist'
> ./sup/xapian_index.rb:361:in `term_docids'
I'm guessing you're using the Chert Xapian backend. When I moved all the
index data into Xapian it started triggering this Chert bug.
Unfortunately, it's nondeterministic and very hard to reproduce in a
small testcase. I've been holding off filing a bug upstream until I had
a better failing testcase than "run sup-sync". If anyone would like to
familiarize themselves with the xapian-index internals and narrow this
bug down a bit I'd be very glad for the help.
The Flint Xapian backend seems to work fine, so for now I suggest using that.
------------------------------
Message: 1020
Date: Sat, 05 Sep 2009 15:35:50 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] new exception
Message-ID: <1252179264-sup-8449@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Rich Lane's message of Sat Sep 05 15:30:04 -0400 2009:
> I'm guessing you're using the Chert Xapian backend. When I moved all the
> index data into Xapian it started triggering this Chert bug.
> Unfortunately, it's nondeterministic and very hard to reproduce in a
> small testcase. I've been holding off filing a bug upstream until I had
> a better failing testcase than "run sup-sync". If anyone would like to
> familiarize themselves with the xapian-index internals and narrow this
> bug down a bit I'd be very glad for the help.
Your guess is as good as mine here...I didn't realize there were
different back ends. How would I go about switching?
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090905/2217f134/attachment-0001.bin>
------------------------------
Message: 1021
Date: Sat, 05 Sep 2009 15:55:12 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] new exception
Message-ID: <1252179965-sup-8043@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from Ben Walton's message of Sat Sep 05 15:35:50 -0400 2009:
> Your guess is as good as mine here...I didn't realize there were
> different back ends. How would I go about switching?
Interesting, AFAIK Flint is still the default. Check for a
.sup/xapian/iamchert file to see if it's really a Chert DB. If it is
Chert, you'll have to delete the xapian directory before you can switch
to Flint. The environment variable XAPIAN_PREFER_CHERT controls which
backend is used. Set it to the empty string to make sure you're getting
Flint.
------------------------------
Message: 1022
Date: Sat, 05 Sep 2009 17:57:41 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] new exception
Message-ID: <1252187828-sup-3676@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Rich Lane's message of Sat Sep 05 15:55:12 -0400 2009:
> Interesting, AFAIK Flint is still the default. Check for a
> .sup/xapian/iamchert file to see if it's really a Chert DB. If it is
Nope. I've got ~/.sup/xapian/iamflint though...
Thanks for the info.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090905/ef9fc4c3/attachment-0001.bin>
------------------------------
Message: 1023
Date: Sat, 05 Sep 2009 20:19:06 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: Sup Mailing List <sup-talk@rubyforge.org>
Subject: [sup-talk] sources.yaml labels
Message-ID: <1252196204-sup-4575@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Hi All,
After still requiring modifications to the LabelManager to manage my
xapian conversion, I'm wondering if I've done something wrong in my
sources.yaml (most of which was put together by hand instead of via
sup-add). What format should a labels definition be using? On of my
sources looks like:
--snip--
- !masanjin.net,2006-10-01/Redwood/Maildir
uri: maildir:///u/bwalton/Maildir/.systemtap/
cur_offset: 12264068440005086
usual: true
archived: false
id: 6
labels:
- systemtap
mtimes:
cur: 2008-10-23 13:22:54 -04:00
new: 2008-11-11 07:34:04 -05:00
--snip--
Should the '- systemtap' be '- :systemtap'?
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090905/7dc9994f/attachment-0001.bin>
------------------------------
Message: 1024
Date: Sun, 06 Sep 2009 19:40:57 +1000
From: Richard Sandilands <richard@infoarts.info>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Sent messages and Sent label
Message-ID:
<1252230039-sup-3920@Richard-Sandilandss-MacBook-Pro.local>
Content-Type: text/plain; charset=UTF-8
Hi there
I've set:
:sent_source: sup://sent
in my config.yaml and am sending using msmtp succesfully, however I'm not
seeing my sent mail anywhere in Sup. I'm assuming that it is labelled as
'Sent' and accessible via the 'Sent' label.
But no mail is visible under that label - should I be adding a hook to label
outgoing mail as 'Sent' or am I missing something obvious?
--
Richard Sandilands
------------------------------
Message: 1025
Date: Sun, 06 Sep 2009 19:42:50 +1000
From: Richard Sandilands <richard@infoarts.info>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Change color of 'highlight' indicator in inbox
view?
Message-ID:
<1252230162-sup-8625@Richard-Sandilandss-MacBook-Pro.local>
Content-Type: text/plain; charset=UTF-8
Hi there
Am just playing with colors.yaml and was looking to change the colors of the
highlight line that indicates a selected thread in inbox view.
Is there a setting for this element?
--
Richard Sandilands
------------------------------
Message: 1026
Date: Sun, 06 Sep 2009 19:40:57 +1000
From: Richard Sandilands <richard@infoarts.info>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Sent messages and Sent label
Message-ID:
<1252230039-sup-3920@Richard-Sandilandss-MacBook-Pro.local>
Content-Type: text/plain; charset=UTF-8
Hi there
I've set:
:sent_source: sup://sent
in my config.yaml and am sending using msmtp succesfully, however I'm not
seeing my sent mail anywhere in Sup. I'm assuming that it is labelled as
'Sent' and accessible via the 'Sent' label.
But no mail is visible under that label - should I be adding a hook to label
outgoing mail as 'Sent' or am I missing something obvious?
--
Richard Sandilands
------------------------------
Message: 1027
Date: Sun, 06 Sep 2009 06:07:48 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Change color of 'highlight' indicator in inbox
view?
Message-ID: <1252241877-sup-6125@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Richard Sandilands's message of 2009-09-06:
> Am just playing with colors.yaml and was looking to change the colors
> of the highlight line that indicates a selected thread in inbox view.
>
> Is there a setting for this element?
Currently the highlight color is generated programmatically, so there's
no setting in colors.yaml. You can edit colormap.rb#highlight_for (circa
line 82) if you want.
Ideas on how to move this configuration to colors.yaml (or some other
configuration mechanism) welcome.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1028
Date: Sun, 06 Sep 2009 06:22:21 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sources.yaml labels
Message-ID: <1252242820-sup-1452@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Walton's message of 2009-09-05:
> Should the '- systemtap' be '- :systemtap'?
The former is "correct". But if you put in the latter, it should be
converted automatically, and written out as the former when you exit
Sup.
I'm a little disturbed that you're still seeing problems with this. Can
you confirm that SerializeLabelsNicely#after_unmarshal! (source.rb circa
line 167) is being run in your sources after they're loaded from
sources.yaml? That should ensure that you end up with a Set of symbols
when Sup's running, regardless of what's in the file.
The other source of bad labels is the serialized version of the messages
stored by Xapian, if you use Xapian. But if you've regenerated your
Xapian index recently, this shouldn't be a problem...
It strikes me now that the other possible source of non-symbol labels is
a hook like before-add. Are you using that to call Message#add_label
with a string argument, by any chance?
If none of the above, can you post the latest version of the exceptions
you're seeing?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1029
Date: Sun, 06 Sep 2009 09:47:06 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sources.yaml labels
Message-ID: <1252244621-sup-3579@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Sun Sep 06 09:22:21 -0400 2009:
> The former is "correct". But if you put in the latter, it should be
> converted automatically, and written out as the former when you exit
> Sup.
Ok, so my sources.yaml is 'good.'
> I'm a little disturbed that you're still seeing problems with this. Can
> you confirm that SerializeLabelsNicely#after_unmarshal! (source.rb circa
> line 167) is being run in your sources after they're loaded from
> sources.yaml? That should ensure that you end up with a Set of symbols
> when Sup's running, regardless of what's in the file.
Yes, I added a debug in that method and saw a message for each source.
> The other source of bad labels is the serialized version of the messages
> stored by Xapian, if you use Xapian. But if you've regenerated your
> Xapian index recently, this shouldn't be a problem...
I generated this about 2 days ago with a current (at the time) head of
next.
> It strikes me now that the other possible source of non-symbol labels is
> a hook like before-add. Are you using that to call Message#add_label
> with a string argument, by any chance?
I was doing this. I had a hook from my very early sup days still in
play. Since it was actually completely redundant (procmail filtering
and autolabelling via sources) now, I've simply removed it.
> If none of the above, can you post the latest version of the exceptions
> you're seeing?
I still can't load sup without coercing strings to symbols in the <<
method though. The exception log is attached (from a clean startup).
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: exception-log.txt
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090906/8e8d8383/attachment-0001.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090906/8e8d8383/attachment-0001.bin>
------------------------------
Message: 1030
Date: Sun, 06 Sep 2009 06:50:35 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sent messages and Sent label
Message-ID: <1252244925-sup-2820@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Richard Sandilands's message of 2009-09-06:
> But no mail is visible under that label - should I be adding a hook to
> label outgoing mail as 'Sent' or am I missing something obvious?
Whoops, this is a bug I introduced recently. I've fixed it now. Please
git pull and try again.
To apply the sent label to previously-sent messages, please run:
sup-tweak-labels -a sent sup://sent
Sorry about that!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1031
Date: Sun, 06 Sep 2009 10:07:55 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sources.yaml labels
Message-ID: <1252246006-sup-3945@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Sun Sep 06 09:22:21 -0400 2009:
> The other source of bad labels is the serialized version of the messages
> stored by Xapian, if you use Xapian. But if you've regenerated your
> Xapian index recently, this shouldn't be a problem...
Since I had a bad hook and imported to Xapian with that hook live,
should I reimport my dumpfile after having the hook removed? I'm
thinking that I did the damage in a permanent fashion while doing the
import...
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090906/e357aff1/attachment-0001.bin>
------------------------------
Message: 1032
Date: Sun, 06 Sep 2009 16:16:56 +0200
From: Ingmar Vanhassel <ingmar@exherbo.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sources.yaml labels
Message-ID: <1252246564-sup-241@cannonball>
Content-Type: text/plain; charset=UTF-8
Excerpts from Ben Walton's message of Sun Sep 06 15:47:06 +0200 2009:
> I still can't load sup without coercing strings to symbols in the <<
> method though. The exception log is attached (from a clean startup).
That looks like you're using labels as strings, or at least not as
symbols, in one of your hooks.
--
Exherbo KDE, X.org maintainer
------------------------------
Message: 1033
Date: Sun, 06 Sep 2009 08:06:16 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sources.yaml labels
Message-ID: <1252248461-sup-5213@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Walton's message of 2009-09-06:
> Since I had a bad hook and imported to Xapian with that hook live,
> should I reimport my dumpfile after having the hook removed? I'm
> thinking that I did the damage in a permanent fashion while doing the
> import...
I suspect that would fix it. I've just pushed a change to to make
Message#add_label coerce arguments to symbols, anyways, so that writing
your hook wrong won't destroy your index for all eternity.
Sorry about all this. The silver lining is that it's a side effect of
lots of development activity. :)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1034
Date: Sun, 06 Sep 2009 11:26:26 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sources.yaml labels
Message-ID: <1252250590-sup-9666@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Sun Sep 06 11:06:16 -0400 2009:
> I suspect that would fix it. I've just pushed a change to to make
> Message#add_label coerce arguments to symbols, anyways, so that writing
> your hook wrong won't destroy your index for all eternity.
Ok, that's cool. I was going to write the same change but with a
'raise ArgumentError' similar to the one in << to stick with the fail
fast approach you prefer.
> Sorry about all this. The silver lining is that it's a side effect of
> lots of development activity. :)
Hey, it's not a problem. I don't mind guinea pigging this stuff at
all. Sup has steadily improved since I've been using it, so I'm a
happy camper. [Plus, I'm running next, so I 'get what I get.']
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090906/26890640/attachment-0001.bin>
------------------------------
Message: 1035
Date: Sun, 06 Sep 2009 12:41:48 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sources.yaml labels
Message-ID: <1252255225-sup-9921@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Sun Sep 06 11:06:16 -0400 2009:
> I suspect that would fix it. I've just pushed a change to to make
> Message#add_label coerce arguments to symbols, anyways, so that writing
> your hook wrong won't destroy your index for all eternity.
Verified. I've re-imported my dump file after removing my hook. The
import ran successfully with an unmodified sup.
I think this makes me a full-time xapian convert.
Thanks for all your effort on this William and Rich!
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090906/6eddaa77/attachment-0001.bin>
------------------------------
Message: 1036
Date: Sun, 06 Sep 2009 13:02:19 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] new exception
Message-ID: <1252255655-sup-2460@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from Ben Walton's message of Sat Sep 05 17:57:41 -0400 2009:
> Excerpts from Rich Lane's message of Sat Sep 05 15:55:12 -0400 2009:
>
> > Interesting, AFAIK Flint is still the default. Check for a
> > .sup/xapian/iamchert file to see if it's really a Chert DB. If it is
>
> Nope. I've got ~/.sup/xapian/iamflint though...
Well, that's not good. How often does this bug occur? What version of
Xapian are you running? How many messages are in your index?
------------------------------
Message: 1037
Date: Sun, 06 Sep 2009 13:22:39 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] new exception
Message-ID: <1252257711-sup-2477@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Rich Lane's message of Sun Sep 06 13:02:19 -0400 2009:
> Well, that's not good. How often does this bug occur? What version of
> Xapian are you running? How many messages are in your index?
It's only occurred twice, but both were with my polluted index of ~77k
messages. Let me run for a bit now that I've cleaned out my string
labels and see what happens.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090906/5f1cedfa/attachment-0001.bin>
------------------------------
Message: 1038
Date: Sun, 06 Sep 2009 14:08:42 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: Sup Mailing List <sup-talk@rubyforge.org>
Subject: [sup-talk] [PATCH] small sent labels fixup
Message-ID: <1252260470-sup-6960@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Hi William,
I still wasn't seeing the sent label applied to things in my maildir.
The attached patch restores the behaviour for non sup://sent sent
sources.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-always-apply-label-sent-to-messages-in-sentmanager.patch
Type: application/octet-stream
Size: 689 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090906/2f2c39fa/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090906/2f2c39fa/attachment-0001.bin>
------------------------------
Message: 1039
Date: Sun, 06 Sep 2009 21:43:06 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Add 'a' and 'd' keybindings to
thread-view-mode to archive/delete current thread
Message-ID: <1252266137-sup-4139@peray>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Thu Sep 03 20:06:55 +0200 2009:
> Reformatted excerpts from Carl Worth's message of 2009-08-26:
> > These behave identically to the existing ",a" and ",d" commands, (that
> > is they archive or delete the current thread and then view the next).
>
> Sorry it's taken me so long to look at this. Thanks for the patch!
>
> I'm curious what other people think about this. On the one hand, it's
> only additional keybindings, so it's not going to adversely affect
> anyone. On the other hand, there is a nice balance with the ".", ","
> and "]" commands which this disrupts, and it can't be extended to the
> other commands from thread-index-mode. And on the third hand, I'm happy
> to have keybinding hooks.
>
> I guess if most people primarily closes their thread-view-modes using
> ",a" and ",d", then I'm fine with this.
I personally do prefer ]a and ]d, to read mail in the chronological order.
--
Nicolas Pouillard
http://nicolaspouillard.fr
------------------------------
Message: 1040
Date: Sun, 6 Sep 2009 23:04:22 +0200
From: Michael Hamann <michael@content-space.de>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH] sort labels in the dump
Message-ID:
<1252271062-8775-1-git-send-email-michael@content-space.de>
Sorting labels in the dump is useful when you e.g. want to keep track of
your dump using an incremental backup system that records diffs, with
this patch lines in the dump will only change when there is a real
change and no longer just because the random order of the labels
changes.
---
bin/sup-dump | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/bin/sup-dump b/bin/sup-dump
index 8b5bf07..7b33be5 100755
--- a/bin/sup-dump
+++ b/bin/sup-dump
@@ -26,5 +26,5 @@ Redwood::SourceManager.init
index.load
index.each_message :load_spam => true, :load_deleted => true, :load_killed => true do |m|
- puts "#{m.id} (#{m.labels.to_a * ' '})"
+ puts "#{m.id} (#{m.labels.to_a.sort_by { |l| l.to_s } * ' '})"
end
--
1.6.4.2
------------------------------
Message: 1041
Date: Mon, 07 Sep 2009 13:03:43 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: Michael Hamann <michael@content-space.de>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] sort labels in the dump
Message-ID: <1252321409-sup-2683@peray>
Content-Type: text/plain; charset=UTF-8
Excerpts from Michael Hamann's message of Sun Sep 06 23:04:22 +0200 2009:
> Sorting labels in the dump is useful when you e.g. want to keep track of
> your dump using an incremental backup system that records diffs, with
> this patch lines in the dump will only change when there is a real
> change and no longer just because the random order of the labels
> changes.
+1 for this change.
--
Nicolas Pouillard
http://nicolaspouillard.fr
------------------------------
Message: 1042
Date: Mon, 7 Sep 2009 21:47:53 +1000
From: Richard Sandilands <richard@infoarts.info>
To: sup-talk@rubyforge.org
Subject: [sup-talk] ArgumentError from thread: poll after loading
inbox
Message-ID:
<2e8d08f0909070447u73d6d2efq8eca89f229f890ed@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Am tracking 'next' branch and moved to Xapian earlier today.
I had Sup running when I slept my OS X laptop by shutting the lid.
Upon awakening, Sup raised the following error. Upon trying to run Sup
again from the prompt, the same error re-occurs:
I'm populating my local Maildirs using getmail from Gmail via POP.
===========
--- ArgumentError from thread: poll after loading inbox
expecting a symbol
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/label.rb:64:in `<<'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:114:in
`sync_message'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/set.rb:195:in
`each'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/set.rb:195:in
`each_key'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/set.rb:195:in
`each'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:114:in
`sync_message'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:87:in `add_message'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/poll.rb:166:in `add_new_message'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/poll.rb:110:in `do_poll'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/poll.rb:152:in `each_message_from'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/maildir.rb:160:in `each'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/maildir.rb:157:in `upto'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/maildir.rb:157:in `each'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:560:in `send'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:560:in `__pass'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:547:in `method_missing'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/poll.rb:140:in `each_message_from'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/poll.rb:93:in `do_poll'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/poll.rb:81:in `each'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/poll.rb:81:in `do_poll'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/poll.rb:80:in `synchronize'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/poll.rb:80:in `do_poll'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/modes/poll-mode.rb:15:in `poll'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/poll.rb:48:in `poll'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
/Users/richard/src/mainline/bin/sup:196
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup.rb:77:in `reporting_thread'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup.rb:75:in `initialize'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup.rb:75:in `new'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup.rb:75:in `reporting_thread'
/Users/richard/src/mainline/bin/sup:196
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:669:in
`call'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:669:in
`__unprotected_load_threads'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:610:in
`call'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:610:in
`load_n_threads_background'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup.rb:77:in `reporting_thread'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup.rb:75:in `initialize'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup.rb:75:in `new'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup.rb:75:in `reporting_thread'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:608:in
`load_n_threads_background'
/Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:679:in
`__unprotected_load_threads'
(eval):12:in `load_threads'
/Users/richard/src/mainline/bin/sup:196
==============
--
Richard
------------------------------
Message: 1043
Date: Mon, 7 Sep 2009 10:04:50 -0700
From: Andrew Pimlott <andrew@pimlott.net>
To: sup-talk@rubyforge.org
Subject: [sup-talk] sup-sync and xapian memory usage
Message-ID: <20090907170450.GO14010@pimlott.net>
Content-Type: text/plain; charset=us-ascii
Last time I tried to use sup[1], I posted about sup-sync crashing with
various symptoms of memory exhaustion[2]. I've tried again (using git
mainline), with similar results, but now I have a bit more to say about
it.
I am running on a fairly low-memory virtual machine. I think some of
the variability in what I was seeing before had to do with what other
things were running. Sorry about not being aware of this before. In
the following, I have pretty well controlled for other system memory
use. All of these tests are done on the same mbox with all indices
cleared.
Some of the failures I see are out of memory when running gpg
("Errno::ENOMEM Exception: Cannot allocate memory - /usr/bin/gpg" ...).
I stopped at that point in the debugger and found that at this point,
the ruby backtick operator fails the same way on any command. Using
strace, I saw a failure in clone:
20528 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7cb3908) = -1 ENOMEM (Cannot allocate memory)
top reports 2.5M of physical and 30M of swap free, so I don't really
know why clone fails, but I guess there's not much you can do about
that.
Other failures were the result of sup blowing up on messages with large
attachments. sup's memory use is many times the attachment size.
Testing on an mbox with a single message with 4 ~5M (encoded size)
attachments (total file size ~21M), sup goes up to ~150M. Accounting
for baseline, that's about 6 times the file size. I hope that can be
improved. FWIW, mutt never seems to try to load a whole attachment into
memory.
Using the ferret index, the memory (virtual as reported by Linux)
behaviour of sup-sync is pretty good. It starts out 25M and levels out
around 31M. It spikes from time to time, presumably because of large
messages, but it comes right back. After processing the last message,
it uses another 10M to finish up.
Using the xapian index, things are different. It starts at 32M and
steadily climbs to 77M after ~3500 messages, or around 1M every 100
messages. It does seem to climb faster at first and then more slowly.
Either xapian is keeping a cache (but some searches suggest it doesn't),
it's leaking memory, or it's allocating memory in a way that the the
allocator can't reclaim the VM space. Any ideas?
BTW, is there really no way to ask for ruby's heap size with (unpatched)
ruby 1.8?
Andrew
[1] This is about the fourth time. I seem to be easily discouraged.
[2] http://rubyforge.org/pipermail/sup-talk/2009-May/002171.html
------------------------------
Message: 1044
Date: Mon, 07 Sep 2009 14:14:41 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup-sync and xapian memory usage
Message-ID: <1252347051-sup-135@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Andrew Pimlott's message of Mon Sep 07 13:04:50 -0400 2009:
> I am running on a fairly low-memory virtual machine. I think some of
> the variability in what I was seeing before had to do with what
> other
I'm running sup on real hardware w/1GB physical ram.
> things were running. Sorry about not being aware of this before. In
> the following, I have pretty well controlled for other system memory
> use. All of these tests are done on the same mbox with all indices
> cleared.
>
> Some of the failures I see are out of memory when running gpg
> ("Errno::ENOMEM Exception: Cannot allocate memory - /usr/bin/gpg" ...).
> I stopped at that point in the debugger and found that at this point,
> the ruby backtick operator fails the same way on any command. Using
> strace, I saw a failure in clone:
I found sup crashed this morning too with an ENOMEM on a gpg
operation. I thought I may actually have been at the memory
exhaustion point normally though as I run screen and tend to leave
lots of sessions going all the time.
> Using the xapian index, things are different. It starts at 32M and
> steadily climbs to 77M after ~3500 messages, or around 1M every 100
> messages. It does seem to climb faster at first and then more
> slowly.
I've never paid attention to this before, but currently, my sup
process (running for about 6 hours now) looks like it's using ~77M
virtual with 59 of that resident.
This has only happened to me once, but since you reported it, I
thought I'd chime in with some extra data.
HTH.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090907/4318eb38/attachment-0001.bin>
------------------------------
Message: 1045
Date: Mon, 07 Sep 2009 14:33:06 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup-sync and xapian memory usage
Message-ID: <1252348258-sup-415@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from Andrew Pimlott's message of Mon Sep 07 13:04:50 -0400 2009:
> Using the xapian index, things are different. It starts at 32M and
> steadily climbs to 77M after ~3500 messages, or around 1M every 100
> messages. It does seem to climb faster at first and then more slowly.
> Either xapian is keeping a cache (but some searches suggest it doesn't),
> it's leaking memory, or it's allocating memory in a way that the the
> allocator can't reclaim the VM space. Any ideas?
Xapian keeps writes buffered in memory. Try setting the environment
variable XAPIAN_FLUSH_THRESHOLD to a smaller value (the default is 10000
documents) and see if that helps.
------------------------------
Message: 1046
Date: Mon, 07 Sep 2009 15:11:58 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup-sync and xapian memory usage
Message-ID: <1252350686-sup-8800@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Rich Lane's message of Mon Sep 07 14:33:06 -0400 2009:
> Xapian keeps writes buffered in memory. Try setting the environment
> variable XAPIAN_FLUSH_THRESHOLD to a smaller value (the default is 10000
> documents) and see if that helps.
Does this explain the lag at shutdown? Xapian is flushing writes to
disk?
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090907/b8fec298/attachment-0001.bin>
------------------------------
Message: 1047
Date: Mon, 07 Sep 2009 15:15:08 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup-sync and xapian memory usage
Message-ID: <1252350896-sup-5026@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from Ben Walton's message of Mon Sep 07 15:11:58 -0400 2009:
> Excerpts from Rich Lane's message of Mon Sep 07 14:33:06 -0400 2009:
> > Xapian keeps writes buffered in memory. Try setting the environment
> > variable XAPIAN_FLUSH_THRESHOLD to a smaller value (the default is 10000
> > documents) and see if that helps.
>
> Does this explain the lag at shutdown? Xapian is flushing writes to
> disk?
Yep.
------------------------------
Message: 1048
Date: Mon, 7 Sep 2009 12:26:11 -0700
From: Andrew Pimlott <andrew@pimlott.net>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] sup-sync and xapian memory usage
Message-ID: <20090907192611.GQ14010@pimlott.net>
Content-Type: text/plain; charset=us-ascii
On Mon, Sep 07, 2009 at 02:33:06PM -0400, Rich Lane wrote:
> Xapian keeps writes buffered in memory. Try setting the environment
> variable XAPIAN_FLUSH_THRESHOLD to a smaller value (the default is 10000
> documents) and see if that helps.
Thanks--it was hard for me to find that kind of information. I first
tried setting XAPIAN_FLUSH_THRESHOLD to 1, and sup-sync ran slowly and
just kept getting slower:
## read 139m (about 7%) @ 9.2m/s. 0:00:15 elapsed, about 0:03:21 remaining
...
## read 1238m (about 35%) @ 3.1m/s. 0:06:36 elapsed, about 0:12:08 remaining
I stopped at this point because it was taking too long. The memory use
seemed stable, but that could have been because it was making such slow
progress. I guess xapian gets a lot slower writing as the db grows?
That's a bit discouraging. Using ferret, sup-sync only dropped from
28.1m/s to 27.3m/s during its run. For reference, when I didn't set
XAPIAN_FLUSH_THRESHOLD, I was getting 35-36m/s until it ran out of
memory.
I then set XAPIAN_FLUSH_THRESHOLD to 100 and got more reasonable
results. It started at 25.6m/s and slowed to 17.8m/s. It stabilized at
around 41M virtual memory used and finished successfuly. I also note
that the memory use didn't jump during the finish-up phase ("Deleting
missing messages") as it had with ferret.
Finally, I set XAPIAN_FLUSH_THRESHOLD to 1000. It started at 34.6m/s
and dropped to 29.8m/s., stabilized at around 51M virtual memory, and
finished successfully. In this case, it stays faster than ferret, but
it sill bugs me that xapian still slows down while ferret doesn't.
So I conclude... I don't know what I conclude. Letting xapian use a lot
of memory sure helps its performance. And a big sup-sync should only
have to be done rarely. So maybe just document that those on low-memory
systems should consider using XAPIAN_FLUSH_THRESHOLD during sup-sync.
Thanks again for your help!
Andrew
------------------------------
Message: 1049
Date: Fri, 4 Sep 2009 09:02:12 +1000
From: infoarts@gmail.com
To: sup-talk@rubyforge.org
Subject: [sup-talk] Can't add a local maildir source
Message-ID:
<2e8d08f0909031602r37472cdcjcf4826f7cd2b48c7@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi there
I'm tracking next via git and am having trouble adding a mail source.
I've removed any existing ~/.sup directory, then run sup-config and
all is OK until sup-config runs sup-add maildir when I get this
message:
"Ok, trying to run "/Users/richard/src/sup/bin/sup-add
maildir:/Users/richard/mail/gmail/INBOX"...
/Users/richard/src/sup/lib/sup/index.rb:177: undefined method `[]' for
false:FalseClass (NoMethodError)
from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in
`gem_original_require'
from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in `require'
from /Users/richard/src/sup/lib/sup.rb:277
from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in
`gem_original_require'
from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in `require'
from /Users/richard/src/sup/bin/sup-add:7
So I'm thinking this might have something to do with my environment
setup on OS X.
I'm running sup from ~/src/sup and am mirroring my gmail mail to
~/mail/gmail via offlineimap - this all seems fine.
I've added: 'export RUBYLIB="~/src/sup/lib" ' to my .bash_profile but
it still fails on the 'require "sup"' line in sup-add
I've checked that I have all the required gem dependencies and that
seems fine too.
And I installed the sup-999 gems.
What could I be missing here?
Any clues appreciated...
--
Richard
------------------------------
Message: 1050
Date: Mon, 07 Sep 2009 18:21:35 +0200
From: Gaute Hope <eg@gaute.vetsj.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] lbdb module for sup
Message-ID: <1252340369-sup-9611@qwerzila>
Content-Type: text/plain; charset="utf-8"
Greetings,
attached is a lbdb (http://sup.rubyforge.org/wiki/wiki.pl?LbdbIntegration)
module for the sup contact list. Useful if you want access to the sup
contact list from Vim.
put in .lbdb/modules and add .lbdb/modules to your MODULES_PATH in
.lbdbrc aswell as adding the m_sup module to the modules list.
- gaute
-------------- next part --------------
A non-text attachment was scrubbed...
Name: m_sup
Type: application/octet-stream
Size: 289 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090907/8dd9e60d/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090907/8dd9e60d/attachment-0001.bin>
------------------------------
Message: 1051
Date: Tue, 08 Sep 2009 00:46:50 +0200
From: Israel Herraiz <isra@herraiz.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Identify list messages by list-id if
list-post is not present
Message-ID: <1252363563-sup-1774@elly>
Content-Type: text/plain; charset=utf8
Excerpts from William Morgan's message of Fri Sep 04 15:56:41 +0200 2009:
> Actually you're right. I think I prefer your patch. But based on the
> code, it seems like reply-mode would crash if it got a message that
> claims it's a list message but doesn't have a list address. Does it
> actually work?
Umm. Yes, you are right. It fails because there is no list
address. Let me figure out another solution for this, I will send
another patch to the list.
Cheers,
Israel
------------------------------
Message: 1052
Date: Tue, 08 Sep 2009 05:25:50 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Identify list messages by list-id if
list-post is not present
Message-ID: <1252412603-sup-9617@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Israel Herraiz's message of 2009-09-07:
> Umm. Yes, you are right. It fails because there is no list
> address. Let me figure out another solution for this, I will send
> another patch to the list.
We need to figure out what the right behavior should be when replying to
a message that you know is a list message, but where you don't know the
list address. If there's a reliable way of extracting the list address
from another header (From?), we can use that, but I suspect there isn't.
If there isn't a reliable wa, then maybe the original behavior is fine
(don't treat it specially at all).
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1053
Date: Tue, 08 Sep 2009 14:41:51 +0200
From: Israel Herraiz <isra@herraiz.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Identify list messages by list-id if
list-post is not present
Message-ID: <1252413599-sup-7371@elly>
Content-Type: text/plain; charset=utf8
Excerpts from William Morgan's message of Tue Sep 08 14:25:50 +0200 2009:
> We need to figure out what the right behavior should be when replying to
> a message that you know is a list message, but where you don't know the
> list address. If there's a reliable way of extracting the list address
> from another header (From?), we can use that, but I suspect there isn't.
> If there isn't a reliable wa, then maybe the original behavior is fine
> (don't treat it specially at all).
Well, yes, after all, the broken thing here is the list, that does not
have a list-post header. So I guess that what should be fixed is that
list, not Sup :-).
I did not realize about the list address bug before sending the patch,
that's why I asked it to be merged. However, I am afraid you are
right, and I think it is worthless to implement this behavior.
Cheers,
Israel
------------------------------
Message: 1054
Date: Tue, 08 Sep 2009 06:15:49 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup-sync and xapian memory usage
Message-ID: <1252415545-sup-3158@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Andrew Pimlott's message of 2009-09-07:
> Last time I tried to use sup[1], I posted about sup-sync crashing with
> various symptoms of memory exhaustion[2].
Excellent resolution to that thread.
> sup's memory use is many times the attachment size. Testing on an
> mbox with a single message with 4 ~5M (encoded size) attachments
> (total file size ~21M), sup goes up to ~150M. Accounting for
> baseline, that's about 6 times the file size. I hope that can be
> improved.
Sup uses the unmaintained RubyMail for MIME handling. I'm sure this
behavior can be improved if you can find someone who wants to write some
MIME handling code. Personally that's near the bottom of my list.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1055
Date: Tue, 08 Sep 2009 06:39:12 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup-sync and xapian memory usage
Message-ID: <1252415772-sup-7288@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Rich Lane's message of 2009-09-07:
> Excerpts from Ben Walton's message of Mon Sep 07 15:11:58 -0400 2009:
> > Excerpts from Rich Lane's message of Mon Sep 07 14:33:06 -0400 2009:
> > > Xapian keeps writes buffered in memory. Try setting the
> > > environment variable XAPIAN_FLUSH_THRESHOLD to a smaller value
> > > (the default is 10000 documents) and see if that helps.
> >
> > Does this explain the lag at shutdown? Xapian is flushing writes to
> > disk?
>
> Yep.
Good to know. Is there a way to force a flush in Xapian? Just curious.
The delay is a little scary sometimes. Maybe it just needs an
appropriate message somewhere.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1056
Date: Tue, 08 Sep 2009 09:58:15 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup-sync and xapian memory usage
Message-ID: <1252418267-sup-8800@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Tue Sep 08 09:39:12 -0400 2009:
> Good to know. Is there a way to force a flush in Xapian? Just curious.
> The delay is a little scary sometimes. Maybe it just needs an
> appropriate message somewhere.
...even just a message indicating that xapian is flushing the buffered
writes would be a good thing.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090908/fa461b0e/attachment-0001.bin>
------------------------------
Message: 1057
Date: Wed, 09 Sep 2009 00:27:10 +1000
From: Richard Heycock <rgh@roughage.com.au>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup-sync and xapian memory usage
Message-ID: <1252419716-sup-3031@roughage.com.au>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Tue Sep 08 23:39:12 +1000 2009:
> Reformatted excerpts from Rich Lane's message of 2009-09-07:
> > Excerpts from Ben Walton's message of Mon Sep 07 15:11:58 -0400 2009:
> > > Excerpts from Rich Lane's message of Mon Sep 07 14:33:06 -0400 2009:
> > > > Xapian keeps writes buffered in memory. Try setting the
> > > > environment variable XAPIAN_FLUSH_THRESHOLD to a smaller value
> > > > (the default is 10000 documents) and see if that helps.
> > >
> > > Does this explain the lag at shutdown? Xapian is flushing writes to
> > > disk?
> >
> > Yep.
>
> Good to know. Is there a way to force a flush in Xapian? Just curious.
> The delay is a little scary sometimes. Maybe it just needs an
> appropriate message somewhere.
Xapian, by default, flushes every 10 000 documents which in email terms
is a pretty long time! You can force a flush but it does increase your
IO significantly. Having said that emails are fairly small so flushing
every 10 or 20 emails might not be too bad.
Maybe it could be dynamic, if there is a high volume of incoming emails
flushing could be done after 50 or 100 emails or a timer based flush
might be easier.
rgh
------------------------------
Message: 1058
Date: Tue, 08 Sep 2009 17:14:22 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: Richard Heycock <rgh@roughage.com.au>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup-sync and xapian memory usage
Message-ID: <1252422827-sup-805@peray>
Content-Type: text/plain; charset=UTF-8
Excerpts from Richard Heycock's message of Tue Sep 08 16:27:10 +0200 2009:
> Excerpts from William Morgan's message of Tue Sep 08 23:39:12 +1000 2009:
> > Reformatted excerpts from Rich Lane's message of 2009-09-07:
> > > Excerpts from Ben Walton's message of Mon Sep 07 15:11:58 -0400 2009:
> > > > Excerpts from Rich Lane's message of Mon Sep 07 14:33:06 -0400 2009:
> > > > > Xapian keeps writes buffered in memory. Try setting the
> > > > > environment variable XAPIAN_FLUSH_THRESHOLD to a smaller value
> > > > > (the default is 10000 documents) and see if that helps.
> > > >
> > > > Does this explain the lag at shutdown? Xapian is flushing writes to
> > > > disk?
> > >
> > > Yep.
> >
> > Good to know. Is there a way to force a flush in Xapian? Just curious.
> > The delay is a little scary sometimes. Maybe it just needs an
> > appropriate message somewhere.
>
> Xapian, by default, flushes every 10 000 documents which in email terms
> is a pretty long time! You can force a flush but it does increase your
> IO significantly. Having said that emails are fairly small so flushing
> every 10 or 20 emails might not be too bad.
>
> Maybe it could be dynamic, if there is a high volume of incoming emails
> flushing could be done after 50 or 100 emails or a timer based flush
> might be easier.
Should the '$' command, force a write of the Xapian database?
--
Nicolas Pouillard
http://nicolaspouillard.fr
------------------------------
Message: 1059
Date: Tue, 08 Sep 2009 09:17:18 -0600
From: Wirt Wolff <wirtwolff@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Add 'a' and 'd' keybindings to
thread-view-mode to archive/delete current thread
Message-ID: <1252422961-sup-9843@chigamba>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Thu Sep 03 12:06:55 -0600 2009:
> Reformatted excerpts from Carl Worth's message of 2009-08-26:
> > These behave identically to the existing ",a" and ",d" commands, (that
> > is they archive or delete the current thread and then view the next).
>
> Sorry it's taken me so long to look at this. Thanks for the patch!
>
> I'm curious what other people think about this. On the one hand, it's
> only additional keybindings, so it's not going to adversely affect
> anyone. On the other hand, there is a nice balance with the ".", ","
> and "]" commands which this disrupts, and it can't be extended to the
> other commands from thread-index-mode. And on the third hand, I'm happy
> to have keybinding hooks.
>
> I guess if most people primarily closes their thread-view-modes using
> ",a" and ",d", then I'm fine with this.
Don't mind having 'a' and 'd' around, but likely won't use them.
Generally I pass down index with &, A, S, etc. occaisionally reading
high priority thread, then ]n, ]a etc. back up in thread view.
--
wmw
------------------------------
Message: 1060
Date: Tue, 08 Sep 2009 12:21:47 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] small sent labels fixup
Message-ID: <1252437698-sup-9601@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Walton's message of 2009-09-06:
> I still wasn't seeing the sent label applied to things in my maildir.
> The attached patch restores the behaviour for non sup://sent sent
> sources.
Applied, thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1061
Date: Tue, 08 Sep 2009 12:45:32 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: Sup-talk mailing list <sup-talk@rubyforge.org>
Subject: [sup-talk] master branch merge report
Message-ID: <1252438950-sup-3895@masanjin.net>
Content-Type: text/plain; charset=UTF-8
On preparation for an 0.9 release, I've merged the following branches
into master (in case anyone's keeping track!): console-mode,
reply-all-keybindings, restore-state, logging-tweaks,
enclosed-message-display-tweaks, hook-local-vars.
If anyone's running master, keep an eye out for changes and problems.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1062
Date: Tue, 08 Sep 2009 21:51:56 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: Sup-talk mailing list <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] master branch merge report
Message-ID: <1252439403-sup-6192@peray>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Tue Sep 08 21:45:32 +0200 2009:
> On preparation for an 0.9 release, I've merged the following branches
> into master (in case anyone's keeping track!): console-mode,
> reply-all-keybindings, restore-state, logging-tweaks,
> enclosed-message-display-tweaks, hook-local-vars.
>
> If anyone's running master, keep an eye out for changes and problems.
Thanks for these reports on the status of branches. They are really precious.
May ask for more? :) I would like you to also report on the status of what is
merged in next (or not yet merged in master).
--
Nicolas Pouillard
http://nicolaspouillard.fr
------------------------------
Message: 1063
Date: Tue, 08 Sep 2009 13:05:14 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: Sup-talk mailing list <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] master branch merge report
Message-ID: <1252440062-sup-8543@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Nicolas Pouillard's message of 2009-09-08:
> Thanks for these reports on the status of branches. They are really
> precious. May ask for more? :) I would like you to also report on the
> status of what is merged in next (or not yet merged in master).
The only branches not merged into master at this point are
preemptive-loading and alignment-tweaks. This is based on a gut estimate
of whether they need to bake a little longer.
You can always get a complete report by using git wtf
(http://git-wt-commit.rubyforge.org/git-wtf). `git wtf -r -s master` and
`git wtf -r -s next` will show you what's merged into master and next
respectively.
I've also just merged custom-search-hook into master, with some effort.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1064
Date: Tue, 08 Sep 2009 13:08:03 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Add 'a' and 'd' keybindings to
thread-view-mode to archive/delete current thread
Message-ID: <1252440374-sup-9813@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Wirt Wolff's message of 2009-09-08:
> Don't mind having 'a' and 'd' around, but likely won't use them.
So far I'm counting 3 yes votes (including patch submitter), 3 "won't
use them" votes (including me), and no one being offended. I think I'm
going to apply this.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1065
Date: Tue, 08 Sep 2009 13:26:45 -0700
From: Carl Worth <cworth@cworth.org>
To: Nicolas Pouillard <nicolas.pouillard@gmail.com>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Add 'a' and 'd' keybindings to
thread-view-mode to archive/delete current thread
Message-ID: <1252441461-sup-5330@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
Excerpts from Nicolas Pouillard's message of Sun Sep 06 12:43:06 -0700 2009:
> I personally do prefer ]a and ]d, to read mail in the chronological order.
What if there were a way to reverse the sort order for the index view?
That would then change the meaning of "next" and "previous" and then
you could use the single letter 'a' and 'd' commands to read your mail
in chronological order.
Would that make sense? Because that is something I would like to do on
occasion.
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090908/01fd44fe/attachment-0001.bin>
------------------------------
Message: 1066
Date: Tue, 08 Sep 2009 22:28:56 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: Sup-talk mailing list <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] master branch merge report
Message-ID: <1252441390-sup-9847@peray>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Tue Sep 08 22:05:14 +0200 2009:
> Reformatted excerpts from Nicolas Pouillard's message of 2009-09-08:
> > Thanks for these reports on the status of branches. They are really
> > precious. May ask for more? :) I would like you to also report on the
> > status of what is merged in next (or not yet merged in master).
>
> The only branches not merged into master at this point are
> preemptive-loading and alignment-tweaks. This is based on a gut estimate
> of whether they need to bake a little longer.
OK nice.
> You can always get a complete report by using git wtf
> (http://git-wt-commit.rubyforge.org/git-wtf). `git wtf -r -s master` and
> `git wtf -r -s next` will show you what's merged into master and next
> respectively.
I already use git-wtf (thanks for this tool BTW), with still some pain though.
These two commands outputs ~60 lines about dozen of branches. However that's
mainly due to the fact that I do have private branches.
It would be nice to simply ask differences between to branches in terms of
merged branches: git wtf mainline/master..mainline/next
> I've also just merged custom-search-hook into master, with some effort.
Thanks
--
Nicolas Pouillard
http://nicolaspouillard.fr
------------------------------
Message: 1067
Date: Tue, 08 Sep 2009 22:33:13 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: Carl Worth <cworth@cworth.org>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Add 'a' and 'd' keybindings to
thread-view-mode to archive/delete current thread
Message-ID: <1252441854-sup-203@peray>
Content-Type: text/plain; charset=UTF-8
Excerpts from Carl Worth's message of Tue Sep 08 22:26:45 +0200 2009:
> Excerpts from Nicolas Pouillard's message of Sun Sep 06 12:43:06 -0700 2009:
> > I personally do prefer ]a and ]d, to read mail in the chronological order.
>
> What if there were a way to reverse the sort order for the index view?
> That would then change the meaning of "next" and "previous" and then
> you could use the single letter 'a' and 'd' commands to read your mail
> in chronological order.
>
> Would that make sense? Because that is something I would like to do on
> occasion.
Yes it does make sense. This change would both improve this feature and
will reduce the default enforcement.
Regards,
--
Nicolas Pouillard
http://nicolaspouillard.fr
------------------------------
Message: 1068
Date: Tue, 08 Sep 2009 13:38:35 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] ArgumentError from thread: poll after loading
inbox
Message-ID: <1252442225-sup-154@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Richard Sandilands's message of 2009-09-07:
> Am tracking 'next' branch and moved to Xapian earlier today.
Do you have a before-add-message hook? If so, I'm sorry to say that you
will have to regenerate your index to fix this. There was a problem with
next for a while that allowed that hook to add non-symbol labels to
messages, and those got serialized into Xapian's index.
If not, regenerating it will probably help, but it would be good to find
the source of the non-symbol labels.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1069
Date: Tue, 08 Sep 2009 13:45:08 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] lbdb module for sup
Message-ID: <1252442690-sup-9709@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Gaute Hope's message of 2009-09-07:
> attached is a lbdb (http://sup.rubyforge.org/wiki/wiki.pl?LbdbIntegration)
> module for the sup contact list. Useful if you want access to the sup
> contact list from Vim.
Thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1070
Date: Tue, 08 Sep 2009 13:47:18 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Can't add a local maildir source
Message-ID: <1252442749-sup-842@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from infoarts's message of 2009-09-03:
> I'm tracking next via git and am having trouble adding a mail source.
This should be fixed in the latest next. Sorry about that!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1071
Date: Tue, 08 Sep 2009 13:50:52 -0700
From: Carl Worth <cworth@cworth.org>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Change color of 'highlight' indicator in inbox
view?
Message-ID: <1252442174-sup-1472@yoom.home.cworth.org>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Sun Sep 06 06:07:48 -0700 2009:
> Reformatted excerpts from Richard Sandilands's message of 2009-09-06:
> > Is there a setting for this element?
>
> Currently the highlight color is generated programmatically, so there's
> no setting in colors.yaml. You can edit colormap.rb#highlight_for (circa
> line 82) if you want.
Thanks for pointing this out. The highlight color has been one of the
last color annoyances for me, but I hadn't done the effort to find
this in the code yet.
> Ideas on how to move this configuration to colors.yaml (or some other
> configuration mechanism) welcome.
What I think I would really like is a mode where none of the
foreground colors/attributes change at all, (it seems distracting to
have the text invert while trying to process mail quickly).
Instead, I'd like the highlight to be a subtle change in the
background color, (but still light or dark like the background so that
the foreground colors are all still readable).
I poked around at this, and my terminal does have two variants of each
of 8 colors available (one brighter than the other), so it seemed like
I should be able to use one as the normal background and one as the
highlight background. But on looking closer, it appears that the
terminal color support here is to name the 8 different colors and to
select the variant for each with the bold attribute. So if I'm
understanding that correctly, that's 16 colors available for the
foreground, but only 8 for the background. That's frustrating.
Such a limited color selection is almost unimaginable with hardware
capability today. (I do see references to "xterm-256color"[*] terminal
definitions. Could sup start depending on things like that? Are there
users of sup using the Linux console or so, and does that support
256-color escape codes?).
Anyway, I gave up for now and decided not to use color for highlight
at all. Instead, I did:
def highlight_for fg, bg, attrs
[fg, bg, attrs + [Curses::A_UNDERLINE]]
I should figure out how to make the underline vs. color choice for
highlighting to be a configuration option in order to propose this as
a proper patch. But I still would prefer a subtle change in the
background color instead of an underline if anyone can figure out how
to give me that[**].
-Car
[*] And even 256 colors is antiquated. Anything requiring a fixed
palette is very constraining on an application author today.
[**] Of course, one way is to go away from a curses-based
interface. That might very well make sense in the future where sup is
implemented as a protocol and we can easily have multiple clients. For
me, a graphical client won't be of any interest unless it allows full
keyboard control exactly as sup does, but if it does that and renders
text as well as my terminal, I could imagine using it.
------------------------------
Message: 1072
Date: Wed, 9 Sep 2009 07:13:07 +1000
From: Richard Sandilands <richard@infoarts.info>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] ArgumentError from thread: poll after loading
inbox
Message-ID:
<2e8d08f0909081413i402cbb71sfbff3b1fb5e59a2f@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Sep 9, 2009 at 6:38 AM, William Morgan<wmorgan-sup@masanjin.net> wrote:
> Do you have a before-add-message hook? If so, I'm sorry to say that you
> will have to regenerate your index to fix this. There was a problem with
> next for a while that allowed that hook to add non-symbol labels to
> messages, and those got serialized into Xapian's index.
I do indeed, as follows:
if message.subj =~ /\[sup-talk\]/
message.add_label "sup"
message.add_label "list"
end
> If not, regenerating it will probably help, but it would be good to find
> the source of the non-symbol labels.
I do have some labels prepended with an ! to force them to sort to the
top of the 'L' list - such as '!followup', '!hold' etc. Could that be
an issue?
--
Richard
------------------------------
Message: 1073
Date: Tue, 8 Sep 2009 14:50:23 -0700
From: Sean Escriva <sean.escriva@gmail.com>
To: Ben Walton <bwalton@artsci.utoronto.ca>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] a few questions on mail handling with sup
Message-ID: <20090908215023.GA7134@gmail.com>
Content-Type: text/plain; charset=us-ascii
Excerpts from Ben Walton's message of Fri Sep 04 05:01:11 -0400 2009:
> Excerpts from Sean Escriva's message of Fri Sep 04 15:13:32 -0400 2009:
>
> > Currently I have no way to way move messages out of my inbox on the
> > imap server, since I'm accessing a local maildir created by
> > offlineimap. This is only an issue since mailboxes have a limit of
> > 800mb in size on the server and given the volume of mail I have that
> > will be reached every other month. I've looked at imap filter and this
> > could possibly work, but anyone have experience with this sort of
> > sitatuation?
>
> Could you pull it down with fetchmail into a local MTA setup that only
> handles local delivery? Fetchmail has the 'delete on server' option
> if offlineimap doesn't.
thanks for the reply. fetchmail/procmail is a better option in this
case than offlineimap. No need to setup a whole different MTA since I
am already using msmtp for sending...
thanks again.
-sme
------------------------------
Message: 1074
Date: Wed, 09 Sep 2009 02:18:09 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup-sync and xapian memory usage
Message-ID: <1252427486-sup-8093@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from Nicolas Pouillard's message of Tue Sep 08 11:14:22 -0400 2009:
> Excerpts from Richard Heycock's message of Tue Sep 08 16:27:10 +0200 2009:
> > Excerpts from William Morgan's message of Tue Sep 08 23:39:12 +1000 2009:
> > > Reformatted excerpts from Rich Lane's message of 2009-09-07:
> > > > Excerpts from Ben Walton's message of Mon Sep 07 15:11:58 -0400 2009:
> > > > > Excerpts from Rich Lane's message of Mon Sep 07 14:33:06 -0400 2009:
> > > > > > Xapian keeps writes buffered in memory. Try setting the
> > > > > > environment variable XAPIAN_FLUSH_THRESHOLD to a smaller value
> > > > > > (the default is 10000 documents) and see if that helps.
> > > > >
> > > > > Does this explain the lag at shutdown? Xapian is flushing writes to
> > > > > disk?
> > > >
> > > > Yep.
> > >
> > > Good to know. Is there a way to force a flush in Xapian? Just curious.
> > > The delay is a little scary sometimes. Maybe it just needs an
> > > appropriate message somewhere.
> >
> > Xapian, by default, flushes every 10 000 documents which in email terms
> > is a pretty long time! You can force a flush but it does increase your
> > IO significantly. Having said that emails are fairly small so flushing
> > every 10 or 20 emails might not be too bad.
> >
> > Maybe it could be dynamic, if there is a high volume of incoming emails
> > flushing could be done after 50 or 100 emails or a timer based flush
> > might be easier.
>
> Should the '$' command, force a write of the Xapian database?
I think once we're saving label changes to the index immediately we
could re-purpose '$' for this. I've also been considering a timer, as
Richard suggests, which would trigger a flush once the user has been
idle for some time.
A fatal exception in Sup is still a clean exit as far as SWIG is
concerned and the Xapian database destructor will do the flush for us in
that case, so don't worry about random Sup exceptions causing data loss.
------------------------------
Message: 1075
Date: Wed, 09 Sep 2009 09:54:53 +0200
From: Gaute Hope <eg@gaute.vetsj.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Exception when trying to open console view
Message-ID: <1252482842-sup-4833@qwerzila>
Content-Type: text/plain; charset="utf-8"
Greetings,
I get this exception when pressing '~' in the main view:
--- ArgumentError from thread: main
wrong number of arguments (0 for 1)
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/console-mode.rb:67:in `initialize'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/console-mode.rb:67:in `initialize'
/home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:302:in `new'
/home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:302
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/buffer.rb:341:in `spawn_unless_exists'
/home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:302
/home/gaute/.gem/ruby/1.8/bin/sup:19:in `load'
/home/gaute/.gem/ruby/1.8/bin/sup:19
Cheers, Gaute
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090909/b3e999f6/attachment-0001.bin>
------------------------------
Message: 1076
Date: Wed, 09 Sep 2009 10:49:21 +0200
From: Gaute Hope <eg@gaute.vetsj.com>
To: Sup Talk <sup-talk@rubyforge.org>
Subject: [sup-talk] updated before-poll hook for offlineimap
Message-ID: <1252485986-sup-4958@qwerzila>
Content-Type: text/plain; charset="utf-8"
Greetings,
Here's an updated before-poll.rb hook for offlineimap working with
latest git. I'm suppressing some nasty python deprecation errors as
well.
before-poll.rb:
def offlineimap(*folders)
cmd = "offlineimap -u Noninteractive.Basic 2>&1"
cmd << " -f #{folders * ','}" unless folders.compact.empty?
`#{cmd}`
end
def folder_names(sources)
sources.map { |s| s.uri.split('/').last }
end
def inbox_sources(sources = SourceManager.sources)
sources.find_all { |s| !s.archived? }.sort_by {|s| s.id }
end
if (@last_fetch || Time.at(0)) < Time.now - 120
say "Running offlineimap..."
# only check non-auto-archived sources on the first run
log offlineimap(@last_fetch ? nil : folder_names(inbox_sources))
say "Finished offlineimap."
end
@last_fetch = Time.now
Cheers, Gaute
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090909/1b71019d/attachment-0001.bin>
------------------------------
Message: 1077
Date: Wed, 09 Sep 2009 09:54:55 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: Sup Mailing List <sup-talk@rubyforge.org>
Subject: [sup-talk] U (unread) search is off
Message-ID: <1252504368-sup-9406@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Since my update to Xapian, my U searches to display on unread mail
aren't working correctly any more. I get lots of mail that is
definitely read (doesn't show as new in the search buffer). Is anyone
else seeing this? I'm hoping to dig into it later today, but wanted
to fire of the query first.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090909/f80057be/attachment-0001.bin>
------------------------------
Message: 1078
Date: Wed, 09 Sep 2009 07:14:16 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Exception when trying to open console view
Message-ID: <1252505638-sup-6887@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Gaute Hope's message of 2009-09-09:
> --- ArgumentError from thread: main
> wrong number of arguments (0 for 1)
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/console-mode.rb:67:in `initialize'
Fixed in master and next. Sorry about that.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1079
Date: Wed, 09 Sep 2009 07:20:03 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] ArgumentError from thread: poll after loading
inbox
Message-ID: <1252505721-sup-2684@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Richard Sandilands's message of 2009-09-08:
> I do indeed, as follows:
Excellent.
> I do have some labels prepended with an ! to force them to sort to the
> top of the 'L' list - such as '!followup', '!hold' etc. Could that be
> an issue?
Nope, it was the hook above. (Which is fine, btw, it just triggered
something bad.) You will need to regenerate the index and everything
should be fine. Sorry about that.
If you don't have a recent dumpfile, you may have to apply the following
patch to get sup-dump to work. Then you should be able to git fetch,
reset the head to origin/next, and run `sup-sync --restored --restore
<dumpfile> --all-sources`.
Let me know if you run into problems.
diff --git a/lib/sup/label.rb b/lib/sup/label.rb
index 67474c2..b94474d 100644
--- a/lib/sup/label.rb
+++ b/lib/sup/label.rb
@@ -61,7 +61,7 @@ class LabelManager
end
def << t
- raise ArgumentError, "expecting a symbol" unless t.is_a? Symbol
+ t = t.to_sym
unless @labels.member?(t) || RESERVED_LABELS.member?(t)
@labels[t] = true
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1080
Date: Wed, 09 Sep 2009 07:30:43 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Change color of 'highlight' indicator in inbox
view?
Message-ID: <1252506333-sup-9244@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Carl Worth's message of 2009-09-08:
> So if I'm understanding that correctly, that's 16 colors available for
> the foreground, but only 8 for the background. That's frustrating.
Yup. Curses is happy to welcome you to 1982!
> Such a limited color selection is almost unimaginable with hardware
> capability today.
FWIW, most terminal emulators allow you to tweak the actual colors that
the curses colors refer to. So you have some flexibility about the
actual colors, just a small palette.
> (I do see references to "xterm-256color"[*] terminal definitions.
> Could sup start depending on things like that? Are there users of sup
> using the Linux console or so, and does that support 256-color escape
> codes?).
I'm not sure. I suspect no, but I would be interested in learning more.
> I should figure out how to make the underline vs. color choice for
> highlighting to be a configuration option in order to propose this as
> a proper patch.
I think the only patch I would accept at this point for tweaking the
highlight would be a new hook.
> Of course, one way is to go away from a curses-based interface. That
> might very well make sense in the future where sup is implemented as a
> protocol and we can easily have multiple clients.
That is one of the goals.
> For me, a graphical client won't be of any interest unless it allows
> full keyboard control exactly as sup does, but if it does that and
> renders text as well as my terminal, I could imagine using it.
I agree completely.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1081
Date: Wed, 09 Sep 2009 07:37:16 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Add 'a' and 'd' keybindings to
thread-view-mode to archive/delete current thread
Message-ID: <1252507021-sup-715@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from William Morgan's message of 2009-09-08:
> So far I'm counting 3 yes votes (including patch submitter), 3 "won't
> use them" votes (including me), and no one being offended. I think I'm
> going to apply this.
Applied to master. Thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1082
Date: Wed, 09 Sep 2009 07:38:59 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] sort labels in the dump
Message-ID: <1252507122-sup-5429@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Applied to master. Thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1083
Date: Wed, 09 Sep 2009 10:24:13 -0700
From: Carl Worth <cworth@cworth.org>
To: Sup Talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Thoughts on simplifying thread-view-mode
keybindings
Message-ID: <1252516237-sup-9414@yoom.home.cworth.org>
Content-Type: text/plain; charset=UTF-8
I only just barely got my proposal for new 'a' and 'd' keybindings
into master, and now I'm rethinking them to some extent.
Take a look at the existing keybindings for navigating away from the
current thread:
.a : Archive this thread and kill buffer
.d : Delete this thread and kill buffer
.s : Mark this thread as spam and kill buffer
.N : Mark this thread as unread and kill buffer
,a : Archive this thread, kill buffer, and view next
,d : Delete this thread, kill buffer, and view next
,s : Mark this thread as spam, kill buffer, and view next
,N : Mark this thread as unread, kill buffer, and view next
,n : Kill buffer, and view next
]a : Archive this thread, kill buffer, and view previous
]d : Delete this thread, kill buffer, and view previous
]s : Mark this thread as spam, kill buffer, and view previous
]N : Mark this thread as unread, kill buffer, and view previous
]n : Kill buffer, and view previous
Each of these keybindings involve two keys, and each command involves
two actions. But the order of the keybindings and actions are reversed.
Imagine, for a moment, what would happen if the keybinding order was
"fixed" to match the order of the commands, (that is, things like "a,"
for archive, then view next). With that change, we would no longer
need dual-key bindings as the single-key actions could be easily
combined with the same effect.
That is, we could have just:
a : Archive this thread
d : Delete this thread
s : Mark this thread as spam
N : Mark this thread as unread
., x : Kill this buffer
, : View next thread
] : View previous thread
That's definitely a simpler amount of documentation to have to grasp,
and shouldn't be any less work to actually use, (other than the pain
of having to retrain muscle memory to do things like "a," instead of
",a").
The next tweak I'd make is to choose keybdindings for 'next' and
'previous' that more obviously go together. (Such as '[' and ']', but
then I think I'd also expect '[' to mean previous and ']' to mean next
which might wreak havoc on muscle memory).
Finally, I'd personally still want a single-key keybinding to do my
most frequent combination, (such as archive-and-view-next as with the
current 'a' that just landed in master), but maybe that makes more
sense to happen only in a hook.
What do you all think?
Me, I'm pretty new to sup, so the muscle-memory thing isn't *too* big
an issue. Is sup still young enough as a tool to be able to accept
interface changes like this?
-Carl
------------------------------
Message: 1084
Date: Wed, 09 Sep 2009 10:32:30 -0700
From: Carl Worth <cworth@cworth.org>
To: Sup Talk <sup-talk@rubyforge.org>
Subject: [sup-talk] How hard would a universal undo be?
Message-ID: <1252517083-sup-58@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
Being a ruthless mail-processor, I sometimes archive or delete a
message hastily and realize a moment later that I actually want to
look at the message again.
Of course, if that happens when I'm in a thread-index-mode, then I can
just hit 'u' to undo and all is fine.
But if I make the same mistake in thread-view-mode then I'm currently
out of luck.
Would it be a small change to move the undo keybinding to somewhere
more universal?
As a first cut, I'd be happy if it just undid the changes to the
index, even without undoing any interface changes. That is, if my
previous command was archive-thread-and-view-next-thread, it would be
OK if it just undid the archiving part. Bonus points if it also undoes
the view-next part, but I can imagine that being more work.
Again, this is a feature I'd be happy to spend some time investigating
myself when I get the chance. I'd just be happy to hear any thoughts
on feasibility. And I'm trying to get in the habit of mentioning
issues as I run into them rather than waiting until I have the chance
to actually work on them, (at which point I may have forgotten the
issues).
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090909/28acedf6/attachment-0001.bin>
------------------------------
Message: 1085
Date: Wed, 09 Sep 2009 19:37:29 +0200
From: Gaute Hope <eg@gaute.vetsj.com>
To: Sup Talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] updated before-poll hook for offlineimap
Message-ID: <1252517773-sup-6259@qwerzila>
Content-Type: text/plain; charset="utf-8"
Greetings,
It seems like the before-poll.rb hooks is not run when i manually poll
for messages; pressing P. Could this be correct?
Running 8903cdedc81
- gaute
Excerpts from Gaute Hope's message of on. sep. 09 10:49:21 +0200 2009:
> Greetings,
>
> Here's an updated before-poll.rb hook for offlineimap working with
> latest git. I'm suppressing some nasty python deprecation errors as
> well.
>
> before-poll.rb:
> def offlineimap(*folders)
> cmd = "offlineimap -u Noninteractive.Basic 2>&1"
> cmd << " -f #{folders * ','}" unless folders.compact.empty?
> `#{cmd}`
> end
>
> def folder_names(sources)
> sources.map { |s| s.uri.split('/').last }
> end
>
> def inbox_sources(sources = SourceManager.sources)
> sources.find_all { |s| !s.archived? }.sort_by {|s| s.id }
> end
>
> if (@last_fetch || Time.at(0)) < Time.now - 120
> say "Running offlineimap..."
> # only check non-auto-archived sources on the first run
> log offlineimap(@last_fetch ? nil : folder_names(inbox_sources))
> say "Finished offlineimap."
> end
> @last_fetch = Time.now
>
> Cheers, Gaute
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090909/ea954818/attachment-0001.bin>
------------------------------
Message: 1086
Date: Thu, 10 Sep 2009 13:22:30 +0200
From: Ingmar Vanhassel <ingmar@exherbo.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] U (unread) search is off
Message-ID: <1252581713-sup-9701@cannonball>
Content-Type: text/plain; charset=UTF-8
Excerpts from Ben Walton's message of Wed Sep 09 15:54:55 +0200 2009:
>
> Since my update to Xapian, my U searches to display on unread mail
> aren't working correctly any more. I get lots of mail that is
> definitely read (doesn't show as new in the search buffer). Is anyone
> else seeing this? I'm hoping to dig into it later today, but wanted
> to fire of the query first.
>
> Thanks
> -Ben
Known issue, see http://mid.gmane.org/1251792282-sup-2057@cannonball and
Rich's answer to my mail.
--
Exherbo KDE, X.org maintainer
------------------------------
Message: 1087
Date: Thu, 10 Sep 2009 06:59:13 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] U (unread) search is off
Message-ID: <1252590993-sup-3885@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ingmar Vanhassel's message of 2009-09-10:
> Known issue, see http://mid.gmane.org/1251792282-sup-2057@cannonball and
> Rich's answer to my mail.
Actually, I haven't been following this too closely, but what is the status?
I noticed we have this in xapian_index.rb:
qp.default_op = Xapian::Query::OP_AND
Is that not sufficient (combined with a newish Xapian, I guess?) to fix
the problem?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1088
Date: Thu, 10 Sep 2009 15:57:42 +0200
From: Michael Stapelberg <michael+sup@stapelberg.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] GPG: Sending mail to people without a trust-path
Message-ID: <1252590996-sup-4087@midna>
Content-Type: text/plain; charset=UTF-8
Hi,
occasionally, I receive E-Mail by people who do not have any signatures or
at least no trust-path to me. sup (or GPG?) rejects to encrypt mail for such
people, just stating:
There is no indication that the key belongs to this user
It would be good if we can fix this somehow.
Best regards,
Michael
------------------------------
Message: 1089
Date: Thu, 10 Sep 2009 10:04:02 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] U (unread) search is off
Message-ID: <1252591407-sup-1747@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Thu Sep 10 09:59:13 -0400 2009:
> Is that not sufficient (combined with a newish Xapian, I guess?) to fix
> the problem?
I'm running 1.0.14. Maybe I need to update to 1.0.15 then?
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090910/d6b22755/attachment-0001.bin>
------------------------------
Message: 1090
Date: Thu, 10 Sep 2009 16:08:15 +0200
From: Ingmar Vanhassel <ingmar@exherbo.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] U (unread) search is off
Message-ID: <1252591597-sup-1906@cannonball>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Thu Sep 10 15:59:13 +0200 2009:
> Reformatted excerpts from Ingmar Vanhassel's message of 2009-09-10:
> > Known issue, see http://mid.gmane.org/1251792282-sup-2057@cannonball and
> > Rich's answer to my mail.
>
> Actually, I haven't been following this too closely, but what is the status?
> I noticed we have this in xapian_index.rb:
> qp.default_op = Xapian::Query::OP_AND
>
> Is that not sufficient (combined with a newish Xapian, I guess?) to fix
> the problem?
Refining a query still doesn't work: Searching for label:foo, then
piping through label:bar gives messages that even have neither label.
This is on xapian 1.0.15
--
Exherbo KDE, X.org maintainer
------------------------------
Message: 1091
Date: Thu, 10 Sep 2009 07:13:50 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk mailing list <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] How hard would a universal undo be?
Message-ID: <1252591706-sup-7219@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Carl Worth's message of 2009-09-09:
> Would it be a small change to move the undo keybinding to somewhere
> more universal?
The undo keybinding could definitely be moved from thread-index-mode to
the main event loop. That's a small change. The bigger amount of work is
writing undo lambdas for every operation you want to be able to undo,
e.g. every command in thread-view-mode. It's not complicated, just a
little tedious, IMO.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1092
Date: Thu, 10 Sep 2009 07:34:01 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] updated before-poll hook for offlineimap
Message-ID: <1252592969-sup-418@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Gaute Hope's message of 2009-09-09:
> It seems like the before-poll.rb hooks is not run when i manually poll
> for messages; pressing P. Could this be correct?
It should be. Are you sure the before-poll hook isn't dying the first
time it's run (automatically), causing Sup to skip it the second time
(when you press P)? You can look in the log buffer.
If that's not the case, can you confirm that PollManager#poll gets
invoked in both cases?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1093
Date: Thu, 10 Sep 2009 16:35:46 +0200
From: Marc Weber <marco-oweber@gmx.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] How hard would a universal undo be?
Message-ID: <1252592875-sup-5649@nixos>
Content-Type: text/plain; charset=UTF-8
Excerpts from Carl Worth's message of Wed Sep 09 19:32:30 +0200 2009:
> Being a ruthless mail-processor, I sometimes archive or delete a
> message hastily and realize a moment later that I actually want to
> look at the message again.
What about a "last viewed history" list?
Then you could use that to review the threads?
Maybe its best to add a property:
last-viewed-on: timestamp.
Then you can even use the existing search engine to view those threads ?
Marc Weber
------------------------------
Message: 1094
Date: Thu, 10 Sep 2009 07:36:22 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] GPG: Sending mail to people without a
trust-path
Message-ID: <1252593258-sup-7506@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Michael Stapelberg's message of 2009-09-10:
> occasionally, I receive E-Mail by people who do not have any signatures or
> at least no trust-path to me. sup (or GPG?) rejects to encrypt mail for such
> people, just stating:
>
> There is no indication that the key belongs to this user
>
> It would be good if we can fix this somehow.
It's a GPG behavior, which we can work around by adding --always-trust
to the GPG commandline, but I'm pretty sure someone will object to that.
Patches for a hook to run gpg in a user-defined matter will be accepted.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1095
Date: Thu, 10 Sep 2009 12:16:35 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] U (unread) search is off
Message-ID: <1252595946-sup-171@zyrg.net>
Content-Type: text/plain; charset=UTF-8
There are actually 2 bugs in this thread. Ben is still using Xapian
1.0.14 which doesn't have my fix for the phantom labels problem.
Ingmar's message was about the surprise Xapian::QueryParser feature.
Excerpts from William Morgan's message of Thu Sep 10 09:59:13 -0400 2009:
> Reformatted excerpts from Ingmar Vanhassel's message of 2009-09-10:
> > Known issue, see http://mid.gmane.org/1251792282-sup-2057@cannonball and
> > Rich's answer to my mail.
>
> Actually, I haven't been following this too closely, but what is the status?
> I noticed we have this in xapian_index.rb:
> qp.default_op = Xapian::Query::OP_AND
>
> Is that not sufficient (combined with a newish Xapian, I guess?) to fix
> the problem?
I thought it was, but it turns out that unless you explicitly add AND
operators Xapian will OR terms over the same field such that
"label:foo label:bar" gives you the union instead of the intersection.
We could fix this by patching Xapian to make this behavior configurable,
or we could come up with an index-agnostic simple query language that
doesn't support boolean operators. The native query language would still
be available, of course, but the simple one would suffice for most usage
and potentially have Sup-specific features.
------------------------------
Message: 1096
Date: Thu, 10 Sep 2009 12:17:11 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] U (unread) search is off
Message-ID: <1252599402-sup-3970@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from Ben Walton's message of Thu Sep 10 10:04:02 -0400 2009:
> Excerpts from William Morgan's message of Thu Sep 10 09:59:13 -0400 2009:
>
> > Is that not sufficient (combined with a newish Xapian, I guess?) to fix
> > the problem?
>
> I'm running 1.0.14. Maybe I need to update to 1.0.15 then?
Yes, upgrading to 1.0.15 will fix this problem.
------------------------------
Message: 1097
Date: Thu, 10 Sep 2009 13:13:32 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] U (unread) search is off
Message-ID: <1252602768-sup-3245@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset="utf-8"
Excerpts from Rich Lane's message of Thu Sep 10 12:17:11 -0400 2009:
> Yes, upgrading to 1.0.15 will fix this problem.
Ok, I rolled rpms for 1.0.16 (available to anyone else if they
want/need them) and updated. This has resolved the issue for me.
Thanks Rich! :)
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090910/ec4dc234/attachment-0001.bin>
------------------------------
Message: 1098
Date: Thu, 10 Sep 2009 18:45:20 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] How hard would a universal undo be?
Message-ID: <1252599828-sup-7368@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from Carl Worth's message of Wed Sep 09 13:32:30 -0400 2009:
> Would it be a small change to move the undo keybinding to somewhere
> more universal?
No :(
> As a first cut, I'd be happy if it just undid the changes to the
> index, even without undoing any interface changes. That is, if my
> previous command was archive-thread-and-view-next-thread, it would be
> OK if it just undid the archiving part. Bonus points if it also undoes
> the view-next part, but I can imagine that being more work.
I know I sound a bit like a broken record here, but immediate
label changes will solve this problem. Then, the undo system would just
need to keep a global stack of (msgid, previous_labels). I'm just hoping
somebody will volunteer for this - it will be a big patch.
------------------------------
Message: 1099
Date: Fri, 11 Sep 2009 11:16:49 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: Rich Lane <rlane@club.cc.cmu.edu>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] How hard would a universal undo be?
Message-ID: <1252660564-sup-4253@peray>
Content-Type: text/plain; charset=UTF-8
Excerpts from Rich Lane's message of Fri Sep 11 00:45:20 +0200 2009:
> Excerpts from Carl Worth's message of Wed Sep 09 13:32:30 -0400 2009:
> > Would it be a small change to move the undo keybinding to somewhere
> > more universal?
>
> No :(
>
> > As a first cut, I'd be happy if it just undid the changes to the
> > index, even without undoing any interface changes. That is, if my
> > previous command was archive-thread-and-view-next-thread, it would be
> > OK if it just undid the archiving part. Bonus points if it also undoes
> > the view-next part, but I can imagine that being more work.
>
> I know I sound a bit like a broken record here, but immediate
> label changes will solve this problem. Then, the undo system would just
> need to keep a global stack of (msgid, previous_labels). I'm just hoping
> somebody will volunteer for this - it will be a big patch.
What prevent us from having a global stack of (msgid, previous_labels) in
the actual settings?
--
Nicolas Pouillard
http://nicolaspouillard.fr
------------------------------
Message: 1100
Date: Fri, 11 Sep 2009 12:58:31 -0400
From: Ben Gamari <bgamari.foss@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Crash while scrolling
Message-ID: <20090911165830.GA11260@ben-laptop>
Content-Type: text/plain; charset=us-ascii
Recently I've been seeing this crash[1] pretty consistently on the next
branch with the Xapian backend. All I need to do to reproduce the crash
is move to the last thread in the thread-index-mode and attempt to move
to the next thread.
I can also produce a very similar crash[2] by attempting to load all
threads. Thanks,
- Ben
[1] Crash while scrolling:
--- RuntimeError from thread: load threads for thread-index-mode
wrong id called on nil
/opt/exp/sup/lib/sup.rb:17:in `id'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `update'
/usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `sort_by'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `each'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `sort_by'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `update'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:223:in `synchronize'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:223:in `update'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:637:in `__unprotected_load_n_threads'
(eval):12:in `load_n_threads'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:609:in `load_n_threads_background'
/opt/exp/sup/lib/sup.rb:77:in `reporting_thread'
/opt/exp/sup/lib/sup.rb:75:in `initialize'
/opt/exp/sup/lib/sup.rb:75:in `new'
/opt/exp/sup/lib/sup.rb:75:in `reporting_thread'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads'
(eval):12:in `load_threads'
/opt/exp/sup/lib/sup/mode.rb:51:in `send'
/opt/exp/sup/lib/sup/mode.rb:51:in `handle_input'
/opt/exp/sup/lib/sup/buffer.rb:267:in `handle_input'
/usr/bin/sup:238
[2] Crash after attempting to load all threads
--- RuntimeError from thread: load threads for thread-index-mode
wrong id called on nil
/opt/exp/sup/lib/sup.rb:17:in `id'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `update'
/usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `sort_by'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `each'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `sort_by'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `update'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:223:in `synchronize'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:223:in `update'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:628:in `__unprotected_load_n_threads'
/opt/exp/sup/lib/sup/thread.rb:334:in `load_n_threads'
/opt/exp/sup/lib/sup/xapian_index.rb:151:in `each_id_by_date'
/opt/exp/sup/lib/sup/xapian_index.rb:144:in `each_id'
/opt/exp/sup/lib/sup/xapian_index.rb:144:in `each'
/opt/exp/sup/lib/sup/xapian_index.rb:144:in `each_id'
/opt/exp/sup/lib/sup/xapian_index.rb:151:in `each_id_by_date'
/opt/exp/sup/lib/sup/thread.rb:328:in `load_n_threads'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:625:in `__unprotected_load_n_threads'
(eval):12:in `load_n_threads'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:609:in `load_n_threads_background'
/opt/exp/sup/lib/sup.rb:77:in `reporting_thread'
/opt/exp/sup/lib/sup.rb:75:in `initialize'
/opt/exp/sup/lib/sup.rb:75:in `new'
/opt/exp/sup/lib/sup.rb:75:in `reporting_thread'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads'
(eval):12:in `load_threads'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:658:in `load_all_threads'
/opt/exp/sup/lib/sup/mode.rb:51:in `send'
/opt/exp/sup/lib/sup/mode.rb:51:in `handle_input'
/opt/exp/sup/lib/sup/buffer.rb:267:in `handle_input'
/usr/bin/sup:238
------------------------------
Message: 1101
Date: Fri, 11 Sep 2009 15:52:24 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: Nicolas Pouillard <nicolas.pouillard@gmail.com>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] How hard would a universal undo be?
Message-ID: <1252685502-sup-8928@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from Nicolas Pouillard's message of Fri Sep 11 05:16:49 -0400 2009:
> Excerpts from Rich Lane's message of Fri Sep 11 00:45:20 +0200 2009:
> > Excerpts from Carl Worth's message of Wed Sep 09 13:32:30 -0400 2009:
> > > Would it be a small change to move the undo keybinding to somewhere
> > > more universal?
> >
> > No :(
> >
> > > As a first cut, I'd be happy if it just undid the changes to the
> > > index, even without undoing any interface changes. That is, if my
> > > previous command was archive-thread-and-view-next-thread, it would be
> > > OK if it just undid the archiving part. Bonus points if it also undoes
> > > the view-next part, but I can imagine that being more work.
> >
> > I know I sound a bit like a broken record here, but immediate
> > label changes will solve this problem. Then, the undo system would just
> > need to keep a global stack of (msgid, previous_labels). I'm just hoping
> > somebody will volunteer for this - it will be a big patch.
>
> What prevent us from having a global stack of (msgid, previous_labels) in
> the actual settings?
Hmm, you may be right. I was thinking that changes weren't propagated
between buffers except on save, but that's wrong because UpdateManager
is called in the keybinding. In that case, the user sees a mostly*
linear series of label changes, so it's safe to have a global undo
stack.
*
User opens thread-index-mode A containing message M with labels L1
User changes labels on A.M to L2
User opens thread-index-mode B containing message M with labels L1
User changes labels on B.M to L3
UpdateManager changes labels on A.M to L3
User hits 'u' - now A.M and B.M have labels L1
------------------------------
Message: 1102
Date: Fri, 11 Sep 2009 23:25:06 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: Rich Lane <rlane@club.cc.cmu.edu>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] How hard would a universal undo be?
Message-ID:
<cd67f63a0909111425q7d04332fvd7e23b48e6dab06a@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Fri, Sep 11, 2009 at 9:52 PM, Rich Lane<rlane@club.cc.cmu.edu> wrote:
> Excerpts from Nicolas Pouillard's message of Fri Sep 11 05:16:49 -0400 2009:
>> Excerpts from Rich Lane's message of Fri Sep 11 00:45:20 +0200 2009:
>> > Excerpts from Carl Worth's message of Wed Sep 09 13:32:30 -0400 2009:
>> > > Would it be a small change to move the undo keybinding to somewhere
>> > > more universal?
>> >
>> > No :(
>> >
>> > > As a first cut, I'd be happy if it just undid the changes to the
>> > > index, even without undoing any interface changes. That is, if my
>> > > previous command was archive-thread-and-view-next-thread, it would be
>> > > OK if it just undid the archiving part. Bonus points if it also undoes
>> > > the view-next part, but I can imagine that being more work.
>> >
>> > I know I sound a bit like a broken record here, but immediate
>> > label changes will solve this problem. Then, the undo system would just
>> > need to keep a global stack of (msgid, previous_labels). I'm just hoping
>> > somebody will volunteer for this - it will be a big patch.
>>
>> What prevent us from having a global stack of (msgid, previous_labels) in
>> the actual settings?
>
> Hmm, you may be right. I was thinking that changes weren't propagated
> between buffers except on save, but that's wrong because UpdateManager
> is called in the keybinding. In that case, the user sees a mostly*
> linear series of label changes, so it's safe to have a global undo
> stack.
he next question is, what else is needed on this undo stack?
Are labels the only interaction we have? Here is what come to my mind:
* contacts (I more and more think that contacts should not be handled by
sup directly, but that's another topic)
* drafts
--
Nicolas Pouillard
------------------------------
Message: 1103
Date: Sat, 12 Sep 2009 09:35:21 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash while scrolling
Message-ID: <1252773189-sup-246@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Gamari's message of 2009-09-11:
> Recently I've been seeing this crash[1] pretty consistently on the next
> branch with the Xapian backend.
Is your Xapian index somewhat old? There have been index format changes
that have caused this type of thing recently. You might try rebuilding
it.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1104
Date: Sat, 12 Sep 2009 09:47:14 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] U (unread) search is off
Message-ID: <1252773806-sup-11@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Rich Lane's message of 2009-09-10:
> I thought it was, but it turns out that unless you explicitly add AND
> operators Xapian will OR terms over the same field such that
> "label:foo label:bar" gives you the union instead of the intersection.
Ok. I only ask because I'm considering how to present the Xapian index
option in 0.9---the options are to not say anything about it, to force
everyone to switch to it, or anywhere in between.
> We could fix this by patching Xapian to make this behavior
> configurable, or we could come up with an index-agnostic simple query
> language that doesn't support boolean operators.
The former sounds easier to me. Especially since it seems like this is
something Xapian should have...
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1105
Date: Sat, 12 Sep 2009 10:08:50 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Fix parsing of encrypted messages that
contain further multipart elements
Message-ID: <1252775304-sup-291@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Adeodato Sim?'s message of 2009-07-23:
> Amended patch follows, with a better wording that I had seemingly not
> committed. Sorry for the noise.
Not sure why I missed this. Branch crypto-mime-fix, merged into next.
Thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1106
Date: Sat, 12 Sep 2009 15:10:03 -0400
From: Kevin Riggle <kevinr@free-dissociation.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Case-sensitivity of Content-Type: more RubyMail
stupidity?
Message-ID: <1252781841-sup-6303@black-opal.mit.edu>
Content-Type: text/plain; charset=UTF-8
Several people from whom I receive e-mail regularly use a MUA which
generates Content-Type: headers of the form
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
The symptoms I see are that I don't get any preview text, and Sup shows
the message as consisting only of a spurious attachment of the form:
> - Attachment: sup-attachment-1252774311-2202. (8 lines)
(Note no file-type suffix.)
RFC 2045 (the MIME specification) section 5.1 says in part
> The type, subtype, and parameter names are not case sensitive. For
> example, TEXT, Text, and TeXt are all equivalent top-level media
> types.
So the above should be handled just like the many mails with headers of
the form
> Content-Type: text/plain; charset="us-ascii"; format=flowed
I get, which Sup handles perfectly.
I theorize that RubyMail is being case-sensitive where it shouldn't.
Given the number of work-arounds Sup has had to implement to compensate
for RubyMail's stupidity, and that RubyMail is currently unmaintained,
has any thought been given to switching Sup to eg. TMail
(http://tmail.rubyforge.org), which is maintained?
Failing that, thoughts on how best to work around this problem in Sup?
- Kevin
--
Kevin Riggle (kevinr@free-dissociation.com)
http://free-dissociation.com
------------------------------
Message: 1107
Date: Sat, 12 Sep 2009 17:01:17 -0400
From: Bo Borgerson <gigabo@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Hello and thanks
Message-ID: <1252787425-sup-4073@longword>
Content-Type: text/plain; charset=UTF-8
Hi,
I just started using sup yesterday. I'm really impressed by it.
As I've been using it I've been thinking of little tweaks to get it working
exactly how I like. Some of these will work with hooks (that's a nice system),
but some seem better suited to small patches.
I'm going to submit some of these patches to see if they're useful enough to
include upstream. A git-send-email out of the blue isn't necessarily the
friendliest of introductions, though, so I just wanted to write first and say
thanks to William and everyone who has contributed to sup. It's pretty
awesome.
Thanks.
Bo
------------------------------
Message: 1108
Date: Sat, 12 Sep 2009 17:04:05 -0400
From: Bo Borgerson <gigabo@gmail.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH] Handle added messages in label-list-mode
Message-ID: <1252789445-30193-1-git-send-email-gigabo@gmail.com>
Register label-list-mode with the UpdateManager and handle added
updates with a reload to keep unread message counts up to date
---
lib/sup/modes/label-list-mode.rb | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/lib/sup/modes/label-list-mode.rb b/lib/sup/modes/label-list-mode.rb
index d94f56f..f0084a9 100644
--- a/lib/sup/modes/label-list-mode.rb
+++ b/lib/sup/modes/label-list-mode.rb
@@ -31,9 +31,15 @@ EOS
@text = []
@unread_only = false
super
+ UpdateManager.register self
regen_text
end
+ def cleanup
+ UpdateManager.unregister self
+ super
+ end
+
def lines; @text.length end
def [] i; @text[i] end
@@ -52,6 +58,10 @@ EOS
reload # make sure unread message counts are up-to-date
end
+ def handle_added_update sender, m
+ reload
+ end
+
protected
def toggle_show_unread_only
--
1.6.0.4
------------------------------
Message: 1109
Date: Sun, 13 Sep 2009 10:38:35 -0400
From: Bo Borgerson <gigabo@gmail.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH] Add command for polling unusual sources
Message-ID: <1252852715-9601-1-git-send-email-gigabo@gmail.com>
bin/sup: Add new global key binding, '{', to poll unusual sources
(requires confirmation). This allows update of unusual sources
without having to leave sup to run a sync.
lib/sup/poll.rb: Add new method, poll_unusual. Both the pre-existing
poll method and the new poll_unusual method are now wrappers around
new poll_with_sources method that contains the bulk of functionality
previously in poll.
lib/sup/source.rb: Add new accessor for unusual_sources
---
bin/sup | 5 +++++
lib/sup/poll.rb | 23 +++++++++++++++++++----
lib/sup/source.rb | 1 +
3 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/bin/sup b/bin/sup
index 76a0438..996c99e 100755
--- a/bin/sup
+++ b/bin/sup
@@ -75,6 +75,7 @@ global_keymap = Keymap.new do |k|
k.add :search_unread, "Show all unread messages", 'U'
k.add :list_labels, "List labels", 'L'
k.add :poll, "Poll for new messages", 'P'
+ k.add :poll_unusual, "Poll for new messages from unusual sources", '{'
k.add :compose, "Compose new message", 'm', 'c'
k.add :nothing, "Do nothing", :ctrl_g
k.add :recall_draft, "Edit most recent draft message", 'R'
@@ -282,6 +283,10 @@ begin
ComposeMode.spawn_nicely
when :poll
reporting_thread("user-invoked poll") { PollManager.poll }
+ when :poll_unusual
+ if BufferManager.ask_yes_or_no "Really poll unusual sources?"
+ reporting_thread("user-invoked unusual poll") { PollManager.poll_unusual }
+ end
when :recall_draft
case Index.num_results_for :label => :draft
when 0
diff --git a/lib/sup/poll.rb b/lib/sup/poll.rb
index b59237f..ec51dec 100644
--- a/lib/sup/poll.rb
+++ b/lib/sup/poll.rb
@@ -35,12 +35,11 @@ EOS
@thread = nil
@last_poll = nil
@polling = false
+ @poll_sources = nil
@mode = nil
end
- def poll
- return if @polling
- @polling = true
+ def poll_with_sources
@mode ||= PollMode.new
HookManager.run "before-poll"
@@ -54,6 +53,22 @@ EOS
HookManager.run "after-poll", :num => num, :num_inbox => numi, :from_and_subj => from_and_subj, :from_and_subj_inbox => from_and_subj_inbox, :num_inbox_total_unread => lambda { Index.num_results_for :labels => [:inbox, :unread] }
+ end
+
+ def poll
+ return if @polling
+ @polling = true
+ @poll_sources = SourceManager.usual_sources
+ num, numi = poll_with_sources
+ @polling = false
+ [num, numi]
+ end
+
+ def poll_unusual
+ return if @polling
+ @polling = true
+ @poll_sources = SourceManager.unusual_sources
+ num, numi = poll_with_sources
@polling = false
[num, numi]
end
@@ -78,7 +93,7 @@ EOS
from_and_subj_inbox = []
@mutex.synchronize do
- SourceManager.usual_sources.each do |source|
+ @poll_sources.each do |source|
# yield "source #{source} is done? #{source.done?} (cur_offset #{source.cur_offset} >= #{source.end_offset})"
begin
yield "Loading from #{source}... " unless source.done? || (source.respond_to?(:has_errors?) && source.has_errors?)
diff --git a/lib/sup/source.rb b/lib/sup/source.rb
index 78386ff..6fe7bfb 100644
--- a/lib/sup/source.rb
+++ b/lib/sup/source.rb
@@ -207,6 +207,7 @@ class SourceManager
def source_for uri; sources.find { |s| s.is_source_for? uri }; end
def usual_sources; sources.find_all { |s| s.usual? }; end
+ def unusual_sources; sources.find_all { |s| !s.usual? }; end
def load_sources fn=Redwood::SOURCE_FN
source_array = (Redwood::load_yaml_obj(fn) || []).map { |o| Recoverable.new o }
--
1.6.0.4
------------------------------
Message: 1110
Date: Sun, 13 Sep 2009 11:02:32 -0400
From: Ben Gamari <bgamari.foss@gmail.com>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Crash while scrolling
Message-ID: <20090913150232.GB10024@ben-laptop>
Content-Type: text/plain; charset=us-ascii
On Sat, Sep 12, 2009 at 09:35:21AM -0700, William Morgan wrote:
> Reformatted excerpts from Ben Gamari's message of 2009-09-11:
> > Recently I've been seeing this crash[1] pretty consistently on the next
> > branch with the Xapian backend.
>
> Is your Xapian index somewhat old? There have been index format changes
> that have caused this type of thing recently. You might try rebuilding
> it.
I wish I could say it was unfortunately I just rebuilt it two days ago,
suspecting that might be part of the issue. I'll try again, just to make
sure but I'm fairly certain the index is up-to-date.
- Ben
------------------------------
Message: 1111
Date: Sun, 13 Sep 2009 11:44:09 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH] xapian: do less work for
update_message_state
Message-ID: <1252867449-30734-1-git-send-email-rlane@club.cc.cmu.edu>
Refactor index_message so that we do the minimal amount of work based on what
state the user has modified.
---
lib/sup/xapian_index.rb | 241 +++++++++++++++++++++++++++--------------------
1 files changed, 137 insertions(+), 104 deletions(-)
diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
index e1cfe65..ad45b0e 100644
--- a/lib/sup/xapian_index.rb
+++ b/lib/sup/xapian_index.rb
@@ -42,8 +42,6 @@ EOS
@xapian = Xapian::WritableDatabase.new(path, Xapian::DB_CREATE)
@xapian.set_metadata 'version', INDEX_VERSION
end
- @term_generator = Xapian::TermGenerator.new()
- @term_generator.stemmer = Xapian::Stem.new(STEM_LANGUAGE)
@enquire = Xapian::Enquire.new @xapian
@enquire.weighting_scheme = Xapian::BoolWeight.new
@enquire.docid_order = Xapian::Enquire::ASCENDING
@@ -91,41 +89,9 @@ EOS
m
end
- def add_message m; sync_message m end
- def update_message m; sync_message m end
- def update_message_state m; sync_message m end
-
- def sync_message m, opts={}
- entry = synchronize { get_entry m.id }
- snippet = m.snippet
- entry ||= {}
- labels = m.labels
- entry = {} if opts[:force_overwrite]
-
- d = {
- :message_id => m.id,
- :source_id => m.source.id,
- :source_info => m.source_info,
- :date => (entry[:date] || m.date),
- :snippet => snippet,
- :labels => labels,
- :from => (entry[:from] || [m.from.email, m.from.name]),
- :to => (entry[:to] || m.to.map { |p| [p.email, p.name] }),
- :cc => (entry[:cc] || m.cc.map { |p| [p.email, p.name] }),
- :bcc => (entry[:bcc] || m.bcc.map { |p| [p.email, p.name] }),
- :subject => m.subj,
- :refs => (entry[:refs] || m.refs),
- :replytos => (entry[:replytos] || m.replytos),
- }
-
- labels.each { |l| LabelManager << l }
-
- synchronize do
- index_message m, d, opts
- end
- true
- end
- private :sync_message
+ def add_message m; sync_message m, true end
+ def update_message m; sync_message m, true end
+ def update_message_state m; sync_message m, false end
def num_results_for query={}
xapian_query = build_xapian_query query
@@ -153,7 +119,6 @@ EOS
def each_message_in_thread_for m, opts={}
# TODO thread by subject
- # TODO handle killed threads
return unless doc = find_doc(m.id)
queue = doc.value(THREAD_VALUENO).split(',')
msgids = [m.id]
@@ -438,100 +403,140 @@ EOS
end
end
- def index_message m, entry, opts
- terms = []
- text = []
+ def sync_message m, overwrite
+ doc = synchronize { find_doc(m.id) }
+ existed = doc != nil
+ doc ||= Xapian::Document.new
+ do_index_static = overwrite || !existed
+ old_entry = !do_index_static && doc.entry
+ snippet = do_index_static ? m.snippet : old_entry[:snippet]
- subject_text = m.indexable_subject
- body_text = m.indexable_body
+ entry = {
+ :message_id => m.id,
+ :source_id => m.source.id,
+ :source_info => m.source_info,
+ :date => m.date,
+ :snippet => snippet,
+ :labels => m.labels.to_a,
+ :from => [m.from.email, m.from.name],
+ :to => m.to.map { |p| [p.email, p.name] },
+ :cc => m.cc.map { |p| [p.email, p.name] },
+ :bcc => m.bcc.map { |p| [p.email, p.name] },
+ :subject => m.subj,
+ :refs => m.refs.to_a,
+ :replytos => m.replytos.to_a,
+ }
+ if do_index_static
+ doc.clear_terms
+ doc.clear_values
+ index_message_static m, doc, entry
+ end
+
+ index_message_threading doc, entry, old_entry
+ index_message_labels doc, entry[:labels], (do_index_static ? [] : old_entry[:labels])
+ doc.entry = entry
+
+ synchronize do
+ unless docid = existed ? doc.docid : assign_docid(m, truncate_date(m.date))
+ # Could be triggered by spam
+ warn "docid underflow, dropping #{m.id.inspect}"
+ return
+ end
+ @xapian.replace_document docid, doc
+ end
+
+ m.labels.each { |l| LabelManager << l }
+ true
+ end
+
+ ## Index content that can't be changed by the user
+ def index_message_static m, doc, entry
# Person names are indexed with several prefixes
person_termer = lambda do |d|
lambda do |p|
["#{d}_name", "name", "body"].each do |x|
- text << [p.name, PREFIX[x]]
+ doc.index_text p.name, PREFIX[x]
end if p.name
- [d, :any].each { |x| terms << mkterm(:email, x, p.email) }
+ [d, :any].each { |x| doc.add_term mkterm(:email, x, p.email) }
end
end
person_termer[:from][m.from] if m.from
(m.to+m.cc+m.bcc).each(&(person_termer[:to]))
- terms << mkterm(:date,m.date) if m.date
- m.labels.each { |t| terms << mkterm(:label,t) }
- terms << mkterm(:type, 'mail')
- terms << mkterm(:msgid, m.id)
- terms << mkterm(:source_id, m.source.id)
+ # Full text search content
+ subject_text = m.indexable_subject
+ body_text = m.indexable_body
+ doc.index_text subject_text, PREFIX['subject']
+ doc.index_text subject_text, PREFIX['body']
+ doc.index_text body_text, PREFIX['body']
+ m.attachments.each { |a| doc.index_text a, PREFIX['attachment'] }
+
+ # Miscellaneous terms
+ doc.add_term mkterm(:date, m.date) if m.date
+ doc.add_term mkterm(:type, 'mail')
+ doc.add_term mkterm(:msgid, m.id)
+ doc.add_term mkterm(:source_id, m.source.id)
m.attachments.each do |a|
a =~ /\.(\w+)$/ or next
- t = mkterm(:attachment_extension, $1)
- terms << t
+ doc.add_term mkterm(:attachment_extension, $1)
+ end
+
+ # Date value for range queries
+ date_value = begin
+ Xapian.sortable_serialise m.date.to_i
+ rescue TypeError
+ Xapian.sortable_serialise 0
end
- ## Thread membership
- children = term_docids(mkterm(:ref, m.id)).map { |docid| @xapian.document docid }
- parent_ids = m.refs + m.replytos
+ doc.add_value MSGID_VALUENO, m.id
+ doc.add_value DATE_VALUENO, date_value
+ end
+
+ def index_message_labels doc, new_labels, old_labels
+ return if new_labels == old_labels
+ added = new_labels.to_a - old_labels.to_a
+ removed = old_labels.to_a - new_labels.to_a
+ added.each { |t| doc.add_term mkterm(:label,t) }
+ removed.each { |t| doc.remove_term mkterm(:label,t) }
+ end
+
+ ## Assign a set of thread ids to the document. This is a hybrid of the runtime
+ ## search done by the Ferret index and the index-time union done by previous
+ ## versions of the Xapian index. We first find the thread ids of all messages
+ ## with a reference to or from us. If that set is empty, we use our own
+ ## message id. Otherwise, we use all the thread ids we previously found. In
+ ## the common case there's only one member in that set, but if we're the
+ ## missing link between multiple previously unrelated threads we can have
+ ## more. XapianIndex#each_message_in_thread_for follows the thread ids when
+ ## searching so the user sees a single unified thread.
+ def index_message_threading doc, entry, old_entry
+ return if old_entry && (entry[:refs] == old_entry[:refs]) && (entry[:replytos] == old_entry[:replytos])
+ children = term_docids(mkterm(:ref, entry[:message_id])).map { |docid| @xapian.document docid }
+ parent_ids = entry[:refs] + entry[:replytos]
parents = parent_ids.map { |id| find_doc id }.compact
thread_members = SavingHash.new { [] }
(children + parents).each do |doc2|
thread_ids = doc2.value(THREAD_VALUENO).split ','
thread_ids.each { |thread_id| thread_members[thread_id] << doc2 }
end
+ thread_ids = thread_members.empty? ? [entry[:message_id]] : thread_members.keys
+ thread_ids.each { |thread_id| doc.add_term mkterm(:thread, thread_id) }
+ parent_ids.each { |ref| doc.add_term mkterm(:ref, ref) }
+ doc.add_value THREAD_VALUENO, (thread_ids * ',')
+ end
- thread_ids = thread_members.empty? ? [m.id] : thread_members.keys
-
- thread_ids.each { |thread_id| terms << mkterm(:thread, thread_id) }
- parent_ids.each do |ref|
- terms << mkterm(:ref, ref)
- end
-
- # Full text search content
- text << [subject_text, PREFIX['subject']]
- text << [subject_text, PREFIX['body']]
- text << [body_text, PREFIX['body']]
- m.attachments.each { |a| text << [a, PREFIX['attachment']] }
-
- truncated_date = if m.date < MIN_DATE
- debug "warning: adjusting too-low date #{m.date} for indexing"
+ def truncate_date date
+ if date < MIN_DATE
+ debug "warning: adjusting too-low date #{date} for indexing"
MIN_DATE
- elsif m.date > MAX_DATE
- debug "warning: adjusting too-high date #{m.date} for indexing"
+ elsif date > MAX_DATE
+ debug "warning: adjusting too-high date #{date} for indexing"
MAX_DATE
else
- m.date
- end
-
- # Date value for range queries
- date_value = begin
- Xapian.sortable_serialise truncated_date.to_i
- rescue TypeError
- Xapian.sortable_serialise 0
- end
-
- docid = nil
- unless doc = find_doc(m.id)
- doc = Xapian::Document.new
- if not docid = assign_docid(m, truncated_date)
- # Could be triggered by spam
- Redwood::log "warning: docid underflow, dropping #{m.id.inspect}"
- return
- end
- else
- doc.clear_terms
- doc.clear_values
- docid = doc.docid
+ date
end
-
- @term_generator.document = doc
- text.each { |text,prefix| @term_generator.index_text text, 1, prefix }
- terms.each { |term| doc.add_term term if term.length <= MAX_TERM_LENGTH }
- doc.add_value MSGID_VALUENO, m.id
- doc.add_value THREAD_VALUENO, (thread_ids * ',')
- doc.add_value DATE_VALUENO, date_value
- doc.data = Marshal.dump entry
-
- @xapian.replace_document docid, doc
end
# Construct a Xapian term
@@ -561,6 +566,34 @@ EOS
end
end
+ module DocumentMethods
+ def entry
+ Marshal.load data
+ end
+
+ def entry=(x)
+ self.data = Marshal.dump x
+ end
+
+ def index_text text, prefix, weight=1
+ term_generator = Xapian::TermGenerator.new
+ term_generator.stemmer = Xapian::Stem.new(STEM_LANGUAGE)
+ term_generator.document = self
+ term_generator.index_text text, weight, prefix
+ end
+
+ def add_term term
+ if term.length <= MAX_TERM_LENGTH
+ super term
+ else
+ warn "dropping excessively long term #{term}"
+ end
+ end
+ end
+end
+
end
+class Xapian::Document
+ include Redwood::XapianIndex::DocumentMethods
end
--
1.6.4.2
------------------------------
Message: 1112
Date: Sun, 13 Sep 2009 17:40:05 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: Nicolas Pouillard <nicolas.pouillard@gmail.com>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] How hard would a universal undo be?
Message-ID: <1252877576-sup-8500@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from Nicolas Pouillard's message of Fri Sep 11 17:25:06 -0400 2009:
> On Fri, Sep 11, 2009 at 9:52 PM, Rich Lane<rlane@club.cc.cmu.edu> wrote:
> > Excerpts from Nicolas Pouillard's message of Fri Sep 11 05:16:49 -0400 2009:
> >> Excerpts from Rich Lane's message of Fri Sep 11 00:45:20 +0200 2009:
> >> > Excerpts from Carl Worth's message of Wed Sep 09 13:32:30 -0400 2009:
> >> > > Would it be a small change to move the undo keybinding to somewhere
> >> > > more universal?
> >> >
> >> > No :(
> >> >
> >> > > As a first cut, I'd be happy if it just undid the changes to the
> >> > > index, even without undoing any interface changes. That is, if my
> >> > > previous command was archive-thread-and-view-next-thread, it would be
> >> > > OK if it just undid the archiving part. Bonus points if it also undoes
> >> > > the view-next part, but I can imagine that being more work.
> >> >
> >> > I know I sound a bit like a broken record here, but immediate
> >> > label changes will solve this problem. Then, the undo system would just
> >> > need to keep a global stack of (msgid, previous_labels). I'm just hoping
> >> > somebody will volunteer for this - it will be a big patch.
> >>
> >> What prevent us from having a global stack of (msgid, previous_labels) in
> >> the actual settings?
> >
> > Hmm, you may be right. I was thinking that changes weren't propagated
> > between buffers except on save, but that's wrong because UpdateManager
> > is called in the keybinding. In that case, the user sees a mostly*
> > linear series of label changes, so it's safe to have a global undo
> > stack.
>
> he next question is, what else is needed on this undo stack?
>
> Are labels the only interaction we have? Here is what come to my mind:
>
> * contacts (I more and more think that contacts should not be handled by
> sup directly, but that's another topic)
> * drafts
>
What actions on drafts are you thinking of making undoable? Could we
implement them with reserved labels?
------------------------------
Message: 1113
Date: Mon, 14 Sep 2009 00:17:53 +0100
From: Adeodato Sim? <dato@net.com.org.es>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] mime-decode hook: provide a "charset"
variable with the attachment charset
Message-ID: <20090913231753.GA20849@chistera.yi.org>
Content-Type: text/plain; charset=us-ascii
+ William Morgan (Sun, 23 Aug 2009 10:34:10 -0700):
> Anyways, I just merged my hook changes into next, on the branch
> hook-local-vars. Take a look and tell me what you think. This should
> also fix Edward Z. Yang's problems with hook locals not being useable in
> statements like "x = x.foo()".
Works for me, thanks.
Now that that fix is in, can you merge the mime-decode improvement from
<6fc2e5dd8aa2b0b8547375d77b1776d779f85817.1247238014.git.dato@net.com.org.es>?
Thanks!
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
------------------------------
Message: 1114
Date: Sun, 13 Sep 2009 20:31:23 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] U (unread) search is off
Message-ID: <1252878152-sup-9190@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Sat Sep 12 12:47:14 -0400 2009:
> Reformatted excerpts from Rich Lane's message of 2009-09-10:
> > I thought it was, but it turns out that unless you explicitly add AND
> > operators Xapian will OR terms over the same field such that
> > "label:foo label:bar" gives you the union instead of the intersection.
>
> Ok. I only ask because I'm considering how to present the Xapian index
> option in 0.9---the options are to not say anything about it, to force
> everyone to switch to it, or anywhere in between.
Yeah, we do need the query behavior to be reasonable before advertising
the Xapian index. What's your timeline on 0.9?
> > We could fix this by patching Xapian to make this behavior
> > configurable, or we could come up with an index-agnostic simple query
> > language that doesn't support boolean operators.
>
> The former sounds easier to me. Especially since it seems like this is
> something Xapian should have...
Agreed that Xapian should have this, and I'll probably implement it. We
still need to support people using older Xapian versions though. Whether
this means a log message telling them to use explicit ANDs in their
query, or automatically transforming simple-enough queries into what we
think they actually want, I don't know. I'll also need to add a
workaround for the earlier Xapian bug before this index gets wider
usage.
As far as which index to make the default, Ferret has the advantage of
being installable as a gem dependency. I think this ease of installation
is important enough to block Xapian for now, unless someone can create a
Xapian gem. There's been interest in this before:
http://article.gmane.org/gmane.comp.search.xapian.devel/1408/
------------------------------
Message: 1115
Date: Mon, 14 Sep 2009 18:29:09 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: Rich Lane <rlane@club.cc.cmu.edu>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] How hard would a universal undo be?
Message-ID: <1252945595-sup-1907@peray>
Content-Type: text/plain; charset=UTF-8
Excerpts from Rich Lane's message of Sun Sep 13 23:40:05 +0200 2009:
> Excerpts from Nicolas Pouillard's message of Fri Sep 11 17:25:06 -0400 2009:
> > On Fri, Sep 11, 2009 at 9:52 PM, Rich Lane<rlane@club.cc.cmu.edu> wrote:
> > > Excerpts from Nicolas Pouillard's message of Fri Sep 11 05:16:49 -0400 2009:
> > >> Excerpts from Rich Lane's message of Fri Sep 11 00:45:20 +0200 2009:
> > >> > Excerpts from Carl Worth's message of Wed Sep 09 13:32:30 -0400 2009:
> > >> > > Would it be a small change to move the undo keybinding to somewhere
> > >> > > more universal?
> > >> >
> > >> > No :(
> > >> >
> > >> > > As a first cut, I'd be happy if it just undid the changes to the
> > >> > > index, even without undoing any interface changes. That is, if my
> > >> > > previous command was archive-thread-and-view-next-thread, it would be
> > >> > > OK if it just undid the archiving part. Bonus points if it also undoes
> > >> > > the view-next part, but I can imagine that being more work.
> > >> >
> > >> > I know I sound a bit like a broken record here, but immediate
> > >> > label changes will solve this problem. Then, the undo system would just
> > >> > need to keep a global stack of (msgid, previous_labels). I'm just hoping
> > >> > somebody will volunteer for this - it will be a big patch.
> > >>
> > >> What prevent us from having a global stack of (msgid, previous_labels) in
> > >> the actual settings?
> > >
> > > Hmm, you may be right. I was thinking that changes weren't propagated
> > > between buffers except on save, but that's wrong because UpdateManager
> > > is called in the keybinding. In that case, the user sees a mostly*
> > > linear series of label changes, so it's safe to have a global undo
> > > stack.
> >
> > he next question is, what else is needed on this undo stack?
> >
> > Are labels the only interaction we have? Here is what come to my mind:
> >
> > * contacts (I more and more think that contacts should not be handled by
> > sup directly, but that's another topic)
> > * drafts
> >
>
> What actions on drafts are you thinking of making undoable? Could we
> implement them with reserved labels?
No I think that's fine for now to consider, discarding, editing...
non-undoable actions.
Basically I agree with a global undo stack of labels, I'm just searching for
issues ahead.
--
Nicolas Pouillard
http://nicolaspouillard.fr
------------------------------
Message: 1116
Date: Tue, 15 Sep 2009 07:18:51 +0000 (UTC)
From: Olly Betts <olly@survex.com>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] U (unread) search is off
Message-ID: <loom.20090915T090521-2@post.gmane.org>
Content-Type: text/plain; charset=us-ascii
Rich Lane <rlane@club.cc.cmu.edu> writes:
> Agreed that Xapian should have this, and I'll probably implement it. We
> still need to support people using older Xapian versions though. Whether
> this means a log message telling them to use explicit ANDs in their
> query, or automatically transforming simple-enough queries into what we
> think they actually want, I don't know. I'll also need to add a
> workaround for the earlier Xapian bug before this index gets wider
> usage.
I've now opened a Xapian ticket for this:
http://trac.xapian.org/ticket/402
Patches are certainly most welcome, especially as I'm currently trying to
focus on getting Xapian 1.2.0 out of the door.
I don't see a satisfactory workaround for it, sadly.
> As far as which index to make the default, Ferret has the advantage of
> being installable as a gem dependency. I think this ease of installation
> is important enough to block Xapian for now, unless someone can create a
> Xapian gem. There's been interest in this before:
> http://article.gmane.org/gmane.comp.search.xapian.devel/1408/
I recently noticed this gem version of (modified) xapian-bindings:
http://groups.google.com/group/acts_as_xapian/msg/1bbb1e0d3753a0b7
I've not had a chance to look at it yet though, so I don't know if the
changes mentioned are compatible or not. Assuming they're useful, they
probably should be folded in upstream - more idiomatic wrappers are a
desirable improvement (though if they're incompatible we'd need some
sort of migration plan). It doesn't seem productive to have forked
versions like this either.
Cheers,
Olly
------------------------------
Message: 1117
Date: Tue, 15 Sep 2009 18:20:59 +0200
From: Michael Hamann <michael@content-space.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Sup and Ruby 1.9.1 - deadlock?
Message-ID: <1253030868-sup-8556@mithink>
Content-Type: text/plain; charset=iso-8859-1
Hi,
as Arch Linux has decided to put Ruby 1.9.1 into the extra repository I've got
Ruby 1.8 replaced by 1.9.1 today. I then tried reinstalling all dependencies of
sup again with Ruby 1.9.1. I've also found a Ferret gem for Ruby 1.9.1 at
http://pennysmalls.com/2009/03/24/ferret-on-ruby-191/.
After that I tried running sup and after seeing the main screen for a few
moments sup crashed with the following error (I'm using the latest version from
next, but with master it's the same):
ThreadError from thread: load threads for thread-index-mode
deadlock; recursive locking
<internal:prelude>:6:in `lock'
<internal:prelude>:6:in `synchronize'
/home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:757:in `regen_text'
/home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:687:in `resize'
/home/michitux/pub/software/sup/lib/sup/buffer.rb:87:in `resize'
/home/michitux/pub/software/sup/lib/sup/buffer.rb:328:in `draw_screen'
/home/michitux/pub/software/sup/lib/sup/buffer.rb:728:in `flash'
/home/michitux/pub/software/sup/lib/sup/util.rb:520:in `method_missing'
/home/michitux/pub/software/sup/lib/sup/hook.rb:87:in `rescue in run'
/home/michitux/pub/software/sup/lib/sup/hook.rb:81:in `run'
/home/michitux/pub/software/sup/lib/sup/util.rb:520:in `method_missing'
/home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:714:in `size_widget_for_thread'
/home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:226:in `block (2 levels) in update'
/home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:226:in `map'
/home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:226:in `block in update'
<internal:prelude>:8:in `synchronize'
/home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:223:in `update'
/home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:637:in `load_n_threads'
(eval):12:in `load_n_threads'
/home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:609:in `block in load_n_threads_background'
/home/michitux/pub/software/sup/lib/sup.rb:77:in `block in reporting_thread
I then tried running sup-dump, it worked without problems, the results looks
correct (just a few changed lines that represent the changes of the last days).
I then installed xapian and tried reimporting my mails and all I've got after
importing 46 mails of about 44000 is:
Scanning maildir:/home/michitux/mail...
/home/michitux/pub/software/sup/lib/sup/message.rb:103:in `gsub': invalid byte sequence in US-ASCII (ArgumentError)
from /home/michitux/pub/software/sup/lib/sup/message.rb:103:in `parse_header'
from /home/michitux/pub/software/sup/lib/sup/message.rb:238:in `load_from_source!'
from /home/michitux/pub/software/sup/lib/sup/message.rb:335:in `build_from_source'
from /home/michitux/pub/software/sup/lib/sup/poll.rb:145:in `block in each_message_from'
from /home/michitux/pub/software/sup/lib/sup/maildir.rb:160:in `block in each'
from /home/michitux/pub/software/sup/lib/sup/maildir.rb:157:in `upto'
from /home/michitux/pub/software/sup/lib/sup/maildir.rb:157:in `each'
from /home/michitux/pub/software/sup/lib/sup/util.rb:560:in `__pass'
from /home/michitux/pub/software/sup/lib/sup/util.rb:547:in `method_missing'
from /home/michitux/pub/software/sup/lib/sup/poll.rb:139:in `each_message_from'
from /home/michitux/pub/software/sup/lib/sup/util.rb:520:in `method_missing'
from bin/sup-sync:146:in `block in <main>'
from bin/sup-sync:141:in `each'
from bin/sup-sync:141:in `<main>'
Running sup with xapian and ruby 1.9.1 works as long as there aren't any mails
displayed, when I e.g. select a label that contains mails, sub crashes again
with the same exception as with ferret.
Is there anything I'm missing, is sup just not ready for Ruby 1.9.1 or is there
another issue?
Greetings
Michael Hamann
------------------------------
Message: 1118
Date: Tue, 15 Sep 2009 10:53:39 -0700
From: Sean Escriva <sean.escriva@gmail.com>
To: Michael Hamann <michael@content-space.de>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup and Ruby 1.9.1 - deadlock?
Message-ID: <20090915175339.GA15735@gmail.com>
Content-Type: text/plain; charset=us-ascii
Excerpts from Michael Hamann's message of Tue Sep 15 06:20:59 +0200 2009:
> Hi,
>
> as Arch Linux has decided to put Ruby 1.9.1 into the extra repository I've got
> Ruby 1.8 replaced by 1.9.1 today. I then tried reinstalling all dependencies of
> sup again with Ruby 1.9.1. I've also found a Ferret gem for Ruby 1.9.1 at
> http://pennysmalls.com/2009/03/24/ferret-on-ruby-191/.
I followed a similar path after the recent upgrade to no avail. In the
end I downgraded ruby back to 1.8.7_p160 from older arch packages
available here:
http://www.schlunix.org/archlinux/extra/os/x86_64/
I'd like a better solution, but I've become dependent on sup for daily
work.
> [..snip..]
------------------------------
Message: 1119
Date: Tue, 15 Sep 2009 22:21:59 +0200
From: Christopher Bertels <mailinglist@flasht.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Fixing header for encrypted messages (might be an
old issue)
Message-ID: <1253045775-sup-210@thinkpad-ubuntu>
Content-Type: text/plain; charset="utf-8"
Hi!
I've been having problems with encrypting messages. No idea where this
came from, but somehow the protocol part in encrypted messages had an
extra pair of quotes, e.g.: protocol=""application/pgp-encrypted""
which caused it to not be recognized by some clients (e.g. mutt as far as I know).
Here's a simple fix. I have no idea, why this suddenly came up. Might
be that it had been like this all the time, just no one had a problem
with it? (I highly doubt that though!)
If this is an old issue and I'm just using an old version, feel free
to ignore this. I've tried using the current master or next branch,
but that causes a crash when trying to open encrypted emails. Maybe
someone else is having a similar problem?
Greetings,
Christopher.
--
================================
Christopher Bertels
http://www.adztec-independent.de
GPG Key ID: 0x2345b203
-------------- next part --------------
A non-text attachment was scrubbed...
Name: protocol-fix.patch
Type: application/octet-stream
Size: 509 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090915/462fe7d5/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090915/462fe7d5/attachment-0001.bin>
------------------------------
Message: 1120
Date: Tue, 15 Sep 2009 16:32:42 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup and Ruby 1.9.1 - deadlock?
Message-ID: <1253043209-sup-8800@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from Michael Hamann's message of Tue Sep 15 12:20:59 -0400 2009:
> Hi,
>
> as Arch Linux has decided to put Ruby 1.9.1 into the extra repository I've got
> Ruby 1.8 replaced by 1.9.1 today. I then tried reinstalling all dependencies of
> sup again with Ruby 1.9.1. I've also found a Ferret gem for Ruby 1.9.1 at
> http://pennysmalls.com/2009/03/24/ferret-on-ruby-191/.
>
> After that I tried running sup and after seeing the main screen for a few
> moments sup crashed with the following error (I'm using the latest version from
> next, but with master it's the same):
>
> ThreadError from thread: load threads for thread-index-mode
> deadlock; recursive locking
> <internal:prelude>:6:in `lock'
> <internal:prelude>:6:in `synchronize'
> /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:757:in
> `regen_text'
> /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:687:in
> `resize'
> /home/michitux/pub/software/sup/lib/sup/buffer.rb:87:in `resize'
> /home/michitux/pub/software/sup/lib/sup/buffer.rb:328:in `draw_screen'
> /home/michitux/pub/software/sup/lib/sup/buffer.rb:728:in `flash'
> /home/michitux/pub/software/sup/lib/sup/util.rb:520:in `method_missing'
> /home/michitux/pub/software/sup/lib/sup/hook.rb:87:in `rescue in run'
> /home/michitux/pub/software/sup/lib/sup/hook.rb:81:in `run'
> /home/michitux/pub/software/sup/lib/sup/util.rb:520:in `method_missing'
> /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:714:in
> `size_widget_for_thread'
> /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:226:in
> `block (2 levels) in update'
> /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:226:in `map'
> /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:226:in
> `block in update'
> <internal:prelude>:8:in `synchronize'
> /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:223:in
> `update'
> /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:637:in
> `load_n_threads'
> (eval):12:in `load_n_threads'
> /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:609:in
> `block in load_n_threads_background'
> /home/michitux/pub/software/sup/lib/sup.rb:77:in `block in reporting_thread
>
We're calling the size widget hook while holding the thread-index-mode
lock, then the hook throws an exception that results in trying to
acquire the lock again. We shouldn't be calling arbitrary code with
locks held. Until we figure that change out we could just change the
mutex to be a monitor.
> I then tried running sup-dump, it worked without problems, the results looks
> correct (just a few changed lines that represent the changes of the last days).
>
> I then installed xapian and tried reimporting my mails and all I've got after
> importing 46 mails of about 44000 is:
>
> Scanning maildir:/home/michitux/mail...
> /home/michitux/pub/software/sup/lib/sup/message.rb:103:in `gsub': invalid byte
> sequence in US-ASCII (ArgumentError)
> from /home/michitux/pub/software/sup/lib/sup/message.rb:103:in `parse_header'
> from /home/michitux/pub/software/sup/lib/sup/message.rb:238:in
> `load_from_source!'
> from /home/michitux/pub/software/sup/lib/sup/message.rb:335:in
> `build_from_source'
> from /home/michitux/pub/software/sup/lib/sup/poll.rb:145:in `block in
> each_message_from'
> from /home/michitux/pub/software/sup/lib/sup/maildir.rb:160:in `block in each'
> from /home/michitux/pub/software/sup/lib/sup/maildir.rb:157:in `upto'
> from /home/michitux/pub/software/sup/lib/sup/maildir.rb:157:in `each'
> from /home/michitux/pub/software/sup/lib/sup/util.rb:560:in `__pass'
> from /home/michitux/pub/software/sup/lib/sup/util.rb:547:in `method_missing'
> from /home/michitux/pub/software/sup/lib/sup/poll.rb:139:in `each_message_from'
> from /home/michitux/pub/software/sup/lib/sup/util.rb:520:in `method_missing'
> from bin/sup-sync:146:in `block in <main>'
> from bin/sup-sync:141:in `each'
> from bin/sup-sync:141:in `<main>'
This is a 1.9 encoding issue. I imagine we have a number of these, even
outside of rmail.
> Running sup with xapian and ruby 1.9.1 works as long as there aren't any mails
> displayed, when I e.g. select a label that contains mails, sub crashes again
> with the same exception as with ferret.
>
> Is there anything I'm missing, is sup just not ready for Ruby 1.9.1 or is there
> another issue?
I think William said he's been doing some 1.9 work recently. I wouldn't
say it's ready just yet.
------------------------------
Message: 1121
Date: Tue, 15 Sep 2009 23:24:58 +0200
From: Dusan <ef_dva@yahoo.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup and Ruby 1.9.1 - deadlock?
Message-ID: <1253049733-sup-276@archpc>
Content-Type: text/plain; charset=UTF-8
Excerpts from Sean Escriva's message of Tue Sep 15 19:53:39 +0200 2009:
> Excerpts from Michael Hamann's message of Tue Sep 15 06:20:59 +0200 2009:
> > Hi,
> >
> > as Arch Linux has decided to put Ruby 1.9.1 into the extra repository I've got
> > Ruby 1.8 replaced by 1.9.1 today. I then tried reinstalling all dependencies of
> > sup again with Ruby 1.9.1. I've also found a Ferret gem for Ruby 1.9.1 at
> > http://pennysmalls.com/2009/03/24/ferret-on-ruby-191/.
>
> I followed a similar path after the recent upgrade to no avail. In the
> end I downgraded ruby back to 1.8.7_p160 from older arch packages
> available here:
>
> http://www.schlunix.org/archlinux/extra/os/x86_64/
>
> I'd like a better solution, but I've become dependent on sup for daily
> work.
>
> > [..snip..]
This is pretty big question for arch users, including me. I can block
ruby upgrade but it's few month before other distros start using 1.9
------------------------------
Message: 1122
Date: Tue, 15 Sep 2009 23:21:19 +0100
From: Adeodato Sim? <dato@net.com.org.es>
To: Christopher Bertels <mailinglist@flasht.de>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Fixing header for encrypted messages (might be
an old issue)
Message-ID: <20090915222119.GA5290@chistera.yi.org>
Content-Type: text/plain; charset=us-ascii
+ Christopher Bertels (Tue, 15 Sep 2009 22:21:59 +0200):
> Hi!
Hello!
> I've been having problems with encrypting messages. No idea where this
> came from, but somehow the protocol part in encrypted messages had an
> extra pair of quotes, e.g.: protocol=""application/pgp-encrypted""
> which caused it to not be recognized by some clients (e.g. mutt as far as I know).
> Here's a simple fix. I have no idea, why this suddenly came up. Might
> be that it had been like this all the time, just no one had a problem
> with it? (I highly doubt that though!)
It's been like that all the time, but AFAIK only Mutt has problem
opening those messages. FWIW, it's a bug in RMail (another one to add to
the pile...):
http://rubyforge.org/tracker/index.php?func=detail&aid=2170&group_id=446&atid=1754
http://rubyforge.org/tracker/index.php?func=detail&aid=2661&group_id=446&atid=1756
I advice against using your patch, since it depends on broken behavior
of RMail to produce correct results, and people may be using fixed
versions of the library. For example, I uploaded fixed packages of RMail
to Debian, and they'll become available in Ubuntu at some point.
Instead, you can find a patch to fix the issue in your system's RMail in
one bugs linked above.
> If this is an old issue and I'm just using an old version, feel free
> to ignore this. I've tried using the current master or next branch,
> but that causes a crash when trying to open encrypted emails. Maybe
> someone else is having a similar problem?
No, I've recently started experiencing this as well, asuming you're
talking about:
--- NoMethodError from thread: load messages for thread-view-mode
undefined method `expandable?' for #<Array:0x7faa50e2d978>
/home/dato/devel/sup/work/lib/sup/modes/thread-view-mode.rb:615:in `regen_text'
/home/dato/devel/sup/work/lib/sup/modes/thread-view-mode.rb:610:in `each'
/home/dato/devel/sup/work/lib/sup/modes/thread-view-mode.rb:610:in `regen_text'
/home/dato/devel/sup/work/lib/sup/thread.rb:68:in `each'
/home/dato/devel/sup/work/lib/sup/thread.rb:170:in `each_with_stuff'
[...]
Cheers,
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
------------------------------
Message: 1123
Date: Wed, 16 Sep 2009 13:23:40 -0400
From: Ben Gamari <bgamari.foss@gmail.com>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Crash while scrolling
Message-ID: <20090916172340.GA20566@ben-laptop>
Content-Type: text/plain; charset=us-ascii
On Sat, Sep 12, 2009 at 09:35:21AM -0700, William Morgan wrote:
> Reformatted excerpts from Ben Gamari's message of 2009-09-11:
> > Recently I've been seeing this crash[1] pretty consistently on the next
> > branch with the Xapian backend.
>
> Is your Xapian index somewhat old? There have been index format changes
> that have caused this type of thing recently. You might try rebuilding
> it.
Well, after several attempts at rebuilding my index, I finally got lucky
and sup-sync ran to completion. Unfortunately, sup now fails to even
start, failing out with the following exception while loading threads
for inbox-mode,
$ sup
--- SystemExit from thread: main
Thread#join: deadlock 0x7f592eec4d78 - mutual join(0x7f592f01d6e8)
/opt/exp/sup/lib/sup/message.rb:240:in `select'
/opt/exp/sup/lib/sup/buffer.rb:35:in `nonblocking_getch'
/usr/bin/sup:213
However, at this point during debugging I happened to pipe stderr to a
file and accidentally found that most of the backtrace was actually
being hidden by curses. Examining the full output on stderr reveals,
/usr/bin/sup:213(eval):3:in `synchronize': Thread#join: deadlock 0x7f4d5da565c0 - mutual join(0x7f4d5daf8be0) (ThreadError)
from (eval):3:in `raw_header'
from /opt/exp/sup/lib/sup/imap.rb:98:in `load_header'
from /opt/exp/sup/lib/sup/util.rb:560:in `send'
from /opt/exp/sup/lib/sup/util.rb:560:in `__pass'
from /opt/exp/sup/lib/sup/util.rb:547:in `method_missing'
from /opt/exp/sup/lib/sup/message.rb:238:in `load_from_source!'
from /opt/exp/sup/lib/sup/message.rb:219:in `chunks'
from /opt/exp/sup/lib/sup/message.rb:164:in `snippet'
from /opt/exp/sup/lib/sup/thread.rb:91:in `snippet'
from /opt/exp/sup/lib/sup/imap.rb:259:in `select'
from /opt/exp/sup/lib/sup/thread.rb:68:in `each'
from /opt/exp/sup/lib/sup/thread.rb:168:in `each_with_stuff'
from /opt/exp/sup/lib/sup/thread.rb:67:in `each'
from /opt/exp/sup/lib/sup/thread.rb:91:in `select'
from /opt/exp/sup/lib/sup/thread.rb:91:in `snippet'
from /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:840:in `text_for_thread_at'
from /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:758:in `regen_text'
from /opt/exp/sup/lib/sup/util.rb:364:in `map_with_index'
from /opt/exp/sup/lib/sup/imap.rb:259:in `each_with_index'
from /opt/exp/sup/lib/sup/util.rb:364:in `each'
from /opt/exp/sup/lib/sup/util.rb:364:in `each_with_index'
from /opt/exp/sup/lib/sup/util.rb:364:in `map_with_index'
from /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:758:in `regen_text'
from /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:687:in `resize'
from /opt/exp/sup/lib/sup/buffer.rb:88:in `resize'
from /opt/exp/sup/lib/sup/buffer.rb:329:in `draw_screen'
from /opt/exp/sup/lib/sup/buffer.rb:745:in `clear'
from /opt/exp/sup/lib/sup/util.rb:520:in `send'
from /opt/exp/sup/lib/sup/util.rb:520:in `method_missing'
from /opt/exp/sup/lib/sup/imap.rb:283:in `shutup'
from /opt/exp/sup/lib/sup/imap.rb:270:in `unsafe_connect'
from /opt/exp/sup/lib/sup/imap.rb:244:in `initialize'
from /opt/exp/sup/lib/sup/imap.rb:244:in `new'
from /opt/exp/sup/lib/sup/imap.rb:244:in `unsafe_connect'
from /opt/exp/sup/lib/sup/imap.rb:331:in `safely'
from /opt/exp/sup/lib/sup/imap.rb:148:in `unsynchronized_connect'
from (eval):3:in `connect'
from (eval):3:in `synchronize'
from (eval):3:in `connect'
from /opt/exp/sup/lib/sup/util.rb:560:in `send'
from /opt/exp/sup/lib/sup/util.rb:560:in `__pass'
from /opt/exp/sup/lib/sup/util.rb:547:in `method_missing'
from /usr/bin/sup:189
from /opt/exp/sup/lib/sup.rb:77:in `reporting_thread'
from /opt/exp/sup/lib/sup.rb:75:in `initialize'
from /opt/exp/sup/lib/sup.rb:75:in `new'
from /opt/exp/sup/lib/sup.rb:75:in `reporting_thread'
from /usr/bin/sup:187
from /usr/bin/sup:185:in `each'
from /usr/bin/sup:185
[Wed Sep 16 13:01:11 -0400 2009] ERROR: oh crap, an exception
----------------------------------------------------------------
I'm very sorry. It seems that an error occurred in Sup. Please
accept my sincere apologies. If you don't mind, please send the
contents of ~/.sup/exception-log.txt and a brief report of the
circumstances to sup-talk at rubyforge dot orgs so that I might
address this problem. Thank you!
Sincerely,
William
----------------------------------------------------------------
with the first stacktrace following this on stdout. With this
information it looks like this bug should become much more debuggable.
Being in the imap module, it seems likely that it is my gmail source
that is causing the failure. Unfortunately I have no way to verify that
the problem is limited to the gmail source as sup raises as exception
when it encounters an unknown source, precluding the option of simply
commenting out the source in sources.yaml.
Anyways, this is the current status of things on my machine. William, do
you have any ideas what might cause such a backtrace. At this point
classes have started and I really have no more time to devote to
getting sup working. If there isn't a fairly simple solution here I guess
I'll just need to stick with mutt (ugh). Anyways, thanks for your work.
Cheers,
- Ben
------------------------------
Message: 1124
Date: Wed, 16 Sep 2009 00:42:04 +0200
From: Christopher Bertels <mailinglist@flasht.de>
To: Adeodato Sim? <dato@net.com.org.es>
Subject: Re: [sup-talk] Fixing header for encrypted messages (might be
an old issue)
Message-ID: <1253054438-sup-8449@thinkpad-ubuntu>
Content-Type: text/plain; charset="utf-8"
Excerpts from Adeodato Sim?'s message of Mi Sep 16 00:21:19 +0200 2009:
> It's been like that all the time, but AFAIK only Mutt has problem
> opening those messages. FWIW, it's a bug in RMail (another one to add to
> the pile...):
Alright, good to know.
> I advice against using your patch, since it depends on broken behavior
> of RMail to produce correct results, and people may be using fixed
> versions of the library. For example, I uploaded fixed packages of RMail
> to Debian, and they'll become available in Ubuntu at some point.
>
> Instead, you can find a patch to fix the issue in your system's RMail in
> one bugs linked above.
Alright, thanks. I'll just leave it for me like this until I've got a
new version of RMail then.
> > If this is an old issue and I'm just using an old version, feel free
> > to ignore this. I've tried using the current master or next branch,
> > but that causes a crash when trying to open encrypted emails. Maybe
> > someone else is having a similar problem?
>
> No, I've recently started experiencing this as well, asuming you're
> talking about:
>
> --- NoMethodError from thread: load messages for thread-view-mode
> undefined method `expandable?' for #<Array:0x7faa50e2d978>
> /home/dato/devel/sup/work/lib/sup/modes/thread-view-mode.rb:615:in `regen_text'
> /home/dato/devel/sup/work/lib/sup/modes/thread-view-mode.rb:610:in `each'
> /home/dato/devel/sup/work/lib/sup/modes/thread-view-mode.rb:610:in `regen_text'
> /home/dato/devel/sup/work/lib/sup/thread.rb:68:in `each'
> /home/dato/devel/sup/work/lib/sup/thread.rb:170:in `each_with_stuff'
> [...]
Yes, it's the same error I get. Any insights as to what is causing this?
Cheers,
Christopher.
--
================================
Christopher Bertels
http://www.adztec-independent.de
GPG Key ID: 0x2345b203
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090916/7f6fbfa9/attachment-0001.bin>
------------------------------
Message: 1125
Date: Thu, 17 Sep 2009 13:05:45 -0700
From: Carl Worth <cworth@cworth.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] [PATCH] Fix message_to_chunks for the m.body ==
nil case.
Message-ID: <1253217341-sup-8631@yoom.home.cworth.org>
Content-Type: text/plain; charset=UTF-8
The code was previously broken in calling EnclosedMessage.new with
only 2 instead of 5 arguments.
---
A friend of mine couldn't import his mail into sup due to the crash
fixed by this patch. It looks like the message he had that was causing
this infrequently-used (and obviously broken) code to be executed had
some mime pieces corrupted.
The message consisted of several mime-attached messages looking like:
--==_Exmh_5062123120
Content-Type: message/rfc822 ; name="5714"
Content-Description: 5714
Content-Disposition: attachment; filename="5714"
Return-path: <omitted>
...
but one part was missing the mime searpate and Content-Type and
instead just looked like:
Content-Description: 5692
Content-Disposition: attachment; filename="5692"
Return-path: <omitted>
...
I tried fixing this first by adding several more empty-string
arguments, that is:
[Chunk::EnclosedMessage.new(nil, "", "", "", "")]
but that ended up causing this exception instead:
./lib/sup/message-chunks.rb:212:in `initialize': undefined
method `full_adress' for nil:NilClass (NoMethodError)
So I'm not 100% sure that this patch is correct, but it does allow
sup-sync to proceed and the message appears in sup as well as could be
expected, (the "extra" headers from the corrupted mime part appear in
the body as one might expect here).
-Carl
lib/sup/message.rb | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/sup/message.rb b/lib/sup/message.rb
index afa8f00..579c1e5 100644
--- a/lib/sup/message.rb
+++ b/lib/sup/message.rb
@@ -453,7 +453,7 @@ private
cc_people = cc ? Person.from_address_list(cc) : nil
[Chunk::EnclosedMessage.new(from_person, to_people, cc_people, msgdate, subj)] + message_to_chunks(payload, encrypted)
else
- [Chunk::EnclosedMessage.new(nil, "")]
+ []
end
else
filename =
--
1.6.4.3
------------------------------
Message: 1126
Date: Fri, 18 Sep 2009 15:50:13 -0400
From: William Erik Baxter <web-sup@superscript.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Hello, and before-add-message hook for applying
labels per CDB
Message-ID: <1253303164-sup-1138@kronos>
Content-Type: text/plain; charset=US-ASCII
Hello fellow sup users. I began using sup last week, spent some time setting
it up in parallel with mutt, and have not used mutt since, except through
accident of habit. Thanks to all developers for your excellent work.
A before-add-message hook follows. It applies labels per entries in a CDB
constructed externally. I hope you find it useful.
Cheers, W.
#### Automatically add labels.
require 'cdb';
@cdb ||= CDB.new("/home/web/Mail/suplabel.cdb");
# Mark by a recipient (to/cc)
# Construct [ [ prefix, string ] ... ].
# Look up "prefix:string" in CDB to obtain a list of labels to apply.
a = []
a += [ [ "from", message.from.email ] ]
a += message.recipients.map{ |x| [ "recipient", x.email ] }
a.each { |pair|
key = pair[0] + ":" + pair[1];
@cdb.each(key) { |value|
value.split.each { |label| message.add_label(label) }
}
}
------------------------------
Message: 1127
Date: Fri, 18 Sep 2009 15:54:18 -0400
From: William Erik Baxter <web-sup@superscript.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] [PATCH] Add hooks to sort and format
label-list-mode display.
Message-ID: <1253303493-sup-288@kronos>
Content-Type: text/plain; charset=US-ASCII
---
lib/sup/modes/label-list-mode.rb | 37 ++++++++++++++++++++++++++++++++++---
1 files changed, 34 insertions(+), 3 deletions(-)
diff --git a/lib/sup/modes/label-list-mode.rb b/lib/sup/modes/label-list-mode.rb
index f65ec2e..d94f56f 100644
--- a/lib/sup/modes/label-list-mode.rb
+++ b/lib/sup/modes/label-list-mode.rb
@@ -8,6 +8,24 @@ class LabelListMode < LineCursorMode
k.add :toggle_show_unread_only, "Toggle between showing all labels and those with unread mail", 'u'
end
+ HookManager.register "label-list-filter", <<EOS
+Filter the label list, typically to sort.
+Variables:
+ counted: an array of counted labels.
+Return value:
+ An array of counted labels with sort_by output structure.
+EOS
+
+ HookManager.register "label-list-format", <<EOS
+Create the sprintf format string for label-list-mode.
+Variables:
+ width: the maximum label width
+ tmax: the maximum total message count
+ umax: the maximum unread message count
+Return value:
+ A format string for sprintf
+EOS
+
def initialize
@labels = []
@text = []
@@ -50,14 +68,22 @@ protected
@text = []
labels = LabelManager.all_labels
- counts = labels.map do |label|
+ counted = labels.map do |label|
string = LabelManager.string_for label
total = Index.num_results_for :label => label
unread = (label == :unread)? total : Index.num_results_for(:labels => [label, :unread])
[label, string, total, unread]
- end.sort_by { |l, s, t, u| s.downcase }
+ end
+
+ if HookManager.enabled? "label-list-filter"
+ counts = HookManager.run "label-list-filter", :counted => counted
+ else
+ counts = counted.sort_by { |l, s, t, u| s.downcase }
+ end
width = counts.max_of { |l, s, t, u| s.length }
+ tmax = counts.max_of { |l, s, t, u| t }
+ umax = counts.max_of { |l, s, t, u| u }
if @unread_only
counts.delete_if { | l, s, t, u | u == 0 }
@@ -78,8 +104,13 @@ protected
next
end
+ fmt = HookManager.run "label-list-format", :width => width, :tmax => tmax, :umax => umax
+ if !fmt
+ fmt = "%#{width + 1}s %5d %s, %5d unread"
+ end
+
@text << [[(unread == 0 ? :labellist_old_color : :labellist_new_color),
- sprintf("%#{width + 1}s %5d %s, %5d unread", string, total, total == 1 ? " message" : "messages", unread)]]
+ sprintf(fmt, string, total, total == 1 ? " message" : "messages", unread)]]
@labels << [label, unread]
yield i if block_given?
end.compact
--
1.5.3.2
------------------------------
Message: 1128
Date: Sat, 19 Sep 2009 08:15:03 +1000
From: Richard Sandilands <richard@infoarts.info>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Trouble implementing UTF-8 ncurses fix
Message-ID:
<1253311953-sup-3472@Richard-Sandilandss-MacBook-Pro.local>
Content-Type: text/plain; charset=UTF-8
Hi there
I'm trying to implement the fix found here:
<http://sup.rubyforge.org/wiki/wiki.pl?UTF8>
but am running into trouble when I run 'run-this-for-sup.sh'. I've
installed the ncurses-5.7 library on my Mac 10.6 machine, but the shell
script above gives this output to mkmf.log: <http://pastie.org/622306>
Any clues on what I might be missing would be appreciated.
--
Richard Sandilands
------------------------------
Message: 1129
Date: Sun, 20 Sep 2009 21:46:24 +0200
From: Michael Stapelberg <michael+sup@stapelberg.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Bug: Converting the index to xapian fails with a
message with very old date
Message-ID: <1253475875-sup-5119@midna.zekjur.net>
Content-Type: text/plain; charset=UTF-8
Hi,
I have a spam mail in one of my sources. This mail has the following Date-line:
Date: Mon, 1 Jan 1601 00:48:33 +0500
This makes sup/xapian/ruby (one of them) go crazy and abort with an exception:
## read 5856m (about 72%) @ 10.0m/s. 0:09:47 elapsed, about 0:03:44 remaining
/usr/lib/ruby/1.8/sup/xapian_index.rb:532:in `_dump': year too big to marshal (ArgumentError)
from /usr/lib/ruby/1.8/sup/xapian_index.rb:532:in `dump'
from /usr/lib/ruby/1.8/sup/xapian_index.rb:532:in `index_message'
from /usr/lib/ruby/1.8/sup/xapian_index.rb:124:in `sync_message'
from /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
from /usr/lib/ruby/1.8/sup/xapian_index.rb:398:in `synchronize'
from /usr/lib/ruby/1.8/sup/xapian_index.rb:123:in `sync_message'
from /usr/lib/ruby/1.8/sup/xapian_index.rb:94:in `add_message'
from /home/michael/software/sup-mainline/bin/sup-sync:211
from /usr/lib/ruby/1.8/sup/poll.rb:151:in `each_message_from'
from /usr/lib/ruby/1.8/sup/imap.rb:197:in `each'
from /usr/lib/ruby/1.8/sup/imap.rb:185:in `upto'
from /usr/lib/ruby/1.8/sup/imap.rb:185:in `each'
from /usr/lib/ruby/1.8/sup/util.rb:560:in `send'
from /usr/lib/ruby/1.8/sup/util.rb:560:in `__pass'
from /usr/lib/ruby/1.8/sup/util.rb:547:in `method_missing'
from /usr/lib/ruby/1.8/sup/poll.rb:139:in `each_message_from'
from /usr/lib/ruby/1.8/sup/util.rb:520:in `send'
from /usr/lib/ruby/1.8/sup/util.rb:520:in `method_missing'
from /home/michael/software/sup-mainline/bin/sup-sync:146
from /home/michael/software/sup-mainline/bin/sup-sync:141:in `each'
from /home/michael/software/sup-mainline/bin/sup-sync:141
I used revision 68bf6a277c5fdefb3b9d6a4b5d4dfbce3f9f9ccf of sup.
Best regards,
Michael
------------------------------
Message: 1130
Date: Sun, 20 Sep 2009 21:51:38 +0200
From: Michael Stapelberg <michael+sup@stapelberg.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Bug: Opening PGP encrypted mails fails with latest
revision
Message-ID: <1253476236-sup-9371@midna.zekjur.net>
Content-Type: text/plain; charset=UTF-8
Hi,
when opening PGP encrypted mails (MIME), sup crashes with the following
exception:
--- NoMethodError from thread: load messages for thread-view-mode
undefined method `expandable?' for nil:NilClass
/usr/lib/ruby/1.8/sup/modes/thread-view-mode.rb:621:in `regen_text'
/usr/lib/ruby/1.8/sup/modes/thread-view-mode.rb:616:in `each'
/usr/lib/ruby/1.8/sup/modes/thread-view-mode.rb:616:in `regen_text'
/usr/lib/ruby/1.8/sup/thread.rb:68:in `each'
/usr/lib/ruby/1.8/sup/thread.rb:168:in `each_with_stuff'
/usr/lib/ruby/1.8/sup/thread.rb:67:in `each'
/usr/lib/ruby/1.8/sup/modes/thread-view-mode.rb:585:in `regen_text'
/usr/lib/ruby/1.8/sup/modes/thread-view-mode.rb:135:in `initialize'
/usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:112:in `new'
/usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:112:in `select'
/usr/lib/ruby/1.8/sup.rb:77:in `reporting_thread'
/usr/lib/ruby/1.8/sup.rb:75:in `initialize'
/usr/lib/ruby/1.8/sup.rb:75:in `new'
/usr/lib/ruby/1.8/sup.rb:75:in `reporting_thread'
/usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:102:in `select'
/usr/lib/ruby/1.8/sup/mode.rb:50:in `send'
/usr/lib/ruby/1.8/sup/mode.rb:50:in `handle_input'
/usr/lib/ruby/1.8/sup/buffer.rb:265:in `handle_input'
bin/sup:236
Best regards,
Michael
------------------------------
Message: 1131
Date: Mon, 21 Sep 2009 00:16:34 +0300
From: Ali Polatel <alip@exherbo.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Problem with lbdb and extra contacts hook
Message-ID: <1253481392-sup-4891@harikalardiyari>
Content-Type: text/plain; charset=UTF-8
Hello,
I've just started using sup and I'm really loving it.
Thanks for the great software.
I have a problem with extra-contact-addresses hook and lbdb.
Using the hook in the wiki:
contacts = []
`lbdbq |awk -F"\t" '{print $2 , "<"$1">"}'`.each { |c| contacts.push(c) }
return contacts
I get error running hook and here's the message that appears in the log:
[Sun Sep 20 23:50:17 +0300 2009] hook: error running hook: unexpected return
[Sun Sep 20 23:50:17 +0300 2009] hook:
/home/alip/.sup/hooks/extra-contact-addresses.rb:7:in `__run'
/home/alip/src/sup/lib/sup/hook.rb:42:in `__run'
/home/alip/src/sup/lib/sup/hook.rb:82:in `run'
/home/alip/src/sup/lib/sup/util.rb:520:in `send'
/home/alip/src/sup/lib/sup/util.rb:520:in `method_missing'
/home/alip/src/sup/lib/sup/buffer.rb:540:in `ask_for_contacts'
/home/alip/src/sup/lib/sup/util.rb:520:in `send'
/home/alip/src/sup/lib/sup/util.rb:520:in `method_missing'
/home/alip/src/sup/lib/sup/modes/compose-mode.rb:24:in `spawn_nicely'
/home/alip/src/sup/bin/sup:282
This is with current master 68bf6a277c5fdefb3b9d6a4b5d4dfbce3f9f9ccf
--
Regards,
Ali Polatel
------------------------------
Message: 1132
Date: Mon, 21 Sep 2009 02:11:04 +0300
From: Ali Polatel <alip@exherbo.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Problem with lbdb and extra contacts hook
Message-ID: <1253488117-sup-4560@harikalardiyari>
Content-Type: text/plain; charset=UTF-8
Ali Polatel yazm??:
> Hello,
> I've just started using sup and I'm really loving it.
> Thanks for the great software.
>
> I have a problem with extra-contact-addresses hook and lbdb.
> Using the hook in the wiki:
> contacts = []
> `lbdbq |awk -F"\t" '{print $2 , "<"$1">"}'`.each { |c| contacts.push(c) }
> return contacts
Answering myself, removing return from the last line works as expected!
I'll see if I can edit the wiki.
--
Regards,
Ali Polatel
------------------------------
Message: 1133
Date: Tue, 22 Sep 2009 19:05:48 +0200
From: Michael Stapelberg <michael+sup@stapelberg.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Bug: Messages using inline GPG are not decrypted
Message-ID: <1253638189-sup-7758@midna.zekjur.net>
Content-Type: text/plain; charset="utf-8"
Hi,
I noticed that emails sent by Thunderbird which contain inline GPG messages
are not decrypted at all. I?ve attached such a message so you can verify
it. Unfortunately my ruby skills did not suffice to fix this on my own.
Thanks and best regards,
Michael
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: crypted.txt
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090922/628024f2/attachment-0001.txt>
------------------------------
Message: 1134
Date: Tue, 22 Sep 2009 19:24:24 +0200
From: Michael Stapelberg <michael+sup@stapelberg.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Bug: Messages using inline GPG are not
decrypted
Message-ID: <1253640093-sup-48@midna.zekjur.net>
Content-Type: text/plain; charset=UTF-8
Hi,
Excerpts from Michael Stapelberg's message of Di Sep 22 19:05:48 +0200 2009:
> I noticed that emails sent by Thunderbird which contain inline GPG messages
> are not decrypted at all. I?ve attached such a message so you can verify
> it. Unfortunately my ruby skills did not suffice to fix this on my own.
Addition: Probably I was able to fix it, but the other bug I reported about
not being able to open GPG encrypted email at all was the one I was seeing.
So, fix should be easy (untested, because of the other bug):
--- a/lib/sup/message.rb
+++ b/lib/sup/message.rb
@@ -436,6 +436,16 @@ private
end
chunks
+ elsif m.header.content_type == "application/pgp"
+ notice, sig, decryptedm = CryptoManager.decrypt m.body
+ if decryptedm # managed to decrypt
+ children = message_to_chunks(decryptedm, true)
+ chunks = [notice, sig, children]
+ else
+ chunks = [notice]
+ end
+
+ chunks
elsif m.header.content_type == "message/rfc822"
if m.body
payload = RMail::Parser.read(m.body)
Best regards,
Michael
------------------------------
Message: 1135
Date: Tue, 22 Sep 2009 14:01:50 -0400
From: David Pflug <david.pflug@hostdime.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Exception while marking mail as read
Message-ID: <1253642183-sup-1331@dpflug-desktop>
Content-Type: text/plain; charset=utf8
Hi there,
I'm using :next, having used the fix from :ncursesw.
I've got some unread threads that are 300+ messages long (threaded by subject) from automated processes. I did a search for is:unread and started marking them read, and saved my changes (or, at least, pressed $ while sup was chugging through the last thread). It's possible a poll started at the same time, but I can't be sure.
Here's exception.log:
--- Ferret::StateError from thread: load threads for thread-index-mode
State Error occured at <except.c>:93 in xraise
Error occured in index.c:4150 - sr_get_lazy_doc
Document 9233 has already been deleted
/usr/lib/ruby/gems/1.8/gems/ferret-0.11.6/lib/ferret/index.rb:421:in `[]'
/usr/lib/ruby/gems/1.8/gems/ferret-0.11.6/lib/ferret/index.rb:421:in `[]'
/usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
/usr/lib/ruby/gems/1.8/gems/ferret-0.11.6/lib/ferret/index.rb:413:in `[]'
./lib/sup/ferret_index.rb:163:in `each_id_by_date'
/usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
./lib/sup/ferret_index.rb:163:in `each_id_by_date'
./lib/sup/ferret_index.rb:162:in `each'
./lib/sup/ferret_index.rb:162:in `each_id_by_date'
./lib/sup/thread.rb:328:in `load_n_threads'
./lib/sup/modes/thread-index-mode.rb:625:in `__unprotected_load_n_threads'
(eval):12:in `load_n_threads'
./lib/sup/modes/thread-index-mode.rb:609:in `load_n_threads_background'
./lib/sup.rb:77:in `reporting_thread'
./lib/sup.rb:75:in `initialize'
./lib/sup.rb:75:in `new'
./lib/sup.rb:75:in `reporting_thread'
./lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background'
./lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads'
(eval):12:in `load_threads'
./lib/sup/modes/thread-index-mode.rb:81:in `initialize'
./lib/sup/modes/line-cursor-mode.rb:22:in `call'
./lib/sup/modes/line-cursor-mode.rb:22:in `initialize'
./lib/sup/modes/line-cursor-mode.rb:22:in `each'
./lib/sup/modes/line-cursor-mode.rb:22:in `initialize'
./lib/sup/modes/line-cursor-mode.rb:19:in `new'
./lib/sup/modes/line-cursor-mode.rb:19:in `initialize'
./lib/sup/modes/thread-index-mode.rb:54:in `initialize'
./lib/sup/modes/search-results-mode.rb:6:in `initialize'
./lib/sup/modes/search-results-mode.rb:30:in `new'
./lib/sup/modes/search-results-mode.rb:30:in `spawn_from_query'
bin/sup:270
Regards,
David
--
David Pflug
System Technician
Hostdime.com, Inc.
------------------------------
Message: 1136
Date: Fri, 25 Sep 2009 21:08:52 +0200
From: Michael Stapelberg <michael+sup@stapelberg.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Bug: Opening PGP encrypted mails fails with
latest revision
Message-ID: <1253905662-sup-1750@midna.zekjur.net>
Content-Type: text/plain; charset=UTF-8
Hi,
Excerpts from Michael Stapelberg's message of So Sep 20 21:51:38 +0200 2009:
> when opening PGP encrypted mails (MIME), sup crashes with the following
> exception:
Further debugging revealed that this has been introduced in revision
927b7df4b2052a6b3c2ae1f2b44a6bc901315f8d and can be fixed with the following
patch:
--- a/lib/sup/message.rb
+++ b/lib/sup/message.rb
@@ -413,7 +413,7 @@ private
notice, sig, decryptedm = CryptoManager.decrypt payload
if decryptedm # managed to decrypt
children = message_to_chunks(decryptedm, true)
- [notice, sig, children]
+ [notice, sig, children].flatten.compact
else
[notice]
end
Best regards,
Michael
------------------------------
Message: 1137
Date: Fri, 25 Sep 2009 21:10:11 +0200
From: Michael Stapelberg <michael+sup@stapelberg.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Bug: Messages using inline GPG are not
decrypted
Message-ID: <1253905743-sup-419@midna.zekjur.net>
Content-Type: text/plain; charset=UTF-8
Hi,
after fixing the other bug related to GPG messages, this patch has to be
modified, too:
--- a/lib/sup/message.rb
+++ b/lib/sup/message.rb
@@ -436,6 +436,16 @@ private
end
chunks
+ elsif m.header.content_type == "application/pgp"
+ notice, sig, decryptedm = CryptoManager.decrypt m.body
+ if decryptedm # managed to decrypt
+ children = message_to_chunks(decryptedm, true)
+ chunks = [notice, sig, children].flatten.compact
+ else
+ chunks = [notice]
+ end
+
+ chunks
elsif m.header.content_type == "message/rfc822"
if m.body
payload = RMail::Parser.read(m.body)
Best regards,
Michael
------------------------------
Message: 1138
Date: Fri, 25 Sep 2009 21:13:29 +0200
From: Michael Stapelberg <michael+sup@stapelberg.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Bug: Killed threads coming up again
Message-ID: <1253905917-sup-5964@midna.zekjur.net>
Content-Type: text/plain; charset=UTF-8
Hi,
I noticed that killed messages sometimes appear in my inbox again. This might
be caused by a new label coming up by a new message for this thread, which
arrived through a different source (in my case, a message was marked as spam,
thus arrived in a new IMAP folder and thus a new source in sup and therefore
came up with the label spam).
Did anyone of you notice the same? Can you reproduce this?
Best regards,
Michael
------------------------------
Message: 1139
Date: Fri, 25 Sep 2009 13:46:31 -0700
From: Carl Worth <cworth@cworth.org>
To: Sup Talk <sup-talk@rubyforge.org>
Subject: [sup-talk] [PATCH] Fix uninitialized @name member in
person.rb.
Message-ID: <1253911543-sup-7680@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
Apparently a Person can be initialized with a nil name, (presumably
from a message where there's no name given), which before this commit
resulted in the following warning:
./lib/sup/person.rb:46: warning: instance variable @name not initialized
This warning was especially unpleasant since it appeared in the current
window, causing the terminal contents to incorrectly scroll up, (as
opposed to just appearing in the log or so).
---
lib/sup/person.rb | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/lib/sup/person.rb b/lib/sup/person.rb
index c4f40a5..cd5b1ea 100644
--- a/lib/sup/person.rb
+++ b/lib/sup/person.rb
@@ -11,6 +11,8 @@ class Person
if @name =~ /^(['"]\s*)(.*?)(\s*["'])$/
@name = $2
end
+ else
+ @name = nil
end
@email = email.gsub(/^\s+|\s+$/, "").gsub(/\s+/, " ").downcase
--
1.6.4.3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090925/26a4d1df/attachment-0001.bin>
------------------------------
Message: 1140
Date: Fri, 25 Sep 2009 14:08:23 -0700
From: Carl Worth <cworth@cworth.org>
To: Sup Talk <sup-talk@rubyforge.org>
Subject: [sup-talk] [PATCH] Allow thread index view to sort oldest
first
Message-ID: <1253911610-sup-2052@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
Keith and I both want to read our email in chronological order,
(reading oldest messages first), so we believe it makes sense to
present the inbox mode in this order, (with the oldest messages at the
top).
This is distinct from the order for global searches where having the
newest messages first does seem obviously correct.
The below patches are a first cut at implementing this. They provide a
new configuration option, (:inbox_newest_first), which can be used to
control the default sorting for the inbox. Keith's original patch
doesn't change sup's behavior unless the user manually configures this
option to false. My second patch changes the default. Obviously, it
would be easy to accept Keith's version without changing the default
for sup.
One nice thing about the inmplentation is that any refined searches
inherit the mode of the parent search, which makes it easy to maintain
oldest-message-first for "reading" and newest-message-first for
"searching".
Also note that there's a new command 'o' to toggle the search order
for a current view. This is a feature that we talked about earlier as
a way to avoid the need for the distinction between the ',' and ']'
commands in thread-view-mode. If the user can control the sort of the
search view, then it would be more natural to have commands that
simply advance to the "next" message, (since the user can choose in
advance what "next" means).
A couple of caveats with respect to the patch as it exists so far:
1. When doing oldest-first searching, it wasn't obvious if it's even
possible to query for only the N oldest messages (to lazily load
new threads while navigating as sup currently does). So the patch
currently loads all threads when in oldest-first mode.
In my use so far this has worked well since I generally have a
small number of messages in my inbox (and even fewer in my refined
views of my inbox) and those are the only places where I use
oldest-first sorting. For global searches, I do have an effectively
infinite number of messages, but there I do use newest-first
searching which still has the lazy loading.
2. Currently sup uses the date of the newest message in a thread as
the key for sorting that message. This is correct for newest-first
sorting. But when doing the new oldest-first sorting, the patch
really should be augmented to instead use the date of the oldest
message in a thread that matches the current search criteria.
We haven't looked yet into how hard this would be to fix. (And we'd
of course be glad for any help or pointers.)
-Carl
PS. We're still total ruby newbies, so please point out any silly
mistakes we're missing with respect to ruby idioms.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Allow-thread-index-view-to-sort-oldest-first.patch
Type: application/octet-stream
Size: 7849 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090925/8fd3d30c/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Change-the-default-sort-for-inbox-mode-to-be-oldest-.patch
Type: application/octet-stream
Size: 777 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090925/8fd3d30c/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090925/8fd3d30c/attachment-0001.bin>
------------------------------
Message: 1141
Date: Sat, 26 Sep 2009 06:48:04 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Problem with lbdb and extra contacts hook
Message-ID: <1253972856-sup-3123@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ali Polatel's message of 2009-09-20:
> Answering myself, removing return from the last line works as
> expected! I'll see if I can edit the wiki.
Yep, that was the problem. Hooks shouldn't call return. Nice work. :)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1142
Date: Sat, 26 Sep 2009 06:50:29 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Trouble implementing UTF-8 ncurses fix
Message-ID: <1253972920-sup-9313@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Richard Sandilands's message of 2009-09-18:
> but am running into trouble when I run 'run-this-for-sup.sh'. I've
> installed the ncurses-5.7 library on my Mac 10.6 machine, but the shell
> script above gives this output to mkmf.log: <http://pastie.org/622306>
I'm not sure of how to do it on your particular system, but you need to
install libncursesw (note the "w"). Maybe someone else who runs Sup on a
mac can help.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1143
Date: Sat, 26 Sep 2009 06:56:04 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Bug: Converting the index to xapian fails with
a message with very old date
Message-ID: <1253973258-sup-3347@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Michael Stapelberg's message of 2009-09-20:
> This makes sup/xapian/ruby (one of them) go crazy and abort with an exception:
> ## read 5856m (about 72%) @ 10.0m/s. 0:09:47 elapsed, about 0:03:44 remaining
> /usr/lib/ruby/1.8/sup/xapian_index.rb:532:in `_dump': year too big to marshal
> (ArgumentError)
Interesting. The Xapian index has had some trouble with crazy dates in
the past, but that should be fixed. Can you apply the following debug
patch and send the output for that message?
Thanks!
diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
index ab25ea0..b94c8b0 100644
--- a/lib/sup/xapian_index.rb
+++ b/lib/sup/xapian_index.rb
@@ -509,6 +509,9 @@ EOS
Xapian.sortable_serialise 0
end
+ puts "> truncated date is #{truncated_date.inspect}"
+ puts "> date_value is #{date_value.inspect}"
+
docid = nil
unless doc = find_doc(m.id)
doc = Xapian::Document.new
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1144
Date: Sat, 26 Sep 2009 06:58:59 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Hello, and before-add-message hook for
applying labels per CDB
Message-ID: <1253973470-sup-620@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from William Erik Baxter's message of 2009-09-18:
> Hello fellow sup users. I began using sup last week, spent some time setting
> it up in parallel with mutt, and have not used mutt since, except through
> accident of habit. Thanks to all developers for your excellent work.
Great! Welcome!
> A before-add-message hook follows. It applies labels per entries in a CDB
> constructed externally. I hope you find it useful.
Thanks! If you get a chance, please add it to the wiki:
http://sup.rubyforge.org/wiki/wiki.pl?Hooks
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1145
Date: Sat, 26 Sep 2009 07:31:56 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash while scrolling
Message-ID: <1253975267-sup-8308@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Sorry it's taken me so long to get back to this.
Reformatted excerpts from Ben Gamari's message of 2009-09-16:
> Thread#join: deadlock 0x7f592eec4d78 - mutual join(0x7f592f01d6e8)
> /opt/exp/sup/lib/sup/message.rb:240:in `select'
> /opt/exp/sup/lib/sup/buffer.rb:35:in `nonblocking_getch'
> /usr/bin/sup:213
>
> However, at this point during debugging I happened to pipe stderr to a
> file and accidentally found that most of the backtrace was actually
> being hidden by curses. Examining the full output on stderr reveals,
>
> /usr/bin/sup:213(eval):3:in `synchronize': Thread#join: deadlock
> 0x7f4d5da565c0 - mutual join(0x7f4d5daf8be0) (ThreadError)
> from (eval):3:in `raw_header'
> from /opt/exp/sup/lib/sup/imap.rb:98:in `load_header'
I definitely am not sure why there's a deadlock happening, but I am
guessing, based on the line numbers in that first exception, that it's
being triggered by an underlying problem with the source. If you run
sup with -n, does that change anything? (Or produce a better exception?)
> Anyways, this is the current status of things on my machine. William, do
> you have any ideas what might cause such a backtrace. At this point
> classes have started and I really have no more time to devote to
> getting sup working. If there isn't a fairly simple solution here I guess
> I'll just need to stick with mutt (ugh). Anyways, thanks for your work.
Well, there's a workaround, which is to switch over to an offlineimap
setup where your Gmail is mirrored locally and Sup reads the mirror
(which is what you want anyways if you're serious about using Sup with
an IMAP client). I don't know what's causing the deadlock, but I will
try and reproduce it on my end.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1146
Date: Sat, 26 Sep 2009 07:40:59 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Fixing header for encrypted messages (might be
an old issue)
Message-ID: <1253976007-sup-711@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Christopher Bertels's message of 2009-09-15:
> Excerpts from Adeodato Sim?'s message of Mi Sep 16 00:21:19 +0200 2009:
> > --- NoMethodError from thread: load messages for thread-view-mode
> > undefined method `expandable?' for #<Array:0x7faa50e2d978>
> > /home/dato/devel/sup/work/lib/sup/modes/thread-view-mode.rb:615:in `regen_text'
> > /home/dato/devel/sup/work/lib/sup/modes/thread-view-mode.rb:610:in `each'
> > /home/dato/devel/sup/work/lib/sup/modes/thread-view-mode.rb:610:in `regen_text'
> > /home/dato/devel/sup/work/lib/sup/thread.rb:68:in `each'
> > /home/dato/devel/sup/work/lib/sup/thread.rb:170:in `each_with_stuff'
> > [...]
>
> Yes, it's the same error I get. Any insights as to what is causing this?
Just to confirm---both of you are seeing this error, with a recent git
master, when opening encrypted messages?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1147
Date: Sat, 26 Sep 2009 07:48:48 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup and Ruby 1.9.1 - deadlock?
Message-ID: <1253976432-sup-3851@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Rich Lane's message of 2009-09-15:
> I think William said he's been doing some 1.9 work recently. I wouldn't
> say it's ready just yet.
My current plan is to release an 0.9 tomorrow or so (probably without
advertising the Xapian support), and to focus on Ruby 1.9 support for
the next release.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1148
Date: Sat, 26 Sep 2009 07:49:41 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Fixing header for encrypted messages (might be
an old issue)
Message-ID: <1253976576-sup-8002@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from William Morgan's message of 2009-09-26:
> Just to confirm---both of you are seeing this error, with a recent git
> master, when opening encrypted messages?
Ah, looks like Michael Stapelberg's patch will fix this.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1149
Date: Sat, 26 Sep 2009 07:56:14 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Hello and thanks
Message-ID: <1253976950-sup-8220@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Hi Bo,
Reformatted excerpts from Bo Borgerson's message of 2009-09-12:
> A git-send-email out of the blue isn't necessarily the friendliest of
> introductions, though, so I just wanted to write first and say thanks
> to William and everyone who has contributed to sup. It's pretty
> awesome.
Thanks for the kind words, and welcome!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1150
Date: Sat, 26 Sep 2009 10:45:49 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Fix uninitialized @name member in
person.rb.
Message-ID: <1253987121-sup-2390@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Carl Worth's message of 2009-09-25:
> Apparently a Person can be initialized with a nil name, (presumably
> from a message where there's no name given), which before this commit
> resulted in the following warning:
>
> ./lib/sup/person.rb:46: warning: instance variable @name not initialized
Thanks, I have fixed this in master. Let me know if it doesn't work!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1151
Date: Sat, 26 Sep 2009 10:50:42 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Bug: Killed threads coming up again
Message-ID: <1253987261-sup-6729@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Michael Stapelberg's message of 2009-09-25:
> I noticed that killed messages sometimes appear in my inbox again.
Rats. I thought we had this problem licked.
> Did anyone of you notice the same? Can you reproduce this?
I haven't seen this recently. Are you using 0.8.1 or git? Does anyone
else see this with git?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1152
Date: Sat, 26 Sep 2009 20:03:53 +0200
From: Michael Stapelberg <michael+sup@stapelberg.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Bug: Killed threads coming up again
Message-ID: <1253988170-sup-189@midna.zekjur.net>
Content-Type: text/plain; charset=UTF-8
Hi,
Excerpts from William Morgan's message of Sa Sep 26 19:50:42 +0200 2009:
> Rats. I thought we had this problem licked.
Unfortunately not. Also, this also happened with a thread which got no new
labels today, so my guess in the last mail was not correct.
> I haven't seen this recently. Are you using 0.8.1 or git? Does anyone
> else see this with git?
I am using git version 68bf6a277c5fdefb3b9d6a4b5d4dfbce3f9f9ccf.
Best regards,
Michael
------------------------------
Message: 1153
Date: Sat, 26 Sep 2009 11:09:36 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Bug: Messages using inline GPG are not
decrypted
Message-ID: <1253988435-sup-8649@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Michael Stapelberg's message of 2009-09-25:
> after fixing the other bug related to GPG messages, this patch has to be
> modified, too:
I believe I've fixed this in git. Thunderbird is not producing
RFC3156-compliant encrypted emails, but by the Postel's Law we will
accomodate their errors. Let me know if it doesn't work.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1154
Date: Sat, 26 Sep 2009 11:10:04 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Bug: Opening PGP encrypted mails fails with
latest revision
Message-ID: <1253988590-sup-9530@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Michael Stapelberg's message of 2009-09-25:
> Further debugging revealed that this has been introduced in revision
> 927b7df4b2052a6b3c2ae1f2b44a6bc901315f8d and can be fixed with the
> following patch:
Thanks, this should be fixed in git. Give it a try.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1155
Date: Sat, 26 Sep 2009 20:09:56 +0200
From: Guillaume Quintard <guillaume.quintard@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Hook, again
Message-ID: <1253988011-sup-8497@altis>
Content-Type: text/plain; charset=UTF-8
Sorry to come back again with that issue, but I'm having trouble with
the reply-from hook. Here's what I have:
message.recipients.each {
|person|
if (person.email =~ /addr@site.com/) != nil
Person.from_address "Foo <bar@site.org>"
end
}
But it doesn't seem to work.
If I reply to a mail addressed to addr@site.com, the log says nothing, but the from field isn't changed.
If I reply to any other mail, le log complains I didn't return a Person
And if I just put Person.from_address "Foo <addr@site.org>" in the
hook, the from field is correctly changed.
I'm a bit lost on that one (still not knowing alot of ruby doesn't help
I must say). Am I missing the obvious here?
Cheers.
--
Guillaume
------------------------------
Message: 1156
Date: Sat, 26 Sep 2009 11:12:24 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Fix message_to_chunks for the m.body
== nil case.
Message-ID: <1253988663-sup-3838@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Carl Worth's message of 2009-09-17:
> The code was previously broken in calling EnclosedMessage.new with
> only 2 instead of 5 arguments.
Thanks, this has been applied.
> So I'm not 100% sure that this patch is correct, but it does allow
> sup-sync to proceed and the message appears in sup as well as could be
> expected, (the "extra" headers from the corrupted mime part appear in
> the body as one might expect here).
Yeah, I think that's the best we can hope for here.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1157
Date: Sat, 26 Sep 2009 11:12:50 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] mime-decode hook: provide a "charset"
variable with the attachment charset
Message-ID: <1253988754-sup-7987@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Adeodato Sim?'s message of 2009-09-13:
> Now that that fix is in, can you merge the mime-decode improvement from
> <6fc2e5dd8aa2b0b8547375d77b1776d779f85817.1247238014.git.dato@net.com.org.es>?
Applied directly to master. Sorry for the grand delay.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1158
Date: Sat, 26 Sep 2009 11:17:14 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Case-sensitivity of Content-Type: more
RubyMail stupidity?
Message-ID: <1253988779-sup-2896@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Kevin Riggle's message of 2009-09-12:
> I theorize that RubyMail is being case-sensitive where it shouldn't.
Although I love criticizing RubyMail, I think this is Sup's fault. I
don't think it's in RubyMail's proper purview to canonicalize header
values (though header names are fine).
Anyways, I think I've fixed this in git. Give it a try.
> Given the number of work-arounds Sup has had to implement to
> compensate for RubyMail's stupidity, and that RubyMail is currently
> unmaintained, has any thought been given to switching Sup to eg. TMail
> (http://tmail.rubyforge.org), which is maintained?
It's certainly an option, but with so many workarounds invested in
RubyMail, I'm not sure it's a win. A patch that magically makes
everything work would certainly be considered.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1159
Date: Sat, 26 Sep 2009 11:23:34 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: Sup-talk mailing list <sup-talk@rubyforge.org>
Subject: [sup-talk] sup 0.9 pre-release checkin
Message-ID: <1253989249-sup-3372@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Hi all,
I'm getting to release Sup 0.9. I have applied all outstanding bugfixes
I've found, and have merged preemptive-loading into master, which was
the only remaining unmerged feature branch.
If there's anything obviously missing, or obviously wrong with the state
of git master, now's a good time to point it out!
Other pending patches will be merged into next afterwards, and targeted
for an 0.10 release.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1160
Date: Sat, 26 Sep 2009 22:28:54 +0200
From: Michael Stapelberg <michael+sup@stapelberg.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Bug: Messages using inline GPG are not
decrypted
Message-ID: <1253996823-sup-6670@midna.zekjur.net>
Content-Type: text/plain; charset=UTF-8
Hi,
Excerpts from William Morgan's message of Sa Sep 26 20:09:36 +0200 2009:
> I believe I've fixed this in git. Thunderbird is not producing
> RFC3156-compliant encrypted emails, but by the Postel's Law we will
> accomodate their errors. Let me know if it doesn't work.
The changes basically work. The message itself is opened and decrypted
correctly. However, when handling some messages, an exception occurs
(downcase called on NilClass), which can be fixed like this:
--- a/lib/sup/message.rb
+++ b/lib/sup/message.rb
@@ -436,7 +436,7 @@ private
end
chunks
- elsif m.header.content_type.downcase == "message/rfc822"
+ elsif m.header.content_type && m.header.content_type.downcase == "message/rfc822"
if m.body
payload = RMail::Parser.read(m.body)
from = payload.header.from.first ? payload.header.from.first.format : ""
@@ -456,7 +456,7 @@ private
debug "no body for message/rfc822 enclosure; skipping"
[]
end
- elsif m.header.content_type.downcase == "application/pgp" && m.body
+ elsif m.header.content_type && m.header.content_type.downcase == "application/pgp" && m.body
## apparently some versions of Thunderbird generate encryped email that
## does not follow RFC3156, e.g. messages with X-Enigmail-Version: 0.95.0
## they have no MIME multipart and just set the body content type to
Best regards,
Michael
------------------------------
Message: 1161
Date: Sat, 26 Sep 2009 17:35:31 -0400
From: Kevin Riggle <kevinr@free-dissociation.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Case-sensitivity of Content-Type: more
RubyMail stupidity?
Message-ID: <1254000848-sup-7848@black-opal.mit.edu>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Sat Sep 26 14:17:14 -0400 2009:
> Reformatted excerpts from Kevin Riggle's message of 2009-09-12:
> > I theorize that RubyMail is being case-sensitive where it shouldn't.
>
> Although I love criticizing RubyMail, I think this is Sup's fault. I
> don't think it's in RubyMail's proper purview to canonicalize header
> values (though header names are fine).
>
> Anyways, I think I've fixed this in git. Give it a try.
>
Updated to next, restarted Sup, went to open a message, and got this crash:
(Appears to be individual messages, not all messages.)
--- NoMethodError from thread: load messages for thread-view-mode
undefined method `downcase' for nil:NilClass
./lib/sup/message.rb:439:in `message_to_chunks'
./lib/sup/message.rb:239:in `load_from_source!'
./lib/sup/modes/thread-index-mode.rb:108:in `select'
./lib/sup/hook.rb:121:in `each_with_index'
./lib/sup/thread.rb:68:in `each'
./lib/sup/thread.rb:168:in `each_with_stuff'
./lib/sup/thread.rb:67:in `each'
./lib/sup/modes/thread-index-mode.rb:105:in `each_with_index'
./lib/sup/modes/thread-index-mode.rb:105:in `select'
./lib/sup/buffer.rb:716:in `say'
./lib/sup/util.rb:520:in `send'
./lib/sup/util.rb:520:in `method_missing'
./lib/sup/modes/thread-index-mode.rb:104:in `select'
./lib/sup.rb:77:in `reporting_thread'
./lib/sup.rb:75:in `initialize'
./lib/sup.rb:75:in `new'
./lib/sup.rb:75:in `reporting_thread'
./lib/sup/modes/thread-index-mode.rb:101:in `select'
./lib/sup/mode.rb:51:in `send'
./lib/sup/mode.rb:51:in `handle_input'
./lib/sup/buffer.rb:267:in `handle_input'
bin/sup:238
- Kevin
--
Kevin Riggle (kevinr@free-dissociation.com)
http://free-dissociation.com
------------------------------
Message: 1162
Date: Sat, 26 Sep 2009 17:37:53 -0400
From: Ben Walton <bwalton@artsci.utoronto.ca>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Bug: Messages using inline GPG are not
decrypted
Message-ID: <1254001034-sup-5895@ntdws12.chass.utoronto.ca>
Content-Type: text/plain; charset=UTF-8
Excerpts from Michael Stapelberg's message of Sat Sep 26 16:28:54 -0400 2009:
> The changes basically work. The message itself is opened and decrypted
> correctly. However, when handling some messages, an exception occurs
> (downcase called on NilClass), which can be fixed like this:
+1 for this patch. I need it after updating too.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
------------------------------
Message: 1163
Date: Sat, 26 Sep 2009 23:38:49 +0200
From: Michael Stapelberg <michael+sup@stapelberg.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Bug: Converting the index to xapian fails with
a message with very old date
Message-ID: <1254001080-sup-5742@midna.zekjur.net>
Content-Type: text/plain; charset=UTF-8
Hi,
Excerpts from William Morgan's message of Sa Sep 26 15:56:04 +0200 2009:
> Interesting. The Xapian index has had some trouble with crazy dates in
> the past, but that should be fixed. Can you apply the following debug
> patch and send the output for that message?
Yes, here we go:
truncated date is Thu Jan 01 01:00:00 +0100 1970
date_value is "\200"
/usr/lib/ruby/1.8/sup/xapian_index.rb:536:in `_dump': year too big to marshal (ArgumentError)
from /usr/lib/ruby/1.8/sup/xapian_index.rb:536:in `dump'
from /usr/lib/ruby/1.8/sup/xapian_index.rb:536:in `index_message'
from /usr/lib/ruby/1.8/sup/xapian_index.rb:124:in `sync_message'
from /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
from /usr/lib/ruby/1.8/sup/xapian_index.rb:398:in `synchronize'
from /usr/lib/ruby/1.8/sup/xapian_index.rb:123:in `sync_message'
from /usr/lib/ruby/1.8/sup/xapian_index.rb:94:in `add_message'
from /home/michael/software/sup-mainline/bin/sup-sync:211
from /usr/lib/ruby/1.8/sup/poll.rb:151:in `each_message_from'
from /usr/lib/ruby/1.8/sup/imap.rb:197:in `each'
from /usr/lib/ruby/1.8/sup/imap.rb:185:in `upto'
from /usr/lib/ruby/1.8/sup/imap.rb:185:in `each'
from /usr/lib/ruby/1.8/sup/util.rb:560:in `send'
from /usr/lib/ruby/1.8/sup/util.rb:560:in `__pass'
from /usr/lib/ruby/1.8/sup/util.rb:547:in `method_missing'
from /usr/lib/ruby/1.8/sup/poll.rb:139:in `each_message_from'
from /usr/lib/ruby/1.8/sup/util.rb:520:in `send'
from /usr/lib/ruby/1.8/sup/util.rb:520:in `method_missing'
from /home/michael/software/sup-mainline/bin/sup-sync:146
from /home/michael/software/sup-mainline/bin/sup-sync:141:in `each'
from /home/michael/software/sup-mainline/bin/sup-sync:141
Best regards,
Michael
------------------------------
Message: 1164
Date: Sat, 26 Sep 2009 23:41:58 +0200
From: Michael Stapelberg <michael+sup@stapelberg.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Bug: Messages using inline GPG are not
decrypted
Message-ID: <1254001238-sup-5754@midna.zekjur.net>
Content-Type: text/plain; charset="utf-8"
Hi,
Excerpts from Michael Stapelberg's message of Sa Sep 26 22:28:54 +0200 2009:
> The changes basically work. The message itself is opened and decrypted
> correctly. However, when handling some messages, an exception occurs
> (downcase called on NilClass), which can be fixed like this:
I noticed that this is not the only place where this was wrong. Complete
patch attached (also fixes mixups like control.header.downcase.content_type
vs. control.header.content_type.downcase).
Best regards,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sup-downcase.patch
Type: application/octet-stream
Size: 2375 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090926/da544580/attachment-0001.obj>
------------------------------
Message: 1165
Date: Sat, 26 Sep 2009 18:27:57 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Hook, again
Message-ID: <1254014763-sup-4749@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Guillaume Quintard's message of 2009-09-26:
> message.recipients.each {
> |person|
> if (person.email =~ /addr@site.com/) != nil
> Person.from_address "Foo <bar@site.org>"
> end
> }
The problem is that #each returns the original array, i.e.
message.recipients. Your Person object is getting constructed and then
forgotten.
Try:
if messages.recipients.any? { |p| p.email =~ /addr@site\.com/ }
Person.from_address "Foo <bar@site.org>"
end
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1166
Date: Sat, 26 Sep 2009 18:40:06 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Bug: Messages using inline GPG are not
decrypted
Message-ID: <1254015511-sup-5690@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Michael Stapelberg's message of 2009-09-26:
> I noticed that this is not the only place where this was wrong. Complete
> patch attached (also fixes mixups like control.header.downcase.content_type
> vs. control.header.content_type.downcase).
Applied, thanks. BTW it will be slightly easier on me if you commit
changes and use git format-patch to send them (or git send-email). That
will also put your name in the automatically-generated contributors
list.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1167
Date: Sat, 26 Sep 2009 18:46:03 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Case-sensitivity of Content-Type: more
RubyMail stupidity?
Message-ID: <1254015946-sup-7518@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Kevin Riggle's message of 2009-09-26:
> undefined method `downcase' for nil:NilClass
Should be fix0red.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1168
Date: Sun, 27 Sep 2009 03:10:51 -0400
From: Kevin Riggle <kevinr@free-dissociation.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Case-sensitivity of Content-Type: more
RubyMail stupidity?
Message-ID: <1254035436-sup-1220@black-opal.mit.edu>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Sat Sep 26 21:46:03 -0400 2009:
> Reformatted excerpts from Kevin Riggle's message of 2009-09-26:
> > undefined method `downcase' for nil:NilClass
>
> Should be fix0red.
Looks like it is -- thanks!
- Kevin
--
Kevin Riggle (kevinr@free-dissociation.com)
http://free-dissociation.com
------------------------------
Message: 1169
Date: Sun, 27 Sep 2009 13:48:56 +0100
From: Adeodato Sim? <dato@net.com.org.es>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Fixing header for encrypted messages (might be
an old issue)
Message-ID: <20090927124856.GA322@chistera.yi.org>
Content-Type: text/plain; charset=us-ascii
+ William Morgan (Sat, 26 Sep 2009 07:49:41 -0700):
> Reformatted excerpts from William Morgan's message of 2009-09-26:
> > Just to confirm---both of you are seeing this error, with a recent git
> > master, when opening encrypted messages?
> Ah, looks like Michael Stapelberg's patch will fix this.
I can confirm it works again on master (and next), thanks!
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
------------------------------
Message: 1170
Date: Sun, 27 Sep 2009 13:04:39 -0400
From: William Erik Baxter <web-sup@superscript.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Why inbox-mode instead of default search?
Message-ID: <1254070015-sup-5151@kronos>
Content-Type: text/plain; charset=US-ASCII
Why does sup have a separate mode for viewing the inbox rather than simply
applying a default search (possibly configurable) and displaying the results
with search-results-mode? Like a number of other posters to the list, I wanted
to refine my inbox search. But the requisite key binding exists only in
search-results-mode and not in inbox-mode.
Using inbox as an ordinary label with search-results-mode instead of inbox-mode
offers several advantages over the separate inbox-mode: less code, less
separate modality, ability to refine the inbox search. It introduces the
possibility of closing the inbox window, readily addressed with a key binding
to perform the default search. What are the disadvantages? One loses the
difference in the archiving behavior between the two modes. The inbox label
would appear in the label editors. The program may need new code to handle a
new no-windows case. Perhaps efficiency considerations enter here.
Thanks, W.
------------------------------
Message: 1171
Date: Sun, 27 Sep 2009 10:46:00 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Why inbox-mode instead of default search?
Message-ID: <1254073440-sup-2700@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from William Erik Baxter's message of 2009-09-27:
> Why does sup have a separate mode for viewing the inbox rather than
> simply applying a default search (possibly configurable) and
> displaying the results with search-results-mode?
Because there are two special actions that are specific to inboxes:
archiving and killing.
> Like a number of other posters to the list, I wanted to refine my
> inbox search. But the requisite key binding exists only in
> search-results-mode and not in inbox-mode.
It would be easy enough to add a "|" command to inbox mode that would
spawn a search buffer with label:inbox and the rest of your search
terms.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1172
Date: Sun, 27 Sep 2009 14:50:08 -0400
From: William Erik Baxter <web-sup@superscript.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Why inbox-mode instead of default search?
Message-ID: <1254074517-sup-4465@kronos>
Content-Type: text/plain; charset=US-ASCII
Excerpts from William Morgan's message of Sun Sep 27 13:46:00 -0400 2009:
> Reformatted excerpts from William Erik Baxter's message of 2009-09-27:
> > Why does sup have a separate mode for viewing the inbox rather than
> > simply applying a default search (possibly configurable) and
> > displaying the results with search-results-mode?
>
> Because there are two special actions that are specific to inboxes:
> archiving and killing.
Both modes support archive and kill in some form. So I don't understand how
this argues for splitting as opposed to consolidating the two modes. The need
for preallocated, special-purpose labels like inbox and killed seems clear
enough. However, minimizing the amount of magical behavior they exhibit also
seems beneficial, if only for the sake of consistency. Treating the inbox as
something other than an ordinary label search is magical.
> It would be easy enough to add a "|" command to inbox mode that would
> spawn a search buffer with label:inbox and the rest of your search
> terms.
A patch to add this command to inbox-mode appears in the August sup-talk
archive. I would like to see this feature become part of the base system.
Cheers, W.
------------------------------
Message: 1173
Date: Mon, 28 Sep 2009 14:10:06 -0400
From: Ben Gamari <bgamari.foss@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash while scrolling
Message-ID: <1254160696-sup-3522@ben-laptop>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Sat Sep 26 10:31:56 -0400 2009:
> Sorry it's taken me so long to get back to this.
Quite alright. I know we're all busy.
>
> I definitely am not sure why there's a deadlock happening, but I am
> guessing, based on the line numbers in that first exception, that it's
> being triggered by an underlying problem with the source. If you run
> sup with -n, does that change anything? (Or produce a better exception?)
Well, things definitely failed a bit differently. I tried this a few
times and after seeing no real improvement, I moved on to your
suggestion below.
>
> > Anyways, this is the current status of things on my machine. William, do
> > you have any ideas what might cause such a backtrace. At this point
> > classes have started and I really have no more time to devote to
> > getting sup working. If there isn't a fairly simple solution here I guess
> > I'll just need to stick with mutt (ugh). Anyways, thanks for your work.
>
> Well, there's a workaround, which is to switch over to an offlineimap
> setup where your Gmail is mirrored locally and Sup reads the mirror
> (which is what you want anyways if you're serious about using Sup with
> an IMAP client). I don't know what's causing the deadlock, but I will
> try and reproduce it on my end.
This is definitely what I should have done from the beginning. Given
that sup seems to work fine after removing my imap sources, it seems
that that might be the source of the above deadlock. I think I'll just
stick with offlineimap for now.
This does raise one important question, however. It seems that
offlineimap will delete messages if they are found to have been deleted
in the remote respository. Is there any way that you know of to disable
this behavior, such that it will only drop new messages into the local
repository, thus making it somewhat compatible with sup's add-only
source requirement? It is awfully nice to be able to use GMail's web
interface when I'm away from my computer, but needing to re-sync sup
afterwards becomes quite tiresome.
This actually brings up a larger question. How difficult would it be to
relax sup's assumption that sources are add-only? This seems like a
horribly restriction to have in an email program. I understand that in
the case of sources such as imap where there is no globally unique
message identifier trying to track message changes could be quite
difficult, but for local sources (especially maildirs) it seems like
this should be quite possible.
Anyways, thanks a ton for your work. Now since I finally have sup up and
running reliably, it's been a joy to use. Leaps and bounds above my
former mutt-based system.
- Ben
------------------------------
Message: 1174
Date: Mon, 28 Sep 2009 15:57:38 -0700
From: Carl Worth <cworth@cworth.org>
To: Sup Talk <sup-talk@rubyforge.org>
Subject: [sup-talk] [PATCH] Add new :crypto_default configuration
option.
Message-ID: <1254178611-sup-369@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
For example, users that want to sign all outgoing messages by default
can set:
:crypto_default: :sign
in ~/.sup/config.yaml. Configuring an invalid value will cause a list
of the valid values to be logged at the "error" level.
---
lib/sup/horizontal-selector.rb | 8 +++++++-
lib/sup/modes/edit-message-mode.rb | 7 ++++++-
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/lib/sup/horizontal-selector.rb b/lib/sup/horizontal-selector.rb
index aef16d4..13c63ed 100644
--- a/lib/sup/horizontal-selector.rb
+++ b/lib/sup/horizontal-selector.rb
@@ -12,7 +12,13 @@ class HorizontalSelector
@selection = 0
end
- def set_to val; @selection = @vals.index(val) end
+ def set_to val
+ if @vals.index(val)
+ @selection = @vals.index(val)
+ else
+ error "Invalid option ", val.inspect, " (valid options: ", @vals.inspect, ")"
+ end
+ end
def val; @vals[@selection] end
diff --git a/lib/sup/modes/edit-message-mode.rb b/lib/sup/modes/edit-message-mode.rb
index 8da316f..3449503 100644
--- a/lib/sup/modes/edit-message-mode.rb
+++ b/lib/sup/modes/edit-message-mode.rb
@@ -89,7 +89,12 @@ EOS
if CryptoManager.have_crypto?
HorizontalSelector.new "Crypto:", [:none] + CryptoManager::OUTGOING_MESSAGE_OPERATIONS.keys, ["None"] + CryptoManager::OUTGOING_MESSAGE_OPERATIONS.values
end
- add_selector @crypto_selector if @crypto_selector
+ if @crypto_selector
+ if !$config[:crypto_default].nil?
+ @crypto_selector.set_to $config[:crypto_default]
+ end
+ add_selector @crypto_selector
+ end
HookManager.run "before-edit", :header => @header, :body => @body
--
1.6.4.3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090928/cc5a4c98/attachment-0001.bin>
------------------------------
Message: 1175
Date: Tue, 29 Sep 2009 20:43:09 +0200
From: Michael Stapelberg <michael+sup@stapelberg.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] [BUG] [PATCH] Encrypted messages without signature
generate an exception
Message-ID: <1254249719-sup-3652@midna.zekjur.net>
Content-Type: text/plain; charset="utf-8"
Hi,
when viewing (or replying to) an encrypted message without a signature,
sup throws an exception because of a nil chunk. I?ve attached a patch
which fixes the issue by instead providing a message stating that this
mail is not signed.
Best regards,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Bugfix-Display-a-notice-when-a-mail-is-not-signed.patch
Type: application/octet-stream
Size: 1212 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090929/1351e062/attachment-0001.obj>
------------------------------
Message: 1176
Date: Tue, 29 Sep 2009 20:14:58 +0200
From: Christian Dietrich <stettberger@dokucode.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode
Message-ID: <1254247706-sup-2745@peer.zerties.org>
Content-Type: text/plain; charset=UTF-8
Hey there,
i am using sup now for just a few weeks and it is just amazing how
good it works (the lack of folders iritated me a little bit at
first).
But now to my Request, i would like to have something like datelines
in index mode, like:
,-----------------
| -- Today
| 12:23 ...
| 23:42 ...
| -- Yesterday
| Yest. 9 ....
| Yest. 4....
| -- Last week
| .....
.---------------
I think this would cause an bigger overview over the mails,
especially in the inbox.
I tried to implement the feature by my self, but the mapping
beetween `curpos' and `@threads' in modes/thread-index-mode.rb made this
a little bit hard, and i didn't know how to solve this problem
without breaking sup. Perhaps you can give me a hint, how this
problem with the direct mapping can be solved.
greetz didi
--
No documentation is better than bad documentation
-- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt.
------------------------------
Message: 1177
Date: Wed, 30 Sep 2009 08:16:35 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Why inbox-mode instead of default search?
Message-ID: <1254323181-sup-1735@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from William Erik Baxter's message of 2009-09-27:
> Both modes support archive and kill in some form. So I don't
> understand how this argues for splitting as opposed to consolidating
> the two modes.
How does the notion of killing a thread that makes sense except in the
context of having an special inbox mode?
> The need for preallocated, special-purpose labels like
> inbox and killed seems clear enough. However, minimizing the amount
> of magical behavior they exhibit also seems beneficial, if only for
> the sake of consistency. Treating the inbox as something other than
> an ordinary label search is magical.
The inbox is magical, because you do different things with your inbox
than you do with non-inbox buffers: you classify threads into a) I'm
done with this thread for now, but let me know if someone replies
(archive); b) I'm done with this thread for now and don't let me know if
someone replies (kill); c) I'll deal with this later (ignore).
> A patch to add this command to inbox-mode appears in the August sup-talk
> archive. I would like to see this feature become part of the base system.
I agree.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1178
Date: Wed, 30 Sep 2009 09:12:35 -0700
From: Carl Worth <cworth@cworth.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Why inbox-mode instead of default search?
Message-ID: <1254326318-sup-904@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Wed Sep 30 08:16:35 -0700 2009:
> How does the notion of killing a thread that makes sense except in the
> context of having an special inbox mode?
The kill-thread notion can be handled in multiple ways without a
special inbox mode.
One way would be to simply not apply the inbox label to new messages
belonging to killed threads.
A better way would be to expand the search capability to something like:
Search for all threads containing messages matching <include-condition>
AND exclude all threads containing messages matching <exclude-condition>
I'd be happy to have that kind of functionality for arbitrary labels
that would function like killed for specific searches.
> The inbox is magical, because you do different things with your inbox
> than you do with non-inbox buffers: you classify threads into a) I'm
> done with this thread for now, but let me know if someone replies
> (archive); b) I'm done with this thread for now and don't let me know if
> someone replies (kill); c) I'll deal with this later (ignore).
It's definitely true that reading new mail is a different activity
than searching old mail, (note my recent patch that provides different
sort orders for these two operations).
But there are at least two problems with the current inbox mode
implemented separately from the search mode:
1. Some functionality appears in only one or the other of the modes.
Refine search is the easy-to-notice one that we've talked
about. But really, any keybindings performing distinct actions in
these two modes is just confusing. The two modes are far too
similar to have independent lists of possible actions and
bindings. This should be unified.
2. There are some things that are currently implemented as "magic" in
inbox mode that should really be made available to all searches.
Things like the archive operation making a message disappear from
the inbox. Instead, any operation making a message no longer
satisfy the current search should cause it to disappear from the
current view.
> > A patch to add this command to inbox-mode appears in the August sup-talk
> > archive. I would like to see this feature become part of the base system.
>
> I agree.
One shortcoming of that patch is that refined versions of the inbox
come up in search-results-mode, not inbox-mode. So you don't actually
get what you want yet, (such as archiving no longer works the same in
a refined inbox as it does in the raw inbox).
Or said another way, you would get exactly what you want if there was
nothing magic about inbox.
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090930/1641d2ef/attachment-0001.bin>
------------------------------
Message: 1179
Date: Wed, 30 Sep 2009 13:47:53 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Why inbox-mode instead of default search?
Message-ID: <1254331067-sup-9065@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from Carl Worth's message of Wed Sep 30 12:12:35 -0400 2009:
> Or said another way, you would get exactly what you want if there was
> nothing magic about inbox.
I've been working on a patch to do this. You can see the current state
at http://github.com/rlane/sup/tree/personal/. It's still buggy and
needs to be cleaned up a lot before I submit it. The basic idea is that
ThreadSet becomes tightly coupled to the Index and stays in sync with
it. This lets us use the index to determine whether a message is
relevant to a query, which was the main cause of magic previously. It
also makes ThreadIndexMode much simpler in general resulting in a net
code reduction.
------------------------------
Message: 1180
Date: Wed, 30 Sep 2009 11:04:52 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Why inbox-mode instead of default search?
Message-ID: <1254333819-sup-408@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Rich Lane's message of 2009-09-30:
> This lets us use the index to determine whether a message is relevant
> to a query, which was the main cause of magic previously. It also
> makes ThreadIndexMode much simpler in general resulting in a net code
> reduction.
Now you're talking my language. :)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1181
Date: Wed, 30 Sep 2009 11:17:55 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Feature Request: Collecting Lines in Index
Mode
Message-ID: <1254334371-sup-5145@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Christian Dietrich's message of 2009-09-29:
> i am using sup now for just a few weeks and it is just amazing how
> good it works (the lack of folders iritated me a little bit at
> first).
Welcome!
> But now to my Request, i would like to have something like datelines
> in index mode, like:
Cool idea. I'd like to see how this looks.
> I tried to implement the feature by my self, but the mapping beetween
> `curpos' and `@threads' in modes/thread-index-mode.rb made this a
> little bit hard, and i didn't know how to solve this problem without
> breaking sup. Perhaps you can give me a hint, how this problem with
> the direct mapping can be solved.
If you look at #regen_text, @text and @lines are the two variables that
control the display. @text is an array of the GUI elements for each line
of the display. Right now it's just set to one line for each thread. You
want to add one additional element at the appropriate position. for each
date line. GUI elements are represented as arrays of [color, text]
pairs; you can look at #text_for_thread_at for an example.
Then, you want to make sure that @lines is set correctly. @lines is a
map (hash) from line number to thread (so that when the user presses a
key, we know which thread the cursor is resting on).
Hope that helps.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1182
Date: Wed, 30 Sep 2009 11:21:46 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: Sup-talk mailing list <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup 0.9 pre-release checkin
Message-ID: <1254334862-sup-8690@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from William Morgan's message of 2009-09-26:
> If there's anything obviously missing, or obviously wrong with the
> state of git master, now's a good time to point it out!
I've just made a few more bugfix changes, so I'm giving this another day
of baking.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1183
Date: Wed, 30 Sep 2009 20:55:30 +0200
From: Michael Stapelberg <michael+sup@stapelberg.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup 0.9 pre-release checkin
Message-ID: <1254336855-sup-2395@midna.zekjur.net>
Content-Type: text/plain; charset=UTF-8
Hi William,
Excerpts from William Morgan's message of Mi Sep 30 20:21:46 +0200 2009:
> I've just made a few more bugfix changes, so I'm giving this another day
> of baking.
I am not sure if you have not noticed my patch, but in any case I would like
to see it in 0.9:
http://rubyforge.org/pipermail/sup-talk/2009-September/003189.html
It fixes a crash when opening PGP encrypted (but not signed) emails.
Best regards,
Michael
------------------------------
Message: 1184
Date: Wed, 30 Sep 2009 12:12:45 -0700
From: Carl Worth <cworth@cworth.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Why inbox-mode instead of default search?
Message-ID: <1254337861-sup-4368@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
Excerpts from Rich Lane's message of Wed Sep 30 10:47:53 -0700 2009:
> Excerpts from Carl Worth's message of Wed Sep 30 12:12:35 -0400 2009:
> > Or said another way, you would get exactly what you want if there was
> > nothing magic about inbox.
>
> I've been working on a patch to do this. You can see the current state
> at http://github.com/rlane/sup/tree/personal/. It's still buggy and
> needs to be cleaned up a lot before I submit it.
Very nice stuff, Rich!
It's great to see this coming along so far already.
Please let me know if there are specific bugs or issues you'd like
help fixing, and I'll be glad to try out where I can. Or even if there
are just specific things you'd like tested---I'm not too afraid of
running half-baked sup branches. :-)
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090930/c996cd28/attachment-0001.bin>
------------------------------
Message: 1185
Date: Wed, 30 Sep 2009 12:33:34 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup 0.9 pre-release checkin
Message-ID: <1254339174-sup-648@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Michael Stapelberg's message of 2009-09-30:
> http://rubyforge.org/pipermail/sup-talk/2009-September/003189.html
>
> It fixes a crash when opening PGP encrypted (but not signed) emails.
Can you please try the branch i-suck?
About five patches later, I've come in a full circle with this bit of
code.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1186
Date: Wed, 30 Sep 2009 12:40:32 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] xapian: do less work for
update_message_state
Message-ID: <1254339542-sup-886@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Rich Lane's message of 2009-09-13:
> Refactor index_message so that we do the minimal amount of work based
> on what state the user has modified.
Branch xapian-message-state, merged into next. Thanks!
BTW I'm excited about the direction this is going. State changes on
large numbers of messages seem significantly faster with this.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1187
Date: Wed, 30 Sep 2009 21:53:03 +0200
From: Michael Stapelberg <michael+sup@stapelberg.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup 0.9 pre-release checkin
Message-ID: <1254340355-sup-5292@midna.zekjur.net>
Content-Type: text/plain; charset=UTF-8
Hi William,
Excerpts from William Morgan's message of Mi Sep 30 21:33:34 +0200 2009:
> Can you please try the branch i-suck?
>
> About five patches later, I've come in a full circle with this bit of
> code.
Hehe. Yes, the version in this branch works.
Thanks for fixing it,
Best regards,
Michael
------------------------------
Message: 1188
Date: Wed, 30 Sep 2009 12:56:55 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Ignore killed messages in U screen
Message-ID: <1254339746-sup-79@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Edward Z. Yang's message of 2009-09-03:
> > What if you just delete messages in the the third condition?
>
> Then replies show up. :-)
I am still thinking about this, BTW. I think solution will either be:
treat deleted like killed for the purposes of inbox-mode (so a thread
with at least one deleted message will just never appear in inbox-mode),
or have a combined delete-and-kill command.
FWIW, I believe Gmail will pull a thread with a deleted message back
into the inbox if someone replies.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1189
Date: Wed, 30 Sep 2009 22:01:33 +0200
From: Michael Stapelberg <michael+sup@stapelberg.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] [PATCH] Save all attachments to a folder
Message-ID: <1254340829-sup-2273@midna.zekjur.net>
Content-Type: text/plain; charset="utf-8"
Hi,
I finally implemented saving all attachments of a message to a folder. Please
review and test this patch, I would be happy if we could merge it into
mainline.
Best regards,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Implement-saving-all-attachments-to-a-folder-keybind.patch
Type: application/octet-stream
Size: 2438 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090930/5873ce53/attachment-0001.obj>
------------------------------
Message: 1190
Date: Wed, 30 Sep 2009 16:05:28 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: Michael Stapelberg <michael+sup@stapelberg.de>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Save all attachments to a folder
Message-ID: <1254341104-sup-4958@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from Michael Stapelberg's message of Wed Sep 30 16:01:33 -0400 2009:
> I finally implemented saving all attachments of a message to a folder. Please
> review and test this patch, I would be happy if we could merge it into
> mainline.
+1 for this functionality. Haven't looked at the patch; I'll let
William do that. :-)
Cheers,
Edward
------------------------------
Message: 1191
Date: Wed, 30 Sep 2009 16:16:53 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] xapian: do less work for
update_message_state
Message-ID: <1254341186-sup-4357@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Wed Sep 30 15:40:32 -0400 2009:
> Reformatted excerpts from Rich Lane's message of 2009-09-13:
> > Refactor index_message so that we do the minimal amount of work based
> > on what state the user has modified.
>
> Branch xapian-message-state, merged into next. Thanks!
>
> BTW I'm excited about the direction this is going. State changes on
> large numbers of messages seem significantly faster with this.
They're about 3 times faster on my machine with this patch. An
optimization the Xapian devs have been planning to make (and that this
patch is necessary to take advantage of) should increase performance
much more.
------------------------------
Message: 1192
Date: Wed, 30 Sep 2009 22:43:13 +0200
From: Michael Stapelberg <michael+sup@stapelberg.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] [PATCH] When providing a wildcard as file for an
attachment, correctly expand it
Message-ID: <1254343324-sup-7275@midna.zekjur.net>
Content-Type: text/plain; charset="utf-8"
Hi,
the attached patch will expand wildcards given as filename when adding
attachments to a message. Thus, you can now add ~/work/foo/* at once.
As with the last patch, please review, test and merge.
Best regards,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-When-providing-a-wildcard-as-file-for-an-attachment-.patch
Type: application/octet-stream
Size: 1050 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090930/03cfa6ab/attachment-0001.obj>
------------------------------
Message: 1193
Date: Wed, 30 Sep 2009 16:54:21 -0400
From: Kevin Riggle <kevinr@free-dissociation.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Save all attachments to a folder
Message-ID: <1254343903-sup-2789@black-opal.mit.edu>
Content-Type: text/plain; charset=UTF-8
Excerpts from Michael Stapelberg's message of Wed Sep 30 16:01:33 -0400 2009:
> Hi,
>
> I finally implemented saving all attachments of a message to a folder. Please
> review and test this patch, I would be happy if we could merge it into
> mainline.
>
+1. And what do you know, I hadn't noticed the :default_attachment_save_dir:
config option and had set myself a to-do list item to implement that, so now I
don't have to, and thanks for drawing it to my attention!
- Kevin
--
Kevin Riggle (kevinr@free-dissociation.com)
http://free-dissociation.com
------------------------------
Message: 1194
Date: Wed, 30 Sep 2009 14:21:01 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash while scrolling
Message-ID: <1254345607-sup-2358@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Gamari's message of 2009-09-16:
> Well, after several attempts at rebuilding my index, I finally got
> lucky and sup-sync ran to completion. Unfortunately, sup now fails to
> even start, failing out with the following exception while loading
> threads for inbox-mode,
Hey, I just started seeing this too, Xapian only. I think I've fixed in
master.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1195
Date: Thu, 01 Oct 2009 00:08:39 +0200
From: Michael Stapelberg <michael+sup@stapelberg.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] [PATCH] more inline GPG madness
Message-ID: <1254348163-sup-6170@midna.zekjur.net>
Content-Type: text/plain; charset="utf-8"
Hi,
browsing some older emails, I noticed that the inline GPG patch I sent earlier
was not completely correct. It only handled messages which were encrypted *and*
signed, but not messages which were signed only.
Attached comes a patch which fixes the behaviour. However (!) the patch is not
well aligned, the error case (else) is untested and should probably be handled
differently and the old_charset line can probably be written more elegantly in
ruby. By the way, the charset stuff is necessary to get the correct character
set for messages which are sent inline. I really start to dislike Thunderbird
and other crappy software for that :-\.
So, please, clean up the patch and merge it. I have also attached a message
which was sent using thunderbird and contains inline crypto. If the patch works
correctly, you should be able to open it and see some umlauts.
Best regards,
Michael
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: sign.txt
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091001/f9f6851c/attachment-0001.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inline-gpg.patch
Type: application/octet-stream
Size: 1394 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091001/f9f6851c/attachment-0001.obj>
------------------------------
Message: 1196
Date: Thu, 01 Oct 2009 01:30:54 +0200
From: Christopher Bertels <mailinglist@flasht.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] i18n?
Message-ID: <1254353101-sup-1021@thinkpad-ubuntu>
Content-Type: text/plain; charset="utf-8"
Hi,
are there any plans on doing some internationalization? If not, would
people like to have something like this, now that I have mentioned it? ;)
I guess something yaml-based could work, there are some good libraries
out there afaik.
Why this came to my mind: I usually write mails in german and english
and have done a custom patch to check for the german word for
"attachment" to warn me before sending an email, if I haven't yet
added an attachment to a composed mail. This obviously works for
english right now, but I wanted to have a similar feature in german.
Since adding language specific options all over the code really isn't
the right way, maybe having some kind of language packs would be
nice. I could take care of some german translation (and I suppose I'm
not the only one on this list ;))
Cheers,
Christopher.
--
================================
Christopher Bertels
http://www.adztec-independent.de
GPG Key ID: 0x2345b203
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 902 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091001/d6569555/attachment-0001.bin>
------------------------------
Message: 1197
Date: Thu, 01 Oct 2009 09:36:00 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Ignore killed messages in U screen
Message-ID: <1254382434-sup-4435@peray>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Wed Sep 30 21:56:55 +0200 2009:
> Reformatted excerpts from Edward Z. Yang's message of 2009-09-03:
> > > What if you just delete messages in the the third condition?
> >
> > Then replies show up. :-)
>
> I am still thinking about this, BTW. I think solution will either be:
> treat deleted like killed for the purposes of inbox-mode (so a thread
> with at least one deleted message will just never appear in inbox-mode),
> or have a combined delete-and-kill command.
>
> FWIW, I believe Gmail will pull a thread with a deleted message back
> into the inbox if someone replies.
Yes I think so (and merely hope so).
Notice that while GMail do not have the kill thread feature, Google Wave does
have a "mute this thread" button, that will cause these threads to no longer
appear in the inbox, however you can still search for is:mute threads.
--
Nicolas Pouillard
http://nicolaspouillard.fr
------------------------------
Message: 1198
Date: Thu, 01 Oct 2009 06:34:50 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Ignore killed messages in U screen
Message-ID: <1254404057-sup-2374@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Nicolas Pouillard's message of 2009-10-01:
> Notice that while GMail do not have the kill thread feature
I think it does (but it didn't always). They also call it "mute".
http://mail.google.com/support/bin/answer.py?hl=en&answer=47787
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1199
Date: Thu, 01 Oct 2009 06:43:48 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash while scrolling
Message-ID: <1254404181-sup-8448@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Gamari's message of 2009-09-28:
> This does raise one important question, however. It seems that
> offlineimap will delete messages if they are found to have been
> deleted in the remote respository. Is there any way that you know of
> to disable this behavior, such that it will only drop new messages
> into the local repository, thus making it somewhat compatible with
> sup's add-only source requirement?
Maybe someone who uses offlineimap can comment on this. In the worst
case, I'm sure the patch wouldn't be too hard.
> This actually brings up a larger question. How difficult would it be
> to relax sup's assumption that sources are add-only?
It's not difficult per se, it just requires scanning over the entire
source, which is slow. Removing this assumption would be tantamount to
running sup-sync -c every time you start up sup.
Here's the idea: scanning over a mailstore is slow. Much of this
slowness is due to Ruby. So let's rewrite this code in C. Then we would
have something as fast as, say, Mutt. But Mutt bogs down on my mbox file
because it's too big. So my *only* reasonable choice with a large
mailstore is Sup and the assumption that the source is add only.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1200
Date: Thu, 01 Oct 2009 06:46:20 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] xapian: do less work for
update_message_state
Message-ID: <1254404707-sup-9253@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Rich Lane's message of 2009-09-30:
> They're about 3 times faster on my machine with this patch. An
> optimization the Xapian devs have been planning to make (and that this
> patch is necessary to take advantage of) should increase performance
> much more.
Awesome. Out of curiousity, what's the optimization?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1201
Date: Thu, 01 Oct 2009 06:49:54 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Bug: Converting the index to xapian fails with
a message with very old date
Message-ID: <1254404956-sup-6574@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Michael Stapelberg's message of 2009-09-26:
> truncated date is Thu Jan 01 01:00:00 +0100 1970
> date_value is "\200"
> /usr/lib/ruby/1.8/sup/xapian_index.rb:536:in `_dump': year too big to marshal
> (ArgumentError)
> from /usr/lib/ruby/1.8/sup/xapian_index.rb:536:in `dump'
> from /usr/lib/ruby/1.8/sup/xapian_index.rb:536:in `index_message'
> from /usr/lib/ruby/1.8/sup/xapian_index.rb:124:in `sync_message'
At this point I'm hoping that Rich will chime in. :)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1202
Date: Thu, 1 Oct 2009 16:07:01 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Ignore killed messages in U screen
Message-ID:
<cd67f63a0910010707q620016bwb899095fb6a50765@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Thu, Oct 1, 2009 at 3:34 PM, William Morgan <wmorgan-sup@masanjin.net> wrote:
> Reformatted excerpts from Nicolas Pouillard's message of 2009-10-01:
>> Notice that while GMail do not have the kill thread feature
>
> I think it does (but it didn't always). They also call it "mute".
> http://mail.google.com/support/bin/answer.py?hl=en&answer=47787
The name and semantics seems just great.
--
Nicolas Pouillard
http://nicolaspouillard.fr
------------------------------
Message: 1203
Date: Thu, 01 Oct 2009 17:47:17 +0200
From: Gregor Hoffleit <gregor@hoffleit.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Bug: store_message writes invalid From lines with
locales set
Message-ID: <1254411555-sup-7650@sam>
Content-Type: text/plain; charset=UTF-8
Obviously store_message uses the current locale settings to dump the
date into the From line (loader.rb, line 179):
f.puts "From #{from_email} #{date.utc}"
The result: Using LANG=de_DE, sup crashed on me today when I had sent my
first mail of October. Problem was that sup failed to grok the localized
abbreviated month name ("Okt") in the From line:
From gregor@hoffleit.de Do Okt 01 14:39:43 UTC 2009
which in turn was written by loader.rb (eat your own food, you know).
Everything worked fine for me in August and September, since those month
names are spelled the same in German and English ;-).
Regards,
Gregor Hoffleit
------------------------------
Message: 1204
Date: Thu, 01 Oct 2009 09:38:36 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Bug: store_message writes invalid From lines
with locales set
Message-ID: <1254414095-sup-8087@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Gregor Hoffleit's message of 2009-10-01:
> f.puts "From #{from_email} #{date.utc}"
Whoops. That should be date.rfc2822. I've fixed in git and this will go
out in 0.9.
> Everything worked fine for me in August and September, since those
> month names are spelled the same in German and English ;-).
You expect your email client to work for more than two months a year?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1205
Date: Thu, 01 Oct 2009 09:44:43 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] i18n?
Message-ID: <1254415145-sup-635@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Christopher Bertels's message of 2009-09-30:
> are there any plans on doing some internationalization? If not, would
> people like to have something like this, now that I have mentioned it?
I have no immediate plans personally, but I would love to have this in
Sup.
> I guess something yaml-based could work, there are some good libraries
> out there afaik.
There is a Ruby-Gettext package, which we already use for other reasons.
I think this is probably the best thing to start with, unless it turns
out to be too hard to use, in which case we could consider a custom
solution.
http://www.yotabanana.com/hiki/ruby-gettext.html
> I could take care of some german translation (and I suppose I'm not
> the only one on this list ;))
I know we have a fair amount of German and French representation on the
list, and that's probably representative of the user population in
general. So you should have an appreciative audience.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1206
Date: Thu, 01 Oct 2009 09:53:15 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Handle added messages in
label-list-mode
Message-ID: <1254415913-sup-6275@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Bo Borgerson's message of 2009-09-12:
> Register label-list-mode with the UpdateManager and handle added
> updates with a reload to keep unread message counts up to date
Branch label-list-mode-auto-update, merged into next. I'm a little
concerned with performance, but we'll see how it goes.
What do you think about handling labeled and deleted updates as well?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1207
Date: Thu, 01 Oct 2009 09:54:48 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Add command for polling unusual
sources
Message-ID: <1254416074-sup-7585@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Bo Borgerson's message of 2009-09-13:
> bin/sup: Add new global key binding, '{', to poll unusual sources
> (requires confirmation). This allows update of unusual sources
> without having to leave sup to run a sync.
Branch poll-unusual, merged into next. Thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1208
Date: Thu, 01 Oct 2009 09:58:16 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Add hooks to sort and format
label-list-mode display.
Message-ID: <1254416245-sup-4497@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Hi William,
Sorry for the delay. I like this patch but I can't get it to apply
cleanly to master. git am -3 complains:
Did you hand edit your patch?
It does not apply to blobs recorded in its index.
Cannot fall back to three-way merge.
Patch failed at 0001.
If you can resubmit against a recent master, I will apply it. Thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1209
Date: Thu, 01 Oct 2009 13:02:18 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] xapian: do less work for
update_message_state
Message-ID: <1254416360-sup-8957@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Thu Oct 01 09:46:20 -0400 2009:
> Reformatted excerpts from Rich Lane's message of 2009-09-30:
> > They're about 3 times faster on my machine with this patch. An
> > optimization the Xapian devs have been planning to make (and that this
> > patch is necessary to take advantage of) should increase performance
> > much more.
>
> Awesome. Out of curiousity, what's the optimization?
replace_document currently deletes all the old postings and inserts new
ones. It can be optimized to make the minimal set of modifications.
------------------------------
Message: 1210
Date: Thu, 01 Oct 2009 10:04:52 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Allow thread index view to sort oldest
first
Message-ID: <1254416597-sup-8156@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Hi Carl,
I am interested in trying these changes but I think these patches were
generated against a custom version of master (e.g. I see the inbox
refine-search command in the context, which hasn't been published yet).
Can you rebase them onto a recent non-modified master so that I can
apply? Thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1211
Date: Thu, 01 Oct 2009 10:07:20 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Add new :crypto_default configuration
option.
Message-ID: <1254416783-sup-5518@masanjin.net>
Content-Type: text/plain; charset=UTF-8
I like the idea, but how about a hook instead? I think the reply-mode
hook is exactly equivalent to this. (Which maybe I will one day rename
to default-reply-mode.)
I have a strong aversion to adding configuration options.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1212
Date: Thu, 01 Oct 2009 10:10:12 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] When providing a wildcard as file for
an attachment, correctly expand it
Message-ID: <1254416978-sup-2395@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Michael Stapelberg's message of 2009-09-30:
> the attached patch will expand wildcards given as filename when adding
> attachments to a message. Thus, you can now add ~/work/foo/* at once.
Branch attach-wildcards, merged into next. Thanks! This is awesome.
> As with the last patch, please review, test and merge.
I changed one minor thing: Dir["#{fn}"] -> Dir[fn]. :)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1213
Date: Thu, 01 Oct 2009 10:13:47 -0700
From: Carl Worth <cworth@cworth.org>
To: Nicolas Pouillard <nicolas.pouillard@gmail.com>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Ignore killed messages in U screen
Message-ID: <1254417174-sup-3659@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
Excerpts from Nicolas Pouillard's message of Thu Oct 01 07:07:01 -0700 2009:
> On Thu, Oct 1, 2009 at 3:34 PM, William Morgan <wmorgan-sup@masanjin.net> wrote:
> > Reformatted excerpts from Nicolas Pouillard's message of 2009-10-01:
> >> Notice that while GMail do not have the kill thread feature
> >
> > I think it does (but it didn't always). They also call it "mute".
> > http://mail.google.com/support/bin/answer.py?hl=en&answer=47787
>
> The name and semantics seems just great.
It seems a simple, little thing. But I'm all in favor of non-violent
metaphors in the interfaces of programs I use.
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091001/d6d54b07/attachment-0001.bin>
------------------------------
Message: 1214
Date: Thu, 01 Oct 2009 19:27:40 +0200
From: Michael Stapelberg <michael+sup@stapelberg.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] more inline GPG madness
Message-ID: <1254417896-sup-2359@midna.zekjur.net>
Content-Type: text/plain; charset=UTF-8
Hi,
Excerpts from Michael Stapelberg's message of Do Okt 01 00:08:39 +0200 2009:
> Attached comes a patch which fixes the behaviour. However (!) the patch is not
> well aligned, the error case (else) is untested and should probably be handled
> differently and the old_charset line can probably be written more elegantly in
> ruby. By the way, the charset stuff is necessary to get the correct character
> set for messages which are sent inline. I really start to dislike Thunderbird
> and other crappy software for that :-\.
I am sorry for the confusion. Please do not merge this patch without close
review if these PGP headers are valid at all. Turns out the headers were
produced by a custom procmail rule I had forgotton about.
I will instead implement support for "correct" inline GPG.
Best regards,
Michael
------------------------------
Message: 1215
Date: Thu, 01 Oct 2009 10:31:00 -0700
From: Carl Worth <cworth@cworth.org>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Add new :crypto_default configuration
option.
Message-ID: <1254417826-sup-6584@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Thu Oct 01 10:07:20 -0700 2009:
> I like the idea, but how about a hook instead? I think the reply-mode
> hook is exactly equivalent to this. (Which maybe I will one day rename
> to default-reply-mode.)
>
> I have a strong aversion to adding configuration options.
I'm intrigued.
What makes a hook preferable over a configuration option?
I've been getting concerned watching the number of hooks in sup grow
as each creates a maintenance burden. Either:
1. All hooks are supported forever with consistent
arguments/semantics, (which may make it more difficult to make
changes in sup than it would be otherwise)
OR:
2. Hooks are not supported forever, in which case users may find that
things just start working when upgrading.
Neither of those seem options look nice to me, and both seem easy to
avoid with configuration options.
If the plan is to go with (1) I'm concerned that I don't see sup
shipping documentation for the current possible hooks. (This applies
to configuration options too though. I think the maintainer should
reject patches that add either without also adding documentation to
the standard list.[*])
[*] Assuming the pre-condition of such documentation existing of
course.
On the other hand, I also dislike configuration options (and hooks,
equally), to the extent that they might be used as an excuse to avoid
putting the most sane and useful default functionality into sup
itself. Obviously, this can be complicated by some people not agreeing
on what the most sane and useful behavior is.
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091001/55fc7ab2/attachment-0001.bin>
------------------------------
Message: 1216
Date: Thu, 01 Oct 2009 13:33:52 -0400
From: William Erik Baxter <web-sup@superscript.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Add hooks to sort and format
label-list-mode display.
Message-ID: <1254418284-sup-3486@kronos>
Content-Type: text/plain; charset="us-ascii"
Another patch against a fresh pull of master is attached.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-hooks-for-label-list-filter-and-format.patch
Type: application/octet-stream
Size: 2759 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091001/e5024e1a/attachment-0001.obj>
------------------------------
Message: 1217
Date: Thu, 01 Oct 2009 10:37:06 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Save all attachments to a folder
Message-ID: <1254418612-sup-4759@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Michael Stapelberg's message of 2009-09-30:
> I finally implemented saving all attachments of a message to a folder.
> Please review and test this patch, I would be happy if we could merge
> it into mainline.
Branch save-all-attachments, merged into next.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1218
Date: Thu, 01 Oct 2009 13:38:27 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Bugfix for custom-search
Message-ID: <1254418685-sup-6611@javelin>
Content-Type: text/plain; charset=UTF-8
I think there's a slight bug in the custom-search implementation.
Patch is here:
>From cea17180933469570e9502ffa7bf67ccaa8ccfc7 Mon Sep 17 00:00:00 2001
From: Edward Z. Yang <edwardzyang@thewritingpot.com>
Date: Wed, 10 Jun 2009 01:42:50 -0400
Subject: [PATCH] Fix bug in which custom-search substitutions are not used.
Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
---
lib/sup/ferret_index.rb | 2 +-
lib/sup/xapian_index.rb | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/sup/ferret_index.rb b/lib/sup/ferret_index.rb
index d605e8d..34dff87 100644
--- a/lib/sup/ferret_index.rb
+++ b/lib/sup/ferret_index.rb
@@ -340,7 +340,7 @@ EOS
query = {}
subs = HookManager.run("custom-search", :subs => s) || s
- subs = s.gsub(/\b(to|from):(\S+)\b/) do
+ subs = subs.gsub(/\b(to|from):(\S+)\b/) do
field, name = $1, $2
if(p = ContactManager.contact_for(name))
[field, p.email]
diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
index ab25ea0..e1cfe65 100644
--- a/lib/sup/xapian_index.rb
+++ b/lib/sup/xapian_index.rb
@@ -193,7 +193,7 @@ EOS
query = {}
subs = HookManager.run("custom-search", :subs => s) || s
- subs = s.gsub(/\b(to|from):(\S+)\b/) do
+ subs = subs.gsub(/\b(to|from):(\S+)\b/) do
field, name = $1, $2
if(p = ContactManager.contact_for(name))
[field, p.email]
--
1.6.4.4
------------------------------
Message: 1219
Date: Thu, 01 Oct 2009 10:43:25 -0700
From: Carl Worth <cworth@cworth.org>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>, Keith Packard
<keithp@keithp.com>
Subject: Re: [sup-talk] [PATCH] Allow thread index view to sort oldest
first
Message-ID: <1254418822-sup-7654@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Thu Oct 01 10:04:52 -0700 2009:
> I am interested in trying these changes but I think these patches were
> generated against a custom version of master (e.g. I see the inbox
> refine-search command in the context, which hasn't been published yet).
Guilty as charged.
> Can you rebase them onto a recent non-modified master so that I can
> apply? Thanks!
See the attached patches.
And as before, the behavior is split into two commits so that you can
decide whether to change the default or not.
And there's still the one minor bug that the oldest-first mode doesn't
actually guarantee that the oldest message is displayed first when
newer messages arrive for an old thread.
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Allow-thread-index-view-to-sort-oldest-first.patch
Type: application/octet-stream
Size: 7502 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091001/ec87d014/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Change-the-default-sort-for-inbox-mode-to-be-oldest-.patch
Type: application/octet-stream
Size: 777 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091001/ec87d014/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091001/ec87d014/attachment-0001.bin>
------------------------------
Message: 1220
Date: Thu, 01 Oct 2009 13:44:19 -0400
From: Ben Gamari <bgamari.foss@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash while scrolling
Message-ID: <1254418089-sup-5800@ben-laptop>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Thu Oct 01 09:43:48 -0400 2009:
> Reformatted excerpts from Ben Gamari's message of 2009-09-28:
> > This actually brings up a larger question. How difficult would it be
> > to relax sup's assumption that sources are add-only?
>
> It's not difficult per se, it just requires scanning over the entire
> source, which is slow. Removing this assumption would be tantamount to
> running sup-sync -c every time you start up sup.
>
> Here's the idea: scanning over a mailstore is slow. Much of this
> slowness is due to Ruby. So let's rewrite this code in C. Then we would
> have something as fast as, say, Mutt. But Mutt bogs down on my mbox file
> because it's too big. So my *only* reasonable choice with a large
> mailstore is Sup and the assumption that the source is add only.
It seems that C would definitely be a good start (or perhaps C++ would
be a better idea as that is the language in which Xapian is written).
However, I think one of the real issues is the exclusive nature of index
access. In fact, this is one of my primary gripes with the sup
workflow. After processing a large number of messages, the write-out
time can be quite substantial upon killing the buffer. This can be a
noticeable interruption to workflow. It seems to me that index access
should be asynchronous at least.
If this were the case, then we could get support for mutable sources for
free, as we could synchronize against sources without interrupting
workflow (although keeping the view in sync with the backend would be a
bit tricky).
As an aside, it would be quite nice if one could run multiple
simultaneous instances of sup. It seems that if one only held write access
to the index during writes (is this the case presently?), there should
be nothing preventing this from being possible.
Correct me if I'm wrong in any part of my above assessment. Hope things
are going well,
- Ben
------------------------------
Message: 1221
Date: Thu, 01 Oct 2009 13:56:12 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Configurable poll time
Message-ID: <1254419578-sup-5569@javelin>
Content-Type: text/plain; charset=UTF-8
Hey all,
I know William is generally opposed to configuration values, but
I think I've found one that would be good to do: DELAY in poll.rb.
I specifically have had to reduce this value in order to prevent
a naughty IMAP server from silently dropping the connection (and
causing sup to consequently hang).
I'll cook up a patch if people are receptive.
Cheers,
Edward
------------------------------
Message: 1222
Date: Thu, 01 Oct 2009 20:15:50 +0200
From: Christopher Bertels <mailinglist@flasht.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] i18n?
Message-ID: <1254420802-sup-3742@thinkpad-ubuntu>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Do Okt 01 18:44:43 +0200 2009:
> I have no immediate plans personally, but I would love to have this in
> Sup.
Alright, good to know.
> There is a Ruby-Gettext package, which we already use for other reasons.
> I think this is probably the best thing to start with, unless it turns
> out to be too hard to use, in which case we could consider a custom
> solution.
>
> http://www.yotabanana.com/hiki/ruby-gettext.html
Cool, I'll have a look at it.
Another reason for adding this would be that for example gpg's output
is different for me (in german) than what sup expects. So trust-paths
for example aren't recognized by default, since the regular expression
in crypto.rb only looks for english output. I fixed this for myself
but I figured it would make more sense to put this kind of stuff to a
central location.
--
================================
Christopher Bertels
http://www.adztec-independent.de
GPG Key ID: 0x2345b203
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091001/cf2f42a4/attachment-0001.bin>
------------------------------
Message: 1223
Date: Thu, 01 Oct 2009 20:21:48 +0200
From: Christopher Bertels <mailinglist@flasht.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] i18n?
Message-ID: <1254421306-sup-8840@thinkpad-ubuntu>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Do Okt 01 18:44:43 +0200 2009:
> I have no immediate plans personally, but I would love to have this in
> Sup.
Ok, great!
> There is a Ruby-Gettext package, which we already use for other reasons.
> I think this is probably the best thing to start with, unless it turns
> out to be too hard to use, in which case we could consider a custom
> solution.
>
> http://www.yotabanana.com/hiki/ruby-gettext.html
Thanks, I'll have a look at it.
Btw, another reason for adding something like this would be that sup
depends on an english version of gpg. For checking a trust-path, for
example, it uses a regular expression that checks for a certain output
of gpg (in english). Since I have a german version, this obviously
doesn't work (I had to patch it for my needs). I guess there probably
are more things where different languages could play a role, so
putting it in a central, well-defined location makes sense.
--
================================
Christopher Bertels
http://www.adztec-independent.de
GPG Key ID: 0x2345b203
------------------------------
Message: 1224
Date: Thu, 01 Oct 2009 11:22:44 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Configurable poll time
Message-ID: <1254421340-sup-4697@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Edward Z. Yang's message of 2009-10-01:
> I know William is generally opposed to configuration values, but I
> think I've found one that would be good to do: DELAY in poll.rb. I
> specifically have had to reduce this value in order to prevent a
> naughty IMAP server from silently dropping the connection (and causing
> sup to consequently hang).
I'd be fine with this one, especially if it were a per-source
configuration that lived in sources.yaml.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1225
Date: Thu, 01 Oct 2009 11:24:57 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] i18n?
Message-ID: <1254421405-sup-8083@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Christopher Bertels's message of 2009-10-01:
> Another reason for adding this would be that for example gpg's output
> is different for me (in german) than what sup expects. So trust-paths
> for example aren't recognized by default, since the regular expression
> in crypto.rb only looks for english output.
It will be interesting to see how gettext handles the case of regular
expressions (which is also probably what you want for the "attachment"
detector). If it's not natural to wedge regexen into gettext, we should
consider a custom solution.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1226
Date: Thu, 01 Oct 2009 11:31:20 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash while scrolling
Message-ID: <1254421545-sup-8303@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Gamari's message of 2009-10-01:
> It seems that C would definitely be a good start (or perhaps C++ would
> be a better idea as that is the language in which Xapian is written).
I was proposing that as a strawman argument. C does not solve my
problem.
> However, I think one of the real issues is the exclusive nature of
> index access. In fact, this is one of my primary gripes with the sup
> workflow. After processing a large number of messages, the write-out
> time can be quite substantial upon killing the buffer.
It is possible to address this in a variety of ways, many of which have
been discussed over the years, but yes, I agree that a delay is
nonideal.
> If this were the case, then we could get support for mutable sources
> for free, as we could synchronize against sources without interrupting
> workflow (although keeping the view in sync with the backend would be
> a bit tricky).
Making message state saving fast, or backgrounded, is a different beast
from scanning over a mailstore.
I have been working on a Sup server for quite some time that would
address many of these problems, but progress is slow.
> As an aside, it would be quite nice if one could run multiple
> simultaneous instances of sup. It seems that if one only held write
> access to the index during writes (is this the case presently?), there
> should be nothing preventing this from being possible.
It might be possible to do this with Xapian, especially if there were no
expectation of updates being transmitted across processes. With Ferret,
if it is possible, it's only with a tremendous amount of effort.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1227
Date: Thu, 01 Oct 2009 20:33:03 +0200
From: Christopher Bertels <mailinglist@flasht.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] i18n?
Message-ID: <1254421963-sup-7532@thinkpad-ubuntu>
Content-Type: text/plain; charset="utf-8"
Please excuse my double posting. Sup crashed after sending a message.
I have the exception log attached.
Seems like it has a problem with the sent.mbox and wants me to
sup-sync --changed sup://sent
I switched from ferret to xapian today and the error clearly happens there.
--
================================
Christopher Bertels
http://www.adztec-independent.de
GPG Key ID: 0x2345b203
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: exception-log.txt
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091001/8366e0e9/attachment-0001.txt>
------------------------------
Message: 1228
Date: Thu, 01 Oct 2009 11:41:59 -0700
From: Carl Worth <cworth@cworth.org>
To: Ben Gamari <bgamari.foss@gmail.com>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Writing time-sensitive portions of sup in C
Message-ID: <1254421959-sup-9506@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
Excerpts from Ben Gamari's message of Thu Oct 01 10:44:19 -0700 2009:
> Excerpts from William Morgan's message of Thu Oct 01 09:43:48 -0400 2009:
> > Here's the idea: scanning over a mailstore is slow. Much of this
> > slowness is due to Ruby. So let's rewrite this code in C. Then we would
> > have something as fast as, say, Mutt. But Mutt bogs down on my mbox file
> > because it's too big. So my *only* reasonable choice with a large
> > mailstore is Sup and the assumption that the source is add only.
>
> It seems that C would definitely be a good start (or perhaps C++ would
> be a better idea as that is the language in which Xapian is written).
I've started some experiments along these lines, (basically just
writing C code (with C++ where necessary) using the Xapian tutorial
and little peeks into sup/xapian-index.rb to get the right prefix
values, etc.).
> However, I think one of the real issues is the exclusive nature of index
> access. In fact, this is one of my primary gripes with the sup
> workflow. After processing a large number of messages, the write-out
> time can be quite substantial upon killing the buffer. This can be a
> noticeable interruption to workflow. It seems to me that index access
> should be asynchronous at least.
What I'm hoping to end up with is a C library that provides
asynchronous access to a sup-compatible index. I'll keep you posted if
I make any actual progress on this front.
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091001/89e0a628/attachment-0001.bin>
------------------------------
Message: 1229
Date: Thu, 01 Oct 2009 11:43:49 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk mailing list <sup-talk@rubyforge.org>, sup-announce
mailing list <sup-announce@rubyforge.org>
Subject: [sup-talk] [ANN] Sup 0.9 released
Message-ID: <1254422532-sup-9948@masanjin.net>
Content-Type: text/plain; charset=UTF-8
I'm pleased to announce the release of Sup 0.9.
Sup is a console-based email client for people with a lot of email.
It supports tagging, very fast full-text search, automatic contact-
list management, and more. If you're the type of person who treats
email as an extension of your long-term memory, Sup is for you.
Get it: gem install sup
Learn it: http://sup.rubyforge.org
Love it: sup-talk@rubyforge.org
Excitement in 0.9:
* Experimental Xapian backend to replace Ferret. Not everything works with it,
but it's fast and less likely to barf. See release notes.
* New keybinding: "G" for reply-all.
* New hook: custom-search, for adding your own query expansions.
* Better preemptive thread loading.
* Random UI tweaks: display labels before subjects, change thread-view-mode's
'n' and 'p' commands slightly
* Better killing of other Sup processes.
* Die gracefully upon SIGKILL.
* Finally figure out the curses+ruby magic to make SIGWINCH (i.e. xterm
resizing) work correctly.
* Add a console mode (press ~) for interactively playing with the index.
* Finally figure out the curses magic to stop the weird keyboard behavior after
leaving the editor.
* Improved logging. Logging now supports SUP_LOG_LEVEL environment variable.
Set this to "debug" for verbiage.
* As always, many bugfixes and tweaks.
Release notes:
There's a new Xapian backend as an alternative to the Ferret one. It's still in
a beta stage. It's much faster and much less prone to the random crashes than
Ferret, but certain things don't work yet, most noticeably the unread message
counts in label-list-mode.
You can switch back and forth between both indexes without harm, *except* any
new messages added to the one index won't be picked up by the other. Follow
these instructions:
To TRY the Xapian index, without screwing Ferret up:
1. sup-dump > dump # takes a while
2. export SUP_INDEX=xapian # or however you do it in your shell
3. sup-sync --all --all-sources --restore dump # takes a long time
4. sup -n # -n ensures that no polling is done. don't hit 'P' either
Step 1 will take a long time, and step 3 will take a very long time.
At this point, whenever you run Sup, the SUP_INDEX environment variable will
determine which index you use. If it's unset, or "ferret", you will use the
ferret index. If it's "xapian", the Xapian index. Make sure when you run sup
with the Xapian index, you use -n and don't hit 'P', to avoid loading new
messages into it.
If you want to switch to Xapian permanently, you can then:
1. rm -rf ~/.sup/ferret
2. permanently set SUP_INDEX=xapian according to your shell
3. Run sup as normal, i.e. without -n.
If you want to go back to Ferret, you can just rm -rf ~/.sup/xapian and make
sure your SUP_INDEX environment variable is unset.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1230
Date: Thu, 01 Oct 2009 14:47:44 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: Christopher Bertels <mailinglist@flasht.de>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] i18n?
Message-ID: <1254422768-sup-4646@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from Christopher Bertels's message of Thu Oct 01 14:33:03 -0400 2009:
> undefined method `[]' for nil:NilClass
> /home/bakkdoor/projekte/ruby/sup/lib/sup/xapian_index.rb:558:in `mkterm'
What commit is your tree at?
------------------------------
Message: 1231
Date: Thu, 01 Oct 2009 14:45:20 -0400
From: Ben Gamari <bgamari.foss@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Crash while loading thread index buffer
Message-ID: <1254422128-sup-970@ben-laptop>
Content-Type: text/plain; charset=UTF-8
I just had this[1] crash while loading a buffer with has:lkml.
Crash occurs in,
@threads = @ts.threads.select { |t| !@hidden_threads[t] }.sort_by { |t| [t.date, t.first.id] }.reverse
Is this perhaps the result of an index inconsistency? It seems to me
that t.first should never be nil. Seems like sup is very susceptible to
these nils slipping in unexpectedly. Is there perhaps a better way to
deal with it other than crashing the client? Seems like a pretty extreme
measure (although granted, it's a pretty serious issue as well)
- Ben
[1] Exception log
--- RuntimeError from thread: load threads for thread-index-mode
wrong id called on nil
/opt/exp/sup/lib/sup.rb:17:in `id'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `update'
/opt/exp/sup/lib/sup/hook.rb:121:in `sort_by'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `each'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `sort_by'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `update'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:223:in `synchronize'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:223:in `update'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:637:in `__unprotected_load_n_threads'
(eval):12:in `load_n_threads'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:609:in `load_n_threads_background'
/opt/exp/sup/lib/sup.rb:77:in `reporting_thread'
/opt/exp/sup/lib/sup.rb:75:in `initialize'
/opt/exp/sup/lib/sup.rb:75:in `new'
/opt/exp/sup/lib/sup.rb:75:in `reporting_thread'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads'
(eval):12:in `load_threads'
/opt/exp/sup/lib/sup/modes/label-search-results-mode.rb:33:in `spawn_nicely'
/opt/exp/sup/lib/sup/modes/label-list-mode.rb:93:in `select_label'
/opt/exp/sup/lib/sup/mode.rb:51:in `send'
/opt/exp/sup/lib/sup/mode.rb:51:in `handle_input'
/opt/exp/sup/lib/sup/buffer.rb:267:in `handle_input'
/usr/bin/sup:238
------------------------------
Message: 1232
Date: Thu, 01 Oct 2009 15:01:35 -0400
From: Ben Gamari <bgamari.foss@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash while scrolling
Message-ID: <1254422805-sup-9288@ben-laptop>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Thu Oct 01 14:31:20 -0400 2009:
> Reformatted excerpts from Ben Gamari's message of 2009-10-01:
> > It seems that C would definitely be a good start (or perhaps C++ would
> > be a better idea as that is the language in which Xapian is written).
>
> I was proposing that as a strawman argument. C does not solve my
> problem.
Certainly, you will never be able to write a message indexer fast enough
to index a source instantly. That is why we have an index to begin with.
That being said, I think we can do substantially better than we are
currently doing in a lower-level language. With mutt, I can come close
to saturating my drive bandwidth while loading a folder. While
synchronizing in sup, I am lucky to get a few hundred kilobytes/second.
Certainly a large amount of that difference has to do with the amount of
processing done by each, but even adjusting for this it seems to me that
we should still be I/O bound (or at least close to it).
>
> > However, I think one of the real issues is the exclusive nature of
> > index access. In fact, this is one of my primary gripes with the sup
> > workflow. After processing a large number of messages, the write-out
> > time can be quite substantial upon killing the buffer.
>
> It is possible to address this in a variety of ways, many of which have
> been discussed over the years, but yes, I agree that a delay is
> nonideal.
Glad we agree.
>
> Making message state saving fast, or backgrounded, is a different beast
> from scanning over a mailstore.
If we are unable to update the index while the client is active,
rescanning sources would destroy usability. I would argue that
asynchronous writeout is very much a prerequisite for mutable sources.
>
> I have been working on a Sup server for quite some time that would
> address many of these problems, but progress is slow.
This was largely what I had in mind. It seems like moving index
manipulation out-of-process might be best, ultimately.
>
> > As an aside, it would be quite nice if one could run multiple
> > simultaneous instances of sup. It seems that if one only held write
> > access to the index during writes (is this the case presently?), there
> > should be nothing preventing this from being possible.
>
> It might be possible to do this with Xapian, especially if there were no
> expectation of updates being transmitted across processes.
I think initially no updates between processes would be fine.
> With Ferret,
> if it is possible, it's only with a tremendous amount of effort.
Is ferret even going to be supported after the Xapian backend
stabilizes?
Thanks for the comments and sup.
- Ben
------------------------------
Message: 1233
Date: Fri, 02 Oct 2009 02:19:35 +0200
From: Christopher Bertels <mailinglist@flasht.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] i18n?
Message-ID: <1254442420-sup-3771@thinkpad-ubuntu>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Do Okt 01 20:24:57 +0200 2009:
> It will be interesting to see how gettext handles the case of regular
> expressions (which is also probably what you want for the "attachment"
> detector). If it's not natural to wedge regexen into gettext, we should
> consider a custom solution.
Hmm. Well I started working on something simple based on yaml files.
I looked at gettext but that seemed a little weird to me. Since
Ruby's yaml module supports regular expressions, this is a plus point,
I guess. It worked with the attachments example.
--
================================
Christopher Bertels
http://www.adztec-independent.de
GPG Key ID: 0x2345b203
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 902 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091002/9c56d49e/attachment-0001.bin>
------------------------------
Message: 1234
Date: Fri, 2 Oct 2009 07:57:55 +0000 (UTC)
From: Olly Betts <olly@survex.com>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] [PATCH] xapian: do less work for
update_message_state
Message-ID: <slrnhcbck3.5ah.olly@msgid.survex.com>
Content-Type: text/plain; charset=us-ascii
On 2009-10-01, Rich Lane <rlane@club.cc.cmu.edu> wrote:
> Excerpts from William Morgan's message of Thu Oct 01 09:46:20 -0400 2009:
>> Reformatted excerpts from Rich Lane's message of 2009-09-30:
>> > They're about 3 times faster on my machine with this patch. An
>> > optimization the Xapian devs have been planning to make (and that this
>> > patch is necessary to take advantage of) should increase performance
>> > much more.
>>
>> Awesome. Out of curiousity, what's the optimization?
>
> replace_document currently deletes all the old postings and inserts new
> ones. It can be optimized to make the minimal set of modifications.
This is the ticket for it:
http://trac.xapian.org/ticket/250
Cheers,
Olly
------------------------------
Message: 1235
Date: Fri, 02 Oct 2009 11:25:04 +0200
From: Gregor Hoffleit <gregor@hoffleit.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Bug: store_message writes invalid From lines
with locales set
Message-ID: <1254475145-sup-5397@sam>
Content-Type: text/plain; charset=UTF-8
* William Morgan <wmorgan-sup@masanjin.net> [Thu Oct 01 18:38:36 +0200 2009]
> > Everything worked fine for me in August and September, since those
> > month names are spelled the same in German and English ;-).
>
> You expect your email client to work for more than two months a year?
Ok. I admit the right way to fix this would have been to take a time of
absence in the months of March, May, October and December. Should have
thought about that before complaining ;-).
Thanks for the quick fix,
Gregor
------------------------------
Message: 1236
Date: Fri, 02 Oct 2009 14:52:47 +0200
From: Christopher Bertels <mailinglist@flasht.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] i18n?
Message-ID: <1254487575-sup-5468@thinkpad-ubuntu>
Content-Type: text/plain; charset=UTF-8
I've uploaded what I've done so far to
http://www.gitorious.org/~bakkdoor/sup/bakkdoors-clone/trees/i18n
You can get it via git here:
git://gitorious.org/~bakkdoor/sup/bakkdoors-clone.git (branch: i18n)
Please tell me what you think. I know it's pretty simple but for now I
guess that's all we need. Or am I missing something?
One thing I wanted to add as well is, that if there is no translation
found for a different language, it will default to the english version
(instead of returning nil).
--
================================
Christopher Bertels
http://www.adztec-independent.de
GPG Key ID: 0x2345b203
------------------------------
Message: 1237
Date: Fri, 02 Oct 2009 16:35:42 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Bug: Converting the index to xapian fails with
a message with very old date
Message-ID: <1254513417-sup-8419@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Thu Oct 01 09:49:54 -0400 2009:
> Reformatted excerpts from Michael Stapelberg's message of 2009-09-26:
> > truncated date is Thu Jan 01 01:00:00 +0100 1970
> > date_value is "\200"
> > /usr/lib/ruby/1.8/sup/xapian_index.rb:536:in `_dump': year too big to marshal
> > (ArgumentError)
> > from /usr/lib/ruby/1.8/sup/xapian_index.rb:536:in `dump'
> > from /usr/lib/ruby/1.8/sup/xapian_index.rb:536:in `index_message'
> > from /usr/lib/ruby/1.8/sup/xapian_index.rb:124:in `sync_message'
>
> At this point I'm hoping that Rich will chime in. :)
This strikes me as a bug in Marshal.dump - it should be able to handle
arbitrary dates. I've never messed with custom marshalling functions
before, but monkey patching one in could be a workaround. Or we could
just truncate the dates before putting them in the index entry.
------------------------------
Message: 1238
Date: Fri, 02 Oct 2009 22:48:24 +0200
From: Christian Dietrich <stettberger@dokucode.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Feature Request: Collecting Lines in Index
Mode
Message-ID: <1254516195-sup-4619@peer.zerties.org>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Mi Sep 30 20:17:55 +0200 2009:
> Cool idea. I'd like to see how this looks.
>
> > I tried to implement the feature by my self, but the mapping beetween
> > `curpos' and `@threads' in modes/thread-index-mode.rb made this a
> > little bit hard, and i didn't know how to solve this problem without
> > breaking sup. Perhaps you can give me a hint, how this problem with
> > the direct mapping can be solved.
>
> If you look at #regen_text, @text and @lines are the two variables that
> control the display. @text is an array of the GUI elements for each line
> of the display. Right now it's just set to one line for each thread. You
> want to add one additional element at the appropriate position. for each
> date line. GUI elements are represented as arrays of [color, text]
> pairs; you can look at #text_for_thread_at for an example.
>
> Then, you want to make sure that @lines is set correctly. @lines is a
> map (hash) from line number to thread (so that when the user presses a
> key, we know which thread the cursor is resting on).
Thank you, that helped a much. I implemented the feature, it is
available at git://github.com/stettberger/sup-mail.git
branch time_marks, it is one commit ahead of next. It is enabled
with setting the config option ":time_markers_in_index_mode: true"
At runtime it can be toggled via '%' (just randomly choosen by me)
greetz didi
--
No documentation is better than bad documentation
-- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt.
------------------------------
Message: 1239
Date: Sat, 3 Oct 2009 03:36:39 -0700 (PDT)
From: gauteh <eg@gaute.vetsj.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] Bug: Xapian exception after having polled
Message-ID: <25727581.post@talk.nabble.com>
Content-Type: text/plain; charset=us-ascii
Greetings,
Sup fails with the attached backtrace right after having polled the
messages. The messages show up in the inbox before it fails, possibly
failing before they are shown, but they then show up the next time, before
the same exception happens again. It doesn't matter if I have new messages
or not.
This happenes both in f6873cee9960 and newest; 93b5552730c1
I keep my messages in maildir, synced with offlineimap on a Gmail account.
- gaute
http://www.nabble.com/file/p25727581/exception-log.txt exception-log.txt
--
View this message in context: http://www.nabble.com/Bug%3A-Xapian-exception-after-having-polled-tp25727581p25727581.html
Sent from the SUP Talk mailing list archive at Nabble.com.
------------------------------
Message: 1240
Date: Sat, 03 Oct 2009 13:31:16 +0300
From: Tarko Tikan <tarko@lanparty.ee>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] labels-before-subject and ask_for_contacts config
knobs
Message-ID: <1254565800-sup-5590@lanparty.ee>
Content-Type: text/plain; charset=ISO-8859-15
hey,
First, 0.9 is nice, thanks for that.
I want to ask the list about a thing (2 things actually, since 0.9) that has been bugging me.
ask_for_contacts is loading 10 contacts from index, imho this doesn't make a sane default (it's too low). I've always patched this to 500 on my end - yes, it takes a second or two to load that many contacts from index but this doesn't bug me as much as first looking up the person and then composing to him.
second, since labels-before-subject was integrated, it's hard to follow thread index on small screen. Most of my inbox is tagged with 3 labels, mailing-list could be tagged with up to 5 labels. The problem is especially bad on very small screens (like mobiles with ssh clients).
I'm tempted to submit a patch that enables to tune these behaviors via config. I don't find these hook-worthy as first is just a integer (default must stay reasonably low for people with slower computers) and second only makes sense together with full thread-index line customization (I'm not sure about the performance impact or complexity it might bring).
Anyone else sharing my view or I just keep patching on my end? :)
--
tarko
------------------------------
Message: 1241
Date: Sat, 3 Oct 2009 11:19:57 -0700
From: Rich Lane <rlane@club.cc.cmu.edu>
To: sup-talk@rubyforge.org
Subject: [sup-talk] [PATCH] don't downcase a nil content-type
Message-ID: <1254593997-32634-1-git-send-email-rlane@club.cc.cmu.edu>
---
lib/sup/message.rb | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/sup/message.rb b/lib/sup/message.rb
index 979597a..cbedb33 100644
--- a/lib/sup/message.rb
+++ b/lib/sup/message.rb
@@ -501,7 +501,7 @@ private
# Lowercase the filename because searches are easier that way
@attachments.push filename.downcase unless filename =~ /^sup-attachment-/
add_label :attachment unless filename =~ /^sup-attachment-/
- content_type = m.header.content_type.downcase || "application/unknown" # sometimes RubyMail gives us nil
+ content_type = (m.header.content_type || "application/unknown").downcase # sometimes RubyMail gives us nil
[Chunk::Attachment.new(content_type, filename, m, sibling_types)]
## otherwise, it's body text
--
1.6.4.2
------------------------------
Message: 1242
Date: Sat, 03 Oct 2009 14:22:34 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: gauteh <eg@gaute.vetsj.com>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Bug: Xapian exception after having polled
Message-ID: <1254594099-sup-719@zyrg.net>
Content-Type: text/plain; charset="utf-8"
Apply the attached patch and let us know what the new backtrace is.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nil-msgid-asserts.patch
Type: application/octet-stream
Size: 1254 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091003/1c9febbc/attachment-0001.obj>
------------------------------
Message: 1243
Date: Sat, 3 Oct 2009 22:04:14 +0200
From: Guillaume Quintard <guillaume.quintard@gmail.com>
To: "Sup-talk@rubyforge.org" <sup-talk@rubyforge.org>
Subject: [sup-talk] Crash, bad index, and ensuing misery
Message-ID:
<1e5fdab70910031304g255a9d13v4dc99400def375a5@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi, I crash my computer with sup running, and it seems the index
didn't really like. sup-sync -a didn't help, what can I do?
--- RuntimeError from thread: load threads for thread-index-mode
DocNotFoundError: Document 2461178145 not found.
./lib/sup/xapian_index.rb:132:in `document'
./lib/sup/xapian_index.rb:132:in `each_message_in_thread_for'
./lib/sup/xapian_index.rb:132:in `map'
./lib/sup/xapian_index.rb:132:in `each_message_in_thread_for'
./lib/sup/thread.rb:341:in `load_thread_for_message'
./lib/sup/thread.rb:333:in `load_n_threads'
./lib/sup/xapian_index.rb:117:in `each_id_by_date'
./lib/sup/xapian_index.rb:110:in `each_id'
./lib/sup/xapian_index.rb:110:in `each'
./lib/sup/xapian_index.rb:110:in `each_id'
./lib/sup/xapian_index.rb:117:in `each_id_by_date'
./lib/sup/thread.rb:328:in `load_n_threads'
./lib/sup/modes/thread-index-mode.rb:625:in `__unprotected_load_n_threads'
(eval):12:in `load_n_threads'
./lib/sup/modes/thread-index-mode.rb:609:in `load_n_threads_background'
./lib/sup.rb:77:in `reporting_thread'
./lib/sup.rb:75:in `initialize'
./lib/sup.rb:75:in `new'
./lib/sup.rb:75:in `reporting_thread'
./lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background'
./lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads'
(eval):12:in `load_threads'
bin/sup:197
--
Guillaume
------------------------------
Message: 1244
Date: Sat, 03 Oct 2009 16:17:54 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: Guillaume Quintard <guillaume.quintard@gmail.com>
Cc: "Sup-talk@rubyforge.org" <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash, bad index, and ensuing misery
Message-ID: <1254600926-sup-5190@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from Guillaume Quintard's message of Sat Oct 03 16:04:14 -0400 2009:
> Hi, I crash my computer with sup running, and it seems the index
> didn't really like. sup-sync -a didn't help, what can I do?
I'd hoped this kind of corruption wouldn't be possible with newer
xapian-index versions. What sup commit are you on? What version of
Xapian are you using? Which Xapian backend, Flint or Chert?
------------------------------
Message: 1245
Date: Sat, 03 Oct 2009 22:49:40 +0200
From: Marc Weber <marco-oweber@gmx.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] next search in buffer view..
Message-ID: <1254602805-sup-2900@nixos>
Content-Type: text/plain; charset=UTF-8
buffer.rb
def handle_input c
if @focus_buf
if @focus_buf.mode.in_search? && c != CONTINUE_IN_BUFFER_SEARCH_KEY[0]
@focus_buf.mode.cancel_search!
@focus_buf.mark_dirty
end
@focus_buf.mode.handle_input c
end
end
Why is the search canceled when typing any other char?
That's really annoying because there are some mails I have to use the
same search multiple times. However I also have to scroll up /down to
see enough context.
So why has this been implemented? Is it safe to remove that if
statement?
Seems to work for me.
It would be better if the next search would continue from the current
line rather than the last search result.
I'd like to see 'N' (search backward) as well.
If you like these ideas I'm going to supply a patch.
Comments?
Marc Weber
------------------------------
Message: 1246
Date: Sat, 3 Oct 2009 23:06:36 +0200
From: Guillaume Quintard <guillaume.quintard@gmail.com>
To: "Sup-talk@rubyforge.org" <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash, bad index, and ensuing misery
Message-ID:
<1e5fdab70910031406x713fad49ubb42b42463899c87@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Sat, Oct 3, 2009 at 10:17 PM, Rich Lane <rlane@club.cc.cmu.edu> wrote:
> I'd hoped this kind of corruption wouldn't be possible with newer
> xapian-index versions. What sup commit are you on? What version of
> Xapian are you using? Which Xapian backend, Flint or Chert?
>
ubuntu 9.10
libxapian-ruby1.8 1.0.14-1
I'd say flink since I often have to remove flintlock after sup
commiting suicide.
and git status says
# On branch next
# Your branch is ahead of 'origin/next' by 6 commits.
(ahead?)
--
Guillaume
------------------------------
Message: 1247
Date: Sat, 03 Oct 2009 17:39:42 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: Guillaume Quintard <guillaume.quintard@gmail.com>
Cc: "Sup-talk@rubyforge.org" <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash, bad index, and ensuing misery
Message-ID: <1254605615-sup-5636@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from Guillaume Quintard's message of Sat Oct 03 17:06:36 -0400 2009:
> On Sat, Oct 3, 2009 at 10:17 PM, Rich Lane <rlane@club.cc.cmu.edu> wrote:
> > I'd hoped this kind of corruption wouldn't be possible with newer
> > xapian-index versions. What sup commit are you on? What version of
> > Xapian are you using? Which Xapian backend, Flint or Chert?
> >
>
> ubuntu 9.10
> libxapian-ruby1.8 1.0.14-1
> I'd say flink since I often have to remove flintlock after sup
> commiting suicide.
>
> and git status says
> # On branch next
> # Your branch is ahead of 'origin/next' by 6 commits.
>
> (ahead?)
>
Please post the output of "git log --pretty=oneline 'origin/next^'.."
------------------------------
Message: 1248
Date: Sat, 3 Oct 2009 23:54:28 +0200
From: Guillaume Quintard <guillaume.quintard@gmail.com>
To: "Sup-talk@rubyforge.org" <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash, bad index, and ensuing misery
Message-ID:
<1e5fdab70910031454n28c57ae5m1f33f10f4e4acaab@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Sat, Oct 3, 2009 at 11:39 PM, Rich Lane <rlane@club.cc.cmu.edu> wrote:
> Please post the output of "git log --pretty=oneline 'origin/next^'.."
>
here you go
80789d873ac555bb1979f7734e95f104d848007e Merge branch 'next' of
git://gitorious.org/sup/mainline into next
0eee0973223b625b66e30c196ccd45d2f7bf358b Merge branch 'master' into next
93b5552730c10e2a352bd33f5ee98800bcd8679e more release-script updates
d1eabf9cb21940b933464ab3efc25df3c1a5f7e1 Merge branch 'next' of
git://gitorious.org/sup/mainline into next
df96980d0573cf91742a8f9ae5e8a49366d338b8 Merge branch 'next' of
git://gitorious.org/sup/mainline into next
a6dcb02dda7dd8bb1742890d460b1b0abfc28454 Merge branch 'next' of
git://gitorious.org/sup/mainline into next
823148627f554fbf5a7fb13379567276eeee14c7 Merge branch 'next' of
git://gitorious.org/sup/mainline into next
40ecc407a8aacf16d7f9f104501311cfd1fb2eb7 Revert "Merge branch
'after-add-message-hook' into next"
--
Guillaume
------------------------------
Message: 1249
Date: Sat, 03 Oct 2009 18:25:19 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: Guillaume Quintard <guillaume.quintard@gmail.com>
Cc: "Sup-talk@rubyforge.org" <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash, bad index, and ensuing misery
Message-ID: <1254607735-sup-864@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from Guillaume Quintard's message of Sat Oct 03 16:04:14 -0400 2009:
> --- RuntimeError from thread: load threads for thread-index-mode
> DocNotFoundError: Document 2461178145 not found.
> ./lib/sup/xapian_index.rb:132:in `document'
The relevant line:
docs = term_docids(mkterm(:thread, thread_id)).map { |x| @xapian.document x }
Basically expands to:
@xapian.postlist(term).map { |x| @xapian.document x.docid }
So, Xapian is giving us docids it can't turn into documents. At this
point I think you should just do a sup-dump (which might still work),
move the old xapian directory out of the way, and re-sync. You can try
running xapian-check on the corrupted version to see if it finds
anything interesting.
------------------------------
Message: 1250
Date: Sun, 4 Oct 2009 12:15:50 +0200
From: Gaute Hope <eg@gaute.vetsj.com>
To: Rich Lane <rlane@club.cc.cmu.edu>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Bug: Xapian exception after having polled
Message-ID: <20091004101550.GA7330@qwerzila.bluecom.no>
Content-Type: text/plain; charset="us-ascii"
Greetings,
Applied; fails at the same point, new backtrace attached.
(ps: your patch fails with 'git am' might be the Author: line that
should be a From:)
- gaute
On Sat, Oct 03, 2009 at 02:22:34PM -0400, Rich Lane wrote:
> Apply the attached patch and let us know what the new backtrace is.
-------------- next part --------------
--- RuntimeError from thread: poll after loading inbox
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:146:in `each_message_from'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/source.rb:104:in `each'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `send'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `__pass'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:547:in `method_missing'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:139:in `each_message_from'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:93:in `do_poll'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:81:in `each'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:81:in `do_poll'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:80:in `synchronize'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:80:in `do_poll'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/poll-mode.rb:15:in `poll'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:48:in `poll'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
/home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:196
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:77:in `reporting_thread'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `initialize'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `new'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `reporting_thread'
/home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:196
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:669:in `call'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:669:in `__unprotected_load_threads'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:610:in `call'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:610:in `load_n_threads_background'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:77:in `reporting_thread'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `initialize'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `new'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `reporting_thread'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads'
(eval):12:in `load_threads'
/home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:196
/home/gaute/.gem/ruby/1.8/bin/sup:19:in `load'
/home/gaute/.gem/ruby/1.8/bin/sup:19
------------------------------
Message: 1251
Date: Sun, 04 Oct 2009 14:36:02 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Simple E-Mail Delaying
Message-ID: <1254659599-sup-7377@peray>
Content-Type: text/plain; charset=UTF-8
Hi all,
I've written a blog post about improving my email experience. And since it
interacts nicely with sup it may be of some interest for you.
Best Regards,
--
Nicolas Pouillard
http://nicolaspouillard.fr
------------------------------
Message: 1252
Date: Sun, 04 Oct 2009 15:42:37 +0100
From: Marcus Williams <marcus-sup@bar-coded.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] labels-before-subject and ask_for_contacts
config knobs
Message-ID: <1254667184-sup-153@bar-coded.net>
Content-Type: text/plain; charset=UTF-8
On 3.10.2009, Tarko Tikan wrote:
> second, since labels-before-subject was integrated, it's hard to follow thread
> index on small screen. Most of my inbox is tagged with 3 labels, mailing-list
> could be tagged with up to 5 labels. The problem is especially bad on very
> small screens (like mobiles with ssh clients).
If you search through the archives you should find a patch I submitted
for an alternate view. The default alternate view I find very good on
smaller devices and its configurable via a hook if you want anything
more. Not sure if its going to get integrated into sup though
(Any thoughts William? - I can resubmit if necessary)
You would need to change the keypress from "~" to something that isnt
taken (currently thats taken as a console view).
HTH
Marcus
------------------------------
Message: 1253
Date: Sun, 04 Oct 2009 10:46:40 -0400
From: Steve Goldman <sgoldman@tower-research.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Simple E-Mail Delaying
Message-ID: <1254667426-sup-9509@sgoldmanlinux.tower-research.com>
Content-Type: text/plain; charset=UTF-8
Excerpts from Nicolas Pouillard's message of Sun Oct 04 08:36:02 -0400 2009:
> Hi all,
>
> I've written a blog post about improving my email experience. And since it
> interacts nicely with sup it may be of some interest for you.
>
> Best Regards,
>
This is brilliant.
Can you help me get it work?
What defines FULLEMAIL? I can't get the script past that.
(I'm not on the latest sup checkout, but i grepped the next branch for
FULLEMAIL and didn't see anything.)
Thanks.
--
Steve Goldman
sgoldman@tower-research.com
T: 212.219.6014
F: 212.219.6007
Tower Research Capital, LLC
377 Broadway, 11th Fl.
New York, NY 10013
------------------------------
Message: 1254
Date: Sun, 04 Oct 2009 11:51:51 -0400
From: William Baxter <web-sup@superscript.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Simple E-Mail Delaying
Message-ID: <1254671303-sup-2911@kronos>
Content-Type: text/plain; charset=US-ASCII
Excerpts from Nicolas Pouillard's message of Sun Oct 04 08:36:02 -0400 2009:
> I've written a blog post about improving my email experience. And since it
> interacts nicely with sup it may be of some interest for you.
I also employ a tickler system in sup, one that relies exclusively on labels.
To mark a thread for review on day DD of the month, label it with #DD.
Obviously this extends forward only one month. I have not found that
problematic. I also use #E to indicate the need to reply, #W as waiting for
something, #A for action required, etc.
The choice of # came from two considerations. First, it sorts before letters.
Second, it does not require quoting in searches. The date labels could do
without the prefix, but I began with the #<letter> labels, and like the way
that the common prefix sets these elements apart in label-list-mode.
Cheers, W.
------------------------------
Message: 1255
Date: Sun, 04 Oct 2009 12:23:17 -0400
From: Bo Borgerson <gigabo@gmail.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Handle added messages in
label-list-mode
Message-ID: <1254669536-sup-2700@longword>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Thu Oct 01 12:53:15 -0400 2009:
> Reformatted excerpts from Bo Borgerson's message of 2009-09-12:
> > Register label-list-mode with the UpdateManager and handle added
> > updates with a reload to keep unread message counts up to date
>
> Branch label-list-mode-auto-update, merged into next.
>
Hi William. Thanks for looking at this.
> I'm a little concerned with performance, but we'll see how it goes.
>
Yeah, I think I might be spoiled by my relatively few messages / labels. If it
turns out to be an issue maybe it could be made toggle-able with a key-press?
(Default off / configurable)?
I actually use the label-list-mode as my "home" screen. I like it to stay
up-to-date so I can quickly scan which labels have new messages.
Incidentally the recent discussion in another thread about making the inbox
more like other labels resonates with me. My workflow for all other labels is
just to 'x' out when I'm done, but with the inbox I have to '$'ave and
'B'uffer-switch.
> What do you think about handling labeled and deleted updates as well?
Is there a way to label or delete threads without leaving the label-list-mode?
There's already a refresh when switching back to the label-list-mode from
elsewhere, I think, so any changes that are $aved should be reflected
immediately when you get back. Labels added automatically in a
before-add-message hook should already be present when the 'added' update event
is received, right?
I'm not trying to argue against adding handlers for labeled and deleted
updates. I just want to make sure I understand the use cases so I know how to
test.
Thanks,
Bo
------------------------------
Message: 1256
Date: Sun, 04 Oct 2009 14:45:55 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: Gaute Hope <eg@gaute.vetsj.com>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Bug: Xapian exception after having polled
Message-ID: <1254681739-sup-4089@zyrg.net>
Content-Type: text/plain; charset="utf-8"
Ok, I've attached a patch with more assertions. Also, can you try with a clean
checkout of next and see if the problem still occurs?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-more-id-assertions.patch
Type: application/octet-stream
Size: 1695 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091004/6622c53c/attachment-0001.obj>
------------------------------
Message: 1257
Date: Sun, 4 Oct 2009 20:56:31 +0200
From: Gaute Hope <eg@gaute.vetsj.com>
To: Rich Lane <rlane@club.cc.cmu.edu>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Bug: Xapian exception after having polled
Message-ID:
<5a5b14cf0910041156q7e755931w4fb75ce57f9f4339@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Still having problems, but got a bit more output, see attached exception.log
[sup.git](next) $ git log --oneline -6
a209178 more id assertions
0eee097 Merge branch 'master' into next
93b5552 more release-script updates
f56badb Merge branch 'master' into next
b9071e5 change date for 0.9 release
9a5c0d1 Merge branch 'save-all-attachments' into next
- gaute
On Sun, Oct 4, 2009 at 8:45 PM, Rich Lane <rlane@club.cc.cmu.edu> wrote:
> Ok, I've attached a patch with more assertions. Also, can you try with a clean
> checkout of next and see if the problem still occurs?
>
-------------- next part --------------
--- RuntimeError from thread: main
@id nil
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/message.rb:342:in `build_from_source'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:160:in `each_message_from'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/maildir.rb:160:in `each'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/maildir.rb:157:in `upto'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/maildir.rb:157:in `each'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `send'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `__pass'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:547:in `method_missing'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:154:in `each_message_from'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:108:in `do_poll'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:96:in `each'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:96:in `do_poll'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:95:in `synchronize'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:95:in `do_poll'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/poll-mode.rb:15:in `poll'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:47:in `poll_with_sources'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:62:in `poll'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
/home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:287
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:73:in `reporting_thread'
/home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:287
/home/gaute/.gem/ruby/1.8/bin/sup:19:in `load'
/home/gaute/.gem/ruby/1.8/bin/sup:19
------------------------------
Message: 1258
Date: Sun, 04 Oct 2009 15:03:51 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: Gaute Hope <eg@gaute.vetsj.com>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Bug: Xapian exception after having polled
Message-ID: <1254682966-sup-6629@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Oops, sorry, bad assertions. Please move the two in
self.build_from_source to the end of load_from_source!.
Excerpts from Gaute Hope's message of Sun Oct 04 14:56:31 -0400 2009:
> Still having problems, but got a bit more output, see attached exception.log
>
> [sup.git](next) $ git log --oneline -6
> a209178 more id assertions
> 0eee097 Merge branch 'master' into next
> 93b5552 more release-script updates
> f56badb Merge branch 'master' into next
> b9071e5 change date for 0.9 release
> 9a5c0d1 Merge branch 'save-all-attachments' into next
>
> - gaute
>
> On Sun, Oct 4, 2009 at 8:45 PM, Rich Lane <rlane@club.cc.cmu.edu> wrote:
> > Ok, I've attached a patch with more assertions. Also, can you try with a clean
> > checkout of next and see if the problem still occurs?
> >
> --- RuntimeError from thread: main
> @id nil
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/message.rb:342:in
> `build_from_source'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:160:in
> `each_message_from'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/maildir.rb:160:in `each'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/maildir.rb:157:in `upto'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/maildir.rb:157:in `each'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `send'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `__pass'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:547:in `method_missing'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:154:in
> `each_message_from'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:108:in `do_poll'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:96:in `each'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:96:in `do_poll'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:95:in `synchronize'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:95:in `do_poll'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/poll-mode.rb:15:in `poll'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:47:in `poll_with_sources'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:62:in `poll'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:287
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:73:in `reporting_thread'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:287
> /home/gaute/.gem/ruby/1.8/bin/sup:19:in `load'
> /home/gaute/.gem/ruby/1.8/bin/sup:19
------------------------------
Message: 1259
Date: Sun, 4 Oct 2009 21:20:50 +0200
From: Gaute Hope <eg@gaute.vetsj.com>
To: Rich Lane <rlane@club.cc.cmu.edu>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Bug: Xapian exception after having polled
Message-ID:
<5a5b14cf0910041220p26a4c830va172df0e33542480@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Still the same..
(run without '-n' then P this time, thats the reason for the longer exception..)
[sup.git](next-nil) $ git log --oneline -4
7e99810 for your confirmation..
eafea2b more id assertions
0eee097 Merge branch 'master' into next
93b5552 more release-script updates
- gaute
On Sun, Oct 4, 2009 at 9:03 PM, Rich Lane <rlane@club.cc.cmu.edu> wrote:
> Oops, sorry, bad assertions. Please move the two in
> self.build_from_source to the end of load_from_source!.
>
> Excerpts from Gaute Hope's message of Sun Oct 04 14:56:31 -0400 2009:
>> Still having problems, but got a bit more output, see attached exception.log
>>
>> [sup.git](next) $ git log --oneline -6
>> a209178 more id assertions
>> 0eee097 Merge branch 'master' into next
>> 93b5552 more release-script updates
>> f56badb Merge branch 'master' into next
>> b9071e5 change date for 0.9 release
>> 9a5c0d1 Merge branch 'save-all-attachments' into next
>>
>> - gaute
>>
>> On Sun, Oct 4, 2009 at 8:45 PM, Rich Lane <rlane@club.cc.cmu.edu> wrote:
>> > Ok, I've attached a patch with more assertions. Also, can you try with a clean
>> > checkout of next and see if the problem still occurs?
>> >
>> --- RuntimeError from thread: main
>> @id nil
>> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/message.rb:342:in
>> `build_from_source'
>> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:160:in
>> `each_message_from'
>> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/maildir.rb:160:in `each'
>> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/maildir.rb:157:in `upto'
>> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/maildir.rb:157:in `each'
>> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `send'
>> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `__pass'
>> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:547:in `method_missing'
>> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:154:in
>> `each_message_from'
>> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:108:in `do_poll'
>> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:96:in `each'
>> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:96:in `do_poll'
>> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:95:in `synchronize'
>> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:95:in `do_poll'
>> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
>> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
>> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/poll-mode.rb:15:in `poll'
>> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:47:in `poll_with_sources'
>> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:62:in `poll'
>> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
>> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
>> /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:287
>> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:73:in `reporting_thread'
>> /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:287
>> /home/gaute/.gem/ruby/1.8/bin/sup:19:in `load'
>> /home/gaute/.gem/ruby/1.8/bin/sup:19
>
-------------- next part --------------
--- RuntimeError from thread: poll after loading inbox
@id nil
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/message.rb:254:in `load_from_source!'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/message.rb:342:in `build_from_source'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:160:in `each_message_from'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/source.rb:104:in `each'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `send'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `__pass'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:547:in `method_missing'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:154:in `each_message_from'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:108:in `do_poll'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:96:in `each'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:96:in `do_poll'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:95:in `synchronize'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:95:in `do_poll'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/poll-mode.rb:15:in `poll'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:47:in `poll_with_sources'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:62:in `poll'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
/home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:197
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:77:in `reporting_thread'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `initialize'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `new'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `reporting_thread'
/home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:197
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:669:in `call'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:669:in `__unprotected_load_threads'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:610:in `call'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:610:in `load_n_threads_background'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:77:in `reporting_thread'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `initialize'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `new'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `reporting_thread'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads'
(eval):12:in `load_threads'
/home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:197
/home/gaute/.gem/ruby/1.8/bin/sup:19:in `load'
/home/gaute/.gem/ruby/1.8/bin/sup:19
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-for-your-confirmation.patch
Type: text/x-patch
Size: 1346 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091004/385603f1/attachment-0001.bin>
------------------------------
Message: 1260
Date: Sun, 4 Oct 2009 21:59:44 +0200
From: Guillaume Quintard <guillaume.quintard@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash while scrolling
Message-ID:
<1e5fdab70910041259j40ceaaeue4473d17136a5efc@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Fri, Sep 11, 2009 at 6:58 PM, Ben Gamari <bgamari.foss@gmail.com> wrote:
> I can also produce a very similar crash[2] by attempting to load all
> threads. Thanks,
I get the same thing when loading all the threads. Index has just been
rebuilt, and I'm using an mbox file.
--
Guillaume
------------------------------
Message: 1261
Date: Sun, 04 Oct 2009 22:55:42 +0200
From: Marc Weber <marco-oweber@gmx.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] next search in buffer view..
Message-ID: <1254689522-sup-2800@nixos>
Content-Type: text/plain; charset=UTF-8
Mmh. Maybe its not that a bad idea to keep the search mode.
However it would be nice to provide the last search term as default.
This minimal patch adds this feature.
However the search_query_input should be global. So where is the place
to add this "last-search-term" ? Isn't it already present in the ask
history? Can you give me a hint to find it faster?
Marc Weber
diff --git a/lib/sup/modes/scroll-mode.rb b/lib/sup/modes/scroll-mode.rb
index c131425..a97f13c 100644
--- a/lib/sup/modes/scroll-mode.rb
+++ b/lib/sup/modes/scroll-mode.rb
@@ -35,6 +35,7 @@ class ScrollMode < Mode
@slip_rows = opts[:slip_rows] || 0 # when we pgup/pgdown,
# how many lines do we keep?
@twiddles = opts.member?(:twiddles) ? opts[:twiddles] : true
+ @search_query_input = ""
@search_query = nil
@search_line = nil
@status = ""
@@ -81,9 +82,10 @@ class ScrollMode < Mode
end
def search_in_buffer
- query = BufferManager.ask :search, "search in buffer: "
+ query = BufferManager.ask :search, "search in buffer: ", @search_query_input
return if query.nil? || query.empty?
@search_query = Regexp.escape query
+ @search_query_input = query
continue_search_in_buffer
end
------------------------------
Message: 1262
Date: Mon, 05 Oct 2009 09:55:09 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: Steve Goldman <sgoldman@tower-research.com>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Simple E-Mail Delaying
Message-ID: <1254728881-sup-3528@peray>
Content-Type: text/plain; charset=UTF-8
Excerpts from Steve Goldman's message of Sun Oct 04 16:46:40 +0200 2009:
> Excerpts from Nicolas Pouillard's message of Sun Oct 04 08:36:02 -0400 2009:
> > Hi all,
> >
> > I've written a blog post about improving my email experience. And since it
> > interacts nicely with sup it may be of some interest for you.
> >
> > Best Regards,
> >
>
> This is brilliant.
>
> Can you help me get it work?
Of course.
> What defines FULLEMAIL? I can't get the script past that.
I defined it in my shell profile (.zshrc actually),
export FULLEMAIL="Nicolas Pouillard <nicolas.pouillard@gmail.com>"
I know that is not standard, and I can be easily convinced to support
something more portable.
In my .zshrc I have $EMAIL, $MAILADDR as well.
--
Nicolas Pouillard
http://nicolaspouillard.fr
------------------------------
Message: 1263
Date: Mon, 05 Oct 2009 09:59:45 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: William Baxter <web-sup@superscript.com>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Simple E-Mail Delaying
Message-ID: <1254729313-sup-1910@peray>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Baxter's message of Sun Oct 04 17:51:51 +0200 2009:
> Excerpts from Nicolas Pouillard's message of Sun Oct 04 08:36:02 -0400 2009:
> > I've written a blog post about improving my email experience. And since it
> > interacts nicely with sup it may be of some interest for you.
>
> I also employ a tickler system in sup, one that relies exclusively on labels.
> To mark a thread for review on day DD of the month, label it with #DD.
> Obviously this extends forward only one month. I have not found that
> problematic. I also use #E to indicate the need to reply, #W as waiting for
> something, #A for action required, etc.
>
> The choice of # came from two considerations. First, it sorts before letters.
> Second, it does not require quoting in searches. The date labels could do
> without the prefix, but I began with the #<letter> labels, and like the way
> that the common prefix sets these elements apart in label-list-mode.
Thanks for the tip!
I already use a "pending" label for a mix of "waiting",
"need to reply", and "action required". I'm thinking about switching to
shorter and more distinct naming like yours.
However I like the system proposed because it is event based and can be more
fine grained than "a day of the month".
Best regards,
--
Nicolas Pouillard
http://nicolaspouillard.fr
------------------------------
Message: 1264
Date: Mon, 05 Oct 2009 18:00:25 +0200
From: Christopher Bertels <mailinglist@flasht.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] i18n?
Message-ID: <1254758256-sup-7400@thinkpad-ubuntu>
Content-Type: text/plain; charset=UTF-8
I think I've translated most of sup's UI-related part (translating
error messages doesn't seem like a good idea, since we really don't
want multilingual bug-reports and exception logs...) I'd like to hear
some feedback and/or opinions/suggestions and would like to see it
integrated into sup. I'll add more translations, if I find anything I
havent missed yet and that is part of the user interface.
Cheers,
Christopher.
--
================================
Christopher Bertels
http://www.adztec-independent.de
GPG Key ID: 0x2345b203
------------------------------
Message: 1265
Date: Tue, 06 Oct 2009 00:01:18 +0200
From: Gaute Hope <eg@gaute.vetsj.com>
To: Rich Lane <rlane@club.cc.cmu.edu>, sup-talk
<sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Bug: Xapian exception after having polled
Message-ID: <1254780036-sup-3214@qwerzila>
Content-Type: text/plain; charset=UTF-8
Did a 'sup-sync --changed -o' and the problem seems to be gone.
- gaute
Excerpts from Gaute Hope's message of su. okt. 04 21:20:50 +0200 2009:
> Still the same..
>
> (run without '-n' then P this time, thats the reason for the longer exception..)
>
> [sup.git](next-nil) $ git log --oneline -4
> 7e99810 for your confirmation..
> eafea2b more id assertions
> 0eee097 Merge branch 'master' into next
> 93b5552 more release-script updates
>
> - gaute
>
> On Sun, Oct 4, 2009 at 9:03 PM, Rich Lane <rlane@club.cc.cmu.edu> wrote:
> > Oops, sorry, bad assertions. Please move the two in
> > self.build_from_source to the end of load_from_source!.
> >
> > Excerpts from Gaute Hope's message of Sun Oct 04 14:56:31 -0400 2009:
> >> Still having problems, but got a bit more output, see attached exception.log
> >>
> >> [sup.git](next) $ git log --oneline -6
> >> a209178 more id assertions
> >> 0eee097 Merge branch 'master' into next
> >> 93b5552 more release-script updates
> >> f56badb Merge branch 'master' into next
> >> b9071e5 change date for 0.9 release
> >> 9a5c0d1 Merge branch 'save-all-attachments' into next
> >>
> >> - gaute
> >>
> >> On Sun, Oct 4, 2009 at 8:45 PM, Rich Lane <rlane@club.cc.cmu.edu> wrote:
> >> > Ok, I've attached a patch with more assertions. Also, can you try with a clean
> >> > checkout of next and see if the problem still occurs?
> >> >
> >> --- RuntimeError from thread: main
> >> @id nil
> >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/message.rb:342:in
> >> `build_from_source'
> >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:160:in
> >> `each_message_from'
> >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/maildir.rb:160:in `each'
> >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/maildir.rb:157:in `upto'
> >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/maildir.rb:157:in `each'
> >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `send'
> >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `__pass'
> >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:547:in `method_missing'
> >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:154:in
> >> `each_message_from'
> >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:108:in `do_poll'
> >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:96:in `each'
> >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:96:in `do_poll'
> >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:95:in `synchronize'
> >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:95:in `do_poll'
> >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
> >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
> >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/poll-mode.rb:15:in `poll'
> >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:47:in `poll_with_sources'
> >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:62:in `poll'
> >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
> >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
> >> /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:287
> >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:73:in `reporting_thread'
> >> /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:287
> >> /home/gaute/.gem/ruby/1.8/bin/sup:19:in `load'
> >> /home/gaute/.gem/ruby/1.8/bin/sup:19
> >
> --- RuntimeError from thread: poll after loading inbox
> @id nil
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/message.rb:254:in
> `load_from_source!'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/message.rb:342:in
> `build_from_source'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:160:in
> `each_message_from'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/source.rb:104:in `each'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `send'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `__pass'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:547:in `method_missing'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:154:in
> `each_message_from'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:108:in `do_poll'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:96:in `each'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:96:in `do_poll'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:95:in `synchronize'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:95:in `do_poll'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/poll-mode.rb:15:in `poll'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:47:in `poll_with_sources'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:62:in `poll'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:197
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:77:in `reporting_thread'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `initialize'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `new'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `reporting_thread'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:197
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:669:in
> `call'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:669:in
> `__unprotected_load_threads'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:610:in
> `call'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:610:in
> `load_n_threads_background'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:77:in `reporting_thread'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `initialize'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `new'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `reporting_thread'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:608:in
> `load_n_threads_background'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:679:in
> `__unprotected_load_threads'
> (eval):12:in `load_threads'
> /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:197
> /home/gaute/.gem/ruby/1.8/bin/sup:19:in `load'
> /home/gaute/.gem/ruby/1.8/bin/sup:19
------------------------------
Message: 1266
Date: Tue, 06 Oct 2009 00:11:17 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: Nicolas Pouillard <nicolas.pouillard@gmail.com>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Simple E-Mail Delaying
Message-ID: <1254780524-sup-6949@peray>
Content-Type: text/plain; charset=UTF-8
Excerpts from Nicolas Pouillard's message of Mon Oct 05 09:55:09 +0200 2009:
> Excerpts from Steve Goldman's message of Sun Oct 04 16:46:40 +0200 2009:
> > Excerpts from Nicolas Pouillard's message of Sun Oct 04 08:36:02 -0400 2009:
> > > Hi all,
> > >
> > > I've written a blog post about improving my email experience. And since it
> > > interacts nicely with sup it may be of some interest for you.
> > >
> > > Best Regards,
> > >
> >
> > This is brilliant.
> >
> > Can you help me get it work?
>
> Of course.
>
> > What defines FULLEMAIL? I can't get the script past that.
>
> I defined it in my shell profile (.zshrc actually),
>
> export FULLEMAIL="Nicolas Pouillard <nicolas.pouillard@gmail.com>"
>
> I know that is not standard, and I can be easily convinced to support
> something more portable.
>
> In my .zshrc I have $EMAIL, $MAILADDR as well.
I have updated my gist [1], to reflect two changes the first is to set the
date at the sending time (not when running email-reminder) and the second is
to use $EMAIL and $REALNAME which are a bit more self-explanatory.
[1]: http://gist.github.com/199197
--
Nicolas Pouillard
http://nicolaspouillard.fr
------------------------------
Message: 1267
Date: Tue, 6 Oct 2009 12:14:43 +0200
From: Guillaume Quintard <guillaume.quintard@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Bug: Xapian exception after having polled
Message-ID:
<1e5fdab70910060314i6a4cce5ck92e7605ec54f98a1@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Tue, Oct 6, 2009 at 12:01 AM, Gaute Hope <eg@gaute.vetsj.com> wrote:
> Did a 'sup-sync --changed -o' and the problem seems to be gone.
It doesn't for me. During sup-sync I get this:
[Tue Oct 06 11:22:55 +0200 2009] hook: error running hook: cannot
generate tempfile `/tmp/12016-9-attachments/389068.html'
[Tue Oct 06 11:22:55 +0200 2009] hook:
/usr/lib/ruby/1.8/tempfile.rb:52:in `initialize'
./lib/sup/message-chunks.rb:149:in `new'
./lib/sup/message-chunks.rb:149:in `write_to_disk'
./lib/sup/message-chunks.rb:105:in `initialize'
./lib/sup/hook.rb:51:in `call'
./lib/sup/hook.rb:51:in `filename'
/home/shivan/.sup/hooks/mime-decode.rb:4:in `__run'
./lib/sup/hook.rb:42:in `__run'
./lib/sup/hook.rb:82:in `run'
./lib/sup/util.rb:520:in `send'
./lib/sup/util.rb:520:in `method_missing'
./lib/sup/message-chunks.rb:104:in `initialize'
./lib/sup/message.rb:503:in `new'
./lib/sup/message.rb:503:in `message_to_chunks'
./lib/sup/message.rb:435:in `message_to_chunks'
./lib/sup/message.rb:435:in `map'
./lib/sup/message.rb:435:in `message_to_chunks'
./lib/sup/message.rb:239:in `load_from_source!'
./lib/sup/message.rb:335:in `build_from_source'
./lib/sup/poll.rb:160:in `each_message_from'
./lib/sup/source.rb:104:in `each'
./lib/sup/util.rb:560:in `send'
./lib/sup/util.rb:560:in `__pass'
./lib/sup/util.rb:547:in `method_missing'
./lib/sup/poll.rb:154:in `each_message_from'
./lib/sup/util.rb:520:in `send'
./lib/sup/util.rb:520:in `method_missing'
bin/sup-sync:146
bin/sup-sync:141:in `each'
bin/sup-sync:141
I got rid of the hooks, ran sup-sync again, the message goes away, but
I still get:
--- RuntimeError from thread: load threads for thread-index-mode
wrong id called on nil
./lib/sup.rb:17:in `id'
./lib/sup/modes/thread-index-mode.rb:225:in `update'
./lib/sup/hook.rb:121:in `sort_by'
./lib/sup/modes/thread-index-mode.rb:225:in `each'
./lib/sup/modes/thread-index-mode.rb:225:in `sort_by'
./lib/sup/modes/thread-index-mode.rb:225:in `update'
./lib/sup/modes/thread-index-mode.rb:223:in `synchronize'
./lib/sup/modes/thread-index-mode.rb:223:in `update'
./lib/sup/modes/thread-index-mode.rb:637:in `__unprotected_load_n_threads'
(eval):12:in `load_n_threads'
./lib/sup/modes/thread-index-mode.rb:609:in `load_n_threads_background'
./lib/sup.rb:77:in `reporting_thread'
./lib/sup.rb:75:in `initialize'
./lib/sup.rb:75:in `new'
./lib/sup.rb:75:in `reporting_thread'
./lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background'
./lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads'
(eval):12:in `load_threads'
bin/sup:197
upon loading
--
Guillaume
------------------------------
Message: 1268
Date: Tue, 6 Oct 2009 12:40:25 +0000 (UTC)
From: Olly Betts <olly@survex.com>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Crash, bad index, and ensuing misery
Message-ID: <loom.20091006T143016-56@post.gmane.org>
Content-Type: text/plain; charset=us-ascii
Guillaume Quintard writes:
> On Sat, Oct 3, 2009 at 10:17 PM, Rich Lane <rlane <at> club.cc.cmu.edu> wrote:
> > I'd hoped this kind of corruption wouldn't be possible with newer
> > xapian-index versions. What sup commit are you on? What version of
> > Xapian are you using? Which Xapian backend, Flint or Chert?
>
> ubuntu 9.10
> libxapian-ruby1.8 1.0.14-1
> I'd say flink since I often have to remove flintlock after sup
> commiting suicide.
NEVER EVER remove the flintlock file. It's not the presence of the file which
determines the lock, but rather whether there's an fcntl() lock on it, so
removing it smashes any lock which is currently held, but leaves the process
which held it thinking it still has exclusive write access to the database,
which will likely quickly lead to a corrupt database, especially if you're
doing so because Xapian says the database is already locked. If Xapian says
that, then there really is a process which still has the database open for
writing.
My guess is that removing the flintlock file is the cause of the corruption
you're seeing. Can you reproduce it on a database where you haven't removed
this file?
Also, both chert and flint use the same locking approach with a file called
flintlock, so that doesn't discriminate between them. The easy way to tell
which you have is whether there's a file called "iamflint" or "iamchert" in
the database directory.
Cheers,
Olly
------------------------------
Message: 1269
Date: Tue, 6 Oct 2009 15:10:44 +0200
From: Guillaume Quintard <guillaume.quintard@gmail.com>
To: Olly Betts <olly@survex.com>
Cc: sup-talk@rubyforge.org
Subject: Re: [sup-talk] Crash, bad index, and ensuing misery
Message-ID:
<1e5fdab70910060610n7486dc1bi27b07c4f5f51faa6@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Tue, Oct 6, 2009 at 2:40 PM, Olly Betts <olly@survex.com> wrote:
> NEVER EVER remove the flintlock file.
Ooops, didn't know, won't do it again.
> My guess is that removing the flintlock file is the cause of the corruption
> you're seeing. ?Can you reproduce it on a database where you haven't removed
> this file?
Unfortunately, no
> which you have is whether there's a file called "iamflint" or "iamchert" in
Flint then
--
Guillaume
------------------------------
Message: 1270
Date: Tue, 06 Oct 2009 15:34:51 +0200
From: Gaute Hope <eg@gaute.vetsj.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Bug: Xapian exception after having polled
Message-ID: <1254835794-sup-6000@qwerzila>
Content-Type: text/plain; charset="utf-8"
Excerpts from Guillaume Quintard's message of ty. okt. 06 12:14:43 +0200 2009:
> On Tue, Oct 6, 2009 at 12:01 AM, Gaute Hope <eg@gaute.vetsj.com> wrote:
> > Did a 'sup-sync --changed -o' and the problem seems to be gone.
> --- RuntimeError from thread: load threads for thread-index-mode
> wrong id called on nil
> ./lib/sup.rb:17:in `id'
I was getting a slightly different error:
--- RuntimeError from thread: poll after loading inbox
@id nil
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/message.rb:254:in
`load_from_source!'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/message.rb:342:in
`build_from_source'
/home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:160:in
`each_message_from'
- gaute
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091006/07fdbfd2/attachment-0001.bin>
------------------------------
Message: 1271
Date: Tue, 06 Oct 2009 07:59:07 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Bug: Xapian exception after having polled
Message-ID: <1254840860-sup-2494@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Guillaume Quintard's message of 2009-10-06:
> [Tue Oct 06 11:22:55 +0200 2009] hook: error running hook: cannot
> generate tempfile `/tmp/12016-9-attachments/389068.html'
> [Tue Oct 06 11:22:55 +0200 2009] hook:
> /usr/lib/ruby/1.8/tempfile.rb:52:in `initialize'
> ./lib/sup/message-chunks.rb:149:in `new'
> ./lib/sup/message-chunks.rb:149:in `write_to_disk'
> ./lib/sup/message-chunks.rb:105:in `initialize'
> ./lib/sup/hook.rb:51:in `call'
> ./lib/sup/hook.rb:51:in `filename'
> /home/shivan/.sup/hooks/mime-decode.rb:4:in `__run'
I think that's an unrelated issue, but it's weird that it couldn't
create that file in /tmp. Are you out of disk space, missing a /tmp
directory, or something weird like that?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1272
Date: Tue, 06 Oct 2009 08:38:39 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] i18n?
Message-ID: <1254842820-sup-9099@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Hi Christopher,
Reformatted excerpts from Christopher Bertels's message of 2009-10-05:
> I'd like to hear some feedback and/or opinions/suggestions and would
> like to see it integrated into sup. I'll add more translations, if I
> find anything I havent missed yet and that is part of the user
> interface.
This looks great. A couple comments:
1. I would prefer that uppercase substitution symbols made lowercase.
The uppercase seems weird and un-Rubyish to me.
2. I think it would be nice to have a simple module along the lines of:
module M17n
def m s, o={}; I18n[m, o] end
end
and to have that be the primary entry point when you want a translated
string. Then classes can include that module if they want m17n support,
and instead of writing
I18n["text", { :var => value }]
you can have
m("text", :var => value)
which is a little easier to read, IMO.
3. Should we call it m17n instead of i18n? I think that might be a
little more accurate. Perhaps too nitpicky. What do you think?
4. A finishing touch would be to have sup-config ask the user what
language they are interested in.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1273
Date: Tue, 06 Oct 2009 11:53:18 -0400
From: Ben Gamari <bgamari.foss@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash while in thread-view-mode
Message-ID: <1254844166-sup-1028@ben-laptop>
Content-Type: text/plain; charset=UTF-8
Well, it seems like whatever caused the crash earlier did something to
my index. Now any attempt to open a thread-index-mode of my LKML label
(which I was viewing in the earlier crash) causes the client to
immediately crash.
Do any of the sup utilities have any sort of index sanity checker to
find potential causes of this sort of issue? Thanks,
- Ben
--- RuntimeError from thread: load threads for thread-index-mode
wrong id called on nil
/opt/exp/sup/lib/sup.rb:17:in `id'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `update'
/usr/lib64/ruby/1.8/rubygems/custom_require.rb:31:in `sort_by'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `each'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `sort_by'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `update'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:223:in `synchronize'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:223:in `update'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:628:in `__unprotected_load_n_threads'
/opt/exp/sup/lib/sup/thread.rb:334:in `load_n_threads'
/opt/exp/sup/lib/sup/xapian_index.rb:117:in `each_id_by_date'
/opt/exp/sup/lib/sup/xapian_index.rb:110:in `each_id'
/opt/exp/sup/lib/sup/xapian_index.rb:110:in `each'
/opt/exp/sup/lib/sup/xapian_index.rb:110:in `each_id'
/opt/exp/sup/lib/sup/xapian_index.rb:117:in `each_id_by_date'
/opt/exp/sup/lib/sup/thread.rb:328:in `load_n_threads'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:625:in `__unprotected_load_n_threads'
(eval):12:in `load_n_threads'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:609:in `load_n_threads_background'
/opt/exp/sup/lib/sup.rb:77:in `reporting_thread'
/opt/exp/sup/lib/sup.rb:75:in `initialize'
/opt/exp/sup/lib/sup.rb:75:in `new'
/opt/exp/sup/lib/sup.rb:75:in `reporting_thread'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads'
(eval):12:in `load_threads'
/opt/exp/sup/lib/sup/modes/label-search-results-mode.rb:33:in `spawn_nicely'
/opt/exp/sup/lib/sup/modes/label-list-mode.rb:103:in `select_label'
/opt/exp/sup/lib/sup/mode.rb:51:in `send'
/opt/exp/sup/lib/sup/mode.rb:51:in `handle_input'
/opt/exp/sup/lib/sup/buffer.rb:267:in `handle_input'
/usr/bin/sup:239
Excerpts from Ben Gamari's message of Tue Oct 06 11:47:34 -0400 2009:
> I just had sup crash on me while reading a thread. Not really sure what
> to make of the backtrace. Looks like it failed during polling but who
> knows why. Thanks,
>
> - Ben
>
------------------------------
Message: 1274
Date: Tue, 06 Oct 2009 11:47:34 -0400
From: Ben Gamari <bgamari.foss@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Crash while in thread-view-mode
Message-ID: <1254844050-sup-4148@ben-laptop>
Content-Type: text/plain; charset=UTF-8
I just had sup crash on me while reading a thread. Not really sure what
to make of the backtrace. Looks like it failed during polling but who
knows why. Thanks,
- Ben
--- RuntimeError from thread: periodic poll
wrong id called on nil
/opt/exp/sup/lib/sup.rb:17:in `id'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `update'
/opt/exp/sup/lib/sup/xapian_index.rb:325:in `sort_by'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `each'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `sort_by'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `update'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:223:in `synchronize'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:223:in `update'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:702:in `add_or_unhide'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:188:in `handle_added_update'
/opt/exp/sup/lib/sup/update.rb:26:in `send'
/opt/exp/sup/lib/sup/update.rb:26:in `relay'
/opt/exp/sup/lib/sup/update.rb:26:in `each'
/opt/exp/sup/lib/sup/update.rb:26:in `relay'
/opt/exp/sup/lib/sup/util.rb:520:in `send'
/opt/exp/sup/lib/sup/util.rb:520:in `method_missing'
/opt/exp/sup/lib/sup/poll.rb:181:in `add_new_message'
/opt/exp/sup/lib/sup/poll.rb:124:in `do_poll'
/opt/exp/sup/lib/sup/poll.rb:166:in `each_message_from'
/opt/exp/sup/lib/sup/maildir.rb:160:in `each'
/opt/exp/sup/lib/sup/maildir.rb:157:in `upto'
/opt/exp/sup/lib/sup/maildir.rb:157:in `each'
/opt/exp/sup/lib/sup/util.rb:560:in `send'
/opt/exp/sup/lib/sup/util.rb:560:in `__pass'
/opt/exp/sup/lib/sup/util.rb:547:in `method_missing'
/opt/exp/sup/lib/sup/poll.rb:154:in `each_message_from'
/opt/exp/sup/lib/sup/poll.rb:108:in `do_poll'
/opt/exp/sup/lib/sup/poll.rb:96:in `each'
/opt/exp/sup/lib/sup/poll.rb:96:in `do_poll'
/opt/exp/sup/lib/sup/poll.rb:95:in `synchronize'
/opt/exp/sup/lib/sup/poll.rb:95:in `do_poll'
/opt/exp/sup/lib/sup/util.rb:520:in `send'
/opt/exp/sup/lib/sup/util.rb:520:in `method_missing'
/opt/exp/sup/lib/sup/modes/poll-mode.rb:15:in `poll'
/opt/exp/sup/lib/sup/poll.rb:47:in `poll_with_sources'
/opt/exp/sup/lib/sup/poll.rb:62:in `poll'
/opt/exp/sup/lib/sup/poll.rb:80:in `start'
/opt/exp/sup/lib/sup.rb:77:in `reporting_thread'
/opt/exp/sup/lib/sup.rb:75:in `initialize'
/opt/exp/sup/lib/sup.rb:75:in `new'
/opt/exp/sup/lib/sup.rb:75:in `reporting_thread'
/opt/exp/sup/lib/sup/poll.rb:77:in `start'
/opt/exp/sup/lib/sup/util.rb:520:in `send'
/opt/exp/sup/lib/sup/util.rb:520:in `method_missing'
/usr/bin/sup:204
------------------------------
Message: 1275
Date: Tue, 06 Oct 2009 12:15:46 -0400
From: Ben Gamari <bgamari.foss@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash while in thread-view-mode
Message-ID: <1254845543-sup-9458@ben-laptop>
Content-Type: text/plain; charset=UTF-8
Excerpts from Ben Gamari's message of Tue Oct 06 11:53:18 -0400 2009:
> Well, it seems like whatever caused the crash earlier did something to
> my index. Now any attempt to open a thread-index-mode of my LKML label
> (which I was viewing in the earlier crash) causes the client to
> immediately crash.
>
Hmm, it seems like the problem is spreading. I now come to find out that
another label triggers this same crash (although I guess it's possible
that the intersection of the two labels is non-nil). I tried running a
sup-sync -oc on the relevant sources to no avail. I really don't have
time to devote to debugging this at the moment so it looks like I might
need to take another hiatus from sup. Just as I was starting to get used
to it... sigh. Anyways, if anyone has any ideas for improving things,
let me know. Thanks!
- Ben
------------------------------
Message: 1276
Date: Tue, 06 Oct 2009 09:35:36 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] next search in buffer view..
Message-ID: <1254846869-sup-9463@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Marc Weber's message of 2009-10-04:
> However the search_query_input should be global. So where is the place
> to add this "last-search-term" ? Isn't it already present in the ask
> history? Can you give me a hint to find it faster?
Probably the best place is to make it a class variable, i.e.
@@search_query_input. Then it will be shared across all buffers with
modes that have search functionality.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1277
Date: Tue, 06 Oct 2009 12:39:08 -0400
From: Mark Alexander <marka@pobox.com>
To: Ben Gamari <bgamari.foss@gmail.com>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash while in thread-view-mode
Message-ID: <1254846746-sup-1820@r50p>
Content-Type: text/plain; charset=UTF-8
> I really don't have
> time to devote to debugging this at the moment so it looks like I might
> need to take another hiatus from sup.
You could try running an older version. I've been using 0.8 at
work, and a May 20 snapshot of next at home, and both have been very
solid. They're good enough, in fact, that I don't feel the need to
upgrade. Maybe after the dust settles from all the recent code
churn...
------------------------------
Message: 1278
Date: Tue, 06 Oct 2009 10:11:06 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Ignore killed messages in U screen
Message-ID: <1254849015-sup-5884@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Carl Worth's message of 2009-10-01:
> It seems a simple, little thing. But I'm all in favor of non-violent
> metaphors in the interfaces of programs I use.
I will accept a patch that renames this and adds "M" as an additional
command.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1279
Date: Tue, 06 Oct 2009 10:16:20 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Add new :crypto_default configuration
option.
Message-ID: <1254849104-sup-6471@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Carl Worth's message of 2009-10-01:
> What makes a hook preferable over a configuration option?
I would like to support everyone's crazy desires, and a hook is worth a
thousand configuration options.
In this case, I'm sure it's only a matter of time before someone wants
to automatically determine the crypto setting based on the recipient, or
based on the message body. A hook would allow that.
> 2. Hooks are not supported forever, in which case users may find that
> things just start working when upgrading.
I am fine with this. Users be damned! (Or at least, required to read the
changelog.)
> Neither of those seem options look nice to me, and both seem easy to
> avoid with configuration options.
How so? Configuration options can change just as easily.
> If the plan is to go with (1) I'm concerned that I don't see sup
> shipping documentation for the current possible hooks. (This applies
> to configuration options too though. I think the maintainer should
> reject patches that add either without also adding documentation to
> the standard list.[*])
sup -l is supposed to produce all the hook documentation you'd need,
assuming a reasonable knowledge of Ruby.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1280
Date: Tue, 06 Oct 2009 10:30:09 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] On making inbox-mode and search-results-mode
more similar
Message-ID: <1254850185-sup-1817@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Carl Worth's message of 2009-08-26:
> This is just a copy of SearchResultsMode's refine_search command. A
> much cleaner, but more involved, approach would be to rework InboxMode
> to derive from SearchResultsMode in the first place.
Branch refine-inbox-mode, merged into next. Sorry for the long delay.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1281
Date: Tue, 06 Oct 2009 22:35:46 +0200
From: Christopher Bertels <mailinglist@flasht.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] i18n?
Message-ID: <1254861112-sup-590@thinkpad-ubuntu>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Di Okt 06 17:38:39 +0200 2009:
> This looks great. A couple comments:
Cool, good to know you like it!
> 1. I would prefer that uppercase substitution symbols made lowercase.
> The uppercase seems weird and un-Rubyish to me.
Ok, sounds good. I thought making them uppercase to let them be more
distict from the rest of the string but since we surround them by #{}
as in Ruby, you're making a good point here. I'll change that.
> 2. I think it would be nice to have a simple module along the lines of:
>
> module M17n
> def m s, o={}; I18n[m, o] end
> end
>
> and to have that be the primary entry point when you want a translated
> string. Then classes can include that module if they want m17n support,
> and instead of writing
>
> I18n["text", { :var => value }]
>
> you can have
>
> m("text", :var => value)
>
> which is a little easier to read, IMO.
Same here. Think this is nicer, too.
> 3. Should we call it m17n instead of i18n? I think that might be a
> little more accurate. Perhaps too nitpicky. What do you think?
I couldn't care less about the name - but I guess m17n fits better,
since it's just multilingualization. :)
> 4. A finishing touch would be to have sup-config ask the user what
> language they are interested in.
Alright, cool. I'll add that as well, once I have the rest changed & working.
Cheers,
Christopher.
--
================================
Christopher Bertels
http://www.adztec-independent.de
GPG Key ID: 0x2345b203
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091006/d19a9780/attachment-0001.bin>
------------------------------
Message: 1282
Date: Tue, 06 Oct 2009 23:56:19 +0200
From: Christopher Bertels <mailinglist@flasht.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] i18n?
Message-ID: <1254866136-sup-6974@thinkpad-ubuntu>
Content-Type: text/plain; charset=UTF-8
OK, I've changed it as mentioned.
See my previously mentioned gitorious branch.
Cheers,
Christopher.
--
================================
Christopher Bertels
http://www.adztec-independent.de
GPG Key ID: 0x2345b203
------------------------------
Message: 1283
Date: Tue, 06 Oct 2009 18:44:09 -0400
From: "Edward Z. Yang" <ezyang@MIT.EDU>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Bugfix for custom-search
Message-ID: <1254869038-sup-9250@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from Edward Z. Yang's message of Thu Oct 01 13:38:27 -0400 2009:
> I think there's a slight bug in the custom-search implementation.
Any comments?
Cheers,
Edward
------------------------------
Message: 1284
Date: Tue, 6 Oct 2009 18:33:03 -0400
From: Dan Falcone <danfalcone@gmail.com>
To: sup-talk@rubyforge.org
Subject: [sup-talk] curses exception
Message-ID:
<ed5557340910061533w7854510tabe9bb2fc864db09@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hello sup-talk,
I'm trying to get sup running on my work machine, which is unfortunately a
windows box. I have cygwin installed, along with the cygwin packages for
ruby and ncurses. Here's the contents of ~/.sup/exception-log.txt:
--- ArgumentError from thread: main
couldn't initialize curses color pair 4, -1 (key 1)
/usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/colormap.rb:133:in `color_for'
/usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/colormap.rb:209:in `send'
/usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/colormap.rb:209:in
`method_missing'
/usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/buffer.rb:116:in `write'
/usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/modes/scroll-mode.rb:51:in
`draw'
/usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/modes/scroll-mode.rb:49:in
`each'
/usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/modes/scroll-mode.rb:49:in
`draw'
/usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/modes/line-cursor-mode.rb:37:in
`dra
w'
/usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/buffer.rb:106:in `draw'
/usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/buffer.rb:327:in `draw_screen'
/usr/lib/ruby/gems/1.8/gems/sup-0.9/bin/sup:183
/usr/bin/sup:19:in `load'
/usr/bin/sup:19
Thanks!
Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091006/044a0301/attachment-0001.html>
------------------------------
Message: 1285
Date: Tue, 6 Oct 2009 19:45:47 -0400
From: Dan Falcone <danfalcone@gmail.com>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] curses exception
Message-ID:
<ed5557340910061645o48ffa653l70c434ccbdc3b8fa@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Resending as a list member...
On Tue, Oct 6, 2009 at 6:33 PM, Dan Falcone <danfalcone@gmail.com> wrote:
> Hello sup-talk,
>
> I'm trying to get sup running on my work machine, which is unfortunately a
> windows box. I have cygwin installed, along with the cygwin packages for
> ruby and ncurses. Here's the contents of ~/.sup/exception-log.txt:
>
> --- ArgumentError from thread: main
> couldn't initialize curses color pair 4, -1 (key 1)
> /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/colormap.rb:133:in `color_for'
> /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/colormap.rb:209:in `send'
> /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/colormap.rb:209:in
> `method_missing'
> /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/buffer.rb:116:in `write'
> /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/modes/scroll-mode.rb:51:in
> `draw'
> /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/modes/scroll-mode.rb:49:in
> `each'
> /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/modes/scroll-mode.rb:49:in
> `draw'
> /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/modes/line-cursor-mode.rb:37:in
> `dra
> w'
> /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/buffer.rb:106:in `draw'
> /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/buffer.rb:327:in `draw_screen'
> /usr/lib/ruby/gems/1.8/gems/sup-0.9/bin/sup:183
> /usr/bin/sup:19:in `load'
> /usr/bin/sup:19
>
>
> Thanks!
> Dan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091006/ad797fc6/attachment-0001.html>
------------------------------
Message: 1286
Date: Wed, 07 Oct 2009 02:44:34 -0400
From: Rich Lane <rlane@club.cc.cmu.edu>
To: Ben Gamari <bgamari.foss@gmail.com>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash while in thread-view-mode
Message-ID: <1254896214-sup-5969@zyrg.net>
Content-Type: text/plain; charset=UTF-8
Excerpts from Ben Gamari's message of Tue Oct 06 12:15:46 -0400 2009:
> Excerpts from Ben Gamari's message of Tue Oct 06 11:53:18 -0400 2009:
> > Well, it seems like whatever caused the crash earlier did something to
> > my index. Now any attempt to open a thread-index-mode of my LKML label
> > (which I was viewing in the earlier crash) causes the client to
> > immediately crash.
> >
>
> Hmm, it seems like the problem is spreading. I now come to find out that
> another label triggers this same crash (although I guess it's possible
> that the intersection of the two labels is non-nil). I tried running a
> sup-sync -oc on the relevant sources to no avail. I really don't have
> time to devote to debugging this at the moment so it looks like I might
> need to take another hiatus from sup. Just as I was starting to get used
> to it... sigh. Anyways, if anyone has any ideas for improving things,
> let me know. Thanks!
I've been seeing this crash for a long time. I think it's a race between
the poll thread / load-more-threads thread and the rest of the UI in the
main thread. Basically any operation on a thread object in
ThreadIndexMode needs to be protected against ThreadSet#add_message (and
probably other ThreadSet methods) because add_message can remove
containers from the thread tree, leaving you with an empty thread whose
"date" method returns nil.
You could try running sup with the -n flag to disable threading. The
major downside is that you have to hit P to poll manually.
I look forward to having a sup-server - I plan on writing a little
android client in Scala using actors. Almost no mutable state and
absolutely no ncurses.
------------------------------
Message: 1287
Date: Wed, 7 Oct 2009 10:48:56 +0200
From: Guillaume Quintard <guillaume.quintard@gmail.com>
To: Rich Lane <rlane@club.cc.cmu.edu>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash while in thread-view-mode
Message-ID:
<1e5fdab70910070148s31a8a371u81182a13e72bea4c@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Wed, Oct 7, 2009 at 8:44 AM, Rich Lane <rlane@club.cc.cmu.edu> wrote:
> You could try running sup with the -n flag to disable threading. The
> major downside is that you have to hit P to poll manually.
That "solves" the problem for me.
--
Guillaume
------------------------------
Message: 1288
Date: Wed, 7 Oct 2009 11:07:47 +0200
From: Guillaume Quintard <guillaume.quintard@gmail.com>
To: Rich Lane <rlane@club.cc.cmu.edu>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash while in thread-view-mode
Message-ID:
<1e5fdab70910070207q3aada8d7y2e2482e0dbbe8bd2@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Wed, Oct 7, 2009 at 10:48 AM, Guillaume Quintard
<guillaume.quintard@gmail.com> wrote:
> That "solves" the problem for me.
Scratch that, I just relaunched sup, and I still get the wrong id
called on nil error.
--
Guillaume
------------------------------
Message: 1289
Date: Wed, 07 Oct 2009 12:52:34 +0200
From: Gregor Hoffleit <gregor@hoffleit.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] [PATCH] Attachment filenames: RFC2184 and
extension guessing
Message-ID: <1254912361-sup-5340@sam.mediasupervision.de>
Content-Type: text/plain; charset="utf-8"
I noticed sup has trouble handling attachments sent by Roundcube
webmail. Somehow, those mails use an alternative encoding of filenames,
specified in RFC2184:
Content-Transfer-Encoding: base64
Content-Type: image/jpeg;
name*="UTF-8''20090912-i004232-gr000.jpg";
Content-Disposition: attachment;
filename*="UTF-8''20090912-i004232-gr000.jpg";
Bugs:
1. Sup fails to detect these filenames.
2. When trying to save these attachements, the filenames generated by
sup have a trailing semicolon.
The attached patch is a quick and dirty fix for these specific problems.
There's probably a better way to implement this.
Regards,
Gregor Hoffleit
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rfc2184.diff
Type: application/octet-stream
Size: 954 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091007/636afab0/attachment-0001.obj>
------------------------------
Message: 1290
Date: Wed, 07 Oct 2009 18:42:09 -0400
From: Ben Gamari <bgamari.foss@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Fwd: Re: Crash while in thread-view-mode
Message-ID: <1254955312-sup-7085@ben-laptop>
Content-Type: text/plain; charset=UTF-8
Excerpts from Guillaume Quintard's message of Wed Oct 07 04:48:56 -0400 2009:
> On Wed, Oct 7, 2009 at 8:44 AM, Rich Lane <rlane@club.cc.cmu.edu> wrote:
> > You could try running sup with the -n flag to disable threading. The
> > major downside is that you have to hit P to poll manually.
>
> That "solves" the problem for me.
>
After going through the process of rebuilding my index (again), things
seem to be more stable (for now). I understand that designing software around a
contingency like this might not be the best practice, but the frequency
with which I've needed to rebuild really does make me think that ruby
isn't the best language for the indexer.
This is easily the fifth time I've needed to rebuild and each time it
has taken over 30 minutes for 1.5 GB of mail. That's substantially less than
1MB/second for what should be an I/O bound operation. Ouch. It'll be
really interesting to see how Carl's work comes out.
- Ben
------------------------------
Message: 1291
Date: Wed, 07 Oct 2009 18:46:39 -0400
From: Ben Gamari <bgamari.foss@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash while in thread-view-mode
Message-ID: <1254955351-sup-5944@ben-laptop>
Content-Type: text/plain; charset=UTF-8
Excerpts from Ben Gamari's message of Wed Oct 07 15:56:43 -0400 2009:
> After going through the process of rebuilding my index (again), things
> seem to be more stable (for now).
Well, this was true for a while. Unfortunately, it seems that my LKML
label is yet again crashing sup. The exception is very similar to that
which I experienced prior to rebuilding. It's quite reproducible, always
crashing after loading a few hundred messages or so. There must be a
better way to deal with these invalid ids than crashing. Is there any
reason this needs to be a show-stopping event? Thanks,
- Ben
--- RuntimeError from thread: load threads for thread-index-mode
wrong id called on nil
/opt/exp/sup/lib/sup.rb:17:in `id'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `update'
/opt/exp/sup/lib/sup/hook.rb:121:in `sort_by'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `each'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `sort_by'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `update'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:223:in `synchronize'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:223:in `update'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:628:in `__unprotected_load_n_threads'
/opt/exp/sup/lib/sup/thread.rb:334:in `load_n_threads'
/opt/exp/sup/lib/sup/xapian_index.rb:117:in `each_id_by_date'
/opt/exp/sup/lib/sup/xapian_index.rb:110:in `each_id'
/opt/exp/sup/lib/sup/xapian_index.rb:110:in `each'
/opt/exp/sup/lib/sup/xapian_index.rb:110:in `each_id'
/opt/exp/sup/lib/sup/xapian_index.rb:117:in `each_id_by_date'
/opt/exp/sup/lib/sup/thread.rb:328:in `load_n_threads'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:625:in `__unprotected_load_n_threads'
(eval):12:in `load_n_threads'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:609:in `load_n_threads_background'
/opt/exp/sup/lib/sup.rb:77:in `reporting_thread'
/opt/exp/sup/lib/sup.rb:75:in `initialize'
/opt/exp/sup/lib/sup.rb:75:in `new'
/opt/exp/sup/lib/sup.rb:75:in `reporting_thread'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads'
(eval):12:in `load_threads'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:81:in `initialize'
/opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:22:in `call'
/opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:22:in `initialize'
/opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:22:in `each'
/opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:22:in `initialize'
/opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:19:in `new'
/opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:19:in `initialize'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:54:in `initialize'
/opt/exp/sup/lib/sup/modes/label-search-results-mode.rb:9:in `initialize'
/opt/exp/sup/lib/sup/modes/label-search-results-mode.rb:32:in `new'
/opt/exp/sup/lib/sup/modes/label-search-results-mode.rb:32:in `spawn_nicely'
/opt/exp/sup/lib/sup/buffer.rb:350:in `spawn_unless_exists'
/opt/exp/sup/lib/sup/util.rb:520:in `send'
/opt/exp/sup/lib/sup/util.rb:520:in `method_missing'
/opt/exp/sup/lib/sup/modes/label-search-results-mode.rb:32:in `spawn_nicely'
/opt/exp/sup/lib/sup/modes/label-list-mode.rb:103:in `select_label'
/opt/exp/sup/lib/sup/mode.rb:51:in `send'
/opt/exp/sup/lib/sup/mode.rb:51:in `handle_input'
/opt/exp/sup/lib/sup/buffer.rb:267:in `handle_input'
/usr/bin/sup:239
------------------------------
Message: 1292
Date: Thu, 08 Oct 2009 09:05:47 +0200
From: Christian Dietrich <stettberger@dokucode.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Feature Request: Collecting Lines in Index
Mode
Message-ID: <1254985425-sup-2303@peer.zerties.org>
Content-Type: text/plain; charset="utf-8"
Excerpts from Christian Dietrich's message of Fr Okt 02 22:48:24 +0200 2009:
> Thank you, that helped a much. I implemented the feature, it is
> available at git://github.com/stettberger/sup-mail.git
> branch time_marks, it is one commit ahead of next. It is enabled
> with setting the config option ":time_markers_in_index_mode: true"
> At runtime it can be toggled via '%' (just randomly choosen by me)
Ok now i did a little bit of reworking the code (don't make it sup
crash :-) and added a little bit color). The is now
:time_marker_color. I attached a screenshot of the time_marks.
greetz didi
--
No documentation is better than bad documentation
-- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sup-time-mark.png
Type: image/png
Size: 38362 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091008/89c94173/attachment-0001.png>
------------------------------
Message: 1293
Date: Thu, 08 Oct 2009 14:31:24 +0200
From: Christopher Bertels <mailinglist@flasht.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Feature Request: Collecting Lines in Index
Mode
Message-ID: <1255005056-sup-7120@thinkpad-ubuntu>
Content-Type: text/plain; charset="utf-8"
Excerpts from Christian Dietrich's message of Do Okt 08 09:05:47 +0200 2009:
> Ok now i did a little bit of reworking the code (don't make it sup
> crash :-) and added a little bit color). The is now
> :time_marker_color. I attached a screenshot of the time_marks.
Looks really cool, I'll give it a try :)
--
================================
Christopher Bertels
http://www.adztec-independent.de
GPG Key ID: 0x2345b203
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091008/91e8eba7/attachment-0001.bin>
------------------------------
Message: 1294
Date: Thu, 08 Oct 2009 14:44:32 +0200
From: Christopher Bertels <mailinglist@flasht.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Feature Request: Collecting Lines in Index
Mode
Message-ID: <1255005777-sup-7020@thinkpad-ubuntu>
Content-Type: text/plain; charset="utf-8"
Ok, I like it so far. But what would really rock (IMO) would be the
possibility to collapse all messages, that are from yesterday or 2
weeks ago etc.
What do you think?
--
================================
Christopher Bertels
http://www.adztec-independent.de
GPG Key ID: 0x2345b203
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091008/88002eca/attachment-0001.bin>
------------------------------
Message: 1295
Date: Thu, 08 Oct 2009 20:28:59 +0200
From: Christian Dietrich <stettberger@dokucode.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Feature Request: Collecting Lines in Index
Mode
Message-ID: <1255026503-sup-3624@peer.zerties.org>
Content-Type: text/plain; charset=UTF-8
Excerpts from Christopher Bertels's message of Do Okt 08 14:44:32 +0200 2009:
> Ok, I like it so far. But what would really rock (IMO) would be the
> possibility to collapse all messages, that are from yesterday or 2
> weeks ago etc.
> What do you think?
Yeah thats cool, i implemented it, just type <Enter> on a Time Mark
(after pulling)
greetz didi
--
No documentation is better than bad documentation
-- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt.
------------------------------
Message: 1296
Date: Thu, 08 Oct 2009 21:24:21 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Ruby 1.9 status?
Message-ID: <1255029826-sup-8182@peray>
Content-Type: text/plain; charset=UTF-8
Hi all,
I would like to know what is the sup status w.r.t ruby 1.9?
--
Nicolas Pouillard
http://nicolaspouillard.fr
------------------------------
Message: 1297
Date: Thu, 08 Oct 2009 21:33:44 +0200
From: Christopher Bertels <mailinglist@flasht.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Feature Request: Collecting Lines in Index
Mode
Message-ID: <1255030392-sup-1135@thinkpad-ubuntu>
Content-Type: text/plain; charset="utf-8"
Excerpts from Christian Dietrich's message of Do Okt 08 20:28:59 +0200 2009:
> Yeah thats cool, i implemented it, just type <Enter> on a Time Mark
> (after pulling)
Indeed, very nice. Thanks :)
I'd like to see this in sup's mainline, btw :)
--
================================
Christopher Bertels
http://www.adztec-independent.de
GPG Key ID: 0x2345b203
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 969 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091008/1e566f11/attachment-0001.bin>
------------------------------
Message: 1298
Date: Thu, 08 Oct 2009 21:44:30 +0200
From: Gaute Hope <eg@gaute.vetsj.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Feature Request: Collecting Lines in Index
Mode
Message-ID: <1255031039-sup-4070@qwerzila>
Content-Type: text/plain; charset="utf-8"
Excerpts from Christopher Bertels's message of to. okt. 08 21:33:44 +0200 2009:
> Excerpts from Christian Dietrich's message of Do Okt 08 20:28:59 +0200 2009:
> > Yeah thats cool, i implemented it, just type <Enter> on a Time Mark
> > (after pulling)
>
> Indeed, very nice. Thanks :)
> I'd like to see this in sup's mainline, btw :)
+1 ! Looks great!
- gaute
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091008/e0c720ab/attachment-0001.bin>
------------------------------
Message: 1299
Date: Thu, 08 Oct 2009 22:04:10 +0200
From: Beno?t PIERRE <benoit.pierre@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Feature Request: Collecting Lines in Index
Mode
Message-ID: <1255032019-sup-3406@localdomain>
Content-Type: text/plain; charset="utf-8"
Excerpts from Christian Dietrich's message of Thu Oct 08 20:28:59 +0200 2009:
> Excerpts from Christopher Bertels's message of Do Okt 08 14:44:32 +0200 2009:
> > Ok, I like it so far. But what would really rock (IMO) would be the
> > possibility to collapse all messages, that are from yesterday or 2
> > weeks ago etc.
> > What do you think?
>
> Yeah thats cool, i implemented it, just type <Enter> on a Time Mark
> (after pulling)
This is great, I love it. Attached 2 small patches:
- fix a warning (space before opening parenthesis in function call)
- fix a bug with thread selection when time marks are not visible
Cheers,
--
A: Because it destroys the flow of conversation.
Q: Why is top posting dumb?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-warning-fix.patch
Type: application/octet-stream
Size: 770 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091008/1336c51c/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-fix-selection-when-time-marks-are-disabled.patch
Type: application/octet-stream
Size: 1114 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091008/1336c51c/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 243 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091008/1336c51c/attachment-0001.bin>
------------------------------
Message: 1300
Date: Thu, 08 Oct 2009 22:12:31 +0200
From: Gaute Hope <eg@gaute.vetsj.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Feature Request: Collecting Lines in Index
Mode
Message-ID: <1255032615-sup-8961@qwerzila>
Content-Type: text/plain; charset="utf-8"
Excerpts from Gaute Hope's message of to. okt. 08 21:44:30 +0200 2009:
> Excerpts from Christopher Bertels's message of to. okt. 08 21:33:44 +0200 2009:
> > Excerpts from Christian Dietrich's message of Do Okt 08 20:28:59 +0200 2009:
> > > Yeah thats cool, i implemented it, just type <Enter> on a Time Mark
> > > (after pulling)
Would be nice if the '1' keybinding would select the first message and
not the first line. Possibly another binding to collapse the current day when
a message is selected (maybe h or E to keep things similar to the
message view)?
- gaute
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091008/814823ee/attachment-0001.bin>
------------------------------
Message: 1301
Date: Thu, 08 Oct 2009 22:26:12 +0200
From: Beno?t PIERRE <benoit.pierre@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Feature Request: Collecting Lines in Index
Mode
Message-ID: <1255033079-sup-8556@localdomain>
Content-Type: text/plain; charset="utf-8"
Excerpts from Gaute Hope's message of Thu Oct 08 22:12:31 +0200 2009:
> Excerpts from Gaute Hope's message of to. okt. 08 21:44:30 +0200 2009:
> > Excerpts from Christopher Bertels's message of to. okt. 08 21:33:44 +0200 2009:
> > > Excerpts from Christian Dietrich's message of Do Okt 08 20:28:59 +0200 2009:
> > > > Yeah thats cool, i implemented it, just type <Enter> on a Time Mark
> > > > (after pulling)
>
> Would be nice if the '1' keybinding would select the first message and
> not the first line. Possibly another binding to collapse the current day when
> a message is selected (maybe h or E to keep things similar to the
> message view)?
And 't' should select the next thread, not the next line. 'a' and 'A'
too, in fact a time tag should only be selectable manually, using
Up/Down or 'j'/'k'. Or never if collapsing/expending is possible with a
mapping (my vote goes to 'E').
Cheers,
--
A: Because it destroys the flow of conversation.
Q: Why is top posting dumb?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091008/ab965140/attachment-0001.bin>
------------------------------
Message: 1302
Date: Thu, 08 Oct 2009 22:50:07 +0200
From: Christian Dietrich <stettberger@dokucode.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Feature Request: Collecting Lines in Index
Mode
Message-ID: <1255034958-sup-5628@peer.zerties.org>
Content-Type: text/plain; charset=UTF-8
> Would be nice if the '1' keybinding would select the first message and
> not the first line. Possibly another binding to collapse the current day when
> a message is selected (maybe h or E to keep things similar to the
> message view)?
Yeah, implemented that, and the other two patches in the branch,
like the idea.
greetz didi
--
No documentation is better than bad documentation
-- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt.
------------------------------
Message: 1303
Date: Fri, 09 Oct 2009 09:19:30 +0200
From: Christian Dietrich <stettberger@dokucode.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Feature Request: Collecting Lines in Index
Mode
Message-ID: <1255072730-sup-9414@peer.zerties.org>
Content-Type: text/plain; charset=UTF-8
> And 't' should select the next thread, not the next line. 'a' and 'A'
> too, in fact a time tag should only be selectable manually, using
> Up/Down or 'j'/'k'. Or never if collapsing/expending is possible with a
> mapping (my vote goes to 'E').
Jep thats right, i fixed that. Please pull.
greetz didi
--
No documentation is better than bad documentation
-- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt.
------------------------------
Message: 1304
Date: Fri, 09 Oct 2009 09:31:38 +0200
From: Gaute Hope <eg@gaute.vetsj.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Feature Request: Collecting Lines in Index
Mode
Message-ID: <1255073126-sup-6984@qwerzila>
Content-Type: text/plain; charset="utf-8"
Excerpts from Christian Dietrich's message of to. okt. 08 22:50:07 +0200 2009:
> > Would be nice if the '1' keybinding would select the first message and
> > not the first line. Possibly another binding to collapse the current day when
> > a message is selected (maybe h or E to keep things similar to the
> > message view)?
>
> Yeah, implemented that, and the other two patches in the branch,
> like the idea.
This doesn't work for me: '1'/'^' just makes the view scroll one down; hiding the
Today marker (same as hitting 'J' one time). 0 works like expected.
a/A/&/d/S/t and E seems to be working alright.
- gaute
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091009/0258c39f/attachment-0001.bin>
------------------------------
Message: 1305
Date: Fri, 09 Oct 2009 09:44:02 +0200
From: Christian Dietrich <stettberger@dokucode.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Feature Request: Collecting Lines in Index
Mode
Message-ID: <1255074206-sup-7503@peer.zerties.org>
Content-Type: text/plain; charset=UTF-8
Excerpts from Gaute Hope's message of Fr Okt 09 09:31:38 +0200 2009:
> This doesn't work for me: '1'/'^' just makes the view scroll one down; hiding
> the
> Today marker (same as hitting 'J' one time). 0 works like expected.
>
> a/A/&/d/S/t and E seems to be working alright.
Yeah ok, that should be fixed now. (I didn't even now about this
keystroke before...)
greetz didi
--
No documentation is better than bad documentation
-- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt.
------------------------------
Message: 1306
Date: Fri, 09 Oct 2009 11:45:13 +0200
From: Gaute Hope <eg@gaute.vetsj.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Feature Request: Collecting Lines in Index
Mode
Message-ID: <1255081131-sup-7915@qwerzila>
Content-Type: text/plain; charset="utf-8"
Excerpts from Christian Dietrich's message of fr. okt. 09 09:44:02 +0200 2009:
> Excerpts from Gaute Hope's message of Fr Okt 09 09:31:38 +0200 2009:
> > This doesn't work for me: '1'/'^' just makes the view scroll one down; hiding
> > the
> > Today marker (same as hitting 'J' one time). 0 works like expected.
> >
> > a/A/&/d/S/t and E seems to be working alright.
>
> Yeah ok, that should be fixed now. (I didn't even now about this
> keystroke before...)
Just discovered a weird bug.. when this thread got polled and updated
the message count, in this case (13), got attached to the thread
beneath, which only had one message, and appeared where it shouldn't be
anything.. the top thread didn't have any post count. It seemed to only
have affected the top two messages, as the count on the third one seemed
normal.
Not entierly sure what caused it since I can't really reproduce it by
sending myself emails.. if it happens again ill post screenshot.
Im using time_marker branch rebased ontop of origin/next.
- gaute
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091009/8bac691b/attachment-0001.bin>
------------------------------
Message: 1307
Date: Fri, 09 Oct 2009 12:12:21 +0200
From: Gaute Hope <eg@gaute.vetsj.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Feature Request: Collecting Lines in Index
Mode
Message-ID: <1255083021-sup-226@qwerzila>
Content-Type: text/plain; charset="utf-8"
Excerpts from Gaute Hope's message of fr. okt. 09 11:45:13 +0200 2009:
> Not entierly sure what caused it since I can't really reproduce it by
> sending myself emails.. if it happens again ill post screenshot.
>
> Im using time_marker branch rebased ontop of origin/next.
Ok.. now the top message count just got copied down to the line
beneath (which should be empty). Sup had just been running for a while,
no new messages, didn't happen on first pool..
- gaute
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2009-10-09-120801_634x755_scrot.png
Type: image/png
Size: 29135 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091009/58f1eb31/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091009/58f1eb31/attachment-0001.bin>
------------------------------
Message: 1308
Date: Fri, 09 Oct 2009 12:39:27 +0200
From: Christian Dietrich <stettberger@dokucode.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Feature Request: Collecting Lines in Index
Mode
Message-ID: <1255084730-sup-671@peer.zerties.org>
Content-Type: text/plain; charset=UTF-8
Excerpts from Gaute Hope's message of Fr Okt 09 12:12:21 +0200 2009:
> Excerpts from Gaute Hope's message of fr. okt. 09 11:45:13 +0200 2009:
> > Not entierly sure what caused it since I can't really reproduce it by
> > sending myself emails.. if it happens again ill post screenshot.
> >
> > Im using time_marker branch rebased ontop of origin/next.
>
> Ok.. now the top message count just got copied down to the line
> beneath (which should be empty). Sup had just been running for a while,
> no new messages, didn't happen on first pool..
I have no idea whats causing this, seems like the data of two
threads is mixed together?
greetz didi
--
No documentation is better than bad documentation
-- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt.
------------------------------
Message: 1309
Date: Fri, 09 Oct 2009 13:00:19 +0200
From: Gaute Hope <eg@gaute.vetsj.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Feature Request: Collecting Lines in Index
Mode
Message-ID: <1255085867-sup-8410@qwerzila>
Content-Type: text/plain; charset="utf-8"
Excerpts from Christian Dietrich's message of fr. okt. 09 12:39:27 +0200 2009:
> Excerpts from Gaute Hope's message of Fr Okt 09 12:12:21 +0200 2009:
> > Excerpts from Gaute Hope's message of fr. okt. 09 11:45:13 +0200 2009:
> > > Not entierly sure what caused it since I can't really reproduce it by
> > > sending myself emails.. if it happens again ill post screenshot.
> > >
> > > Im using time_marker branch rebased ontop of origin/next.
> >
> > Ok.. now the top message count just got copied down to the line
> > beneath (which should be empty). Sup had just been running for a while,
> > no new messages, didn't happen on first pool..
>
> I have no idea whats causing this, seems like the data of two
> threads is mixed together?
Or the thread count isn't aware of the Today mark and still thinks line
2 is thread 2? Don't really know anything about the implementation.
When it happens it doesn't dissapear before I do a M or there is a pull
that redraws the screen.. just pressing Ctrl+L or opening/closing a
thread doesn't remove it.
As said earlier it only seems to affect the top two threads.
- gaute
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091009/de9efe70/attachment-0001.bin>
------------------------------
Message: 1310
Date: Sat, 10 Oct 2009 10:21:33 +0300
From: Tero Tilus <tero@tilus.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] [PATCH] moved deriving the cmd for bouncing to
Account and fixed a bug in it
Message-ID: <1255159160-sup-8754@tilus.net>
Content-Type: text/plain; charset=UTF-8
The default sendmail command used for bouncing mail was derived from
Account#sendmail in ThreadViewMode#bounce. Moved it to
Account#bounce_sendmail. Part of work towards more DRY mail bouncing
within mark-as-spam hook. The code also had a bug, "$1" (instead of $1
or "#{$1}"). Fixed it.
Signed-off-by: Tero Tilus <tero@tilus.net>
---
lib/sup/account.rb | 11 +++++++++++
lib/sup/modes/thread-view-mode.rb | 7 +------
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/lib/sup/account.rb b/lib/sup/account.rb
index eed2794..bf8a8a0 100644
--- a/lib/sup/account.rb
+++ b/lib/sup/account.rb
@@ -10,6 +10,17 @@ class Account < Person
@sendmail = h[:sendmail]
@signature = h[:signature]
end
+
+ # Default sendmail command for bouncing mail,
+ # deduced from #sendmail
+ def bounce_sendmail
+ sendmail.sub(/\s(\-(ti|it|t))\b/) do |match|
+ case $1
+ when '-t' then ''
+ else ' -i'
+ end
+ end
+ end
end
class AccountManager
diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb
index 81197c2..e7f4a4f 100644
--- a/lib/sup/modes/thread-view-mode.rb
+++ b/lib/sup/modes/thread-view-mode.rb
@@ -202,12 +202,7 @@ EOS
m = @message_lines[curpos] or return
to = BufferManager.ask_for_contacts(:people, "Bounce To: ") or return
- defcmd = AccountManager.default_account.sendmail.sub(/\s(\-(ti|it|t))\b/) do |match|
- case "$1"
- when '-t' then ''
- else ' -i'
- end
- end
+ defcmd = AccountManager.default_account.bounce_sendmail
cmd = case (hookcmd = HookManager.run "bounce-command", :from => m.from, :to => to)
when nil, /^$/ then defcmd
--
1.5.6.5
--
Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
------------------------------
Message: 1311
Date: Sat, 10 Oct 2009 14:01:14 +0200
From: Sven Schober <sven.schober@uni-ulm.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] pinentry-curses messes up sup
Message-ID: <1255175624-sup-8207@hysbald>
Content-Type: text/plain; charset="utf-8"
Hi Suppers!
First of all, let me say i really enjoy using sup :) Thanks for the
great mua!
No to my problem: I'm experiencing the problem described by Nicolas
Pouillard, here [1]. After using pinentry-curses to enter my gpg
passphrase sup seems to be a little messed up, as the arrow keys
won't work any more, or at least, not as expected (pressing left has
horrendous consequences as its control sequence seems to be ^[[D,
which caused some major mail deletion for me *g*).
As that thread is rather old, i would like to now if there's been
some development on this? Are there any console alternatives to
pinentry-curses?
Keep up the good work!
Cheers,
Sven
[1]:<http://rubyforge.org/pipermail/sup-talk/2008-January/000959.html>
--
Sven Schober, sven.schober@uni-ulm.de |UNI ULM
http://www-vs.informatik.uni-ulm.de/dept/staff/schober/ |DISTRIBUTED
Room O27-346, Phone: +49-731-5024146 [+49-179-5060182] |SYSTEMS LAB
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091010/fa2d56e4/attachment-0001.bin>
------------------------------
Message: 1312
Date: Sat, 10 Oct 2009 16:41:29 +0200
From: Christopher Bertels <mailinglist@flasht.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] show labels of polled messages
Message-ID: <1255184817-sup-1561@thinkpad-ubuntu>
Content-Type: text/plain; charset="utf-8"
Hi,
I always thought it would be nice to see to which labels new polled
messages have been added. Usually, when I see new messages arrived,
most of them aren't in my inbox, since I archive the messages of most
of my sources (e.g. mailinglists like this one).
Then, I usually go and look at the labels-list-mode to see where new
messages got added. I've attached a patch that displays the labels of
newly polled messages at the bottom, next to the amount of total
messages added from polling. The patch is based on my i18n branch, but
it should be easy to rebase it on next or master.
What do you think of it?
Cheers,
Christopher.
--
================================
Christopher Bertels
http://www.adztec-independent.de
GPG Key ID: 0x2345b203
-------------- next part --------------
A non-text attachment was scrubbed...
Name: label_notification.patch
Type: application/octet-stream
Size: 3505 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091010/ee06edf8/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091010/ee06edf8/attachment-0001.bin>
------------------------------
Message: 1313
Date: Sat, 10 Oct 2009 16:56:46 -0400
From: Kevin Riggle <kevinr@free-dissociation.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Exception in thread-view-mode
Message-ID: <1255208137-sup-835@black-opal.mit.edu>
Content-Type: text/plain; charset=UTF-8
I ran a search, I hit enter to load a message, I changed my mind and 'x'ed out
before the message finished loading, and Sup crashed with:
--- NoMethodError from thread: load messages for thread-view-mode
undefined method `content_width' for nil:NilClass
./lib/sup/modes/thread-index-mode.rb:882:in `from_width'
./lib/sup/modes/thread-index-mode.rb:807:in `text_for_thread_at'
./lib/sup/hook.rb:122:in `each_with_index'
./lib/sup/modes/thread-index-mode.rb:806:in `each'
./lib/sup/modes/thread-index-mode.rb:806:in `each_with_index'
./lib/sup/modes/thread-index-mode.rb:806:in `text_for_thread_at'
./lib/sup/modes/thread-index-mode.rb:751:in `update_text_for_line'
./lib/sup/modes/thread-index-mode.rb:119:in `select'
./lib/sup.rb:77:in `reporting_thread'
./lib/sup.rb:75:in `initialize'
./lib/sup.rb:75:in `new'
./lib/sup.rb:75:in `reporting_thread'
./lib/sup/modes/thread-index-mode.rb:101:in `select'
./lib/sup/mode.rb:51:in `send'
./lib/sup/mode.rb:51:in `handle_input'
./lib/sup/buffer.rb:267:in `handle_input'
bin/sup:239
- Kevin
--
Kevin Riggle (kevinr@free-dissociation.com)
http://free-dissociation.com
------------------------------
Message: 1314
Date: Sun, 11 Oct 2009 13:25:33 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] pinentry-curses messes up sup
Message-ID: <1255292709-sup-2216@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Sven Schober's message of 2009-10-10:
> As that thread is rather old, i would like to now if there's been some
> development on this? Are there any console alternatives to
> pinentry-curses?
I think I've fixed this in git next. Please try that.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1315
Date: Sun, 11 Oct 2009 13:28:48 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Fwd: Re: Crash while in thread-view-mode
Message-ID: <1255292742-sup-3957@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Gamari's message of 2009-10-07:
> I understand that designing software around a contingency like this
> might not be the best practice, but the frequency with which I've
> needed to rebuild really does make me think that ruby isn't the best
> language for the indexer.
The indexer isn't in Ruby, it's written in C++ in the case of Xapian and
C in the case of Ferret.
> This is easily the fifth time I've needed to rebuild and each time it
> has taken over 30 minutes for 1.5 GB of mail. That's substantially
> less than 1MB/second for what should be an I/O bound operation. Ouch.
I think this isn't the indexer's fault so much as the mbox parsing,
which is Ruby.
I'm sorry you've had to rebuild the index so many times. The Xapian side
of things is very new, and I think you've had a run of bad luck. But I
am personally not motivated to improve index time performance, because
that's not a common event. At least, it shouldn't be.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1316
Date: Sun, 11 Oct 2009 13:30:08 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] curses exception
Message-ID: <1255292940-sup-5558@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Dan Falcone's message of 2009-10-06:
> I'm trying to get sup running on my work machine, which is unfortunately a
> windows box. I have cygwin installed, along with the cygwin packages for
> ruby and ncurses. Here's the contents of ~/.sup/exception-log.txt:
>
> --- ArgumentError from thread: main
> couldn't initialize curses color pair 4, -1 (key 1)
> /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/colormap.rb:133:in `color_for'
Weird. We've had other people get it working on Cygwin before, I
believe. Are you running this within Cygwin's rxvt?
What if you modify lib/sup/colormap.rb so that NUM_COLORS=15?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1317
Date: Sun, 11 Oct 2009 13:31:49 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash while scrolling
Message-ID: <1255293077-sup-9788@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Gamari's message of 2009-10-01:
> Is ferret even going to be supported after the Xapian backend
> stabilizes?
No, I'm going to drop it at some point. I barely have enough time or
energy for Sup's current set of problems as is. :)
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1318
Date: Sun, 11 Oct 2009 17:04:53 -0400
From: Ben Gamari <bgamari.foss@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Fwd: Re: Crash while in thread-view-mode
Message-ID: <1255294905-sup-8@ben-laptop>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Sun Oct 11 16:28:48 -0400 2009:
> Reformatted excerpts from Ben Gamari's message of 2009-10-07:
> > I understand that designing software around a contingency like this
> > might not be the best practice, but the frequency with which I've
> > needed to rebuild really does make me think that ruby isn't the best
> > language for the indexer.
>
> The indexer isn't in Ruby, it's written in C++ in the case of Xapian and
> C in the case of Ferret.
Sorry, I was referring to the mail indexer (i.e. message,
mbox/maildir parser), not the backend indexing engine (e.g. Xapian).
Should have been more specific.
>
> > This is easily the fifth time I've needed to rebuild and each time it
> > has taken over 30 minutes for 1.5 GB of mail. That's substantially
> > less than 1MB/second for what should be an I/O bound operation. Ouch.
>
> I think this isn't the indexer's fault so much as the mbox parsing,
> which is Ruby.
Exactly. This is where I think C++ is probably appropriate.
>
> I'm sorry you've had to rebuild the index so many times. The Xapian side
> of things is very new, and I think you've had a run of bad luck. But I
> am personally not motivated to improve index time performance, because
> that's not a common event. At least, it shouldn't be.
Completely understandable. I really don't have a right to complain. It
does work a large majority of the time, after all. Just figured I'd let
you know of problems as they happen. Thanks for the awesome client.
- Ben
------------------------------
Message: 1319
Date: Mon, 12 Oct 2009 09:11:35 +0200
From: Christian Dietrich <stettberger@dokucode.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Feature Request: Collecting Lines in Index
Mode
Message-ID: <1255331296-sup-5993@peer.zerties.org>
Content-Type: text/plain; charset=UTF-8
Excerpts from Gaute Hope's message of Fr Okt 09 13:00:19 +0200 2009:
> Or the thread count isn't aware of the Today mark and still thinks line
> 2 is thread 2? Don't really know anything about the implementation.
>
> When it happens it doesn't dissapear before I do a M or there is a pull
> that redraws the screen.. just pressing Ctrl+L or opening/closing a
> thread doesn't remove it.
>
> As said earlier it only seems to affect the top two threads.
Hi,
i also experienced now this Problem, but can't see were this problem
is located, because i don't touch the internal states of the
threads. There must be one @thread[curpos] left, which causes this
Problem.
greetz didi
--
No documentation is better than bad documentation
-- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt.
------------------------------
Message: 1320
Date: Mon, 12 Oct 2009 05:14:42 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Ruby 1.9 status?
Message-ID: <1255349584-sup-5924@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Nicolas Pouillard's message of 2009-10-08:
> I would like to know what is the sup status w.r.t ruby 1.9?
The code is syntactically ready for 1.9. There's a Ferret 1.9 gem as of
recently, which you can try. Someone wrote a blog post here:
http://trickyco.de/2009/09/24/installing-the-sup-mua-on-64bit-arch-linux
And made some patches, which I haven't had a chance to review yet.
At some point I tried Xapian with 1.9 and ran into some weird errors. If
you search the mailing list, you should find it.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1321
Date: Mon, 12 Oct 2009 05:48:50 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Allow thread index view to sort oldest
first
Message-ID: <1255350472-sup-5679@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Hi Carl & Keith,
Reformatted excerpts from Carl Worth's message of 2009-09-25:
> The below patches are a first cut at implementing this.
I've finally gotten a chance to look at this. It looks good so far. I
would like to merge this in in such a way that it doesn't change
behavior for anyone who doesn't want it.
So I definitely don't want the second patch which changes the default
order. The configuration boolean is fine. (And if you want to add a
question to sup-config, that's icing on the cake.)
I would also like to disable forcing the loading of all messages.
Personalyl, I follow the inbox 30,000 philosophy. The 'o' keybinding is
cool, but if I scroll down then suddenly the thread loading goes crazy.
For those who have inboxes that are small enough to load but bigger than
one screen (the "reverse inbox 50" crowd), I don't think that pressing
!! is too onerous.
> 1. When doing oldest-first searching, it wasn't obvious if it's even
> possible to query for only the N oldest messages (to lazily load
> new threads while navigating as sup currently does). So the patch
> currently loads all threads when in oldest-first mode.
It is possible in Ferret: remove the DESC in ferret_index.rb line 160.
It is also possible in Xapian, but we're building the Xapian index to
optimize newest-first access. (Of course that would also be possible to
change, but then we're talking about a total index rebuild.)
If you wanted to tweak that, the load-all-threads wouldn't be necessary.
Either way, I'm happy to merge the first patch with the "n = -1" thing
removed.
> 2. Currently sup uses the date of the newest message in a thread as
> the key for sorting that message. This is correct for newest-first
> sorting. But when doing the new oldest-first sorting, the patch
> really should be augmented to instead use the date of the oldest
> message in a thread that matches the current search criteria.
>
> We haven't looked yet into how hard this would be to fix. (And we'd
> of course be glad for any help or pointers.)
Pretty easy to change. In thread.rb, there's a date method which takes a
max; you can make it take a min instead.
The hard work for both of these things is wiring this option through.
Although $config is a global variable, I don't really want to use it
directly in e.g. thread.rb.
> PS. We're still total ruby newbies, so please point out any silly
> mistakes we're missing with respect to ruby idioms.
Everything looks good. The only slgihtly non-idiomatic thing is using
"if !x" instead of "unless x".
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1322
Date: Mon, 12 Oct 2009 06:30:21 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Add hooks to sort and format
label-list-mode display.
Message-ID: <1255354211-sup-1536@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Branch label-list-mode-hooks, merged into next. Thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1323
Date: Mon, 12 Oct 2009 06:31:21 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] don't downcase a nil content-type
Message-ID: <1255354267-sup-3594@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Applied directly to master. Thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1324
Date: Mon, 12 Oct 2009 06:42:10 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] labels-before-subject and ask_for_contacts
config knobs
Message-ID: <1255354888-sup-8991@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Tarko Tikan's message of 2009-10-03:
> ask_for_contacts is loading 10 contacts from index, imho this doesn't
> make a sane default (it's too low). I've always patched this to 500 on
> my end - yes, it takes a second or two to load that many contacts from
> index but this doesn't bug me as much as first looking up the person
> and then composing to him.
Yeah, this number should be increased. Unfortunately the time required
is tied to your index size and your machine, and 500 is way too slow for
me.
There are actually two numbers: the number of initial contacts, and the
number that gets added when you press "M". I've changed the first to (2
* # of screen rows) and the second to 100. Hopefully that's a little
more usable to you.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1325
Date: Mon, 12 Oct 2009 06:43:48 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] labels-before-subject and ask_for_contacts
config knobs
Message-ID: <1255354943-sup-8569@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Marcus Williams's message of 2009-10-04:
> If you search through the archives you should find a patch I submitted
> for an alternate view. The default alternate view I find very good on
> smaller devices and its configurable via a hook if you want anything
> more. Not sure if its going to get integrated into sup though (Any
> thoughts William? - I can resubmit if necessary)
I'm a little wary of starting down the slippery slope of a million
different screen configurations, but maybe it's ok to have a "small
screen mode". Is that what the alternate view is for?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1326
Date: Mon, 12 Oct 2009 06:46:44 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Handle added messages in
label-list-mode
Message-ID: <1255355098-sup-4003@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Bo Borgerson's message of 2009-10-04:
> Is there a way to label or delete threads without leaving the
> label-list-mode? There's already a refresh when switching back to the
> label-list-mode from elsewhere, I think, so any changes that are $aved
> should be reflected immediately when you get back.
That's a good point. Yeah, this is unnecessary until we make some major
interface redesigns.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1327
Date: Mon, 12 Oct 2009 06:51:31 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Bugfix for custom-search
Message-ID: <1255355369-sup-9880@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Edward Z. Yang's message of 2009-10-06:
> Any comments?
Sorry about the delay. Applied directly to master. I was sure I had done
this right, but somehow it was only reflected in next, not in master. Oh
well. Thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1328
Date: Mon, 12 Oct 2009 06:54:06 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] more inline GPG madness
Message-ID: <1255355627-sup-2988@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Michael Stapelberg's message of 2009-10-01:
> I will instead implement support for "correct" inline GPG.
I've reworked this code a bit in recent commits, so make sure you have
an up-to-date copy.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1329
Date: Mon, 12 Oct 2009 10:09:48 -0400
From: Dan Falcone <danfalcone@gmail.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] curses exception
Message-ID:
<ed5557340910120709u62e97e67id6580f0a8ee6ec64@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Normally I use puttycyg (http://code.google.com/p/puttycyg/), but I gave
rxvt and even the normal cmd.exe window a try. Same error in all three. I
also tried modifying NUM_COLORS to 15 (and other values... 1, 8, 16, 32) but
got the same error every time in each terminal emulator.
Honestly, it's probably an issue with my setup... is there a guide anywhere
on how to get sup running in cygwin? Maybe I'm missing a required package?
Thanks!
Dan
On Sun, Oct 11, 2009 at 4:30 PM, William Morgan <wmorgan-sup@masanjin.net>wrote:
> Reformatted excerpts from Dan Falcone's message of 2009-10-06:
> > I'm trying to get sup running on my work machine, which is unfortunately
> a
> > windows box. I have cygwin installed, along with the cygwin packages for
> > ruby and ncurses. Here's the contents of ~/.sup/exception-log.txt:
> >
> > --- ArgumentError from thread: main
> > couldn't initialize curses color pair 4, -1 (key 1)
> > /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/colormap.rb:133:in
> `color_for'
>
> Weird. We've had other people get it working on Cygwin before, I
> believe. Are you running this within Cygwin's rxvt?
>
> What if you modify lib/sup/colormap.rb so that NUM_COLORS=15?
> --
> William <wmorgan-sup@masanjin.net>
> _______________________________________________
> sup-talk mailing list
> sup-talk@rubyforge.org
> http://rubyforge.org/mailman/listinfo/sup-talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091012/cc3998ff/attachment-0001.html>
------------------------------
Message: 1330
Date: Mon, 12 Oct 2009 17:35:48 +0100
From: Marcus Williams <marcus-sup@bar-coded.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] labels-before-subject and ask_for_contacts
config knobs
Message-ID: <1255365030-sup-4877@bar-coded.net>
Content-Type: text/plain; charset="utf-8"
On 12.10.2009, William Morgan wrote:
> I'm a little wary of starting down the slippery slope of a million
> different screen configurations, but maybe it's ok to have a "small
> screen mode". Is that what the alternate view is for?
Thats certainly what I use it for. The default "alternative" is just
to strip authors/dates from the index view (see screenshot). A hook
allows you to do what you want with it (like remove the labels). Its
only toggleable via a keypress currently, but I find it useful on a
smaller screen.
If you're happy with it I might change the default alternative view to
not include labels (or maybe move them to the end of the subject)
before resubmission. My hooked version doesnt bother displaying the
labels at all.
Marcus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sup.jpg
Type: image/jpeg
Size: 187012 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091012/bef721fc/attachment-0001.jpg>
------------------------------
Message: 1331
Date: Mon, 12 Oct 2009 21:23:48 +0200
From: Christian Dietrich <stettberger@dokucode.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Feature Request: Collecting Lines in Index
Mode
Message-ID: <1255375298-sup-2024@peer.zerties.org>
Content-Type: text/plain; charset=UTF-8
Excerpts from Christian Dietrich's message of Mo Okt 12 09:11:35 +0200 2009:
> Excerpts from Gaute Hope's message of Fr Okt 09 13:00:19 +0200 2009:
> > Or the thread count isn't aware of the Today mark and still thinks line
> > 2 is thread 2? Don't really know anything about the implementation.
> >
> > When it happens it doesn't dissapear before I do a M or there is a pull
> > that redraws the screen.. just pressing Ctrl+L or opening/closing a
> > thread doesn't remove it.
> >
> > As said earlier it only seems to affect the top two threads.
>
> Hi,
> i also experienced now this Problem, but can't see were this problem
> is located, because i don't touch the internal states of the
> threads. There must be one @thread[curpos] left, which causes this
> Problem.
>
> greetz didi
Hi,
i think i've fixed the problem now, it was a wrong mapping in
update_text_for_line, now the situation that caused the error before
succeeds. There was a misguiding declaration of @size_widgets in the
init function.
@size_widgets isn't a Hash, mapping line numbers to a size_widget,
it is the same index as in @threads for the specific thread.
greetz didi
PS: please pull :-)
--
No documentation is better than bad documentation
-- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt.
------------------------------
Message: 1332
Date: Tue, 13 Oct 2009 00:50:20 +0300
From: Tero Tilus <tero@tilus.net>
To: sup-talk@rubyforge.org
Subject: [sup-talk] Oddities of marking spam
Message-ID: <20091012215020.GA31940@tilus.net>
Content-Type: text/plain; charset=us-ascii
First of all, Sup is a mindblowing experience! Really. Right after
first trial I decided it will (no ifs) replace mutt as my primary MUA.
I'll do whatever it takes to make this one work for me too. It almost
does already.
In between tuning other things I made a couple of observations (branch
next). Sorry about not having a patch (not working on this, right now
I'm trying to make Xapian eat my 100k+ mails).
Marking spam in thread-view-mode does not run mark-as-spam hook. This
isn't intentional?
If I look at spam (L, 'spam', ret) and then decide there's a false
positive and hit S, spam-tag is removed but thread will not disappear
from the view. If I then view the thread, hit .s spam label is
correctly added to the thread but at the same time it is _removed_
from the previously mentioned spam list. The same happens if I don't
view the thread but hit S again. Pressing M doesn't bring the
re-spammed thread back to the label search view showing spam. Killing
the buffer and doing L, 'spam', ret again does.
--
Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
------------------------------
Message: 1333
Date: Tue, 13 Oct 2009 01:34:49 +0300
From: Tero Tilus <tero@tilus.net>
To: sup-talk@rubyforge.org
Subject: [sup-talk] Xapian: Term too long
Message-ID: <20091012223449.GB31940@tilus.net>
Content-Type: text/plain; charset=us-ascii
sup-sync blows up like this
/home/terotil/src/sup/lib/sup/xapian_index.rb:446:in `replace_document': InvalidArgumentError: Term too long (> 245): Lfwd: =?iso-8859-1?q?tekij=e4n_oikeudet=5d?= (ArgumentError)
x-enigmail-version: 0.92.0.0
content-type: multipart/mixed;
boundary="------------010606010007070802040301"
x-virus-scanned: amavisd-new at cc.jyu.fi
x-spam-status: no, hits=-2.373 required=5 tests=[awl=0.226, bayes_00=-2.599
from /home/terotil/src/sup/lib/sup/xapian_index.rb:446:in `sync_message'
from /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
from /home/terotil/src/sup/lib/sup/xapian_index.rb:363:in `synchronize'
from /home/terotil/src/sup/lib/sup/xapian_index.rb:440:in `sync_message'
from /home/terotil/src/sup/lib/sup/xapian_index.rb:92:in `add_message'
from /home/terotil/src/sup/bin/sup-sync:211
...
Relevant part of the problematic mail looks like this
User-Agent: Debian Thunderbird 1.0.6 (X11/20050802)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: mutikainen@iki.fi
Subject: [Fwd: =?ISO-8859-1?Q?tekij=E4n_oikeudet=5D?=
X-Enigmail-Version: 0.92.0.0
Content-Type: multipart/mixed;
boundary="------------010606010007070802040301"
X-Virus-Scanned: amavisd-new at cc.jyu.fi
X-Spam-Status: No, hits=-2.373 required=5 tests=[AWL=0.226, BAYES_00=-2.599]
X-Spam-Level:
X-Sorted: Whitelist
Content-Length: 11892
This is how I solved it for me, for now
diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
index ad45b0e..d3b3e25 100644
--- a/lib/sup/xapian_index.rb
+++ b/lib/sup/xapian_index.rb
@@ -443,7 +443,11 @@ EOS
warn "docid underflow, dropping #{m.id.inspect}"
return
end
- @xapian.replace_document docid, doc
+ begin
+ @xapian.replace_document docid, doc
+ rescue StandardError => err
+ warn "Failed to add message #{m.id.inspect} to Xapian index: #{err}"
+ end
end
m.labels.each { |l| LabelManager << l }
Looks like lib/sup/xapian_index.rb tries to override
Xapian::Document#add_term with a version which is wired to ditch too
long terms. Only that you can't override methods just by including a
module. Methods of the including class override methods in included
module.
terotil@sotka:~$ irb
> class Foo; def bar; :bar; end; end
=> nil
> module Baz; def bar; :baz; end; end
=> nil
> class Foo; include Baz; end
=> Foo
> Foo.new.bar
=> :bar
> Foo.ancestors
=> [Foo, Baz, Object, Kernel] # Foo before Baz, methods in Foo take priority
It is still Foo#bar being called, not Baz#bar. You need to open up
Xapian::Document and then do alias method chaining to override
methods. Or you could do tricks like
http://coderrr.wordpress.com/2008/10/29/secure-alias-method-chaining/
--
Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
------------------------------
Message: 1334
Date: Mon, 12 Oct 2009 16:02:30 -0700
From: Carl Worth <cworth@cworth.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] Allow thread index view to sort oldest
first
Message-ID: <1255388543-sup-7477@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Mon Oct 12 05:48:50 -0700 2009:
> I've finally gotten a chance to look at this. It looks good so far.
Thanks for taking a look at it.
> So I definitely don't want the second patch which changes the default
> order. The configuration boolean is fine. (And if you want to add a
> question to sup-config, that's icing on the cake.)
I totally understand that, and that's why I did that part as a
separate patch.
> I would also like to disable forcing the loading of all messages.
I can understand that too.
> It is possible in Ferret: remove the DESC in ferret_index.rb line 160.
> It is also possible in Xapian, but we're building the Xapian index to
> optimize newest-first access. (Of course that would also be possible to
> change, but then we're talking about a total index rebuild.)
>
> If you wanted to tweak that, the load-all-threads wouldn't be necessary.
How do we get this behavior in xapian? I'm fine if the index is not
optimized for this. The current newest-first optimization is perfect
for actual searching, (as opposed to reading of new messages), and the
patches don't change that.
> Either way, I'm happy to merge the first patch with the "n = -1" thing
> removed.
I wouldn't want the patch accepted with just that change. It results
in a "broken" view, (it claims to be showing the oldest message first,
but it doesn't, and trying to scroll "up" to see earlier messages also
doesn't work).
So I'll see if I can figure out how to just load the N oldest message
instead. (My working theory was that this perform similarly to
actually loading all the messages, and that's why the patch just did
that).
> Pretty easy to change. In thread.rb, there's a date method which takes a
> max; you can make it take a min instead.
Excellent. I'll take a look at that.
> The hard work for both of these things is wiring this option through.
> Although $config is a global variable, I don't really want to use it
> directly in e.g. thread.rb.
OK. I'll see if there's nearby code to mimic for this.
-Carl
> > PS. We're still total ruby newbies, so please point out any silly
> > mistakes we're missing with respect to ruby idioms.
>
> Everything looks good. The only slgihtly non-idiomatic thing is using
> "if !x" instead of "unless x".
Heh. Just today I noticed "unless" while poking around in some sup
code. I have to say that "unless ... else" seems like a downright
malicious construct to unleash against people reading code.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091012/88815a8c/attachment-0001.bin>
------------------------------
Message: 1335
Date: Tue, 13 Oct 2009 02:22:15 +0300
From: Tero Tilus <tero@tilus.net>
To: sup-talk@rubyforge.org
Subject: [sup-talk] RMail chokes on broken headers
Message-ID: <20091012232215.GD31940@tilus.net>
Content-Type: text/plain; charset=us-ascii
RMail::Header#content_type breaks when it encounters broken
Content-Type and takes sup-sync down with it
/usr/lib/ruby/gems/1.8/gems/rmail-1.0.0/lib/rmail/header.rb:537:in `content_type': undefined method `downcase' for nil:NilClass (NoMethodError)
from /home/terotil/src/sup/lib/sup/message.rb:439:in `message_to_chunks'
from /home/terotil/src/sup/lib/sup/message.rb:239:in `load_from_source!'
from /home/terotil/src/sup/lib/sup/message.rb:335:in `build_from_source'
from /home/terotil/src/sup/lib/sup/poll.rb:160:in `each_message_from'
Worked around it this way
diff --git a/lib/sup/message.rb b/lib/sup/message.rb
index f9f87de..5ff3e48 100644
--- a/lib/sup/message.rb
+++ b/lib/sup/message.rb
@@ -436,7 +436,7 @@ private
end
chunks
- elsif m.header.content_type && m.header.content_type.downcase == "message/rfc822"
+ elsif (m.header.content_type == "message/rfc822" rescue false) # rmail 1.0.0 may choke on broken content-type header, FIXME: fix rmail
if m.body
payload = RMail::Parser.read(m.body)
from = payload.header.from.first ? payload.header.from.first.format : ""
@@ -456,7 +456,7 @@ private
debug "no body for message/rfc822 enclosure; skipping"
[]
end
- elsif m.header.content_type && m.header.content_type.downcase == "application/pgp" && m.body
+ elsif (m.header.content_type.downcase == "application/pgp" rescue false) && m.body # rmail 1.0.0 may choke on broken content-type header, FIXME: fix rmail
## apparently some versions of Thunderbird generate encryped email that
## does not follow RFC3156, e.g. messages with X-Enigmail-Version: 0.95.0
## they have no MIME multipart and just set the body content type to
The problem itself is inside RMail. I reported it.
http://rubyforge.org/tracker/index.php?func=detail&aid=27282&group_id=446&atid=1754
RMail looks abandoned. Development is pretty much stalled. No
functional changes since 2004-04-27. None of the reported bugs have
been fixed. Might it be worth to think about switching to another
mail lib? TMail author's http://github.com/mikel/mail/ looks
promising.
--
Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
------------------------------
Message: 1336
Date: Tue, 13 Oct 2009 10:13:53 +0200
From: Sven Schober <sven.schober@uni-ulm.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] pinentry-curses messes up sup
Message-ID: <1255421626-sup-4525@hysbald>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Sun Oct 11 22:25:33 +0200 2009:
> Reformatted excerpts from Sven Schober's message of 2009-10-10:
> > As that thread is rather old, i would like to now if there's been some
> > development on this? Are there any console alternatives to
> > pinentry-curses?
>
> I think I've fixed this in git next. Please try that.
Works like a charm :) Thanks!
--
Sven Schober, sven.schober@uni-ulm.de |UNI ULM
http://www-vs.informatik.uni-ulm.de/dept/staff/schober/ |DISTRIBUTED
Room O27-346, Phone: +49-731-5024146 [+49-179-5060182] |SYSTEMS LAB
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091013/fa723900/attachment-0001.bin>
------------------------------
Message: 1337
Date: Tue, 13 Oct 2009 15:40:03 +0300
From: Tero Tilus <tero@tilus.net>
To: sup-talk@rubyforge.org
Subject: [sup-talk] IMAP and recursion
Message-ID: <20091013124002.GA7129@tilus.net>
Content-Type: text/plain; charset=us-ascii
I had quite a lot of IMAP folders to add and went looking for
recursion. I found old sup-talk threads on the subject and thought of
it a while.
I might have missed something, but I could not easily get around
sup-add asking me all the time which account she should use. So I
went on to add --force-account user@host to be able to batch-add IMAP
sources.
What do you think?
---
diff --git a/bin/sup-add b/bin/sup-add
index e27a0eb..c53378d 100755
--- a/bin/sup-add
+++ b/bin/sup-add
@@ -39,6 +39,7 @@ EOS
opt :unusual, "Do not automatically poll these sources for new messages."
opt :labels, "A comma-separated set of labels to apply to all messages from this source", :type => String
opt :force_new, "Create a new account for this source, even if one already exists."
+ opt :force_account, "Reuse previously defined account user@hostname.", :type => String
end
Trollop::die "require one or more sources" if ARGV.empty?
@@ -56,13 +57,20 @@ def get_login_info uri, sources
username, password = nil, nil
unless accounts.empty? || $opts[:force_new]
- say "Would you like to use the same account as for a previous source for #{uri}?"
- choose do |menu|
- accounts.each do |host, olduser, oldpw|
- menu.choice("Use the account info for #{olduser}@#{host}") { username, password = olduser, oldpw }
+ if $opts[:force_account]
+ host, username, password = accounts.find { |h, u, p| $opts[:force_account] == "#{u}@#{h}" }
+ unless username && password
+ say "No previous account #{$opts[:force_account].inspect} found."
+ end
+ else
+ say "Would you like to use the same account as for a previous source for #{uri}?"
+ choose do |menu|
+ accounts.each do |host, olduser, oldpw|
+ menu.choice("Use the account info for #{olduser}@#{host}") { username, password = olduser, oldpw }
+ end
+ menu.choice("Use a new account") { }
+ menu.prompt = "Account selection? "
end
- menu.choice("Use a new account") { }
- menu.prompt = "Account selection? "
end
end
---
--
Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
------------------------------
Message: 1338
Date: Tue, 13 Oct 2009 16:18:44 -0400
From: Ben Gamari <bgamari.foss@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Fwd: Re: Crash while in thread-view-mode
Message-ID: <1255464686-sup-4163@ben-laptop>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Sun Oct 11 16:28:48 -0400 2009:
> I'm sorry you've had to rebuild the index so many times. The Xapian side
> of things is very new, and I think you've had a run of bad luck. But I
> am personally not motivated to improve index time performance, because
> that's not a common event. At least, it shouldn't be.
Unfortunately, it seems that the crashes have returned (In fact, they
returned only hours after I rebuilt). Interestingly, it is once again my
LKML label that is the culprit.
On the note of crashing, is it really necessary for the "wrong id called
on nil" exception to be fatal? Couldn't the client at least make some
attempt at recovering (skipping the problematic thread while catching
and logging the exception)? It seems like these issues could be rather
tricky to sort out (I've put an hour or so into tracking down the source
of the nils to no avail), and with a dynamically typed language like
Ruby, could occur at any time. Considering this, it seems like it might
be a good idea to handle these failures a bit more gracefully. Would
this be problematic?
Regardless, it might be a good idea to have a hierarchy of exception
classes instead of just throwing Strings. It seems that throwing
specialized classes would make the above substantially easier.
Thanks,
- Ben
--- RuntimeError from thread: load threads for thread-index-mode
wrong id called on nil
/opt/exp/sup/lib/sup.rb:17:in `id'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `update'
/usr/lib64/ruby/1.8/rubygems/custom_require.rb:31:in `sort_by'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `each'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `sort_by'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `update'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:223:in `synchronize'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:223:in `update'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:628:in `__unprotected_load_n_threads'
/opt/exp/sup/lib/sup/thread.rb:334:in `load_n_threads'
/opt/exp/sup/lib/sup/xapian_index.rb:117:in `each_id_by_date'
/opt/exp/sup/lib/sup/xapian_index.rb:110:in `each_id'
/opt/exp/sup/lib/sup/xapian_index.rb:110:in `each'
/opt/exp/sup/lib/sup/xapian_index.rb:110:in `each_id'
/opt/exp/sup/lib/sup/xapian_index.rb:117:in `each_id_by_date'
/opt/exp/sup/lib/sup/thread.rb:328:in `load_n_threads'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:625:in `__unprotected_load_n_threads'
(eval):12:in `load_n_threads'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:609:in `load_n_threads_background'
/opt/exp/sup/lib/sup.rb:77:in `reporting_thread'
/opt/exp/sup/lib/sup.rb:75:in `initialize'
/opt/exp/sup/lib/sup.rb:75:in `new'
/opt/exp/sup/lib/sup.rb:75:in `reporting_thread'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads'
(eval):12:in `load_threads'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:81:in `initialize'
/opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:22:in `call'
/opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:22:in `initialize'
/opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:22:in `each'
/opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:22:in `initialize'
/opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:19:in `new'
/opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:19:in `initialize'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:54:in `initialize'
/opt/exp/sup/lib/sup/modes/label-search-results-mode.rb:9:in `initialize'
/opt/exp/sup/lib/sup/modes/label-search-results-mode.rb:32:in `new'
/opt/exp/sup/lib/sup/modes/label-search-results-mode.rb:32:in `spawn_nicely'
/opt/exp/sup/lib/sup/buffer.rb:350:in `spawn_unless_exists'
/opt/exp/sup/lib/sup/util.rb:520:in `send'
/opt/exp/sup/lib/sup/util.rb:520:in `method_missing'
/opt/exp/sup/lib/sup/modes/label-search-results-mode.rb:32:in `spawn_nicely'
/opt/exp/sup/lib/sup/modes/label-list-mode.rb:134:in `select_label'
/opt/exp/sup/lib/sup/mode.rb:51:in `send'
/opt/exp/sup/lib/sup/mode.rb:51:in `handle_input'
/opt/exp/sup/lib/sup/buffer.rb:267:in `handle_input'
/usr/bin/sup:245
------------------------------
Message: 1339
Date: Tue, 13 Oct 2009 20:51:10 +0000 (UTC)
From: Olly Betts <olly@survex.com>
To: sup-talk@rubyforge.org
Subject: Re: [sup-talk] [PATCH] Allow thread index view to sort oldest
first
Message-ID: <slrnhd9q1u.gga.olly@msgid.survex.com>
Content-Type: text/plain; charset=us-ascii
On 2009-10-12, Carl Worth <cworth@cworth.org> wrote:
> How do we get this behavior in xapian? I'm fine if the index is not
> optimized for this. The current newest-first optimization is perfect
> for actual searching, (as opposed to reading of new messages), and the
> patches don't change that.
@enquire.docid_order = Xapian::Enquire::DESCENDING
This means that the docid order (which is used as the least significant
ordering) is descending rather than ascending. In this case (I assume)
we're using Xapian::BoolWeight so this is the only ordering.
Cheers,
Olly
------------------------------
Message: 1340
Date: Wed, 14 Oct 2009 16:34:55 +0300
From: Tero Tilus <tero@tilus.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Sup finds ghost messages
Message-ID: <1255526768-sup-3152@tilus.net>
Content-Type: text/plain; charset=UTF-8
sup-sync --all (using xapian) from a new source occasionally says 1-2
messages already were in the index, even if they most certainly
weren't. I noticed this when I added sup-talk archives to my index.
I'm 100% sure I did not have any sup-talk mails from somewhere
2007-2008 in any of my other sources. Still sup-sync said it did not
add a couple of messages which supposedly already were in the index.
ps. Happily on sup now. \o/ All mails in, 1G index. Xapian is
blazing fast...
pps. Why bugs to this list? Why not use a tracker? (besides that sup
is awesome tracker too ;)
--
Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
------------------------------
Message: 1341
Date: Thu, 15 Oct 2009 01:27:03 +0300
From: Tero Tilus <tero@tilus.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Wrapping long lines
Message-ID: <1255558925-sup-2369@tilus.net>
Content-Type: text/plain; charset=UTF-8
How can I make sup wrap long lines? I occasionally receive unwrapped
text/plain mails and it would be cool to have the "i dont care what
you need to do, but just fit it in the terminal window width" button.
--
Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
------------------------------
Message: 1342
Date: Thu, 15 Oct 2009 12:50:13 +0200
From: Michael Stapelberg <michael+sup@stapelberg.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] About faking message IDs
Message-ID: <1255603625-sup-2558@midna.zekjur.net>
Content-Type: text/plain; charset=UTF-8
Hi,
I just noticed that the lack of emails from my backup program seems to be
because of the missing message ids in the mail script I use. In case of
no message id inside the header, sup uses the md5sum of the whole header
(see lib/sup/message.rb:74). This effectively means that messages having
the same md5sum of their header (which happened, since the header was also
generated completely by the script and the values did not change) will
"overwrite" the old message.
As a workaround, I now added the current time to my script, so that every
header will have a different md5 sum. But maybe we can think of a more
clever way to generate faked message ids? Maybe also hash the body of the
message?
Best regards,
Michael
------------------------------
Message: 1343
Date: Thu, 15 Oct 2009 05:46:51 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash while in thread-view-mode
Message-ID: <1255610731-sup-7030@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Ben Gamari's message of 2009-10-07:
> There must be a better way to deal with these invalid ids than
> crashing. Is there any reason this needs to be a show-stopping event?
This is probably a symptom of some thread protection issues. You're
right, there's no reason this needs to crash Sup. You could apply this:
diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb
index 82f258b..17d5836 100644
--- a/lib/sup/modes/thread-index-mode.rb
+++ b/lib/sup/modes/thread-index-mode.rb
@@ -222,7 +222,7 @@ EOS
def update
@mutex.synchronize do
## let's see you do THIS in python
- @threads = @ts.threads.select { |t| !@hidden_threads[t] }.sort_by { |t| [t.date, t.first.id] }.reverse
+ @threads = @ts.threads.select { |t| !@hidden_threads[t] }.select { |t| t.first }.sort_by { |t| [t.date, t.first.id] }.reverse
@size_widgets = @threads.map { |t| size_widget_for_thread t }
@size_widget_width = @size_widgets.max_of { |w| w.display_length }
end
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1344
Date: Thu, 15 Oct 2009 05:51:50 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] curses exception
Message-ID: <1255611057-sup-1320@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Dan Falcone's message of 2009-10-12:
> Honestly, it's probably an issue with my setup... is there a guide
> anywhere on how to get sup running in cygwin? Maybe I'm missing a
> required package?
There's no guide per se. Other people have definitely made it work in
the past. Are you able to get other color curses programs to work? I
suspect it's not a Sup issue per se, but I'm not that familiar with the
intricacies of Cygwin.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1345
Date: Thu, 15 Oct 2009 05:56:29 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Oddities of marking spam
Message-ID: <1255611277-sup-9644@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Tero Tilus's message of 2009-10-12:
> Marking spam in thread-view-mode does not run mark-as-spam hook. This
> isn't intentional?
Good point, that's a bug.
> If I look at spam (L, 'spam', ret) and then decide there's a false
> positive and hit S, spam-tag is removed but thread will not disappear
> from the view. If I then view the thread, hit .s spam label is
> correctly added to the thread but at the same time it is _removed_
> from the previously mentioned spam list. The same happens if I don't
> view the thread but hit S again. Pressing M doesn't bring the
> re-spammed thread back to the label search view showing spam. Killing
> the buffer and doing L, 'spam', ret again does.
The auto-adding and auto-removing of threads from search-result-mode is
only able to work in certain limited cases, in general, but this sounds
like a bug too.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1346
Date: Thu, 15 Oct 2009 05:59:53 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Xapian: Term too long
Message-ID: <1255611567-sup-8695@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Tero Tilus's message of 2009-10-12:
> Looks like lib/sup/xapian_index.rb tries to override
> Xapian::Document#add_term with a version which is wired to ditch too
> long terms. Only that you can't override methods just by including a
> module. Methods of the including class override methods in included
> module.
Very good point. Thanks!
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1347
Date: Thu, 15 Oct 2009 06:11:36 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] RMail chokes on broken headers
Message-ID: <1255612194-sup-3880@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Tero Tilus's message of 2009-10-12:
> RMail looks abandoned. Development is pretty much stalled. No
> functional changes since 2004-04-27. None of the reported bugs have
> been fixed. Might it be worth to think about switching to another
> mail lib? TMail author's http://github.com/mikel/mail/ looks
> promising.
Yeah, this is certainly an option. But it seems like a lot of work. And
every day our set of rmail workarounds grows more robust. :)
Not to say I wouldn't accept a patch that magically did this all for me,
of course.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1348
Date: Thu, 15 Oct 2009 06:45:47 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Sup finds ghost messages
Message-ID: <1255612303-sup-410@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Tero Tilus's message of 2009-10-14:
> sup-sync --all (using xapian) from a new source occasionally says 1-2
> messages already were in the index, even if they most certainly
> weren't. I noticed this when I added sup-talk archives to my index.
Can you run with -v and grep to make sure those message ids don't
actually appear more than once in the mbox file? If they don't, can you
isolate a particular one and use devel/console.sh to find out where Sup
thinks the previous occurence is?
> pps. Why bugs to this list? Why not use a tracker? (besides that sup
> is awesome tracker too ;)
If there's a good one out there I'd like to hear about it. We used ditz
for a while because I hate clicking the mouse, but eventually it became
too much effort.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1349
Date: Thu, 15 Oct 2009 15:47:00 +0200
From: Guillaume Quintard <guillaume.quintard@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash while in thread-view-mode
Message-ID: <1255614287-sup-4683@altis>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Thu Oct 15 14:46:51 +0200 2009:
> Reformatted excerpts from Ben Gamari's message of 2009-10-07:
> > There must be a better way to deal with these invalid ids than
> > crashing. Is there any reason this needs to be a show-stopping event?
>
> This is probably a symptom of some thread protection issues. You're
> right, there's no reason this needs to crash Sup. You could apply this:
>
> diff --git a/lib/sup/modes/thread-index-mode.rb
> b/lib/sup/modes/thread-index-mode.rb
> index 82f258b..17d5836 100644
> --- a/lib/sup/modes/thread-index-mode.rb
> +++ b/lib/sup/modes/thread-index-mode.rb
> @@ -222,7 +222,7 @@ EOS
> def update
> @mutex.synchronize do
> ## let's see you do THIS in python
> - @threads = @ts.threads.select { |t| !@hidden_threads[t] }.sort_by { |t|
> [t.date, t.first.id] }.reverse
> + @threads = @ts.threads.select { |t| !@hidden_threads[t] }.select { |t|
> t.first }.sort_by { |t| [t.date, t.first.id] }.reverse
> @size_widgets = @threads.map { |t| size_widget_for_thread t }
> @size_widget_width = @size_widgets.max_of { |w| w.display_length }
> end
Man, I love you, I can finally use sup again.
(and I love the Python comment, even if I have no effing idea of what
the code could mean.)
Thanks!
--
Guillaume
------------------------------
Message: 1350
Date: Thu, 15 Oct 2009 06:47:36 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] About faking message IDs
Message-ID: <1255614431-sup-5910@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Michael Stapelberg's message of 2009-10-15:
> I just noticed that the lack of emails from my backup program seems to be
> because of the missing message ids in the mail script I use. In case of
> no message id inside the header, sup uses the md5sum of the whole header
> (see lib/sup/message.rb:74). This effectively means that messages having
> the same md5sum of their header (which happened, since the header was also
> generated completely by the script and the values did not change) will
> "overwrite" the old message.
Doesn't the header include the date?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1351
Date: Thu, 15 Oct 2009 15:55:13 +0200
From: Michael Stapelberg <michael+sup@stapelberg.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: [sup-talk] before-edit hook and accessing the original sender
Message-ID: <1255614656-sup-7039@midna.zekjur.net>
Content-Type: text/plain; charset=UTF-8
Hi,
I just configured a before-edit hook which prepends my usual greeting to the
message and appends my greeting. To personalize the greeting, I access
header["To"]. However, when replying to emails, this is not always the original
sender of the message I am replying to (think of mailing lists).
So, the question is, can I somehow access the message to which I am replying
to when in the before-edit hook called when replying to a message.
Best regards,
Michael
PS: I am not using the signature hook as I want to edit my signature inside my
$EDITOR. Also, I need the greeting at the top of the message.
------------------------------
Message: 1352
Date: Thu, 15 Oct 2009 15:59:01 +0200
From: Michael Stapelberg <michael+sup@stapelberg.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] About faking message IDs
Message-ID: <1255615018-sup-5653@midna.zekjur.net>
Content-Type: text/plain; charset=UTF-8
Hi William,
Excerpts from William Morgan's message of Thu Oct 15 15:47:36 +0200 2009:
> Doesn't the header include the date?
No, in my case it did not. The reason for that is calling "deliver" directly,
that is without talking SMTP to a mailserver. Thus, no headers are getting
added. Surely this is a corner case, but I think it will cause headache for
system administrators running into this one, if they notice it all (overwriting
messages is quite dangerous).
Best regards,
Michael
------------------------------
Message: 1353
Date: Thu, 15 Oct 2009 10:40:54 -0400
From: Dan Falcone <danfalcone@gmail.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] curses exception
Message-ID:
<ed5557340910150740i4e701044l12be4fd43e2bc072@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hmm... good question. I regularly use emacs with colors enabled, but I'm
not sure if that uses curses. I tried typespeed and that seemed to work.
According to its man page, it uses curses. Is there any way I could disable
colors in sup as a test? I'll also try reinstalling curses and installing
older versions to see if that makes a difference...
Thanks!
Dan
On Thu, Oct 15, 2009 at 8:51 AM, William Morgan <wmorgan-sup@masanjin.net>wrote:
> Reformatted excerpts from Dan Falcone's message of 2009-10-12:
> > Honestly, it's probably an issue with my setup... is there a guide
> > anywhere on how to get sup running in cygwin? Maybe I'm missing a
> > required package?
>
> There's no guide per se. Other people have definitely made it work in
> the past. Are you able to get other color curses programs to work? I
> suspect it's not a Sup issue per se, but I'm not that familiar with the
> intricacies of Cygwin.
> --
> William <wmorgan-sup@masanjin.net>
> _______________________________________________
> sup-talk mailing list
> sup-talk@rubyforge.org
> http://rubyforge.org/mailman/listinfo/sup-talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091015/0a373709/attachment-0001.html>
------------------------------
Message: 1354
Date: Thu, 15 Oct 2009 11:03:04 -0400
From: Ben Gamari <bgamari.foss@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash while in thread-view-mode
Message-ID: <1255618838-sup-1025@ben-laptop>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Thu Oct 15 08:46:51 -0400 2009:
> Reformatted excerpts from Ben Gamari's message of 2009-10-07:
> > There must be a better way to deal with these invalid ids than
> > crashing. Is there any reason this needs to be a show-stopping event?
>
> This is probably a symptom of some thread protection issues. You're
> right, there's no reason this needs to crash Sup. You could apply this:
>
Yep, this fixes it. Thank you so much. Now to sort through my backlog of
mail. Thanks again,
- Ben
------------------------------
Message: 1355
Date: Thu, 15 Oct 2009 08:16:36 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Crash while in thread-view-mode
Message-ID: <1255619752-sup-3707@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Guillaume Quintard's message of 2009-10-15:
> (and I love the Python comment, even if I have no effing idea of what
> the code could mean.)
It refers to the fact that Python programs don't have bugs.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1356
Date: Thu, 15 Oct 2009 08:27:44 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] curses exception
Message-ID: <1255620005-sup-7616@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Dan Falcone's message of 2009-10-15:
> Hmm... good question. I regularly use emacs with colors enabled, but
> I'm not sure if that uses curses. I tried typespeed and that seemed
> to work. According to its man page, it uses curses.
Hm. What version of the ncurses gem do you have? (gem list --local
should tell you.)
What does this program print?
require 'rubygems'
require 'ncurses'
x = begin
Ncurses::initscr();
Ncurses::has_colors?()
ensure
Ncurses::endwin();
end
puts x
If it prints true, then, if you look in the contents of the gem
(wherever that is on your system), there should be an examples/
directory. If you run examples/tlock.rb or examples/rain.rb, (probably
with ruby -rubygems), do you see color?
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1357
Date: Thu, 15 Oct 2009 08:29:29 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] About faking message IDs
Message-ID: <1255620476-sup-8113@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Michael Stapelberg's message of 2009-10-15:
> No, in my case it did not. The reason for that is calling "deliver"
> directly, that is without talking SMTP to a mailserver. Thus, no
> headers are getting added. Surely this is a corner case, but I think
> it will cause headache for system administrators running into this
> one, if they notice it all (overwriting messages is quite dangerous).
Ok. I think it's fine to generate the message id via another mechanism,
e.g. the way we do it in edit-message-mode ("<#{Time.now.to_i}-sup-#{rand 10000}@#{hostname}").
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1358
Date: Thu, 15 Oct 2009 08:32:54 -0700
From: William Morgan <wmorgan-sup@masanjin.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] before-edit hook and accessing the original
sender
Message-ID: <1255620578-sup-9650@masanjin.net>
Content-Type: text/plain; charset=UTF-8
Reformatted excerpts from Michael Stapelberg's message of 2009-10-15:
> So, the question is, can I somehow access the message to which I am
> replying to when in the before-edit hook called when replying to a
> message.
Not currently. We could wire that through without too much effort, I
think.
--
William <wmorgan-sup@masanjin.net>
------------------------------
Message: 1359
Date: Thu, 15 Oct 2009 10:23:40 -0700
From: Carl Worth <cworth@cworth.org>
To: Sup Talk <sup-talk@rubyforge.org>
Subject: [sup-talk] Indexing messages without ruby
Message-ID: <1255623468-sup-2284@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
I've gone forward with an experiment I had mentioned I might try:
trying to create a faster sup-sync by using C rather than ruby.
My approach was to use Xapian to create a sup-compatible index, and to
use libgmime for the mail parsing. That meant that I only had to write
a tiny bit of code to glue gmime together with xapian. The code is an
unholy mess of C and C++, (so there are as many as three different
string types, sometimes all in one function!), but it seems to be
working at least.
I wrote a little xapian-dump program to make a textual dump of a
database, (all data, terms, and values for each document), and I
verified that my program, notmuch, could create identical[*] terms and
values when indexing about 150 recent messages from the sup-talk
mailing list.
I've also verified that notmuch can index my own collection of nearly
600,000 email messages without any problems.
The big difference in notmuch that makes the resulting index
incompatible with sup is that it doesn't generate a serialized ruby
data structure for the document data like sup currently
expects. Instead it just shoves the mail message's filename into the
data field. So if anyone wanted to use notmuch with sup, this would
need to be resolved on one side or the other.[**]
As for performance, things look pretty good, but perhaps not as good
as I had hoped. From a test of importing about 400,000 messages from
my mail archive, notmuch starts out between 300 - 400 messages/sec.
but after about 40,000 messages slows down to about 100
messages/sec. and stabilizes there.
I haven't tested sup recently, but from my recollection indexing the
same archive on the same computer, sup started out at about 40
messages/sec. and slowed down to about 20 messages/sec. (for as long
as I watched it).
So this is preliminary, but it looks like notmuch gives a 5-10x
performance improvement over sup, (but likely closer to the 5x end of
that range unless you've got a very small index---at which point who
cares how fast/slow things are?).
A quick glance with a profiler shows xapian dominating the notmuch
profile at 62% and gmime hardly appearing at all (near 2%). As
contrast, ruby dominates the sup-sync profile with xapian down in the
8% range. (So there's the 10x target there.) One other advantage is
that with xapian dominating the profile, notmuch stands to benefit
from future performance improvements to xapian itself.
If that ruby time is dominated by mail parsing, it's possible that
much of the advantage of notmuch could be gained by simply switching
from rmail to a non-ruby-based parser like gmime. But that's just a
guess as I haven't tried to find where the ruby time is being spent.
If anyone is interested in playing along at home, my code is available
via git with:
git clone git://git.cworth.org/git/notmuch
Have fun,
-Carl
[*] Some minor differences exist in the heuristics for reognizing
signatures, and sup sometimes splits numbers into multiple terms (such
as "1754" indexed as two terms "17" and "54") which I couldn't explain
nor replicate. Finally notmuch doesn't attempt to index encrypted
messages.
[**] Beyond this incompatibility, notmuch is not even close to being a
functional replacement for sup-sync. It currently only knows how to
shove new documents into the database and doesn't know how to do any
updating. Similarly it doesn't have any code to examine mtimes to
identify new or changed messages to be updated. It also doesn't look
at maildir filename flags to determine labels, nor does it provide any
means for the user to request custom labels to be attached to certain
messages.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091015/25074e86/attachment-0001.bin>
------------------------------
Message: 1360
Date: Thu, 15 Oct 2009 21:21:29 +0200
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] About faking message IDs
Message-ID: <1255634425-sup-8445@peray>
Content-Type: text/plain; charset=UTF-8
Excerpts from William Morgan's message of Thu Oct 15 17:29:29 +0200 2009:
> Reformatted excerpts from Michael Stapelberg's message of 2009-10-15:
> > No, in my case it did not. The reason for that is calling "deliver"
> > directly, that is without talking SMTP to a mailserver. Thus, no
> > headers are getting added. Surely this is a corner case, but I think
> > it will cause headache for system administrators running into this
> > one, if they notice it all (overwriting messages is quite dangerous).
>
> Ok. I think it's fine to generate the message id via another mechanism,
> e.g. the way we do it in edit-message-mode ("<#{Time.now.to_i}-sup-#{rand 10000}@#{hostname}").
This way we loose the reproducibility, but I concede that we can't have both.
--
Nicolas Pouillard
http://nicolaspouillard.fr
------------------------------
Message: 1361
Date: Thu, 15 Oct 2009 17:14:09 -0700
From: Carl Worth <cworth@cworth.org>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] About faking message IDs
Message-ID: <1255651999-sup-9911@yoom.home.cworth.org>
Content-Type: text/plain; charset="utf-8"
Excerpts from William Morgan's message of Thu Oct 15 08:29:29 -0700 2009:
> Ok. I think it's fine to generate the message id via another mechanism,
> e.g. the way we do it in edit-message-mode ("<#{Time.now.to_i}-sup-#{rand
> 10000}@#{hostname}").
Won't that then make sup insert duplicate documents into the index for
any run of sup-sync --all over the relevant sources?
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091015/78f02bbd/attachment-0001.bin>
------------------------------
Message: 1362
Date: Sun, 18 Oct 2009 00:32:25 +0200
From: Michael Stapelberg <michael+sup@stapelberg.de>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] [PATCH] more inline GPG madness
Message-ID: <1255818685-sup-6010@midna.zekjur.net>
Content-Type: text/plain; charset="utf-8"
Hi,
Excerpts from William Morgan's message of Mo Okt 12 15:54:06 +0200 2009:
> Reformatted excerpts from Michael Stapelberg's message of 2009-10-01:
> > I will instead implement support for "correct" inline GPG.
See the attached patch. Please consider merging it :).
Best regards,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Implement-inline-GPG.patch
Type: application/octet-stream
Size: 5354 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091018/dbd897f2/attachment.obj>
------------------------------
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
End of sup-talk Digest, Vol 30, Issue 1
***************************************