TODO 45.3 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
* INTRESSANTA SAKER

8 9 10 11
** Knappar i email-adressen i importerade brev.

** Knappar å sånt i Återse brevhuvud.

12 13 14 15 16 17 18
** Man vill kunna skicka user-agent och proxy-authorization till
   HTTP-proxyn. Se specen för HTTP 1.1, kapitel 11 och RFC 2069.

        ftp://ftp.isi.edu/in-notes/rfc2616.txt
        ftp://ftp.isi.edu/in-notes/rfc261y.txt


19 20
* SHOWSTOPPERS

David Byers's avatar
David Byers committed
21 22 23 24
** Martin, hade vissa problem med inställningarna. User-arean såg OK
   ut och han säger att problemen försvann när han skrev en
   presentation för sin person Martin;. User-arean finns i 4730269.

David Byers's avatar
David Byers committed
25 26 27 28 29 30
** Man får illegal consp nil i processfiltret när man går med i eller
   ändrar prioritet på ett möte ibland. Sällan. Jag gick med i
   programmering i TokKOM med kom-handle-membership uppe. När jag
   tryckte + så blev det fel. Tror det är i callbacken. Det verkar
   vara timingberoende och cacheberoende på något vis. Jag har fått
   det på andra sätt också.
31 32

   Händer ibland när man loggar in också.
David Byers's avatar
David Byers committed
33

34 35 36
** När man går med i ett möte så sorteras inte medlemskapet in korrekt 
   i medlemskapslistan.

David Byers's avatar
David Byers committed
37 38 39 40 41 42 43 44 45
   Problemet uppstår framförallt med 1.9-servers som inte vet hur man
   skall handskas med medlemskapspositioner. Hanteringen av
   medlemskapen i lyskom-insert-membership med vänner är också
   suspekt. Den måste sätta in på rätt position, om man kan
   positionen, och därefter uppdatera de andra elementens position.

   Antagligen fixat, men Stacken uppgraderade sin server så det är
   svårare att testa nu.

46

David Byers's avatar
David Byers committed
47 48 49 50
* MULEification
  These items have to be dealt with before the client can be used in a
  multibyte environment (where the strings sent from the server are in
  a multibyte charset.) They do not affect users of unibyte charsets.
51

52 53 54 55 56 57 58
** In edit-filter mode, check how subject åäö is handled.

** Write code to deal with the situation where you create a filter in
   a unibyte environment and then move to a multibyte environment, and
   vice versa. Or make the filter code convert strings to the
   appropriate bytedness. Maybe.

David Byers's avatar
David Byers committed
59
** In completing-read.el, MULEify the character comparisons.
David Byers's avatar
David Byers committed
60

David Byers's avatar
David Byers committed
61 62
** In completing-read.el, end of lyskom-complete-string, check how the
   result of make-string is used and modified.
David Byers's avatar
David Byers committed
63

David Byers's avatar
David Byers committed
64 65 66 67
** The definition of lyskom-line-start-chars is not really kosher.
   This should be MULEified. Perhaps a hash table of characters
   instead of a vector. Problem is, speed is of the essence. Perhaps a
   hash table for chars over 255 and a hash table for the rest?
68

David Byers's avatar
David Byers committed
69 70
** In completing-read.el there are a lot of explicit character
   constants. All of these are suspicious.
71

David Byers's avatar
David Byers committed
72 73
** Already checked suspicious things: substring->truncate-to-width, 
   length->string-bytes or string-width.
David Byers's avatar
David Byers committed
74

David Byers's avatar
David Byers committed
75 76 77
** MULEify the user area by explicitly coding all strings. This is
   implemented but disabled in the code that outputs the user area.
   Look for (and val nil) or something very similar in the code.
David Byers's avatar
David Byers committed
78

David Byers's avatar
David Byers committed
79 80
** Make sure that kom-save-text and kom-save-text-body output a
   suitable coding to the file.
David Byers's avatar
David Byers committed
81

David Byers's avatar
David Byers committed
82 83


David Byers's avatar
David Byers committed
84 85
* The Parser
  This needs to be done by the next release.
David Byers's avatar
David Byers committed
86

David Byers's avatar
David Byers committed
87 88 89 90 91 92
** Get rid of lyskom-is-parsing, make the parser reentrant, install
   the reentrant blocking-do. The parsed string has to be removed from
   the parse buffer before calling the callback. This goes for
   asynchronous calls too.

** Look over all callbacks and see to it that they don't use
David Byers's avatar
David Byers committed
93
   lyskom-wait-queue, lyskom-collect, lyskom-use, lyskom-list-use,
David Byers's avatar
David Byers committed
94 95
   blocking-do or multiple-blocking do since this is detrimental to
   performance and possibly incompatible with the current parser.
David Byers's avatar
David Byers committed
96

97 98


David Byers's avatar
David Byers committed
99

100 101


102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121
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
122

David Byers's avatar
David Byers committed
123 124 125 126 127

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.

David Byers's avatar
David Byers committed
128 129
Man borde använda next-command-event med vänner i silent-read och
j-or-n-p.
130

131

David Byers's avatar
David Byers committed
132
* SAKER ATT KOLLA TILL 0.46
133

David Byers's avatar
David Byers committed
134 135 136
    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.
David Byers's avatar
David Byers committed
137

David Byers's avatar
David Byers committed
138

139 140 141 142 143 144 145
    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
146

147
    Testa lyskom-is-anonymous!
David Byers's avatar
David Byers committed
148

149 150
    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
151

152 153
    Hur och var skall man egentligen spara inställningar? .emacs är
    kanske inte det bästa alternativet. 
David Byers's avatar
David Byers committed
154 155


156
* BUGGAR
David Kågedal's avatar
David Kågedal committed
157

David Byers's avatar
David Byers committed
158 159
** OSORTERADE

David Byers's avatar
David Byers committed
160 161 162 163 164 165 166 167 168 169 170 171 172
    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.
    FIX BY: 0.46

    ispell-hooken rättar ärendet i bufferten men det blir inte rättat
    i den inskickade versionen av inlägget. Kanske.
    FIX BY: 0.46

    lyskom-filter hanterar inte lyskom-debug-what-i-am-doing rätt. Den
    tittar på antal token i meddelandet, inte meddelandet i sig.
    FIX BY: Whenever

173
    Om förbindelsen bryts så får man args out of range ibland.
David Byers's avatar
David Byers committed
174
    FIX BY: 0.46
175 176 177 178

    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
179
    FIX BY: ---
180

David Byers's avatar
David Byers committed
181 182
    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
183
    blev det rätt. Det verkar som om window-width ljuger.
David Byers's avatar
David Byers committed
184
    FIX BY: N/A
David Byers's avatar
David Byers committed
185 186 187 188 189 190

    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
191
    FIX BY: 0.46-0.47
David Byers's avatar
David Byers committed
192 193 194

    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
195
    FIX BY: ---
David Byers's avatar
David Byers committed
196 197


198 199
** VIKTIGA BUGGAR

David Byers's avatar
David Byers committed
200 201 202
** OMBRYTNING

    Vi klarar inte emailheaders som är brutna över flera rader.
David Byers's avatar
David Byers committed
203 204 205 206 207
    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
208
    FIX BY: 0.46-0.47
David Byers's avatar
David Byers committed
209 210


211
** DEFERRED INSERT
212

David Byers's avatar
X  
David Byers committed
213 214 215
    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
216
    FIX BY: ---
217

218
    Om ett namn som fylls i i efterhand gör att sista raden blir för
David Byers's avatar
David Byers committed
219 220 221
    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
222
    FIX BY: --- (check before release of 0.46)
223 224 225 226


** PREFETCH 

David Byers's avatar
David Byers committed
227 228 229 230 231
    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
X  
David Byers committed
232 233 234
    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
235
    FIX BY: 
David Kågedal's avatar
David Kågedal committed
236

237 238
    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
239
    FIX BY: 0.46
240

241 242 243

** COMPLETING READ

244 245 246 247 248
    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.
249
    FIX BY: 0.46-0.47                           KLART!
David Byers's avatar
David Byers committed
250 251 252 253 254 255 256 257 258 259 260 261

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

David Byers's avatar
David Byers committed
264 265 266 267 268
    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
269
    FIX BY: Whenever
David Byers's avatar
David Byers committed
270 271 272 273

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

276 277 278

** HANTERING AV FOTNOTER

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

283 284 285
    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
286 287 288 289
    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
290
    FIX BY: ---
291

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

David Kågedal's avatar
David Kågedal committed
295 296
    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
297
    FIX BY: 
David Kågedal's avatar
David Kågedal committed
298

299 300

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

302 303
    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
304 305
    kommentar". Kommentaren ligger inte i brevlådan.
    FIX BY: --- 
306

David Byers's avatar
David Byers committed
307

308 309 310 311 312
** 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
313
    FIX BY: --- (Check by 0.46)
314 315

    Tommy Persson får LysKOM protocol error. Det kan bero på strulande
David Byers's avatar
David Byers committed
316 317
    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
318
    fortfarande kan ingen reproducera det. Nu har jag också fått det. 
David Byers's avatar
David Byers committed
319
    FIX BY: YESTERDAY
320 321 322



David Byers's avatar
David Byers committed
323 324
* FÖRBÄTTRINGAR

David Byers's avatar
David Byers committed
325 326
** Kopiera inställningar från en server till en annan.

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



353 354
** LÄSA INLÄGG

355 356 357 358 359
    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

360
    Det vore skoj om lyskom.el kunde, som jag har för mig att någon
David Byers's avatar
David Byers committed
361 362 363 364 365 366
    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.
367 368 369 370 371

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

David Byers's avatar
David Byers committed
374 375
    FIX BY: 0.46-0.47

376

David Byers's avatar
David Byers committed
377

David Byers's avatar
David Byers committed
378
** SKRIVA INLÄGG
David Byers's avatar
David Byers committed
379

David Byers's avatar
David Byers committed
380 381 382
    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
383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426
    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
427

428 429

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

David Byers's avatar
David Byers committed
431
    Defaultplaceringen av nya mottagare i editbufferten är fånig.
David Byers's avatar
David Byers committed
432
    FIX BY: 0.46            FIXAT. Sist istf först.
David Byers's avatar
David Byers committed
433 434 435 436

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

439 440
    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
441
    FIX BY: 0.46            FIXAT
442 443 444 445

    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.)
446
    FIX BY: 0.46            KLART
David Byers's avatar
David Byers committed
447 448 449

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

David Byers's avatar
David Byers committed
452

453
** FILTER
David Byers's avatar
David Byers committed
454

455
    Ny filter-edit-mode
David Byers's avatar
David Byers committed
456
    FIX BY: 0.48
457 458

    Använd den nya filterkompilatorn.
David Byers's avatar
David Byers committed
459
    FIX BY: 0.48
460 461 462 463 464 465

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


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

David Byers's avatar
David Byers committed
467 468
    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
469
    FIX BY: 0.47
David Kågedal's avatar
David Kågedal committed
470

471
    Filtrera asynkrona meddelanden (Pontus Lidman)
472
    FIX BY: 0.47            KLART
473 474 475 476


** MEDLEMSSKAPSINFORMATION

David Byers's avatar
X  
David Byers committed
477
    Lista medlemsskap borde hållas uppdaterad. Vi behöver hookar för
478 479 480 481
    - 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
482 483 484
    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
485
    FIX BY: 0.48
David Byers's avatar
X  
David Byers committed
486

487 488 489 490 491 492 493 494 495
** 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

496 497 498

** ÅTERSE

David Byers's avatar
X  
David Byers committed
499 500 501
    Å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
502
    FIX BY: 0.47 or later
David Byers's avatar
X  
David Byers committed
503 504

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

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

David Kågedal's avatar
David Kågedal committed
510
    Strunta i hemliga texter vid åar.
David Byers's avatar
David Byers committed
511
    FIX BY: 0.46-0.47
David Kågedal's avatar
David Kågedal committed
512

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

David Byers's avatar
David Byers committed
516 517
    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
518
    FIX BY: Who knows?
David Byers's avatar
David Byers committed
519

520

521 522 523
** INTERNA SAKER

    Inför en membership-cache.
524

David Kågedal's avatar
David Kågedal committed
525 526
    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?
527
    [Det gör man väl? /davidk]
David Kågedal's avatar
David Kågedal committed
528

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

532 533 534 535 536 537

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

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

David Kågedal's avatar
David Kågedal committed
541
    Det skulle vara bra om skönsvärde för att skriva fotnot vore den
David Byers's avatar
David Byers committed
542 543
    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?
544 545
    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
546
    FIX BY: 0.46-0.47
547

David Byers's avatar
X  
David Byers committed
548

549 550
** ANVäNDARVäNLIGHET

David Byers's avatar
David Byers committed
551 552 553
    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
554 555
    FIX BY: 0.48

556
    Klickbara kommandon, vad nu det är.
David Byers's avatar
David Byers committed
557
    FIX BY: 0.48
558

David Byers's avatar
David Byers committed
559 560 561
    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
562
    FIX BY:
David Byers's avatar
David Byers committed
563

David Byers's avatar
David Byers committed
564
    Språkgranskning av den engelska versionen.
David Byers's avatar
David Byers committed
565
    FIX BY:
566

David Byers's avatar
David Byers committed
567 568 569
    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.
570
    FIX BY: 0.46                                    KLART
David Byers's avatar
David Byers committed
571 572 573 574 575 576 577 578


** 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.
579
    FIX BY: 0.46                                    KLART!
580 581


David Byers's avatar
David Byers committed
582
** MARKERINGAR
David Byers's avatar
David Byers committed
583

David Byers's avatar
David Byers committed
584
    JySKomska markeringstyper.
David Byers's avatar
David Byers committed
585
    FIX BY: 0.47-0.48
David Byers's avatar
David Byers committed
586 587


588 589 590 591 592 593 594
** 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
595
** DIVERSE OSORTERAT
David Byers's avatar
David Byers committed
596

597 598
    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
599
    FIX BY: 0.47-0.48
600

601
    Sortera vilkaslistan efter t.ex. idletid.
David Byers's avatar
David Byers committed
602

David Byers's avatar
David Byers committed
603 604 605
    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
606 607 608 609 610
    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
611
    FIX BY: 0.47
David Byers's avatar
David Byers committed
612

David Byers's avatar
David Byers committed
613 614 615
    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.
616

617 618 619 620 621
    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
622

David Byers's avatar
David Byers committed
623 624 625
    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
626 627 628 629 630
    
    Implementera re-z-lookup med re-lookup-X så att vi kan återinföra
    maximal kompatibilitet.


David Byers's avatar
David Byers committed
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
** FACES

    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
664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687
** 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



688 689 690 691




David Byers's avatar
David Byers committed
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 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


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".
795
    
David Byers's avatar
David Byers committed
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 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
    (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
1357 1358
FIX BY: 0.46            KLART.

David Byers's avatar
David Byers committed
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 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458















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.


1459 1460 1461 1462 1463 1464

Local variables:
mode: outline
paragraph-separate: "[ \t]*$"
outline-regexp: "[*]+"
end: