-*- Mode: outline; -*-

Att göra i elisp-klienten
=========================

* SPRÅK

Moderaden och fönstertiteln ändras inte om man byter språk.

* PREFETCH

Prefetchen verkar ställa till problem. När man skickar ett mail till
sig själv med attachments så kommer klienten att hämta text-stat för
brevet innan det har fått mx-attachments-in satt, och trots att man
raderar det ur cachen när attachmentet dyker upp.

Jag misstänker att det finns en prefetch inlagd som hämtar text-staten
innan importören har hunnit sätta mx-attachments-in. Det vore bra om
man kunde fördröja den en aning.

Man skulle kunna slå på debugging och titta i lyskom-prefetch-stack
och i anropsköerna när 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 såg jag att textmassan för inlägg verkar hämtas två gånger,
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 inlägg med vänner borde kolla om man försöker kommentera en
bilaga. I så fall borde man få förslag att kommentera "urinlägget"
istället. Klienten får följa "belongs-to"-länkarna uppåt. 

Det vore trevligt om man kunde välja vilka sorters bilagor man inte
vill följa kommentarer till.

Inför en ATTACHMENT-IN type i read-listan som komplement till COMM-IN.
Prompten blir läsa nästa bilaga.

Det går inte att konsekvent få se "bilaga" istället för "text" eller
"inlägg" eftersom man inte alltid har text-staten i tid. Till exempel
slipper man nog när man bygger kontextmenyn för inläggsnumret.

Om man vill få se "återse nästa bilaga" när man gör åak, åar, åt så
behöve ett komplement till REVIEW-TREE och REVIEW. Man måste ha
text-staten när man skapar entryt för att kunna titta på mx-belongs-to
innan man stoppar in det i read-listan.


Använd lyskom-read-text-no-prefix arg i alla funktioner där det är
meningsfullt. Följande är relevanta:

        Kommando                            Default     Prompt
        ------------------------------------------------------
      * Radera inlägg                       SL          Alltid
      * Återse inlägg                       SL          Ja
      * Återse omodifierat                  SL          Nej
      * Återse urinlägget                   SL          Nej
      * Återse alla kommentarer             SL          Nej
      * Återse alla kommentarer reku        SL          Nej
      * Återse träd                         SL          Nej
      * Återse det kommenterade             SL          Nej
      * Återse det föregående kommen        NSL         Nej
      * Kommentera inlägget                 SL          Nej
      * Kommentera föregående inlägg        NSL         Nej
      * Fotnot till inlägg                  SS          Ja
      * Personligt svar                     SL          Nej
      * Personligt svar på föregåend        NSL         Nej
      * Markera (inlägg)                    SL          Ja
      * Avmarkera (inlägg)                  SL          Ja
      * Addera mottagare                    SL          Ja
      * Addera extra kopiemottagare         SL          Ja
      * Addera för kännedom                 SL          Ja
      * Subtrahera mottagare                SL          Ja
      * Flytta inlägg                       SL          Ja
      * Addera kommentar                    SL          Ja
      * Subtrahera kommentar                SL          Ja
      X Arkivera inlägg (till fil)          SL          Ja
      * Spara inläggstext (på fil)          SL          Ja
      X Sätt loginmeddelande                SS          Ja
      * Kort replik                         SL          Nej
      * Hålla med                           SL          Nej
      * Addera FAQ                          SS          Ja
      * Addera fotnot                       SS          Ja
      * Subtrahera fotnot                   SS          Ja
      * Förhindra kommentarer               SS          Ja
      * Begär personligt svar               SS          Ja
      * Begär läsbekräftelse                SS          Ja
      * Återse brevhuvud                    SL          Nej
        ------------------------------------------------------
        SL  Senast lästa
        NSL Näst senast lästa
        SS  Senast skrivna/eget läst
        *   Klart
        -   Hanterar kanske inte returvärde nil 
        X   Borde inte vara med på listan

Bestäm vettig default och om kommandot skall fråga 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 håller på att uppdateras.

** Stöd för att helt dölja ett medlemskap i kom-handle-membership. Man
   vill kanske dölja alla man inte har olästa i, eller alla som man
   inte har varit inne i på jättelänge

** Stöd för 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 för 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 gör lite fel. Om man har en rad med :/ i så stoppar
   den radbrytningen. Egentligen så borde kanske en rad som bara
   består av icke-bokstäver avsluta aktuellt stycke och kanske vara
   sitt eget stycke också.

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

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

   Händer ibland när man loggar in också.

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

   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.


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



När man gör status för ett tomt möte så är lägsta lokala nummer högre
än det högsta. Snygga till utskriften till exempel genom att skriva
att mötet är tomt.  Det skall synas skillnad på möten som alltid har
varit tomma och sådana som har haft inlägg som har garbats.


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.


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.

Man borde använda next-command-event med vänner i silent-read och
j-or-n-p.


* SAKER ATT KOLLA TILL 0.46

    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.


    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

    Testa lyskom-is-anonymous!

    Prioritet noll är tillåten. Kolla alla strängar som nämner
    prioriter så att det står rätt i dem.

    Hur och var skall man egentligen spara inställningar? .emacs är
    kanske inte det bästa alternativet. 


* BUGGAR

** OSORTERADE

    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

    Om förbindelsen bryts så får man args out of range ibland.
    FIX BY: 0.46

    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.
    FIX BY: ---

    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
    blev det rätt. Det verkar som om window-width ljuger.
    FIX BY: N/A

    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.
    FIX BY: 0.46-0.47

    Endast gör fortfarande fel. Den klarar inte hål och använder 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 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. 
    FIX BY: 0.46-0.47
        Inlagd i LysKOM.


** DEFERRED INSERT

    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.
    FIX BY: ---

    Om ett namn som fylls i i efterhand gör att sista raden blir för
    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.)
    FIX BY: --- (check before release of 0.46)


** PREFETCH 

    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.

    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.
    FIX BY: 

    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.
    FIX BY: 0.46


** COMPLETING READ

    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.
    FIX BY: 0.46-0.47                           KLART!

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

    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.
    FIX BY: Whenever


** HANTERING AV FOTNOTER

    Den försöker fortfarande följa hemliga kommentarer om
    kom-show-footnotes-immediately är satt.
    FIX BY: --- (Check before release of 0.46)

    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
    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...]
    FIX BY: ---

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

    kom-review-tree på en text med fotnoter visar fotnoterna på en
    gång. Är det en bug?
    FIX BY: 


** PROMPTEN

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


** 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.
    FIX BY: --- (Check by 0.46)

    Tommy Persson får LysKOM protocol error. Det kan bero på strulande
    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
    fortfarande kan ingen reproducera det. Nu har jag också fått det. 
    FIX BY: YESTERDAY



* FÖRBÄTTRINGAR

** Kopiera inställningar från en server till en annan.

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



** LÄSA INLÄGG

    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 för mig att någon
    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.

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

    FIX BY: 0.46-0.47



** SKRIVA INLÄGG

    Någon form at reply till importerade brev som använder mx-reply-to
    eller mx-to, mx-cc om de finns.
        Inlagd i LysKOM

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

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

** EDIT-BUFFERTEN

    Defaultplaceringen av nya mottagare i editbufferten är fånig.
    FIX BY: 0.46            FIXAT. Sist istf först.

    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.
    FIX BY: 0.46            FIXAT

    Borde kolla efter dublettmottagare innan man skickar in inlägget.
    Annars så får man ett tråkigt felmeddelande från servern.
    FIX BY: 0.46            FIXAT

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

    Använd den nya filterkompilatorn.
    FIX BY: 0.48
        Inskriven i LysKOM

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


** ASYNKRONA MEDDELANDEN

    Färgläggning av meddelanden baserat på varifrån de kommer, och
    vart det går. John Olsson efterfrågar.
    FIX BY: 0.47

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


** MEDLEMSSKAPSINFORMATION

    Lista medlemsskap borde hållas uppdaterad. Vi behöver hookar för
    - Gå in i möte (uppdatera datum)
    - Ändra prioritet (det har vi)
    - Ändra olästa
    - Invalidera conf-stat (kanske)
    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...
    FIX BY: 0.48

** MANIPULERA MEDLEMSKAPSTYPEN

    Lägg till kommandot ändra medlemskapstyp.
    FIX BY: 0.46
        Inskriven i LysKOM
 
    När 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 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å.
    FIX BY: 0.47 or later
        Inskriven i LysKOM

    "Återse n inlägg av person x till möte y från datum z framåt"
    FIX BY: 0.47 or later
        Inskriven i LysKOM

    "Återse n inlägg av person x till möte 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 nästa möte.
    FIX BY: 0.46-0.47           NOTE: Verkar fungera

    Det vore trevligt om inlägg man återsåg inte bidde varnade för när
    man skriver kommentarer.
        Inskriven i LysKOM
    FIX BY: Who knows?


** INTERNA SAKER

    Inför en membership-cache.

    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?
    [Det gör man väl? /davidk]

    Använd blocking.el som innehåller en reentrant blocking-do.
    FIX BY: 0.47


** FOTNOTER

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

    Visa fotnoter på ett bättre sätt.

    Kommandot kom-review-comments visar fotnoter sist, inte först.

    Det skulle vara bra om skönsvärde för att skriva fotnot vore den
    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?
    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.
    FIX BY: 0.46-0.47               FIXAT.


** ANVäNDARVäNLIGHET

    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.
    FIX BY: 0.48
        Inskrivet i LysKOM.

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

    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.
    FIX BY:

    Språkgranskning av den engelska versionen.
    FIX BY:
        Inskrivet i LysKOM.

    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.
    FIX BY: 0.46                                    KLART


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


** MARKERINGAR

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


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


** DIVERSE OSORTERAT

    Lista sessioner, ungefär 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 göra start of command innan den pratar om att
    vänta på medlemskapslistan. Den gör rätt ibland, men inte alltid.

    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.
    FIX BY: 0.47            get-unread-confs används nu.

    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.

    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 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.
        Inskrivet i LysKOM.
    
    Implementera re-z-lookup med re-lookup-X så att vi kan återinföra
    maximal kompatibilitet.


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


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









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".
    
    (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 text/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: text/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;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 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
	    (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 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.

FIX BY: 0.46            KLART.
















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.


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