-*- Mode: outline; -*-

Att gra i elisp-klienten
=========================

* SPRK

Moderaden och fnstertiteln ndras inte om man byter sprk.

* PREFETCH

Prefetchen verkar stlla till problem. Nr man skickar ett mail till
sig sjlv med attachments s kommer klienten att hmta text-stat fr
brevet innan det har ftt mx-attachments-in satt, och trots att man
raderar det ur cachen nr attachmentet dyker upp.

Jag misstnker att det finns en prefetch inlagd som hmtar text-staten
innan importren har hunnit stta mx-attachments-in. Det vore bra om
man kunde frdrja den en aning.

Man skulle kunna sl p debugging och titta i lyskom-prefetch-stack
och i anropskerna nr attachmentet kommer fram. Ett problem bara...
Om anropet redan ligger ute s kommer det att g klart medan man
hattar runt i debuggern (iofs s tror jag inte att anropet redan
ligger ute d).

Dessutom sg jag att textmassan fr inlgg verkar hmtas tv gnger,
vilket inte r s himlans bra.



* INTRESSANTA SAKER

Johans hack av lyskom-add-sub-recipient gjorde koden nnu fulare.
Eliminera lyskom-add-sub-recipient *helt*.

Kommentera inlgg med vnner borde kolla om man frsker kommentera en
bilaga. I s fall borde man f frslag att kommentera "urinlgget"
istllet. Klienten fr flja "belongs-to"-lnkarna uppt. 

Det vore trevligt om man kunde vlja vilka sorters bilagor man inte
vill flja kommentarer till.

Infr en ATTACHMENT-IN type i read-listan som komplement till COMM-IN.
Prompten blir lsa nsta bilaga.

Det gr inte att konsekvent f se "bilaga" istllet fr "text" eller
"inlgg" eftersom man inte alltid har text-staten i tid. Till exempel
slipper man nog nr man bygger kontextmenyn fr inlggsnumret.

Om man vill f se "terse nsta bilaga" nr man gr ak, ar, t s
behve ett komplement till REVIEW-TREE och REVIEW. Man mste ha
text-staten nr man skapar entryt fr att kunna titta p mx-belongs-to
innan man stoppar in det i read-listan.


Anvnd lyskom-read-text-no-prefix arg i alla funktioner dr det r
meningsfullt. Fljande r relevanta:

        Kommando                            Default     Prompt
        ------------------------------------------------------
      * Radera inlgg                       SL          Alltid
      * terse inlgg                       SL          Ja
      * terse omodifierat                  SL          Nej
      * terse urinlgget                   SL          Nej
      * terse alla kommentarer             SL          Nej
      * terse alla kommentarer reku        SL          Nej
      * terse trd                         SL          Nej
      * terse det kommenterade             SL          Nej
      * terse det fregende kommen        NSL         Nej
      * Kommentera inlgget                 SL          Nej
      * Kommentera fregende inlgg        NSL         Nej
      * Fotnot till inlgg                  SS          Ja
      * Personligt svar                     SL          Nej
      * Personligt svar p fregend        NSL         Nej
      * Markera (inlgg)                    SL          Ja
      * Avmarkera (inlgg)                  SL          Ja
      * Addera mottagare                    SL          Ja
      * Addera extra kopiemottagare         SL          Ja
      * Addera fr knnedom                 SL          Ja
      * Subtrahera mottagare                SL          Ja
      * Flytta inlgg                       SL          Ja
      * Addera kommentar                    SL          Ja
      * Subtrahera kommentar                SL          Ja
      X Arkivera inlgg (till fil)          SL          Ja
      * Spara inlggstext (p fil)          SL          Ja
      X Stt loginmeddelande                SS          Ja
      * Kort replik                         SL          Nej
      * Hlla med                           SL          Nej
      * Addera FAQ                          SS          Ja
      * Addera fotnot                       SS          Ja
      * Subtrahera fotnot                   SS          Ja
      * Frhindra kommentarer               SS          Ja
      * Begr personligt svar               SS          Ja
      * Begr lsbekrftelse                SS          Ja
      * terse brevhuvud                    SL          Nej
        ------------------------------------------------------
        SL  Senast lsta
        NSL Nst senast lsta
        SS  Senast skrivna/eget lst
        *   Klart
        -   Hanterar kanske inte returvrde nil 
        X   Borde inte vara med p listan

Bestm vettig default och om kommandot skall frga efter nummer eller
bara anta default om man inte ger prefixargument.


** Blockera eller klara av att man ger kommandon i
   kom-handle-membership medan bufferten hller p att uppdateras.

** Std fr att helt dlja ett medlemskap i kom-handle-membership. Man
   vill kanske dlja alla man inte har olsta i, eller alla som man
   inte har varit inne i p jttelnge

** Std fr att hajlajta medlemskap i kom-handle-membership. Man vill
   kanske hajlajta allt som uppfyller ett visst kriterium (eller
   anti-hajlajta allt annat). Man vill kunna hajlajta alla markerade.

** Man vill kunna skicka user-agent och proxy-authorization till
   HTTP-proxyn. Se specen fr HTTP 1.1, kapitel 11 och RFC 2069.

        ftp://ftp.isi.edu/in-notes/rfc2616.txt
        ftp://ftp.isi.edu/in-notes/rfc2069.txt
  Instoppat i LysKOM.


* SHOWSTOPPERS

** Radbrytningen gr lite fel. Om man har en rad med :/ i s stoppar
   den radbrytningen. Egentligen s borde kanske en rad som bara
   bestr av icke-bokstver avsluta aktuellt stycke och kanske vara
   sitt eget stycke ocks.

** Martin, hade vissa problem med instllningarna. User-arean sg OK
   ut och han sger att problemen frsvann nr han skrev en
   presentation fr sin person Martin;. User-arean finns i 4730269.

** Man fr illegal consp nil i processfiltret nr man gr med i eller
   ndrar prioritet p ett mte ibland. Sllan. Jag gick med i
   programmering i TokKOM med kom-handle-membership uppe. Nr jag
   tryckte + s blev det fel. Tror det r i callbacken. Det verkar
   vara timingberoende och cacheberoende p ngot vis. Jag har ftt
   det p andra stt ocks.

   Hnder ibland nr man loggar in ocks.

** Nr man gr med i ett mte s sorteras inte medlemskapet in korrekt 
   i medlemskapslistan.

   Problemet uppstr framfrallt med 1.9-servers som inte vet hur man
   skall handskas med medlemskapspositioner. Hanteringen av
   medlemskapen i lyskom-insert-membership med vnner r ocks
   suspekt. Den mste stta in p rtt position, om man kan
   positionen, och drefter uppdatera de andra elementens position.

   Antagligen fixat, men Stacken uppgraderade sin server s det r
   svrare att testa nu.


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

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

** In completing-read.el, MULEify the character comparisons.

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

** In completing-read.el there are a lot of explicit character
   constants. All of these are suspicious.

** Already checked suspicious things: substring->truncate-to-width, 
   length->string-bytes or string-width.

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

** Make sure that kom-save-text and kom-save-text-body output a
   suitable coding to the file.



* The Parser
  This needs to be done by the next release.

** 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
   lyskom-wait-queue, lyskom-collect, lyskom-use, lyskom-list-use,
   blocking-do or multiple-blocking do since this is detrimental to
   performance and possibly incompatible with the current parser.



Nr man gr status fr ett tomt mte s r lgsta lokala nummer hgre
n det hgsta. Snygga till utskriften till exempel genom att skriva
att mtet r tomt.  Det skall synas skillnad p mten som alltid har
varit tomma och sdana som har haft inlgg som har garbats.


initiate-get-membership skulle kunna fylla i positionen fr
medlemskapet automatiskt. Tyvrr gr det inte att gra s i
query-read-texts.

Nr man fr en new-membership async s borde man kolla att
medlemskapet verkligen har ndrats, och bara d gra ngot.

lyskom-add-member eller vad den nu heter kan hitta rtt position inom
en prioritet genom att lgga det nya medlemskapet frst eller sist och
sedan sortera listan. D kommer det nya medlemskapet att f rtt
position inom prioriteten. Frst drefter behver man tala om fr
servern.

lyskom-sort-membership skulle kunna hlla servern uppdaterad genom att 
se efter nr man har gett ett medlemskap en ny position, och i s fall 
tala om det fr servern. Om man dessutom kan den gamla positionen s
borde man kunna rkna fram vilka positioner vriga medlemskap vars
gamla positioner man knner till har ftt fr nya positioner. Det kr
frsts ihop sig helt om man inte vet den gamla positionen fr ett
mte, men det r smllar man fr ta, som det heter.


Som det ser ut just nu, om man gr hantera medlemskap och sedan loggar 
in som en ny person i LysKOM-bufferten s blir det fel saatan eftersom 
prioriterabufferten anvnder lyskom-pers-no.

Man borde anvnda next-command-event med vnner i silent-read och
j-or-n-p.


* SAKER ATT KOLLA TILL 0.46

    Testa vad som hnder om man har en ogiltig misc-item eller
    aux-item i headersarna nr man adderar en mottagare eller flyttar
    ett inlgg eller adderar en aux-item eller tar bord en aux-item.


    Medlemskapslistan kan bli osorterad p mnga olika stt. Klienten
    mste klara av detta.
    . Man kan adderas till ett mte s det ligger osorterat i listan.
    . Nr man gr med i ett mte sjlv s hamnar det i allmnhet osorterat.
    Elispklienten borde kanske upptcka nr listan verkar osorterad
    och i det lget sortera om den lokalt och i servern. Det skulle
    till exempel kunna sk

    Testa lyskom-is-anonymous!

    Prioritet noll r tillten. Kolla alla strngar som nmner
    prioriter s att det str rtt i dem.

    Hur och var skall man egentligen spara instllningar? .emacs r
    kanske inte det bsta alternativet. 


* BUGGAR

** OSORTERADE

    ispell-hooken rttar rendet i bufferten men det blir inte rttat
    i den inskickade versionen av inlgget. Kanske.
    FIX BY: 0.46

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

    Om frbindelsen bryts s fr man args out of range ibland.
    FIX BY: 0.46

    Om frbindelsen bryts i en buffert s ofungerar scrollningen en
    gng i en annan buffert. Man trycker SPC och fr inte nsta
    kommando, utan hamnar verst i bufferten.
    FIX BY: ---

    Peter Enderborg hade en 118 tecken bred XEmacs 20.3 med scrollbar,
    och vilkalistan blev precis 1 tecken fr bred. I Gnu Emacs 19.30
    blev det rtt. Det verkar som om window-width ljuger.
    FIX BY: N/A

    Race condition nr man skickar in inlgg. Fnsterkonfigurationen
    terstlls asynkront, och det gr att trycka C-c C-c k
    tillrckligt fort att man skapar den nya inlggsbufferten innan
    den gamla fnsterkonfigurationen (fr den frra inlggsbufferten)
    terstlls. Resultatet r att man aldrig ser den nya bufferten.
    FIX BY: 0.46-0.47

    Endast gr fortfarande fel. Den klarar inte hl och anvnder inte
    set-last-read, utan set-unread.
    FIX BY: ---


** VIKTIGA BUGGAR

** OMBRYTNING

    Vi klarar inte emailheaders som r brutna ver flera rader.
    Klienten tror att den indragna fortsttningen r brjan p ett
    nytt stycke. Man skulle kunna tnka sig att nytt-stycke-regeln
    inte gr nytt stycke om alla rader har brjat med ord: och man
    hamnar p en indragen rad. Indragna rader skulle inte sabotera
    ord:-prefixet. 
    FIX BY: 0.46-0.47
        Inlagd i LysKOM.


** DEFERRED INSERT

    lyskom-replace-deferred verkar inte anvnda lyskom-last-viewed i
    alla fall. Och den beter sig fel nr man str vid prompten och
    vill blddra bakt.
    FIX BY: ---

    Om ett namn som fylls i i efterhand gr att sista raden blir fr
    lng, s scrollar klienten trots att den inte borde. David Kgedal
    trodde att han hade fixat det. (Detta r en gammal rapport. Den
    kanske inte stmmer.)
    FIX BY: --- (check before release of 0.46)


** PREFETCH 

    Nr man har krt prefetchen fr man en skum k i
    lyskom-prefetch-stack som inte innehller ngot annat n element
    som r ker vars sista element r FINISHED. Ibland verkar kerna
    bli cirkulra.

    Dubbla prefetcher kan vara vldigt frvirrande. Om man t.ex. gr
    endast i ett mte (sg IM) innan det prefetchas fr man tv
    parallella prefetcher p samma mte.
    FIX BY: 

    Om man gr till ett mte som inte prefetchats och inte har ngra
    inlgg blir promten fel, och man fr ett felmeddelande.
    FIX BY: 0.46


** COMPLETING READ

    Om man skriver in ett namn exakt, modulo parenteser, borde det
    *antagligen* accepteras som exakt. Jus nu krvs det att man
    skriver in parenteserna ocks. Problem uppstr till exempel om det
    finns tv mten "(P) TV" och "(Gamla) TV-spel erfarenhetsutbyte".
    Om man skriver in "TV" s betraktas det inte som en exakt match.
    FIX BY: 0.46-0.47                           KLART!

    Man kan f olndiga loopar i completion. Just nu r det inte s
    ltt, men det gr fortfarande. Problemet uppstr 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 olndig loop och
    stoppa den. 
        Minitestfall: (lyskom-complete-string '("L\t" "L s")).
        Problem uppstr om man fr space-mismatch pga att tv olika
        tecken med spacesemantik mismatchar (fin svenska, eller hur.)
        Man borde f match nr det intrffar.
    FIX BY: 0.46

    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 lta den returnera info
    om specifikt sessionsnummer ocks.
    FIX BY: Whenever

    Fixa s LysKOM och complete.el fungerar ihop genom att stta om
    samma mappar som complete.el gr, till wrappers runt complete.el
    som kollar om completion r LysKOM-completion eller ngot annat.
    FIX BY: Whenever


** HANTERING AV FOTNOTER

    Den frsker fortfarande flja hemliga kommentarer om
    kom-show-footnotes-immediately r satt.
    FIX BY: --- (Check before release of 0.46)

    Om man lser ett inlgg som har en fotnot (tex 1449843) och vill
    spara det p fil, s blir det bara fotnoten som sparas.  Man vill
    nog spara minst sjlva huvudinlgget, och nog ocks fotnoterna
    samtidigt. [Pja, det r faktist meningen att det skall funka s
    hr. Spara text sparar sisa inlgget man tittade p.
    Prefixargument ger fler. Frgan om det r *bra* eller inte r en
    helt annan...]
    FIX BY: ---

    Fotnoter som visas p en gng filtreras inte. [verkar fixat]
    FIX BY: --- (Check by 0.46)

    kom-review-tree p en text med fotnoter visar fotnoterna p en
    gng. r det en bug?
    FIX BY: 


** PROMPTEN

    Nr jag ska lsa en kommentar till ett brev i min brevlda s blir
    prompten "Lsa nsta brev" i stllet fr "Lsa nsta
    kommentar". Kommentaren ligger inte i brevldan.
    FIX BY: --- 


** HEISENBUGS

    Sentinelmeddelanden i ikoniferade frames buggar. Prova att kasta
    ut en session i ett ikonifierat fnster. Eller kanske till och med
    bara i en gmd buffert.
    FIX BY: --- (Check by 0.46)

    Tommy Persson fr LysKOM protocol error. Det kan bero p strulande
    modem. Tyvrr var det ngon annan som ocks fick det, som kanske
    inte sitter bakom modem. Nu fick Kgedal ocks problemet, men
    fortfarande kan ingen reproducera det. Nu har jag ocks ftt det. 
    FIX BY: YESTERDAY



* FRBTTRINGAR

** Kopiera instllningar frn en server till en annan.

** PRIORITERA MTEN
    
    Skriv klart Hantera medlemskap (aka prioritera mten.) Se till att 
    den hlls uppdaterad nr man
    . Gr med i ett mte
    . Passiviserar ett mte
    . Gr ur ett mte
    . ndrar prioritet p ett mte
    . Ett mte byter namn
    . Man byter namn p sig sjlv
    . Man ndrar mtestyp
    . Man ndrar medlemskapstyp
    . Man blir utkastad ur ett mte
    . Man blir adderad till ett mte
    . Ett mte raderas
    . Man skapar ett mte (och blir med i det)

    Funktioner som borde finnas:
    . Endast lsa senaste N i alla markerade mten
    . Samma funktioner som i gamla prioritera mten
    . Uppdatera all information
    . ndra namn p ett mte
    . ndra typ p ett mte



** LSA INLGG

    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
        Inlagd i lyskom.

    Det vore skoj om lyskom.el kunde, som jag har fr mig att ngon
    freslog en gng, parsa fotnoter av det dr slaget [sed-mnster
    ungefr] och applicera dem p texten. Det korrigerade inlgget
    skulle ha formatmarkeringen (korrigerad av 123455) i foten. terse
    omodifierat skulle visa inlgget okorrigerat. Den korrigerande
    fotnoten visas inte i den normala lsordningen och markeras som
    lst automatiskt.

        * Krvs inkrokningar view-text.el fr att inte skriva ut att
          det finns en fotnot.
        * Krvs mer flexibel formatmarkering.
        * Krvs att man hmtar fotnoter innan man visar inlgget.
        * Troligtvis r det bttre att anvnda aux-items fr detta.

    FIX BY: 0.46-0.47



** SKRIVA INLGG

    Ngon form at reply till importerade brev som anvnder mx-reply-to
    eller mx-to, mx-cc om de finns.
        Inlagd i LysKOM

    Frgan om flera mottagare kanske inte borde stllas om man har
    arrangerat om mottagarlistan rejlt. Den skall stllas om man
    lgger till en mottagare till en existerande. Den kanske inte
    behver stllas om man har arrangerat om alla mottagare. Frgan r
    vad som hnder mittemellan.

    Varningen om olsta kommentarer r inte perfekt. Det finns flera
    frslag till ndringar. Ett r att varna bara fr kommentarer som
    skapades efter man brjade skriva kommentaren, men det verkar vara
    en kompromiss. Minst en som efterfrgade det ville i sjlva verket
    kunna sl p/av varningarna per mte. Bellman ville att varningen
    inte skulle g att sl av helt med mindre n att man explicit slr
    av den i alla mten som man r med i.

        * Den rtta saken att gra r antagligen att gra det mjligt
          att ge variabeln ett defaultvrde och ha mjlighet att ge
          undantag. 

        * Defaultvrden skulle kunna vara varna, varna inte och varna
          fr nya. Ett frslag r ocks att varna fr nya enbart om
          man har lst minst en eller kanske alla av kommentarerna
          till inlgget man kommenterar.

        * Eventuellt skulle det vara bra med en varning innan man
          brjar kommentera om kommentarer som redan finns dr. Den
          varningen borde vara oberoende av den som kommer nr man
          skickar in.
        Inlagd i LysKOM.

    Addera det kommenterades frfattare som mottagare vid behov nr
    man brjar skriva inlgget. Se till att inte gnlla om denna
    mottagare nr man skickar in inlgget.

        * Nr man brjar skriva inlgg, hll reda p att man har lagt
          till frfattare automatiskt, och frsk lta bli att gnlla
          om dessa. 

        * Hans Persson ville att att det kommenterades frfattare
          skulle lggas till automatiskt, men att om man har editerad
          headrarna s skulle kontrollen gras om igen nr man
          skickade in inlgget. Dock skulle den *inte* gras om man
          manuellt tog bort det kommenterades frfattare (det hr
          skulle hindra att man tog bort mottagare s att det
          kommenterades frfattare blev utan.) Hans Persson har helt
          rtt.
        Inlagd i LysKOM.

** EDIT-BUFFERTEN

    Defaultplaceringen av nya mottagare i editbufferten r fnig.
    FIX BY: 0.46            FIXAT. Sist istf frst.

    Det borde g att ndra mottagare till cc-mottagare genom att bara
    lgga till mottagaren igen som cc-mottagare. Motsvarande fr bcc
    och s vidare.
    FIX BY: 0.46            FIXAT

    Borde kolla efter dublettmottagare innan man skickar in inlgget.
    Annars s fr man ett trkigt felmeddelande frn servern.
    FIX BY: 0.46            FIXAT

    Kolla hur misslyckad inskickning hanteras. Vi borde ajtomagiskt
    ploppa upp edit-bufferten, alternativt ha ett kommando fr att
    gra det (och gra det till defaultkommandot.)
    FIX BY: 0.46            KLART

    Man borde kunna manipulera mottagare i editbufferten med musen (ta
    bort, ndra typ.)
    FIX BY: 0.46


** FILTER

    Ny filter-edit-mode
    FIX BY: 0.48
        Inskriven i LysKOM

    Anvnd den nya filterkompilatorn.
    FIX BY: 0.48
        Inskriven i LysKOM

    Gr inte nsta kommando efter en filtrering. Kontrollera med
    variabel.


** ASYNKRONA MEDDELANDEN

    Frglggning av meddelanden baserat p varifrn de kommer, och
    vart det gr. John Olsson efterfrgar.
    FIX BY: 0.47

    Filtrera asynkrona meddelanden (Pontus Lidman)
    FIX BY: 0.47            KLART


** MEDLEMSSKAPSINFORMATION

    Lista medlemsskap borde hllas uppdaterad. Vi behver hookar fr
    - G in i mte (uppdatera datum)
    - ndra prioritet (det har vi)
    - ndra olsta
    - Invalidera conf-stat (kanske)
    Plus att vi mste fixa en datastruktur till bufferten. Vilket slit.
    Kanske kan man mergea prioritera och lista medlemsskap? Det skulle
    ju frenkla...
    FIX BY: 0.48

** MANIPULERA MEDLEMSKAPSTYPEN

    Lgg till kommandot ndra medlemskapstyp.
    FIX BY: 0.46
        Inskriven i LysKOM
 
    Nr man accepterar en inbjudan borde man automatiskt prioritera om
    den enligt ens defaultprioritet och defaultposition.
    FIX BY: 0.46
        Inskriven i LysKOM


** TERSE

    terse senaste borde vara superinkrementell. Man kunde hmta s
    mycket man hinner under sg tre sekunder och stoppa ngonting p
    read-listan som hmtar nsta tre sekunder eller s.
    FIX BY: 0.47 or later
        Inskriven i LysKOM

    "terse n inlgg av person x till mte y frn datum z framt"
    FIX BY: 0.47 or later
        Inskriven i LysKOM

    "terse n inlgg av person x till mte y under de senaste k dagarna"
    FIX BY: 0.47 or later
        Inskriven i LysKOM

    Strunta i hemliga texter vid ar.
    FIX BY: 0.46-0.47
        Inskriven i LysKOM

    terse alla markerade borde g att avbryta med nsta mte.
    FIX BY: 0.46-0.47           NOTE: Verkar fungera

    Det vore trevligt om inlgg man tersg inte bidde varnade fr nr
    man skriver kommentarer.
        Inskriven i LysKOM
    FIX BY: Who knows?


** INTERNA SAKER

    Infr en membership-cache.

    Har detta att gra med lite fr optimistisk cache att gra? Kanske
    br man lsa om person-staten innan man varnar fr lapp p drren?
    [Det gr man vl? /davidk]

    Anvnd blocking.el som innehller en reentrant blocking-do.
    FIX BY: 0.47


** FOTNOTER

    Skriv inte ut stora fonoter p en gng.

    Visa fotnoter p ett bttre stt.

    Kommandot kom-review-comments visar fotnoter sist, inte frst.

    Det skulle vara bra om sknsvrde fr att skriva fotnot vore den
    senaste text man sjlv skrev, inte den senaste man lste. Eller
    kanske den senaste man lste om det var man sjlv som skrev den?
    Snarare den sista man lste av sig sjlv alt. den sista man skrev
    om man inte har lst ngot av sig sjlv sedan dess.
    FIX BY: 0.46-0.47               FIXAT.


** ANVNDARVNLIGHET

    Man skulle kunna lta fnstrets titelrad indikera om man har
    olsta i ngon session. Det skulle vara praktiskt fr oss som har
    KOM igng ikonifierad i en separat Emacs strre delen av tiden.
    FIX BY: 0.48
        Inskrivet i LysKOM.

    Klickbara kommandon, vad nu det r.
    FIX BY: 0.48

    Det behvs dokumentation: frmst anvndarhandledning, men det
    skulle inte skada med en kortfattad beskrivning av stabila delar
    av systemet fr presumtiva kommandoskribenter.
    FIX BY:

    Sprkgranskning av den engelska versionen.
    FIX BY:
        Inskrivet i LysKOM.

    Det skulle vara bra om man kunde ange fr varje instllning om den
    skulle sparas i servern eller inte. I princip r det enkelt, men
    det behvs ett grnssnitt fr det.
    FIX BY: 0.46                                    KLART


** AUX-ITEMS

    Implementera en FAQ aux-item. Detta kommer att krva en flagga
    till i servern som talar om fr servern att inte garba ett inlgg.
    Det i sin tur krver att man fixar dbck att forcera garb av inlgg
    med den hr flaggan som inte borde ha den eller nt snt.
    FIX BY: 0.46                                    KLART!


** MARKERINGAR

    JySKomska markeringstyper.
    FIX BY: 0.47-0.48
        Inskrivet i LysKOM


** PREFETCH

    Frbttra prefetchen. Till exempel borde ett mtes inlgg
    prefetchas vid lmpligt tillflle, t.ex. nr man gr till
    det. Idag prefetchas bara kommentarskedjor.


** DIVERSE OSORTERAT

    Lista sessioner, ungefr som lista klienter, men som ger mer
    sessionsinformation, till exempel idletid. nskad av David Hedbor.
    FIX BY: 0.47-0.48               Integrerat i Vilka. Klart.

    Sortera vilkaslistan efter t.ex. idletid.
        Inskrivet i LysKOM

    Lista nyheter borde gra start of command innan den pratar om att
    vnta p medlemskapslistan. Den gr rtt ibland, men inte alltid.

    Man borde anvnda get-unread-confs fr att lista ut vilka
    medlemsskap som skall prefetchas frst. D mste man ordna s att
    ingenting r beroende av att medlemsskapslistan hmtas i
    prioritetsordning. Prefetchen mste kunna sortera in medlemsskap i
    prioritetsordning nr den fr dem frn servern.
    FIX BY: 0.47            get-unread-confs anvnds nu.

    kom-show-presence-messages borde kunna ha ett alternativ som gr
    att kom-friends anvnds, s man fr nrvaromeddelanden enbart om
    sina vnner. Uppdatera ven instllningsbufferten.

    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.

    Implementera anonyma medlemskap i klienten. Detta r inte lngt
    ifrn klart. Vi har hemliga medlemskap och behver bara en hook
    att bli anonym nr man gr in i mtet.
        Inskrivet i LysKOM.
    
    Implementera re-z-lookup med re-lookup-X s att vi kan terinfra
    maximal kompatibilitet.


** FACES

    Anvnd face-flag i lyskom-format-aux fr att bestmma om man skall
    visa faces eller inte. Kolla att

    1) det gr att visa faces
    2) lyskom-show-faces r satt

    innan man frsker. Man skulle till och med kunna stta face-flag
    efter de hr villkoren. Lgg till anvndarvariabeln kom-show-faces som 
    talar om nr man vill ha faces:

    0) alltid/aldrig
    1) vilkalistan (working conf och person)
    2) status mte/person   (freslagen default)
    3) varje inlgg
    4) brev
    5) in- och utloggningar
    6) personliga meddelanden
    7) mottagarna till inlgg
    8) namnndring

    dessa funktioner fr sedan binda om lyskom-show-faces dynamiskt till
    true eller false.
    
    Visa bilder mindre n X * Y pixels, mindre n X bytes
    
    Kombinera med mjlighet att bara visa bilder fr kom-friends
    
    Fr varje punkt p listan, tala om vilka man vill eller inte vill se
    bilder fr. 


** KOLLA ATT DETTA R KLART

    Om man terser senaste av sig sjlv s kan man rka 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 fr inte frska formattera som HTML om det
    inte gr att ladda w3.
    FIX BY: 0.46

    lyskom-w3-region fr inte krascha. Stoppa condition-case runt.
    FIX BY: 0.46

    Buggar i special-insert gr att eoc inte krs, och man har inte
    lst inlgget. Man borde f inlgget lsmarkerat och f end of
    command.
    FIX BY: 0.46









Jag skrev ett inlgg.  Gjorde sedan snabbt C-c C-c M return.
Markering frskte gras innan meddelandet om att inlgget skapats
kommit.  Det verkade lsa sig d och jag fick gra quit och koppla upp
mig igen.











Det vore trevligt om statusraden rapprterade om olsta endast fr de
lsbuffrar som inte syns.

Exempel: jag str i lsbufferten dr lyslyskom finns och jag har ven
csdkom igng, men denna buffert syns inte.

	Olsta i	Olsta i	Status raden
	lyslys		csdkom		sger "olsta"?

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


P detta vis ser jag om det har dykt upp olsta i andra lyskomsystem.
Det just nu aktiva lyskomsystemet ser jag ju nd statusen fr.

Naturligtvis br beteendet vara valbart.





Jag har diverse sm elips-snuttar knutna till krokar i elisp-klienten.
Ibland vill jag modifiera namnet p den frame dr lyskom kr av lite
olika anledninger.  Den kod jag f.n. anvnder modifierar namnet p
aktiv frame oavsett om lyskom r synlig i den eller ej.  Finns det
ngot kanoniskt (eller i vart fall fungerande) stt att ta reda p
vilken frame (om ngon) som ska manipuleras med frn ett
elisp-program?

Jag vill nedan uppn att framen heter "<LYSKOMSERVER>" om jag inte har
ngra olsta (primitivt detekterat av ifall min klient fr meddelande
om en ny text, att jag inte har olsta avgr jag baserat bara p att
jag utfr *ngot* kommando i lyskom som framgr nedan) samt
"<LYSKOMSERVER> *" nr det inkommit olsta texter.  Skillnaden mot
nedanstende kod r att jag just bara vill byta namn p den frame dr
lyskom r synlig (eller inte ndra alls om lyskoms buffer r begravd).

Jag har fljande kod i min .emacs (mjligen hller servern reda p
ngon av krokarna utan att jag behver 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 hr:

  (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".
    
    (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 fr att ha en variabel i dokumentstrngen s att
vrdet av variabeln anvnds vid visandet av strngen?










Vill man ha hemliga medlemmar s vill man nog minska allt eventuellt
informationslckage om att en viss person r eller har varit hemlig
medlem i ett mte.

Tvinga hemlig till ickehemlig: gr det att f s att organisatr kan
sga att Sune inte fr vara hemlig i mte Foo, dvs att det r tupeln
<person,mte> som hemlighetsprivlegiet ligger p? I s fall kanske
organisatren kan sga "Sune fr endast vara medlem som ickehemlig".
r Sune redan medlem och hemlig s r det utkastning (helst med
ihgkommen mtesstatus vad gller vilka texter som r lsta) som ger
minst informationslckage.

Konvertering av mte till ickehemligt: minst elakt vad gller
informationslckage 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 mten
dr jag r medlem. Jag vill allts f en massa varningar nr jag blir
medlem i ett mte eller nr ett mte ndrar status till att tillta
hemliga medlemmar.

Jag r dessutom nyfiken och tror att det vore trevlig om kommandot
status mte anger inte bara om hemliga medlemmar r tilltna utan ven
hur mnga som r hemliga fr tillfllet.








Det vore trevligt om det funnes kommandon fr att lista volka lyskom
man har olsta i.

Kanske i stil med att "lista lyskom" visade totalt antal olsta inlgg
man har i de olika lyskomsystemen som man r uppkopplad mot:

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











> Fr alternativa vyer finns fr tillfllet inget alternativ annat n
> att anvnda multipart/alternative eller ngot liknande. Iofs skulle
> man kunna tnka sig att man stoppar in information om delarna i en
> eller flera aux-items och talar om var i texten varje del brjar och
> slutar. D skulle en klient kunna hmta bara de delar den vill ha.
> 
> Borde man gra s?

Ja, det tycker jag.  Nedan kommer tv ogenomtnkta frslag p hur man
skulle kunna utforma dem.  Som exempel anvnder jag ett inlgg som har
den hr strukturen:

	Byte	Innehll
	0-24	renderaden
	25-149	Texten i formatet text/x-kom-basic (dvs omformatterbar text)
	150-299	Texten i formatet text/html
	300-399	En liten ikon som anvnds av HTML-versionen
	400-799	En shockwave-animation som anvnds av HTML-versionen
	800-999	En stillbild som kan anvndas i stllet fr
		shockwave-animation av klienter som inte frstr shockwave

1.

En aux-item per textdel.  Varje aux-item innehller en "rubrikniv",
en MIME-typ, offset och lngd.  Ordet "rubrikniv" r dligt, men jag
kommer inte p ngot bttre just nu.  Frsta 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 bestr det alternativet i sin tur av en
sekvens av delar.  En fjrde siffra innebr att en sdan del i sin tur
finns i flera format, et c.

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

Nedkodat skulle det kunna bli s hr:

	1;x-kom/subject;0;24
	2.1;text/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 inlggets struktur med hjlp av en sexp
eller ngot liknande.  Exemplet skulle kunna se ut ungefr s hr:

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

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

Man behver fundera mer p om man behver kunna namnge bilagor.  Jag
har inte lst MIME-dokumenten p vldigt lnge; det r nog lmpligt
att gra innan man spikar formatet.











I IMAP finns det en typ "body-structure" som r tnkt att beskriva hur
ett meddelande r uppbyggt i MIME-avseende. Det r inte jttevackert,
och kanske overkill fr KOM, men kanske kan vara vrt 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 gnger upplevt att elispklienten gtt
brsrkagng, och kom just p vad som orsakade problemet; i
aInstllningar (fr) LysKOM hade jag angivit en ljudspelare
som inte existerade, vilket fick fljden att hela Emacs
frefll tvrd d jag fick personliga meddelanden snda med
aSnda meddelande (det enda jag valt att f ljud spelade fr),
samtidigt som Emacsprocessen brjade ta upp all processortid
den frmdde 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 ngon ger sig p att rota efter felet och inte lyckas
terskapa situationen/tycker sig behva en
kom-compile-bug-report, r det bara att sga till.








Jag satt och frskte komma fram till hur man kunde gra det hr igr
och kom fram till bde bra och dliga saker. Om man bestmmer sig fr
att anvndare A loggar in frst och anvndare B sedan s r det
enkelt. Om man vill kunna logga in sina anvndare i godtycklig ordning
(och det vill man ju) s blir det lite svrare, fr mode-raden stts
innan anvndaren loggar in.

Det finns en funktion som gr om mode-raden varje gng man gr till
ett nytt mte, men svitt jag kan begripa s ritar den bara om den
delen som jag inte vill pilla med. Kan jag ndra den andra biten p
ngot stt efter att anvndaren har loggat in?














Jag brukar ofta kra tv sessioner i samma Emacs, en fr den hr
identiteten och en fr min I]M-person. Den som loggar in frst fr en
moderad som brjar

    --%*-LysKOM: (47/11) Mtesnamn

medan den andra fr

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

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

    --%*-LysKOM(main):

och

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

Gr det att stakomma p ett rimligt enkelt stt?















Efter "terse alla markerade" pstr B-kommandot inversen av vad som
gller. Ser jag bakt (frskaste frst, gende mot ldsta) pstr den
att jag ser frammt, ser jag frammt pstr den att jag ser bakt:


| terse alla markerade - terse alla markerade
| terse nsta markerade - (terse) Baklnges
| Du terser nu bakt.
| terse nsta markerade - (terse) Baklnges
| Du terser nu framt.
| terse nsta markerade.
| 3487158 1998-11-13  15:23  /1 rad/ (sno)pp
...
| (3487158)
| Kommentar i text 3487169 av Ronny Svedman (desillusionerad, eller nt)
| terse nsta markerade - (terse) Baklnges
| Du terser nu bakt.
| terse nsta markerade.
| 336328 1993-04-02  20:37  /71 rader/ Lars Aronsson (lars@aronsson.se)
...

Detta skiljer sig frn vad som hnder vid "terse senaste 10" i ett
mte.



| G till nsta mte - terse senaste
| terse senaste 10 av vem som helst till PC (IBM PC med efterfljare) erfarenhetsutbyte framt.
| terse nsta text - (terse) Baklnges
| Du terser nu bakt.
| terse nsta text.
| 3493782 idag 13:05 /9 rader/ Magnus K
...
| (3493782)
| terse nsta text - (terse) Baklnges
| Du terser nu framt.
| terse nsta text.
| 3493466 idag 11:55 /1 rad/ Erland Costyson
...


Vid "terse senaste" kommer jag att f frskaste texten om jag r i
lget "baklnges", vid "terse alla markerade" om jag r i lget
"framlnges".

Jag kr LysKOM elisp-klient version 0.45.









Jag skulle vilja ha lite mer makt ver det som skrivs i statusraden.
Nu str dr "Olsta" eller "Olsta brev". Jag skulle vilja ha
mjlighet till till exempel fljande:

 * Skriv "Olsta" om det r i den aktiva (versta) KOM-bufferten,
   annars "(Olsta)". Motsvarande fr brev.

 * Skriv "Olsta brev" men lt bli att rapportera om olsta inlgg fr
   det har jag alltid.

 * Ngon mjlighet att pverka det som skrivs ut beroende p vilken
   buffert (vilken server/KOMperson) det hr till.















Medan jag kommer ihg det ska jag frresten rapportera att jag tycker
att "Fotnot till inlgg" beter sig fel. Nr den senast lsta texten r
ett eget inlgg och man drefter skapat en text borde denna, senaste,
text fotnoteras per default istllet fr det senast lsta.

Anledningen r enkel - man lser ofta en kommentar till en egen text,
gr k, kommenterar fregende 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
rkar hlla reda p att man skrivit en kommentar senare n man lst en
text.

FIX BY: 0.46            KLART.
















Vilka typer av markeringar finns det planer p?

Jag skulle tminstone vilja ha permanent markering, tidsbegrnsad (men
oborttagbar under den tiden), pminnelse (visas automatiskt nsta gng
jag loggar in), och grna mjlighet att stta olika nyckelord p
texterna jag markerar. Jag vill ocks ha mjligheten att erstta
renderaden p texterna jag markerar med ngot mer informativt s att
lista renden fungerar bttre.

Lista markerade (per) nyckelord












Ungefr som vilka-listan men med sessionsinfo, typ:

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

Varfr? Frmst fr att se idle-tiden. Kan nog kombineras med Lista
Klienter.














Det hr tycker jag verkar vara en bug i 0.45.1:

Jag kommenterar ett inlgg som ligger i ett mte jag inte r med i.
Mtet ifrga r ett originalmte, varfr min kommentar fr ett annat
mte som mottagare.  Trots att jag r med i supermtet lgger klienten
till min brevlda som mottagare till komentaren.














Nr man gr med i ett nytt mte s blir man tillfrgad vilken
prioritet man vill ha p det nya mtet. Det r bra. Problemet r bara
att jag inte kommer ihg hur jag sorterat mtena, s varje gng jag
lagt till nya mten s fr jag g in och prioritera s att det hamnar
dr jag tnkt mig.

Jag kom just p att vad jag skulle vilja ha r mjligheten att ange
inte bara en prioritet p det nya mtet, utan istllet kunna ange
namnet p ett annat mte vilket i s fall naturligtvis betyder att det
nya mtet ska ha samma prioritet som det jag anger.







Jag har tidigare efterlyst mjligheten att kunna skriva en egen text
att f visad istllet fr originalrdenderaden p texter jag
markerat. Allt fr ofta har mina markerade texter renderader som inte
har ett skvatt med innehllet att gra.



Local variables:
mode: outline
paragraph-separate: "[ \t]*$"
outline-regexp: "[*]+"
end:
