TODO 42.7 KB
Newer Older
1
2
-*- Mode: outline; -*-

David Kågedal's avatar
David Kågedal committed
3
Att göra i elisp-klienten
David Kågedal's avatar
David Kågedal committed
4
5
=========================

David Byers's avatar
David Byers committed
6
7
8
9
10
11
Kolla alla användningar av length och substring för att se var man
borde använda string-width och truncate-string-to-width istället.

Kolla alla aset och aref så att de inte använder tecken som nyckel
utan omkodning till iso-8859-1 först.

12
13
14
15
MULEifiera hanteringen av user-arean.

Kolla att spara text sparar med en vettig kodning.

David Byers's avatar
David Byers committed
16
17
18
19
20
21
22
Bli av med lyskom-is-parsing, gör parsern reentrant, installera
reentrant blocking-do. Se över alla användningar av lyskom-wait-queue
eftersom den just nu inte kan användas i svar på asynkront anrop.

* Den parsade strängen måste bort innan man anropar callback-funktionen.


David Byers's avatar
David Byers committed
23
24
25
26
27
28
29
30
ispell-hooken rättar ärendet i bufferten men det blir inte rättat i
den inskickade versionen av inlägget. KAnske.

Om det kommer ett async-new-recipient och vi inte kan hitta lokalt
textnummer i mottagaren, ignorera meddelandet. 



31
32
33
34
Någon form at reply till importerade brev som använder mx-reply-to
eller mx-to, mx-cc om de finns.


David Byers's avatar
David Byers committed
35
36
37
            Om du fixar någonting som står med på den här
            listan, glöm inte att ta bort det från listan!

38
39
40
41
42
Testa vad som händer om man har en ogiltig misc-item eller aux-item i
headersarna när man adderar en mottagare eller flyttar ett inlägg
eller adderar en aux-item eller tar bord en aux-item.


43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
initiate-get-membership skulle kunna fylla i positionen för
medlemskapet automatiskt. Tyvärr går det inte att göra så i
query-read-texts.

När man får en new-membership async så borde man kolla att
medlemskapet verkligen har ändrats, och bara då göra något.

lyskom-add-member eller vad den nu heter kan hitta rätt position inom
en prioritet genom att lägga det nya medlemskapet först eller sist och
sedan sortera listan. Då kommer det nya medlemskapet att få rätt
position inom prioriteten. Först därefter behöver man tala om för
servern.

lyskom-sort-membership skulle kunna hålla servern uppdaterad genom att 
se efter när man har gett ett medlemskap en ny position, och i så fall 
tala om det för servern. Om man dessutom kan den gamla positionen så
borde man kunna räkna fram vilka positioner övriga medlemskap vars
gamla positioner man känner till har fått för nya positioner. Det kör
förstås ihop sig helt om man inte vet den gamla positionen för ett
möte, men det är smällar man får ta, som det heter.
David Byers's avatar
David Byers committed
63

David Byers's avatar
David Byers committed
64
65
66
67
68

Som det ser ut just nu, om man gör hantera medlemskap och sedan loggar 
in som en ny person i LysKOM-bufferten så blir det fel saatan eftersom 
prioriterabufferten använder lyskom-pers-no.

69
70
71
72
När man har kört prefetchen får man en skum kö i lyskom-prefetch-stack 
som inte innehåller något annat än element som är köer vars sista
element är FINISHED. Ibland verkar köerna bli cirkulära.

David Byers's avatar
David Byers committed
73
74
Man borde använda next-command-event med vänner i silent-read och
j-or-n-p.
75
76
77
78
79
80

lyskom-get-texts-to är buggig. Om man återser senaste N av vem som
helst till ett möte och det inte finns N texter så buggar den ur. Den
borde klippa till max texter i mötet.


81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
Använd face-flag i lyskom-format-aux för att bestämma om man skall
visa faces eller inte. Kolla att 

1) det går att visa faces
2) lyskom-show-faces är satt

innan man försöker. Man skulle till och med kunna sätta face-flag
efter de här villkoren. Lägg till användarvariabeln kom-show-faces som 
talar om när man vill ha faces:

0) alltid/aldrig
1) vilkalistan (working conf och person)
2) status möte/person   (föreslagen default)
3) varje inlägg
4) brev
5) in- och utloggningar
6) personliga meddelanden
7) mottagarna till inlägg
8) namnändring

dessa funktioner får sedan binda om lyskom-show-faces dynamiskt till
true eller false.

Visa bilder mindre än X * Y pixels, mindre än X bytes

Kombinera med möjlighet att bara visa bilder för kom-friends

För varje punkt på listan, tala om vilka man vill eller inte vill se
bilder för. 


David Byers's avatar
David Byers committed
112

113
* SAKER ATT KOLLA TILL 0.46
David Byers's avatar
David Byers committed
114

115
116
117
118
119
120
121
    Medlemskapslistan kan bli osorterad på många olika sätt. Klienten
    måste klara av detta.
    . Man kan adderas till ett möte så det ligger osorterat i listan.
    . När man går med i ett möte själv så hamnar det i allmänhet osorterat.
    Elispklienten borde kanske upptäcka när listan verkar osorterad
    och i det läget sortera om den lokalt och i servern. Det skulle
    till exempel kunna sk
David Byers's avatar
David Byers committed
122

123
    Testa lyskom-is-anonymous!
David Byers's avatar
David Byers committed
124

125
126
    Prioritet noll är tillåten. Kolla alla strängar som nämner
    prioriter så att det står rätt i dem.
David Byers's avatar
David Byers committed
127

128
129
    Hur och var skall man egentligen spara inställningar? .emacs är
    kanske inte det bästa alternativet. 
David Byers's avatar
David Byers committed
130
131


132
* BUGGAR
David Kågedal's avatar
David Kågedal committed
133

David Byers's avatar
David Byers committed
134
135
** OSORTERADE

136
    Om förbindelsen bryts så får man args out of range ibland.
David Byers's avatar
David Byers committed
137
    FIX BY: 0.46
138
139
140
141

    Om förbindelsen bryts i en buffert så ofungerar scrollningen en
    gång i en annan buffert. Man trycker SPC och får inte nästa
    kommando, utan hamnar överst i bufferten.
David Byers's avatar
David Byers committed
142
    FIX BY: ---
143

144
145
146
147
148
    Om man byter buffert med C-x b till den sista aktiva KOM-bufferten
    så tycker Nästa LysKOM att det inte finns fler aktiva
    KOM-sessioner. Funktionen verkar vara lite för känslig för hur
    lyskom-buffer-list ser ut. Den borde nog göra något lite
    intelligentare när listan ser ut att ha tagit slut.
David Byers's avatar
David Byers committed
149
    FIX BY: 0.46        KLART
150

David Byers's avatar
David Byers committed
151
152
    Peter Enderborg hade en 118 tecken bred XEmacs 20.3 med scrollbar,
    och vilkalistan blev precis 1 tecken för bred. I Gnu Emacs 19.30
153
    blev det rätt. Det verkar som om window-width ljuger.
David Byers's avatar
David Byers committed
154
    FIX BY: N/A
David Byers's avatar
David Byers committed
155
156
157
158
159
160

    Race condition när man skickar in inlägg. Fönsterkonfigurationen
    återställs asynkront, och det går att trycka C-c C-c k
    tillräckligt fort att man skapar den nya inläggsbufferten innan
    den gamla fönsterkonfigurationen (för den förra inläggsbufferten)
    återställs. Resultatet är att man aldrig ser den nya bufferten.
David Byers's avatar
David Byers committed
161
    FIX BY: 0.46-0.47
David Byers's avatar
David Byers committed
162
163
164

    Endast gör fortfarande fel. Den klarar inte hål och använder inte
    set-last-read, utan set-unread.
David Byers's avatar
David Byers committed
165
    FIX BY: ---
David Byers's avatar
David Byers committed
166
167


168
169
** VIKTIGA BUGGAR

David Byers's avatar
David Byers committed
170
171
172
** OMBRYTNING

    Vi klarar inte emailheaders som är brutna över flera rader.
David Byers's avatar
David Byers committed
173
174
175
176
177
    Klienten tror att den indragna fortsättningen är början på ett
    nytt stycke. Man skulle kunna tänka sig att nytt-stycke-regeln
    inte gör nytt stycke om alla rader har börjat med ord: och man
    hamnar på en indragen rad. Indragna rader skulle inte sabotera
    ord:-prefixet. 
David Byers's avatar
David Byers committed
178
    FIX BY: 0.46-0.47
David Byers's avatar
David Byers committed
179
180


181
** DEFERRED INSERT
182

David Byers's avatar
X    
David Byers committed
183
184
185
    lyskom-replace-deferred verkar inte använda lyskom-last-viewed i
    alla fall. Och den beter sig fel när man står vid prompten och
    vill bläddra bakåt.
David Byers's avatar
David Byers committed
186
    FIX BY: ---
187

188
    Om ett namn som fylls i i efterhand gör att sista raden blir för
David Byers's avatar
David Byers committed
189
190
191
    lång, så scrollar klienten trots att den inte borde. David Kågedal
    trodde att han hade fixat det. (Detta är en gammal rapport. Den
    kanske inte stämmer.)
David Byers's avatar
David Byers committed
192
    FIX BY: --- (check before release of 0.46)
193
194
195
196


** PREFETCH 

David Byers's avatar
X    
David Byers committed
197
198
199
    Dubbla prefetcher kan vara väldigt förvirrande. Om man t.ex. gör
    endast i ett möte (säg IÅM) innan det prefetchas får man två
    parallella prefetcher på samma möte.
David Byers's avatar
David Byers committed
200
    FIX BY: 
David Kågedal's avatar
David Kågedal committed
201

202
    Gå ur mötet man prefetchar genererar en bug.
203
    FIX BY: 0.46            FIXED
204

205
206
    Om man går till ett möte som inte prefetchats och inte har några
    inlägg blir promten fel, och man får ett felmeddelande.
David Byers's avatar
David Byers committed
207
    FIX BY: 0.46
208

209
210
211

** COMPLETING READ

212
213
214
215
216
    Om man skriver in ett namn exakt, modulo parenteser, borde det
    *antagligen* accepteras som exakt. Jus nu krävs det att man
    skriver in parenteserna också. Problem uppstår till exempel om det
    finns två möten "(På) TV" och "(Gamla) TV-spel erfarenhetsutbyte".
    Om man skriver in "TV" så betraktas det inte som en exakt match.
217
    FIX BY: 0.46-0.47                           KLART!
David Byers's avatar
David Byers committed
218
219
220
221
222
223
224
225
226
227
228
229

    Man kan få oländiga loopar i completion. Just nu är det inte så
    lätt, men det går fortfarande. Problemet uppstår då två teckern
    har spacesemantik men inte mappas till samma tecken av
    collate-tabellen. Den riktiga fixen är i två steg: (1) se till att
    collate-tabellen alltid mappar alla space till space (2) se till
    att lyskom-complete-string kan detektera en oländig loop och
    stoppa den. 
        Minitestfall: (lyskom-complete-string '("L\t" "L s")).
        Problem uppstår om man får space-mismatch pga att två olika
        tecken med spacesemantik mismatchar (fin svenska, eller hur.)
        Man borde få match när det inträffar.
David Byers's avatar
David Byers committed
230
    FIX BY: 0.46
David Byers's avatar
David Byers committed
231

David Byers's avatar
David Byers committed
232
233
234
235
236
    lyskom-read-session-no hanterar inte att man anger specifikt
    sessionsnummer om samma person har flera sessioner, tror jag.
    Problemet är att s xxxx hanteras i lyskom-read-conf-internal som
    bara kan returnera conf-z-info. Man borde låta den returnera info
    om specifikt sessionsnummer också.
David Byers's avatar
David Byers committed
237
    FIX BY: Whenever
David Byers's avatar
David Byers committed
238
239
240
241

    Fixa så LysKOM och complete.el fungerar ihop genom att sätta om
    samma mappar som complete.el gör, till wrappers runt complete.el
    som kollar om completion är LysKOM-completion eller något annat.
David Byers's avatar
David Byers committed
242
    FIX BY: Whenever
David Byers's avatar
David Byers committed
243

244
245
246

** HANTERING AV FOTNOTER

David Kågedal's avatar
David Kågedal committed
247
248
    Den försöker fortfarande följa hemliga kommentarer om
    kom-show-footnotes-immediately är satt.
David Byers's avatar
David Byers committed
249
    FIX BY: --- (Check before release of 0.46)
David Kågedal's avatar
David Kågedal committed
250

251
252
253
    Om man läser ett inlägg som har en fotnot (t ex 1449843) och vill
    spara det på fil, så blir det bara fotnoten som sparas.  Man vill
    nog spara minst själva huvudinlägget, och nog också fotnoterna
David Byers's avatar
David Byers committed
254
255
256
257
    samtidigt. [Pja, det är faktist meningen att det skall funka så
    här. Spara text sparar sisa inlägget man tittade på.
    Prefixargument ger fler. Frågan om det är *bra* eller inte är en
    helt annan...]
David Byers's avatar
David Byers committed
258
    FIX BY: ---
259

260
    Fotnoter som visas på en gång filtreras inte. [verkar fixat]
David Byers's avatar
David Byers committed
261
    FIX BY: --- (Check by 0.46)
David Kågedal's avatar
David Kågedal committed
262

David Kågedal's avatar
David Kågedal committed
263
264
    kom-review-tree på en text med fotnoter visar fotnoterna på en
    gång. Är det en bug?
David Byers's avatar
David Byers committed
265
    FIX BY: 
David Kågedal's avatar
David Kågedal committed
266

267
268

** PROMPTEN
David Kågedal's avatar
David Kågedal committed
269

270
271
    När jag ska läsa en kommentar till ett brev i min brevlåda så blir
    prompten "Läsa nästa brev" i stället för "Läsa nästa
David Byers's avatar
David Byers committed
272
273
    kommentar". Kommentaren ligger inte i brevlådan.
    FIX BY: --- 
274

David Byers's avatar
David Byers committed
275

276
277
278
279
280
** HEISENBUGS

    Sentinelmeddelanden i ikoniferade frames buggar. Prova att kasta
    ut en session i ett ikonifierat fönster. Eller kanske till och med
    bara i en gömd buffert.
David Byers's avatar
David Byers committed
281
    FIX BY: --- (Check by 0.46)
282
283

    Tommy Persson får LysKOM protocol error. Det kan bero på strulande
David Byers's avatar
David Byers committed
284
285
    modem. Tyvärr var det någon annan som också fick det, som kanske
    inte sitter bakom modem. Nu fick Kågedal också problemet, men
286
    fortfarande kan ingen reproducera det. Nu har jag också fått det. 
David Byers's avatar
David Byers committed
287
    FIX BY: YESTERDAY
288
289
290



David Byers's avatar
David Byers committed
291
292
* FÖRBÄTTRINGAR

293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
** PRIORITERA MÖTEN
    
    Skriv klart Hantera medlemskap (aka prioritera möten.) Se till att 
    den hålls uppdaterad när man
    . Går med i ett möte
    . Passiviserar ett möte
    . Går ur ett möte
    . Ändrar prioritet på ett möte
    . Ett möte byter namn
    . Man byter namn på sig själv
    . Man ändrar mötestyp
    . Man ändrar medlemskapstyp
    . Man blir utkastad ur ett möte
    . Man blir adderad till ett möte
    . Ett möte raderas
    . Man skapar ett möte (och blir med i det)

    Funktioner som borde finnas:
    . Endast läsa senaste N i alla markerade möten
    . Samma funktioner som i gamla prioritera möten
    . Uppdatera all information
    . Ändra namn på ett möte
    . Ändra typ på ett möte



319
320
** LÄSA INLÄGG

321
322
323
324
325
    Ceder tycker att Återse omodifierat skulle visa headerrader som
    man normalt hoppar över. Det är saker som till exempel
    creating-software.
    FIX BY: 0.46

326
    Det vore skoj om lyskom.el kunde, som jag har för mig att någon
David Byers's avatar
David Byers committed
327
328
329
330
331
332
    föreslog en gång, parsa fotnoter av det där slaget [sed-mönster
    ungefär] och applicera dem på texten. Det korrigerade inlägget
    skulle ha formatmarkeringen (korrigerad av 123455) i foten. Återse
    omodifierat skulle visa inlägget okorrigerat. Den korrigerande
    fotnoten visas inte i den normala läsordningen och markeras som
    läst automatiskt.
333
334
335
336
337

        * Krävs inkrokningar view-text.el för att inte skriva ut att
          det finns en fotnot.
        * Krävs mer flexibel formatmarkering.
        * Krävs att man hämtar fotnoter innan man visar inlägget.
David Byers's avatar
David Byers committed
338
        * Troligtvis är det bättre att använda aux-items för detta.
339

David Byers's avatar
David Byers committed
340
341
    FIX BY: 0.46-0.47

342

David Byers's avatar
David Byers committed
343

David Byers's avatar
David Byers committed
344
** SKRIVA INLÄGG
David Byers's avatar
David Byers committed
345

David Byers's avatar
David Byers committed
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
    Frågan om flera mottagare kanske inte borde ställas om man har
    arrangerat om mottagarlistan rejält. Den skall ställas om man
    lägger till en mottagare till en existerande. Den kanske inte
    behöver ställas om man har arrangerat om alla mottagare. Frågan är
    vad som händer mittemellan.

    Varningen om olästa kommentarer är inte perfekt. Det finns flera
    förslag till ändringar. Ett är att varna bara för kommentarer som
    skapades efter man började skriva kommentaren, men det verkar vara
    en kompromiss. Minst en som efterfrågade det ville i själva verket
    kunna slå på/av varningarna per möte. Bellman ville att varningen
    inte skulle gå att slå av helt med mindre än att man explicit slår
    av den i alla möten som man är med i.

        * Den rätta saken att göra är antagligen att göra det möjligt
          att ge variabeln ett defaultvärde och ha möjlighet att ge
          undantag. 

        * Defaultvärden skulle kunna vara varna, varna inte och varna
          för nya. Ett förslag är också att varna för nya enbart om
          man har läst minst en eller kanske alla av kommentarerna
          till inlägget man kommenterar.

        * Eventuellt skulle det vara bra med en varning innan man
          börjar kommentera om kommentarer som redan finns där. Den
          varningen borde vara oberoende av den som kommer när man
          skickar in.

    Addera det kommenterades författare som mottagare vid behov när
    man börjar skriva inlägget. Se till att inte gnälla om denna
    mottagare när man skickar in inlägget.

        * När man börjar skriva inlägg, håll reda på att man har lagt
          till författare automatiskt, och försök låta bli att gnälla
          om dessa. 

        * Hans Persson ville att att det kommenterades författare
          skulle läggas till automatiskt, men att om man har editerad
          headrarna så skulle kontrollen göras om igen när man
          skickade in inlägget. Dock skulle den *inte* göras om man
          manuellt tog bort det kommenterades författare (det här
          skulle hindra att man tog bort mottagare så att det
          kommenterades författare blev utan.) Hans Persson har helt
          rätt.
David Byers's avatar
David Byers committed
390

391
392

** EDIT-BUFFERTEN
David Kågedal's avatar
David Kågedal committed
393

David Byers's avatar
David Byers committed
394
    Defaultplaceringen av nya mottagare i editbufferten är fånig.
David Byers's avatar
David Byers committed
395
    FIX BY: 0.46            FIXAT. Sist istf först.
David Byers's avatar
David Byers committed
396
397
398
399

    Det borde gå att ändra mottagare till cc-mottagare genom att bara
    lägga till mottagaren igen som cc-mottagare. Motsvarande för bcc
    och så vidare.
David Byers's avatar
David Byers committed
400
    FIX BY: 0.46            FIXAT
David Byers's avatar
David Byers committed
401

402
403
    Borde kolla efter dublettmottagare innan man skickar in inlägget.
    Annars så får man ett tråkigt felmeddelande från servern.
David Byers's avatar
David Byers committed
404
    FIX BY: 0.46            FIXAT
405
406
407
408

    Kolla hur misslyckad inskickning hanteras. Vi borde ajtomagiskt
    ploppa upp edit-bufferten, alternativt ha ett kommando för att
    göra det (och göra det till defaultkommandot.)
David Byers's avatar
David Byers committed
409
    FIX BY: 0.46
David Byers's avatar
David Byers committed
410
411
412

    Man borde kunna manipulera mottagare i editbufferten med musen (ta
    bort, ändra typ.)
David Byers's avatar
David Byers committed
413
    FIX BY: 0.46
David Byers's avatar
David Byers committed
414

David Byers's avatar
David Byers committed
415

416
** FILTER
David Byers's avatar
David Byers committed
417

418
    Ny filter-edit-mode
David Byers's avatar
David Byers committed
419
    FIX BY: 0.48
420
421

    Använd den nya filterkompilatorn.
David Byers's avatar
David Byers committed
422
    FIX BY: 0.48
423
424
425
426
427
428

    Gör inte nästa kommando efter en filtrering. Kontrollera med
    variabel.


** ASYNKRONA MEDDELANDEN
David Byers's avatar
David Byers committed
429

David Byers's avatar
David Byers committed
430
431
    Färgläggning av meddelanden baserat på varifrån de kommer, och
    vart det går. John Olsson efterfrågar.
David Byers's avatar
David Byers committed
432
    FIX BY: 0.47
David Kågedal's avatar
David Kågedal committed
433

434
    Filtrera asynkrona meddelanden (Pontus Lidman)
David Byers's avatar
David Byers committed
435
    FIX BY: 0.47
436
437
438
439


** MEDLEMSSKAPSINFORMATION

David Byers's avatar
X    
David Byers committed
440
    Lista medlemsskap borde hållas uppdaterad. Vi behöver hookar för
441
442
443
444
    - Gå in i möte (uppdatera datum)
    - Ändra prioritet (det har vi)
    - Ändra olästa
    - Invalidera conf-stat (kanske)
David Byers's avatar
X    
David Byers committed
445
446
447
    Plus att vi måste fixa en datastruktur till bufferten. Vilket slit.
    Kanske kan man mergea prioritera och lista medlemsskap? Det skulle
    ju förenkla...
David Byers's avatar
David Byers committed
448
    FIX BY: 0.48
David Byers's avatar
X    
David Byers committed
449

450
451
452
453
454
455
456
457
458
** MANIPULERA MEDLEMSKAPSTYPEN

    Lägg till kommandot ändra medlemskapstyp.
    FIX BY: 0.46
 
    När man accepterar en inbjudan borde man automatiskt prioritera om
    den enligt ens defaultprioritet och defaultposition.
    FIX BY: 0.46

459
460
461

** ÅTERSE

David Byers's avatar
X    
David Byers committed
462
463
464
    Återse senaste borde vara superinkrementell. Man kunde hämta så
    mycket man hinner under säg tre sekunder och stoppa någonting på
    read-listan som hämtar nästa tre sekunder eller så.
David Byers's avatar
David Byers committed
465
    FIX BY: 0.47 or later
David Byers's avatar
X    
David Byers committed
466
467

    "Återse n inlägg av person x till möte y från datum z framåt"
David Byers's avatar
David Byers committed
468
    FIX BY: 0.47 or later
David Byers's avatar
X    
David Byers committed
469
470

    "Återse n inlägg av person x till möte y under de senaste k dagarna"
David Byers's avatar
David Byers committed
471
    FIX BY: 0.47 or later
David Byers's avatar
X    
David Byers committed
472

David Kågedal's avatar
David Kågedal committed
473
    Strunta i hemliga texter vid åar.
David Byers's avatar
David Byers committed
474
    FIX BY: 0.46-0.47
David Kågedal's avatar
David Kågedal committed
475

476
    Återse alla markerade borde gå att avbryta med nästa möte.
David Byers's avatar
David Byers committed
477
    FIX BY: 0.46-0.47           NOTE: Verkar fungera
David Kågedal's avatar
David Kågedal committed
478

David Byers's avatar
David Byers committed
479
480
    Det vore trevligt om inlägg man återsåg inte bidde varnade för när
    man skriver kommentarer.
David Byers's avatar
David Byers committed
481
    FIX BY: Who knows?
David Byers's avatar
David Byers committed
482

483

484
485
486
** INTERNA SAKER

    Inför en membership-cache.
487

David Kågedal's avatar
David Kågedal committed
488
489
    Har detta att göra med lite för optimistisk cache att göra? Kanske
    bör man läsa om person-staten innan man varnar för lapp på dörren?
490
    [Det gör man väl? /davidk]
David Kågedal's avatar
David Kågedal committed
491

492
    Använd blocking.el som innehåller en reentrant blocking-do.
David Byers's avatar
David Byers committed
493
    FIX BY: 0.47
494

495
496
497
498
499
500

** FOTNOTER

    Skriv inte ut stora fonoter på en gång.

    Visa fotnoter på ett bättre sätt.
David Kågedal's avatar
David Kågedal committed
501

David Byers's avatar
X    
David Byers committed
502
    Kommandot kom-review-comments visar fotnoter sist, inte först.
503

David Kågedal's avatar
David Kågedal committed
504
    Det skulle vara bra om skönsvärde för att skriva fotnot vore den
David Byers's avatar
David Byers committed
505
506
    senaste text man själv skrev, inte den senaste man läste. Eller
    kanske den senaste man läste om det var man själv som skrev den?
507
508
    Snarare den sista man läste av sig själv alt. den sista man skrev
    om man inte har läst något av sig själv sedan dess.
David Byers's avatar
David Byers committed
509
    FIX BY: 0.46-0.47
510

David Byers's avatar
X    
David Byers committed
511

512
513
** ANVäNDARVäNLIGHET

David Byers's avatar
David Byers committed
514
515
516
    Man skulle kunna låta fönstrets titelrad indikera om man har
    olästa i någon session. Det skulle vara praktiskt för oss som har
    KOM igång ikonifierad i en separat Emacs större delen av tiden.
David Byers's avatar
David Byers committed
517
518
    FIX BY: 0.48

519
    Klickbara kommandon, vad nu det är.
David Byers's avatar
David Byers committed
520
    FIX BY: 0.48
521

David Byers's avatar
David Byers committed
522
523
524
    Det behövs dokumentation: fråmst användarhandledning, men det
    skulle inte skada med en kortfattad beskrivning av stabila delar
    av systemet för presumtiva kommandoskribenter.
David Byers's avatar
David Byers committed
525
    FIX BY:
David Byers's avatar
David Byers committed
526

David Byers's avatar
David Byers committed
527
    Språkgranskning av den engelska versionen.
David Byers's avatar
David Byers committed
528
    FIX BY:
529

David Byers's avatar
David Byers committed
530
531
532
    Det skulle vara bra om man kunde ange för varje inställning om den
    skulle sparas i servern eller inte. I princip är det enkelt, men
    det behövs ett gränssnitt för det.
David Byers's avatar
David Byers committed
533
    FIX BY: 0.46
David Byers's avatar
David Byers committed
534
535
536
537
538
539
540
541


** AUX-ITEMS

    Implementera en FAQ aux-item. Detta kommer att kräva en flagga
    till i servern som talar om för servern att inte garba ett inlägg.
    Det i sin tur kräver att man fixar dbck att forcera garb av inlägg
    med den här flaggan som inte borde ha den eller nåt sånt.
542
    FIX BY: 0.46                                    KLART!
543
544


David Byers's avatar
David Byers committed
545
** MARKERINGAR
David Byers's avatar
David Byers committed
546

David Byers's avatar
David Byers committed
547
    JySKomska markeringstyper.
David Byers's avatar
David Byers committed
548
    FIX BY: 0.47-0.48
David Byers's avatar
David Byers committed
549
550


551
552
553
554
555
556
557
** PREFETCH

    Förbättra prefetchen. Till exempel borde ett mötes inlägg
    prefetchas vid lämpligt tillfälle, t.ex. när man går till
    det. Idag prefetchas bara kommentarskedjor.


David Byers's avatar
David Byers committed
558
** DIVERSE OSORTERAT
David Byers's avatar
David Byers committed
559

560
561
    Lista sessioner, ungefär som lista klienter, men som ger mer
    sessionsinformation, till exempel idletid. Önskad av David Hedbor.
David Byers's avatar
David Byers committed
562
    FIX BY: 0.47-0.48
563

564
    Sortera vilkaslistan efter t.ex. idletid.
David Byers's avatar
David Byers committed
565

David Byers's avatar
David Byers committed
566
567
568
    Lista nyheter borde göra start of command innan den pratar om att
    vänta på medlemskapslistan. Den gör rätt ibland, men inte alltid.

David Byers's avatar
David Byers committed
569
570
571
572
573
    Man borde använda get-unread-confs för att lista ut vilka
    medlemsskap som skall prefetchas först. Då måste man ordna så att
    ingenting är beroende av att medlemsskapslistan hämtas i
    prioritetsordning. Prefetchen måste kunna sortera in medlemsskap i
    prioritetsordning när den får dem från servern.
David Byers's avatar
David Byers committed
574
    FIX BY: 0.47
David Byers's avatar
David Byers committed
575

David Byers's avatar
David Byers committed
576
577
578
    kom-show-presence-messages borde kunna ha ett alternativ som gör
    att kom-friends används, så man får närvaromeddelanden enbart om
    sina vänner. Uppdatera även inställningsbufferten.
579

580
581
582
583
584
    Det finns rester av den gamla vilkabufferten kvar i koden i
    cache.el.

    Skriv ihop hantera medlemskap (prioritize-new.el.) Den skall
    utnyttja den nya medlemskapsstrukturen.
David Byers's avatar
David Byers committed
585

David Byers's avatar
David Byers committed
586
587
588
    Implementera anonyma medlemskap i klienten. Detta är inte långt
    ifrån klart. Vi har hemliga medlemskap och behöver bara en hook
    att bli anonym när man går in i mötet.
David Byers's avatar
David Byers committed
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
    
    Implementera re-z-lookup med re-lookup-X så att vi kan återinföra
    maximal kompatibilitet.


** KOLLA ATT DETTA ÄR KLART

    Om man återser senaste av sig själv så kan man råka få se sin
    user-area.

    LysKOM fungerar inte i XEmacs i tty-mode. No such face:
    kom-active-face. Antingen är det fixat eller så är det inte fel i
    20.2. Jag har noterat liknande problem i 19.30 i Sun-consolen.
    FIX BY: 0.46        

    lyskom-format-html får inte försöka formattera som HTML om det
    inte går att ladda w3.
    FIX BY: 0.46

    lyskom-w3-region får inte krascha. Stoppa condition-case runt.
    FIX BY: 0.46

    Buggar i special-insert gör att eoc inte körs, och man har inte
    läst inlägget. Man borde få inlägget läsmarkerat och få end of
    command.
    FIX BY: 0.46



618
619
620
621




David Byers's avatar
David Byers committed
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724


Jag skrev ett inlägg.  Gjorde sedan snabbt C-c C-c M return.
Markering försökte göras innan meddelandet om att inlägget skapats
kommit.  Det verkade låsa sig då och jag fick göra quit och koppla upp
mig igen.











Det vore trevligt om statusraden rapprterade om olästa endast för de
läsbuffrar som inte syns.

Exempel: jag står i läsbufferten där lyslyskom finns och jag har även
csdkom igång, men denna buffert syns inte.

	Olästa i	Olästa i	Status raden
	lyslys		csdkom		säger "olästa"?

	NEJ		NEJ		NEJ
	NEJ		JA		JA
	JA		NEJ		NEJ
	JA		JA		JA


På detta vis ser jag om det har dykt upp olästa i andra lyskomsystem.
Det just nu aktiva lyskomsystemet ser jag ju ändå statusen för.

Naturligtvis bör beteendet vara valbart.





Jag har diverse små elips-snuttar knutna till krokar i elisp-klienten.
Ibland vill jag modifiera namnet på den frame där lyskom kör av lite
olika anledninger.  Den kod jag f.n. använder modifierar namnet på
aktiv frame oavsett om lyskom är synlig i den eller ej.  Finns det
något kanoniskt (eller i vart fall fungerande) sätt att ta reda på
vilken frame (om någon) som ska manipuleras med från ett
elisp-program?

Jag vill nedan uppnå att framen heter "<LYSKOMSERVER>" om jag inte har
några olästa (primitivt detekterat av ifall min klient får meddelande
om en ny text, att jag inte har olästa avgör jag baserat bara på att
jag utför *något* kommando i lyskom som framgår nedan) samt
"<LYSKOMSERVER> *" när det inkommit olästa texter.  Skillnaden mot
nedanstående kod är att jag just bara vill byta namn på den frame där
lyskom är synlig (eller inte ändra alls om lyskoms buffer är begravd).

Jag har följande kod i min .emacs (möjligen håller servern reda på
någon av krokarna utan att jag behöver ha dem med i koden nedan...).

(defun pbn-lyskom-name ()
  (let ((name (cdr (assoc lyskom-server-name kom-server-aliases))))
    (if (not name)
	(concat "Unknown KOM Server (" lyskom-server-name ")")
      name)))
(defun pbn-kom-frame-no-unread ()
  (modify-frame-parameters
   (selected-frame)
   (list (cons 'name (pbn-lyskom-name)))))

(defun pbn-kom-frame-unread ()
  (modify-frame-parameters
   (selected-frame)
   (list (cons 'name (concat (pbn-lyskom-name) " *")))))

(defun pbn-lyskom-login-hook ()
  (pbn-kom-frame-unread)  ; set initial frame string
  (add-hook 'lyskom-new-text-hook 'pbn-kom-frame-unread)
  (add-hook 'lyskom-after-command-hook 'pbn-kom-frame-no-unread))
(add-hook 'lyskom-login-hook 'pbn-lyskom-login-hook)









Ingen omformattering än, men nu ser det ut så här:

  (defvar lyskom-view-text-hook-hide-inserted-comments-marker " [---]"
    "The marker shown instead of inserted comment lines")

  (defun lyskom-view-text-hook-hide-inserted-comments ()
    "Hide junk lines, i.e., lines staring with '>'" 
    
    ;; First the hard part - should we patch the text
    ;; in the text object?
    ;; Don't rely on lyskom-format-special being non-nil,
    ;; rather check value of lyskom-current-command to see
    ;; whether the user asked for review-noconversion, i.e.,
    ;; "återse omodifierat".
725
    
David Byers's avatar
David Byers committed
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
    (if (not (equal lyskom-current-command
		    'kom-review-noconversion))
	
	;; Yes, modify the text (stored in mod)
	
	(let ((mod (aref (cdr text) 1)) ;The text in the text-object
	      (marker lyskom-view-text-hook-hide-inserted-comments-marker))
	  
	  ;; Remove empty lines between junk lines
	  (while (string-match
		  (concat "^\\s-*"
			  kom-cite-string
			  ".*\n\\(\\s-*\n\\)+\\s-*"
			  kom-cite-string
			  ".*")
		  mod)
	    (setq mod (concat (substring mod
					 0 (match-beginning 0))
			      (substring mod (match-end 0)))))
	  
	  ;; Hide, i.e., replace junk lines with value of
	  ;; lyskom-view-text-hook-hide-inserted-comments-marker
	  (while (string-match (concat "^\\(\\s-*" kom-cite-string ".*$\\)+")
			       mod)
	    (setq mod (concat
		       (substring mod 0 (match-beginning 0))
		       (format "\n\n%s\n\n" marker)
		       (substring mod (match-end 0)))))
	  
	  ;; Clean up, remove spurios empty lines
	  (while (string-match "\n\n\n+" mod)
	    (setq mod (concat
		       (substring mod 0 (match-beginning 0))
		       "\n\n"
		       (substring mod (match-end 0)))))
	  
	  ;; Patch the text-object with the modified text
	  (aset (cdr text) 1 mod))))

Hur var det man skrev för att ha en variabel i dokumentsträngen så att
värdet av variabeln används vid visandet av strängen?










Vill man ha hemliga medlemmar så vill man nog minska allt eventuellt
informationsläckage om att en viss person är eller har varit hemlig
medlem i ett möte.

Tvinga hemlig till ickehemlig: går det att få så att organisatör kan
säga att Sune inte får vara hemlig i möte Foo, dvs att det är tupeln
<person,möte> som hemlighetsprivlegiet ligger på? I så fall kanske
organisatören kan säga "Sune får endast vara medlem som ickehemlig".
Är Sune redan medlem och hemlig så är det utkastning (helst med
ihågkommen mötesstatus vad gäller vilka texter som är lästa) som ger
minst informationsläckage.

Konvertering av möte till ickehemligt: minst elakt vad gäller
informationsläckage vid konvertering till ickehemlighet är utkastning,
men den fd medlemmar vill nog få ett meddelande om att så har skett.
Automatiskt brev?

Andra reaktioner: jag ogillar tanken på hemliga medlemmar i de möten
där jag är medlem. Jag vill alltså få en massa varningar när jag blir
medlem i ett möte eller när ett möte ändrar status till att tillåta
hemliga medlemmar.

Jag är dessutom nyfiken och tror att det vore trevlig om kommandot
status möte anger inte bara om hemliga medlemmar är tillåtna utan även
hur många som är hemliga för tillfället.








Det vore trevligt om det funnes kommandon för att lista volka lyskom
man har olästa i.

Kanske i stil med att "lista lyskom" visade totalt antal olästa inlägg
man har i de olika lyskomsystemen som man är uppkopplad mot:

       | blahonga - Lista lyskom
       | 
       | Olästa Kortnamn        Server
       |     18 LysKOM          kom.lysator.liu.se
       |        CSD-KOM         kom.csd.uu.se
       |  18914 TokKOM          kom.stacken.kth.se
       | 
       | blahonga - Lista olästa (i lyskom)
       | 
       | Olästa Kortnamn        Server
       |     18 LysKOM          kom.lysator.liu.se
       |  18914 TokKOM          kom.stacken.kth.se
       | 
       | blahonga -











> För alternativa vyer finns för tillfället inget alternativ annat än
> att använda multipart/alternative eller något liknande. Iofs skulle
> man kunna tänka sig att man stoppar in information om delarna i en
> eller flera aux-items och talar om var i texten varje del börjar och
> slutar. Då skulle en klient kunna hämta bara de delar den vill ha.
> 
> Borde man göra så?

Ja, det tycker jag.  Nedan kommer två ogenomtänkta förslag på hur man
skulle kunna utforma dem.  Som exempel använder jag ett inlägg som har
den här strukturen:

	Byte	Innehåll
	0-24	Ärenderaden
	25-149	Texten i formatet x-kom/basic (dvs omformatterbar text)
	150-299	Texten i formatet text/html
	300-399	En liten ikon som används av HTML-versionen
	400-799	En shockwave-animation som används av HTML-versionen
	800-999	En stillbild som kan användas i stället för
		shockwave-animation av klienter som inte förstår shockwave

1.

En aux-item per textdel.  Varje aux-item innehåller en "rubriknivå",
en MIME-typ, offset och längd.  Ordet "rubriknivå" är dåligt, men jag
kommer inte på något bättre just nu.  Första siffran i en rubriknivå
anger vilken del det är; en klient ska normalt visa alla delar.  Andra
siffran, om den finns, anger olika alternativ inom en del.  Om det
finns en tredje siffra så består det alternativet i sin tur av en
sekvens av delar.  En fjärde siffra innebär att en sådan del i sin tur
finns i flera format, et c.

Exemplet är en sekvens av ärenderaden och texten.  Texten finns i två
varianter: x-kom/basic och text/html.  text/html-varianten är en
sekvens av tre delar: själva html-texten, en ikon, och en animation.
Animationen finns i två varianter: en shockwaveanimation och en
stillbild.

Nedkodat skulle det kunna bli så här:

	1;x-kom/subject;0;24
	2.1;x-kom/basic;25;125
	2.2.1;text/html;150;150
	2.2.2;image/png;300;100
	2.2.3.1;image/shockwave;400;400
	2.2.3.2;image/png;800;200

2.

En enda aux-item som beskriver inläggets struktur med hjälp av en sexp
eller något liknande.  Exemplet skulle kunna se ut ungefär så här:

	(sequence
	  (x-kom/subject 0 24)
	  (alternative
	    (x-kom/basic 25 125)
	    (text/html 150 150
	      (inline
		(image/png 300 100)
		(alternative
		  (image/shockwave 400 400)
		  (image/png 800 200))))))

--------------------

Man behöver fundera mer på om man behöver kunna namnge bilagor.  Jag
har inte läst MIME-dokumenten på väldigt länge; det är nog lämpligt
att göra innan man spikar formatet.











I IMAP finns det en typ "body-structure" som är tänkt att beskriva hur
ett meddelande är uppbyggt i MIME-avseende. Det är inte jättevackert,
och kanske overkill för KOM, men kanske kan vara värt att ha i
bakgrunden.

      BODYSTRUCTURE  A parenthesized list that describes the [MIME-IMB]
                     body structure of a message.  This is computed by
                     the server by parsing the [MIME-IMB] header fields,
                     defaulting various fields as necessary.

                     For example, a simple text message of 48 lines
                     and 2279 octets can have a body structure of:
                     ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL
                     "7BIT" 2279 48)


                     Multiple parts are indicated by parenthesis
                     nesting. Instead of a body type as the first
                     element of the parenthesized list there is a
                     nested body. The second element of the
                     parenthesized list is the multipart subtype
                     (mixed, digest, parallel, alternative, etc.).


                     For example, a two part message consisting of a
                     text and a BASE645-encoded text attachment can
                     have a body structure of: (("TEXT" "PLAIN"
                     ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152
                     23)("TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME"
                     "cc.diff")
                     "<960723163407.20117h@cac.washington.edu>"
                     "Compiler diff" "BASE64" 4554 73) "MIXED"))


                     Extension data follows the multipart subtype.
                     Extension data is never returned with the BODY
                     fetch, but can be returned with a BODYSTRUCTURE
                     fetch. Extension data, if present, MUST be in
                     the defined order.


                     The extension data of a multipart body part are
                     in the following order:


                     body parameter parenthesized list
                        A parenthesized list of attribute/value pairs
                        [e.g. ("foo" "bar" "baz" "rag") where "bar" is
                        the value of "foo" and "rag" is the value of



Crispin                     Standards Track                    [Page 59]

RFC 2060                       IMAP4rev1                   December 1996


                        "baz"] as defined in [MIME-IMB].

                     body disposition
                        A parenthesized list, consisting of a
                        disposition type string followed by a
                        parenthesized list of disposition
                        attribute/value pairs.  The disposition type and
                        attribute names will be defined in a future
                        standards-track revision to [DISPOSITION].

                     body language
                        A string or parenthesized list giving the body
                        language value as defined in [LANGUAGE-TAGS].

                     Any following extension data are not yet defined
                     in this version of the protocol. Such extension
                     data can consist of zero or more NILs, strings,
                     numbers, or potentially nested parenthesized
                     lists of such data. Client implementations that
                     do a BODYSTRUCTURE fetch MUST be prepared to
                     accept such extension data. Server
                     implementations MUST NOT send such extension
                     data until it has been defined by a revision of
                     this protocol.


                     The basic fields of a non-multipart body part are
                     in the following order:

                     body type
                        A string giving the content media type name as
                        defined in [MIME-IMB].

                     body subtype
                        A string giving the content subtype name as
                        defined in [MIME-IMB].

                     body parameter parenthesized list
                        A parenthesized list of attribute/value pairs
                        [e.g. ("foo" "bar" "baz" "rag") where "bar" is
                        the value of "foo" and "rag" is the value of
                        "baz"] as defined in [MIME-IMB].

                     body id
                        A string giving the content id as defined in
                        [MIME-IMB].

                     body description
                        A string giving the content description as
                        defined in [MIME-IMB].



Crispin                     Standards Track                    [Page 60]

RFC 2060                       IMAP4rev1                   December 1996


                     body encoding
                        A string giving the content transfer encoding as
                        defined in [MIME-IMB].

                     body size
                        A number giving the size of the body in octets.
                        Note that this size is the size in its transfer
                        encoding and not the resulting size after any
                        decoding.

                     A body type of type MESSAGE and subtype RFC822
                     contains, immediately after the basic fields, the
                     envelope structure, body structure, and size in
                     text lines of the encapsulated message.

                     A body type of type TEXT contains, immediately
                     after the basic fields, the size of the body in
                     text lines. Note that this size is the size in
                     its content transfer encoding and not the
                     resulting size after any decoding.


                     Extension data follows the basic fields and the
                     type-specific fields listed above. Extension
                     data is never returned with the BODY fetch, but
                     can be returned with a BODYSTRUCTURE fetch.
                     Extension data, if present, MUST be in the
                     defined order.


                     The extension data of a non-multipart body part
                     are in the following order:


                     body MD5
                        A string giving the body MD5 value as defined in
                        [MD5].

                     body disposition
                        A parenthesized list with the same content and
                        function as the body disposition for a multipart
                        body part.

                     body language
                        A string or parenthesized list giving the body
                        language value as defined in [LANGUAGE-TAGS].

                     Any following extension data are not yet defined
                     in this version of the protocol, and would be as
                     described above under multipart extension data.






Crispin                     Standards Track                    [Page 61]

RFC 2060                       IMAP4rev1                   December 1996








Jag har ett flertal gånger upplevt att elispklienten gått
bärsärkagång, och kom just på vad som orsakade problemet; i
aInställningar (för) LysKOM hade jag angivit en ljudspelare
som inte existerade, vilket fick följden att hela Emacs
föreföll tvärdö då jag fick personliga meddelanden sända med
aSända meddelande (det enda jag valt att få ljud spelade för),
samtidigt som Emacsprocessen började äta upp all processortid
den förmådde roffa åt sig.

(Som jag ser det) relevanta data:

lyskom-version:
"0.45.1"
emacs-version:
"GNU Emacs 20.3.1 (i386-redhat-linux, X toolkit)
 of Mon Oct 26 1998 on lawmaster.bpc.org"
system-id:
gnu/linux

Om någon ger sig på att rota efter felet och inte lyckas
återskapa situationen/tycker sig behöva en
kom-compile-bug-report, är det bara att säga till.








Jag satt och försökte komma fram till hur man kunde göra det här igår
och kom fram till både bra och dåliga saker. Om man bestämmer sig för
att användare A loggar in först och användare B sedan så är det
enkelt. Om man vill kunna logga in sina användare i godtycklig ordning
(och det vill man ju) så blir det lite svårare, för mode-raden sätts
innan användaren loggar in.

Det finns en funktion som gör om mode-raden varje gång man går till
ett nytt möte, men såvitt jag kan begripa så ritar den bara om den
delen som jag inte vill pilla med. Kan jag ändra den andra biten på
något sätt efter att användaren har loggat in?














Jag brukar ofta köra två sessioner i samma Emacs, en för den här
identiteten och en för min I]M-person. Den som loggar in först får en
moderad som börjar

    --%*-LysKOM: (47/11) Mötesnamn

medan den andra får

    --%*-LysKOM(kom.lysator.liu.se<2>): (47/11) Annat mötesnamn

Den andra varianten gillar jag inte eftersom den äter upp så mycket av
moderaden. Jag skulle vilja ha någonting i stil med 

    --%*-LysKOM(main):

och

    --%*-LysKOM(I]M):

Går det att åstakomma på ett rimligt enkelt sätt?















Efter "återse alla markerade" påstår B-kommandot inversen av vad som
gäller. Ser jag bakåt (färskaste först, gående mot äldsta) påstår den
att jag ser frammåt, ser jag frammåt påstår den att jag ser bakåt:


| Återse alla markerade - Återse alla markerade
| Återse nästa markerade - (Återse) Baklänges
| Du återser nu bakåt.
| Återse nästa markerade - (Återse) Baklänges
| Du återser nu framåt.
| Återse nästa markerade.
| 3487158 1998-11-13  15:23  /1 rad/ (sno)pp
...
| (3487158)
| Kommentar i text 3487169 av Ronny Svedman (desillusionerad, eller nåt)
| Återse nästa markerade - (Återse) Baklänges
| Du återser nu bakåt.
| Återse nästa markerade.
| 336328 1993-04-02  20:37  /71 rader/ Lars Aronsson (lars@aronsson.se)
...

Detta skiljer sig från vad som händer vid "återse senaste 10" i ett
möte.



| Gå till nästa möte - Återse senaste
| Återse senaste 10 av vem som helst till PC (IBM PC med efterföljare) erfarenhetsutbyte framåt.
| Återse nästa text - (Återse) Baklänges
| Du återser nu bakåt.
| Återse nästa text.
| 3493782 idag 13:05 /9 rader/ Magnus K
...
| (3493782)
| Återse nästa text - (Återse) Baklänges
| Du återser nu framåt.
| Återse nästa text.
| 3493466 idag 11:55 /1 rad/ Erland Costyson
...


Vid "återse senaste" kommer jag att få färskaste texten om jag är i
läget "baklänges", vid "återse alla markerade" om jag är i läget
"framlänges".

Jag kör LysKOM elisp-klient version 0.45.









Jag skulle vilja ha lite mer makt över det som skrivs i statusraden.
Nu står där "Olästa" eller "Olästa brev". Jag skulle vilja ha
möjlighet till till exempel följande:

 * Skriv "Olästa" om det är i den aktiva (översta) KOM-bufferten,
   annars "(Olästa)". Motsvarande för brev.

 * Skriv "Olästa brev" men låt bli att rapportera om olästa inlägg för
   det har jag alltid.

 * Någon möjlighet att påverka det som skrivs ut beroende på vilken
   buffert (vilken server/KOMperson) det hör till.















Medan jag kommer ihåg det ska jag förresten rapportera att jag tycker
att "Fotnot till inlägg" beter sig fel. När den senast lästa texten är
ett eget inlägg och man därefter skapat en text borde denna, senaste,
text fotnoteras per default istället för det senast lästa.

Anledningen är enkel - man läser ofta en kommentar till en egen text,
gör åk, kommenterar föregående text och kommer på att man vill skriva
en fotnot till den nyss skrivna texten.

Jag inser dock att det kan vara jobbigt att bygga, om klienten inte
råkar hålla reda på att man skrivit en kommentar senare än man läst en
text.

David Byers's avatar
David Byers committed
1287
1288
FIX BY: 0.46            KLART.

David Byers's avatar
David Byers committed
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388















Vilka typer av markeringar finns det planer på?

Jag skulle åtminstone vilja ha permanent markering, tidsbegränsad (men
oborttagbar under den tiden), påminnelse (visas automatiskt nästa gång
jag loggar in), och gärna möjlighet att sätta olika nyckelord på
texterna jag markerar. Jag vill också ha möjligheten att ersätta
ärenderaden på texterna jag markerar med något mer informativt så att
lista ärenden fungerar bättre.

Lista markerade (per) nyckelord












Ungefär som vilka-listan men med sessionsinfo, typ:

	<num>	<namn>	<klient>	<idle-tid>

Varför? Främst för att se idle-tiden. Kan nog kombineras med Lista
Klienter.














Det här tycker jag verkar vara en bug i 0.45.1:

Jag kommenterar ett inlägg som ligger i ett möte jag inte är med i.
Mötet ifråga är ett originalmöte, varför min kommentar får ett annat
möte som mottagare.  Trots att jag är med i supermötet lägger klienten
till min brevlåda som mottagare till komentaren.














När man går med i ett nytt möte så blir man tillfrågad vilken
prioritet man vill ha på det nya mötet. Det är bra. Problemet är bara
att jag inte kommer ihåg hur jag sorterat mötena, så varje gång jag
lagt till nya möten så får jag gå in och prioritera så att det hamnar
där jag tänkt mig.

Jag kom just på att vad jag skulle vilja ha är möjligheten att ange
inte bara en prioritet på det nya mötet, utan istället kunna ange
namnet på ett annat möte vilket i så fall naturligtvis betyder att det
nya mötet ska ha samma prioritet som det jag anger.







Jag har tidigare efterlyst möjligheten att kunna skriva en egen text
att få visad istället för originalärdenderaden på texter jag
markerat. Allt för ofta har mina markerade texter ärenderader som inte
har ett skvatt med innehållet att göra.


1389
1390
1391
1392
1393
1394

Local variables:
mode: outline
paragraph-separate: "[ \t]*$"
outline-regexp: "[*]+"
end: