TODO 41.8 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
=========================

6
7
8
9
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
10
11
12
            Om du fixar någonting som står med på den här
            listan, glöm inte att ta bort det från listan!

13
14
15
16
17
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.


18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
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
38

David Byers's avatar
David Byers committed
39
40
41
42
43

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.

44
45
46
47
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
48
49
Man borde använda next-command-event med vänner i silent-read och
j-or-n-p.
50
51
52
53
54
55

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.


56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
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
87

88
* SAKER ATT KOLLA TILL 0.46
David Byers's avatar
David Byers committed
89

90
91
92
93
94
95
96
    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
97

98
    Testa lyskom-is-anonymous!
David Byers's avatar
David Byers committed
99

100
101
    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
102

103
104
    Hur och var skall man egentligen spara inställningar? .emacs är
    kanske inte det bästa alternativet. 
David Byers's avatar
David Byers committed
105
106


107
* BUGGAR
David Kågedal's avatar
David Kågedal committed
108

David Byers's avatar
David Byers committed
109
110
** OSORTERADE

111
    Om förbindelsen bryts så får man args out of range ibland.
David Byers's avatar
David Byers committed
112
    FIX BY: 0.46
113
114
115
116

    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
117
    FIX BY: ---
118

119
120
121
122
123
    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
124
    FIX BY: 0.46        KLART
125

David Byers's avatar
David Byers committed
126
127
    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
128
    blev det rätt. Det verkar som om window-width ljuger.
David Byers's avatar
David Byers committed
129
    FIX BY: N/A
David Byers's avatar
David Byers committed
130
131
132
133
134
135

    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
136
    FIX BY: 0.46-0.47
David Byers's avatar
David Byers committed
137
138
139

    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
140
    FIX BY: ---
David Byers's avatar
David Byers committed
141
142


143
144
** VIKTIGA BUGGAR

David Byers's avatar
David Byers committed
145
146
147
** OMBRYTNING

    Vi klarar inte emailheaders som är brutna över flera rader.
David Byers's avatar
David Byers committed
148
149
150
151
152
    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
153
    FIX BY: 0.46-0.47
David Byers's avatar
David Byers committed
154
155


156
** DEFERRED INSERT
157

David Byers's avatar
X    
David Byers committed
158
159
160
    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
161
    FIX BY: ---
162

163
    Om ett namn som fylls i i efterhand gör att sista raden blir för
David Byers's avatar
David Byers committed
164
165
166
    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
167
    FIX BY: --- (check before release of 0.46)
168
169
170
171


** PREFETCH 

David Byers's avatar
X    
David Byers committed
172
173
174
    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
175
    FIX BY: 
David Kågedal's avatar
David Kågedal committed
176

177
    Gå ur mötet man prefetchar genererar en bug.
178
    FIX BY: 0.46            FIXED
179

180
181
    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
182
    FIX BY: 0.46
183

184
185
186

** COMPLETING READ

187
188
189
190
191
    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.
192
    FIX BY: 0.46-0.47                           KLART!
David Byers's avatar
David Byers committed
193
194
195
196
197
198
199
200
201
202
203
204

    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
205
    FIX BY: 0.46
David Byers's avatar
David Byers committed
206

David Byers's avatar
David Byers committed
207
208
209
210
211
    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
212
    FIX BY: Whenever
David Byers's avatar
David Byers committed
213
214
215
216

    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
217
    FIX BY: Whenever
David Byers's avatar
David Byers committed
218

219
220
221

** HANTERING AV FOTNOTER

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

226
227
228
    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
229
230
231
232
    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
233
    FIX BY: ---
234

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

David Kågedal's avatar
David Kågedal committed
238
239
    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
240
    FIX BY: 
David Kågedal's avatar
David Kågedal committed
241

242
243

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

245
246
    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
247
248
    kommentar". Kommentaren ligger inte i brevlådan.
    FIX BY: --- 
249

David Byers's avatar
David Byers committed
250

251
252
253
254
255
** 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
256
    FIX BY: --- (Check by 0.46)
257
258

    Tommy Persson får LysKOM protocol error. Det kan bero på strulande
David Byers's avatar
David Byers committed
259
260
    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
261
    fortfarande kan ingen reproducera det. Nu har jag också fått det. 
David Byers's avatar
David Byers committed
262
    FIX BY: YESTERDAY
263
264
265



David Byers's avatar
David Byers committed
266
267
* FÖRBÄTTRINGAR

268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
** 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



294
295
** LÄSA INLÄGG

296
297
298
299
300
    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

301
    Det vore skoj om lyskom.el kunde, som jag har för mig att någon
David Byers's avatar
David Byers committed
302
303
304
305
306
307
    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.
308
309
310
311
312

        * 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
313
        * Troligtvis är det bättre att använda aux-items för detta.
314

David Byers's avatar
David Byers committed
315
316
    FIX BY: 0.46-0.47

317

David Byers's avatar
David Byers committed
318

David Byers's avatar
David Byers committed
319
** SKRIVA INLÄGG
David Byers's avatar
David Byers committed
320

David Byers's avatar
David Byers committed
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
    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
365

366
367

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

David Byers's avatar
David Byers committed
369
    Defaultplaceringen av nya mottagare i editbufferten är fånig.
David Byers's avatar
David Byers committed
370
    FIX BY: 0.46            FIXAT. Sist istf först.
David Byers's avatar
David Byers committed
371
372
373
374

    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
375
    FIX BY: 0.46            FIXAT
David Byers's avatar
David Byers committed
376

377
378
    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
379
    FIX BY: 0.46            FIXAT
380
381
382
383

    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
384
    FIX BY: 0.46
David Byers's avatar
David Byers committed
385
386
387

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

David Byers's avatar
David Byers committed
390

391
** FILTER
David Byers's avatar
David Byers committed
392

393
    Ny filter-edit-mode
David Byers's avatar
David Byers committed
394
    FIX BY: 0.48
395
396

    Använd den nya filterkompilatorn.
David Byers's avatar
David Byers committed
397
    FIX BY: 0.48
398
399
400
401
402
403

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


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

David Byers's avatar
David Byers committed
405
406
    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
407
    FIX BY: 0.47
David Kågedal's avatar
David Kågedal committed
408

409
    Filtrera asynkrona meddelanden (Pontus Lidman)
David Byers's avatar
David Byers committed
410
    FIX BY: 0.47
411
412
413
414


** MEDLEMSSKAPSINFORMATION

David Byers's avatar
X    
David Byers committed
415
    Lista medlemsskap borde hållas uppdaterad. Vi behöver hookar för
416
417
418
419
    - 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
420
421
422
    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
423
    FIX BY: 0.48
David Byers's avatar
X    
David Byers committed
424

425
426
427
428
429
430
431
432
433
** 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

434
435
436

** ÅTERSE

David Byers's avatar
X    
David Byers committed
437
438
439
    Å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
440
    FIX BY: 0.47 or later
David Byers's avatar
X    
David Byers committed
441
442

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

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

David Kågedal's avatar
David Kågedal committed
448
    Strunta i hemliga texter vid åar.
David Byers's avatar
David Byers committed
449
    FIX BY: 0.46-0.47
David Kågedal's avatar
David Kågedal committed
450

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

David Byers's avatar
David Byers committed
454
455
    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
456
    FIX BY: Who knows?
David Byers's avatar
David Byers committed
457

458

459
460
461
** INTERNA SAKER

    Inför en membership-cache.
462

David Kågedal's avatar
David Kågedal committed
463
464
    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?
465
    [Det gör man väl? /davidk]
David Kågedal's avatar
David Kågedal committed
466

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

470
471
472
473
474
475

** 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
476

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

David Kågedal's avatar
David Kågedal committed
479
    Det skulle vara bra om skönsvärde för att skriva fotnot vore den
David Byers's avatar
David Byers committed
480
481
    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?
482
483
    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
484
    FIX BY: 0.46-0.47
485

David Byers's avatar
X    
David Byers committed
486

487
488
** ANVäNDARVäNLIGHET

David Byers's avatar
David Byers committed
489
490
491
    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
492
493
    FIX BY: 0.48

494
    Klickbara kommandon, vad nu det är.
David Byers's avatar
David Byers committed
495
    FIX BY: 0.48
496

David Byers's avatar
David Byers committed
497
498
499
    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
500
    FIX BY:
David Byers's avatar
David Byers committed
501

David Byers's avatar
David Byers committed
502
    Språkgranskning av den engelska versionen.
David Byers's avatar
David Byers committed
503
    FIX BY:
504

David Byers's avatar
David Byers committed
505
506
507
    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
508
    FIX BY: 0.46
David Byers's avatar
David Byers committed
509
510
511
512
513
514
515
516


** 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.
517
    FIX BY: 0.46                                    KLART!
518
519


David Byers's avatar
David Byers committed
520
** MARKERINGAR
David Byers's avatar
David Byers committed
521

David Byers's avatar
David Byers committed
522
    JySKomska markeringstyper.
David Byers's avatar
David Byers committed
523
    FIX BY: 0.47-0.48
David Byers's avatar
David Byers committed
524
525


526
527
528
529
530
531
532
** 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
533
** DIVERSE OSORTERAT
David Byers's avatar
David Byers committed
534

535
536
    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
537
    FIX BY: 0.47-0.48
538

539
    Sortera vilkaslistan efter t.ex. idletid.
David Byers's avatar
David Byers committed
540

David Byers's avatar
David Byers committed
541
542
543
    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
544
545
546
547
548
    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
549
    FIX BY: 0.47
David Byers's avatar
David Byers committed
550

David Byers's avatar
David Byers committed
551
552
553
    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.
554

555
556
557
558
559
    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
560

David Byers's avatar
David Byers committed
561
562
563
    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
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
    
    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



593
594
595
596




David Byers's avatar
David Byers committed
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
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


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".
700
    
David Byers's avatar
David Byers committed
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
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
    (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
1262
1263
FIX BY: 0.46            KLART.

David Byers's avatar
David Byers committed
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
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















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.


1364
1365
1366
1367
1368
1369

Local variables:
mode: outline
paragraph-separate: "[ \t]*$"
outline-regexp: "[*]+"
end: