community/pipermail-archives/sup-devel/2014-04.txt (14928B) - raw
1 From mbaehr@email.archlab.tuwien.ac.at Tue Apr 1 03:46:29 2014
2 From: mbaehr@email.archlab.tuwien.ac.at (=?utf-8?q?Martin_B=C3=A4hr?=)
3 Date: Tue, 01 Apr 2014 05:46:29 +0200
4 Subject: [sup-devel] use-mail branch and other work
5 In-Reply-To: <1396294116-sup-6519@kpad>
6 References: <1396168444-sup-8010@email.archlab.tuwien.ac.at>
7 <1396294116-sup-6519@kpad>
8 Message-ID: <1396321899-sup-4786@email.archlab.tuwien.ac.at>
9
10 Excerpts from Matthieu Rakotojaona's message of 2014-03-31 21:42:57 +0200:
11 > > add support for a "new" state that is different from unread.
12 > > the idea here is that the new state of a message can be cleared without
13 > > reading the message or marking it as read. this distinction is important
14 > > because i have lots of old unread mail, and so i can't see where i have
15 > > actual new mail.
16 > Isn't that more ore less achievable with the inbox label ? It is added
17 > automatically to new messages unless you explicitely specify otherwise.
18
19 the inbox is where all the important new mail comes in. it is easy to reach
20 with "I", which is important. i do not want mailing list emails in the inbox. i
21 have some very active lists, which would just flodd the inbox view and drown
22 out all other new messages.
23
24 i could use the inbox if i made a search that excludes all mailinglists, but
25 that search would take more than one keystroke to reach. and it would not give me other features, such as a count of new messages in the label-list
26
27 "new" is a state that should be automatically cleared when i read a message or
28 when the message/thread goes out of view.
29
30 i currently have it working semi-automaticly in
31 https://github.com/eMBee/sup/commit/9debc5be804f6dc38cc9d4a14d5eead0337b1e22
32
33 the new state is cleared when a thread is read or when i refresh with @
34
35 in the label-list-mode, labels are sorted by the time of the latest new
36 message, and each label has a count of how many new messages this label has:
37
38 new 429 messages, 260 unread, 429 new - 5:21am
39 Unread 614916 messages, 614916 unread, 260 new - 5:21am
40 Inbox 928373 messages, 562870 unread, 9 new - 5:18am
41 news 91638 messages, 55560 unread, 74 new - 5:03am
42 fish 4037 messages, 2447 unread, 5 new - 3:33am
43 Spam 18456 messages, 11190 unread, 43 new - 3:26am
44 git 55779 messages, 33819 unread, 100 new - 2:53am
45 Replied 77 messages, 0 unread, 0 new - 2:08am
46 sup 6401 messages, 3880 unread, 0 new - Mar 31
47 Attachment 14521 messages, 8804 unread, 8 new - Mar 31
48 debian 13541 messages, 8210 unread, 10 new - Mar 31
49 fedora 221 messages, 89 unread, 14 new - Mar 31
50
51 i can now easily see where there are new messages, how recent they are, and how many.
52
53 > > some ideas:
54 > > i'd like the ability to apply a label change to all messages that match a
55 > > given search, not just the ones loaded into the buffer.
56 > Semi-answer: bin/sup-tweak-labels is this, except it's supposed to be
57 > used from the command line. Moreover you must exit sup because the index
58 > can't be shared safely.
59
60 ah, thanks, yes, that should solve this problem mostly.
61
62 > I don't know how we could manage to reproduce the bin/sup-tweak-labels
63 > _inside_ sup efficiently, but I'm open to the discussion.
64
65 i'd be happy for it to not be efficient. just some fire-and-forget command that
66 silently chuggs away in the background.
67
68 > You do have interesting ideas. Welcome on board :)
69
70 thank you.
71
72 greetings, martin.
73
74 --
75 eKita - the online platform for your entire academic life
76 hackerspace beijing - http://qike.info
77 --
78 chief engineer eKita.co
79 pike programmer pike.lysator.liu.se caudium.net societyserver.org
80 BLUG secretary beijinglug.org
81 foresight developer foresightlinux.org realss.com
82 unix sysadmin
83 Martin B?hr working in china http://societyserver.org/mbaehr/
84
85 From mbaehr@email.archlab.tuwien.ac.at Tue Apr 1 03:55:12 2014
86 From: mbaehr@email.archlab.tuwien.ac.at (=?utf-8?q?Martin_B=C3=A4hr?=)
87 Date: Tue, 01 Apr 2014 05:55:12 +0200
88 Subject: [sup-devel] use-mail branch and other work
89 In-Reply-To: <1396299131-sup-5113@qwerzila>
90 References: <1396168444-sup-8010@email.archlab.tuwien.ac.at>
91 <1396294116-sup-6519@kpad> <1396299131-sup-5113@qwerzila>
92 Message-ID: <1396324091-sup-9960@email.archlab.tuwien.ac.at>
93
94 Excerpts from Gaute Hope's message of 2014-03-31 22:57:06 +0200:
95 > We could do something similar to what tagging and + does now, but
96 > iterate over all the threads in the search without rendering them.
97 > Unless the chunks are loaded it is a matter of loading it from the
98 > index. It would be an extension to thread-index mode. Basically a
99 > command: Apply an action to all threads matching the current search. It
100 > will be the equivalent of: Search + show all (!!) + tag all +
101 > do action.
102
103 yes, that's how i imagined to use it.
104
105 btw: do action for all tagged blocks. with a few threads tagged or on a fast
106 machine it's not noticable, but on a slower machine it is.
107
108 if the above is solved to run in the background, then the current do action for
109 all tagged, could use the same mechanism. it is just a matter of which list of
110 threads/messages the function receives to operate on:
111
112 search + tag some messages + do action on tagged -> call action with list of tagged messages.
113 search + do action on search -> call action with list of matching messages.
114
115 same function for both, return to view immideately, maybe update view when function completes
116
117 greetings, martin.
118
119 --
120 eKita - the online platform for your entire academic life
121 hackerspace beijing - http://qike.info
122 --
123 chief engineer eKita.co
124 pike programmer pike.lysator.liu.se caudium.net societyserver.org
125 BLUG secretary beijinglug.org
126 foresight developer foresightlinux.org realss.com
127 unix sysadmin
128 Martin B?hr working in china http://societyserver.org/mbaehr/
129
130 From mbaehr@email.archlab.tuwien.ac.at Tue Apr 1 04:13:44 2014
131 From: mbaehr@email.archlab.tuwien.ac.at (=?utf-8?q?Martin_B=C3=A4hr?=)
132 Date: Tue, 01 Apr 2014 06:13:44 +0200
133 Subject: [sup-devel] use-mail branch and other work
134 In-Reply-To: <1396267373-sup-7639@qwerzila>
135 References: <1396168444-sup-8010@email.archlab.tuwien.ac.at>
136 <1396267373-sup-7639@qwerzila>
137 Message-ID: <1396324522-sup-8837@email.archlab.tuwien.ac.at>
138
139 Excerpts from Gaute Hope's message of 2014-03-31 14:09:56 +0200:
140 > > add support for a "new" state that is different from unread.
141
142 > Perhaps you followed the discussion with Ico / Zevv on irc? There might
143 > be a solution together with the proposed hooks in #276, or are you
144 > looking for something more integrated?
145
146 new state operates on the thread-index.
147 a message is new if it has not been seen in an index.
148
149 if i have read the cubject-line and decided that i don't want to read this
150 thread, then at that point it is no longer new. (of course if i do read it, it
151 is also no longer new)
152
153 i have this mostly working in
154 https://github.com/eMBee/sup/commit/9debc5be804f6dc38cc9d4a14d5eead0337b1e22
155
156 since we don't have a ruby mind-reader gem, i am currently using @ refresh to
157 clear the new state. other options could be to detect when the cursor is
158 scrolled over a message, or when the buffer is closed or hidden when i switch
159 to another buffer.
160
161 initially i cleared the new state when the thread-index was loaded, but that
162 meant i could not see what was actually new, so i switched it to refresh.
163
164 > Some of these might be harder to do with sup since we don't keep an
165 > adress book.
166
167 for another idea that i have in mind, this is something i'd like to change.
168
169 > > i'd like to treat saved searches as virtual folders. they should be in a
170 > > combined list with labels, and i'd like to be able to open them by typing the
171 > > name in the search prompt.
172 >
173 > You can presse enter after searching to get a list, but I agree, it
174 > could be a streamlined way to do these things.
175
176 that's what i do now, i hardwired \+enter as the key-sequence to get the list.
177 but it means i have to deal with two lists, which is not wrong, but a merged
178 list would be nice as a 3rd option.
179
180 > This is great, if you are interested I could set you up as an
181 > contributor on the github organization and you could push your changes
182 > to the use-mail branch. With your changes and especially if we get
183 > crypto working on Mail I would switch completely as well.
184
185 let me work on my own repo for a while, as i am quite new to ruby, learning it
186 as i go along, so i don't feel confident to make commits without anyone
187 reviewing them. (actually, i think, if at all possible any commit to a project
188 should be reviewed by at least one other person)
189
190 but thanks for the offer. i am sure in time we'll see
191 whether my work is good enough.
192
193 greetings, martin.
194
195 --
196 eKita - the online platform for your entire academic life
197 hackerspace beijing - http://qike.info
198 --
199 chief engineer eKita.co
200 pike programmer pike.lysator.liu.se caudium.net societyserver.org
201 BLUG secretary beijinglug.org
202 foresight developer foresightlinux.org realss.com
203 unix sysadmin
204 Martin B?hr working in china http://societyserver.org/mbaehr/
205
206 From steven@schmeiser.org Wed Apr 2 00:42:35 2014
207 From: steven@schmeiser.org (Steven Schmeiser)
208 Date: Tue, 01 Apr 2014 20:42:35 -0400
209 Subject: [sup-devel] spam and maildirroot
210 Message-ID: <1396399147-sup-1409@indy.local>
211
212 I'm trying to figure out if this is the intended behavior with the maildir-root branch.
213
214 When I get a new message in my inbox and mark it as spam, it also gets added to the archive folder. Looking briefly at the code, it looks like threads marked as spam or deleted skip the ensure_in_archive step (and the debug logs confirm this), but it must be getting added to the archive at some other point? Thanks for any pointers.
215
216 steve
217
218
219 From matthieu.rakotojaona@gmail.com Thu Apr 3 20:16:19 2014
220 From: matthieu.rakotojaona@gmail.com (Matthieu Rakotojaona)
221 Date: Thu, 03 Apr 2014 22:16:19 +0200
222 Subject: [sup-devel] [sup] Maildir root: Keep labels in sync with
223 maildir folders (#253)
224 In-Reply-To: <18152441-C2B3-4454-B1E1-3242F62E7412@schmeiser.org>
225 References: <sup-heliotrope/sup/pull/253@github.com>
226 <sup-heliotrope/sup/pull/253/c37732781@github.com>
227 <1395042468-sup-5821@qwerzila>
228 <18152441-C2B3-4454-B1E1-3242F62E7412@schmeiser.org>
229 Message-ID: <1396556151-sup-8951@kpad>
230
231 Hey Steven,
232
233 Turns out that $dayjob was far longer than expected.
234
235 I've pushed a PR at https://github.com/sup-heliotrope/sup/pull/286 that
236 should solve your issue. Could you please have a go at it ?
237
238 --
239 Matthieu Rakotojaona
240 -------------- next part --------------
241 A non-text attachment was scrubbed...
242 Name: signature.asc
243 Type: application/pgp-signature
244 Size: 966 bytes
245 Desc: not available
246 URL: <http://rubyforge.org/pipermail/sup-devel/attachments/20140403/d6ae23ba/attachment.bin>
247
248 From m.klinik@gmx.de Tue Apr 8 12:59:46 2014
249 From: m.klinik@gmx.de (Markus Klinik)
250 Date: Tue, 08 Apr 2014 14:59:46 +0200
251 Subject: [sup-devel] documentation for removing a source
252 Message-ID: <1396961864-sup-9525@x200>
253
254 Hi,
255
256 I wrote a wiki page on how to remove a source. Can you review it for
257 correctness and comprehensibility?
258
259 https://github.com/sup-heliotrope/sup/wiki/Removing-A-Source
260
261 Thanks!
262 Markus
263
264 From matthieu.rakotojaona@gmail.com Tue Apr 8 18:34:25 2014
265 From: matthieu.rakotojaona@gmail.com (Matthieu Rakotojaona)
266 Date: Tue, 08 Apr 2014 20:34:25 +0200
267 Subject: [sup-devel] documentation for removing a source
268 In-Reply-To: <1396961864-sup-9525@x200>
269 References: <1396961864-sup-9525@x200>
270 Message-ID: <1396981865-sup-5808@kpad>
271
272 Excerpts from Markus Klinik's message of 2014-04-08 14:59:46 +0200:
273 > Hi,
274 >
275 > I wrote a wiki page on how to remove a source. Can you review it for
276 > correctness and comprehensibility?
277 >
278 > https://github.com/sup-heliotrope/sup/wiki/Removing-A-Source
279 >
280 > Thanks!
281 > Markus
282
283 Looks good to me.
284
285 I personally had to re-index my whole index, and I followed pretty much
286 those steps with success.
287
288 --
289 Matthieu Rakotojaona
290 -------------- next part --------------
291 A non-text attachment was scrubbed...
292 Name: signature.asc
293 Type: application/pgp-signature
294 Size: 966 bytes
295 Desc: not available
296 URL: <http://rubyforge.org/pipermail/sup-devel/attachments/20140408/5e6893d2/attachment-0001.bin>
297
298 From eg@gaute.vetsj.com Fri Apr 11 07:20:14 2014
299 From: eg@gaute.vetsj.com (Gaute Hope)
300 Date: Fri, 11 Apr 2014 09:20:14 +0200
301 Subject: [sup-devel] release 0.17.0
302 Message-ID: <1397200723-sup-7099@qwerzila>
303
304 greetings,
305
306 sup 0.17.0 is out, get it at rubygems: $ gem install sup.
307
308 Release notes:
309 > == 0.17.0 / 2014-04-11
310 >
311 > * add continuous scrolling to thread view
312 > * add option for always editing in async mode
313 > * bugfix: fix completion char
314 > * bugfix: thread-view: dont close message when it is the first or last
315
316
317 - gaute
318
319 -------------- next part --------------
320 A non-text attachment was scrubbed...
321 Name: signature.asc
322 Type: application/pgp-signature
323 Size: 836 bytes
324 Desc: not available
325 URL: <http://rubyforge.org/pipermail/sup-devel/attachments/20140411/f1d39e94/attachment.bin>
326
327 From eg@gaute.vetsj.com Thu Apr 24 08:07:20 2014
328 From: eg@gaute.vetsj.com (Gaute Hope)
329 Date: Thu, 24 Apr 2014 10:07:20 +0200
330 Subject: [sup-devel] more colors for you
331 Message-ID: <1398326551-sup-1169@qwerzila>
332
333 Hi,
334
335 Thanks to several contributors we've now gotten a bunch of new
336 colorschemes in https://github.com/sup-heliotrope/sup-colors, most of
337 them with screenshots.
338
339 Also: It is now also possible to customize the attachment char color
340 (76ab78ef00) using the :with_attachment property. Check out the new
341 default colors in the template folder for color schemes:
342 https://github.com/sup-heliotrope/sup-colors/tree/master/template
343
344 - gaute
345
346 -------------- next part --------------
347 A non-text attachment was scrubbed...
348 Name: signature.asc
349 Type: application/pgp-signature
350 Size: 836 bytes
351 Desc: not available
352 URL: <http://rubyforge.org/pipermail/sup-devel/attachments/20140424/60a20faa/attachment.bin>
353