Egen stavningskontroll. Hur hålla koll på ord och positioner?

Om du har tillgång till texteditorn vars text det är som påverkas så skulle jag göra följande:
Ge varje rad ett unikt id.
Alternativt, gör en checksumma av varje rad och jämför det mot befintliga rader. Raderna som du redan har är redan uträknade.

Att arbeta på radnivå gör så att du bara behöver kontrollera raderna som är påverkade (dirty).

Låter något av det jag har sagt rimligt/genomförbart?

Ok, men vad tror du på den alternativa lösningen då?

Alltså att göra en checksumma av varje rad. Jag tror du tjänar på det i längden eftersom att bara det nya/påverkade rader behövs kontrolleras. Checksumman blir alltså IDt. Det behöver inte vara unikt heller då flera rader kan (beroende på vilken text som skrivs) vara identiska.

Det här är ju bara ett av problemen som sagt. Att indexera/placera orden som är ok/inte ok har jag inte ens funderat på.

Vi kan sova på saken och hoppas på att någon annan har något intressant förslag.
Rolig nöt att försöka knäcka!

Ingen aning om hur det ser ut i koden, men du kan väl plocka hem OO/libreoffice koden och ta en kik hur de löst det där, men det kanske är för mycket fusk

Det är svårt att förklara närmare... Jag försöker.

1. Skicka in texten till rättstavaren (kallas text1 nu)
2. Rättstavaren splittar text1 på nya rader.
3. Rättstavaren gör en checksumma av varje rad baserat på alla tecken på denna rad.
4a. Rättstavaren jämför radernas checksumma i text1 med checksummor från en befintlig texts rader (texten från innan denna rättstavning gjordes. Vi har alltså alltid OLD och NEW, exempelvis text0 och text1)
4b. Checksummor som skiljer sig är alltså nya eller påverkade rader.
5. Vid nya/påverkade rader så görs rättstavning för dessa raders ord.

Jag har inte alls testat detta. Jag tänker bara att det borde vara bättre att slå upp rättstavning för förändrade raders ord än att göra det för alla varje gång. Det kan ju visa sig att det kostar mer att göra på detta sätt. Det kanske till och med kostar mer än att jämföra raderna utan checksummor.

Om jag inte missförstår något så måste man alltså kontinuerligt göra checksummor för alla rader i den nya texten och jämföra med samtliga checksummor i den gamla (eftersom vi arbetar med ett okänt antal oindexerade textrader). Om man ändå måste räkna ut checksums vid varje check så känns det rent intuitivt "billigare" att jämföra nytt-tecken mot gammalt-tecken.

edit: ok, jag tror jag förstår idén bättre nu. Det känns som att metoden borde fungera bra på korta rader och mindre bra om man skriver ett längre stycke utan radbrytningar, då hela raden måste bearbetas för att få ett checksum att jämföra med.

Ja, det stämmer. Hade varit väldigt kul att jämföra det där. Varför jag tänker checksummor är för att det "gamla" resultatets checksumma redan är uträknat. Men visst, den nya raden måste göras till en checksumma. Jämförelsen newRow[x] == oldRow[y] är dyrare än checksum1[x] == checksum2[y]. Möjligtvis så kanske checksum-uträkningen är dyrare än den enkla jämförelsen. Jag kan inte komma på någon enkel checksumma som skulle vara tokbillig. Avgränsningar kan inte göras då bara ett tecken kan skilja sig.
För att optimera så tror jag ändå att man måste bryta ut det på radnivå för att slippa rättstavning på redan avklarade rader. Ännu bättre hade kanske varit att ha något på ord-nivå eller det också. Frågan är hur pass stor minnesanvändningen får vara...

Min ursprungliga tanke var att skapa en ordlista i form av ett btree med flera "entry points", en för varje bokstav.
En grundläggande definition kan exempelvis ha 29 entry points för bokstäverna a till och med ö. Dessa entry points fungerar som index in i trädet; man kan se dem som roten på flera "under-träd". Det går också att ha 29 separata btrees men tanken på en samlad datastruktur med smarta index känns mer rolig.

Hursomhelst, datastrukturen kombineras med en enkel klass som håller reda på varje ord i rutan. Kanske något i stil med

class CheckedWord {
   long startpos;
   String s; // faktiskt värde
}

Dictionaryn kan i sin tur ha

   String[] getSuggestionsFor(String s) { ... } // hämtar förslag för strängen s, praktiskt taget alla noder som börjar med strängen 's'. Använder första bokstaven i s som index för snabbare lookups

En vektor representerar alla positioner i texten. Ett index i vektorn kan antingen vara ett CheckedWord eller null. Är värdet null letar man sig framåt tills man hittar en CheckedWord, och sedan räknar man längden på CheckedWord.s och drar det ifrån vektorns index för att få startpositionen (dvs vektorn registrerar bara stället där ordet slutar för att undvika en referens för varje bokstav i ordet)

edit: exempel

 text: Lorem ipsum dolor sit amet
array: 0,0,0,0,CheckedWord (Lorem),0,0,0,0,0,0,CheckedWord (ipsum), osv

Hitta ord på position 8: array[8] = 0 (följt av 0, 0, CheckedWord (ipsum)). Gå framåt i arrayen tills vi hittar ett CheckedWord (position 11). Ta längden av ordet (ipsum = 5). Vi vet nu att ordet börjar på position 11-5 = 6. Gör en lookup på ordet 'ipsum' i dictionary, färga beroende på resultat, etc etc..

Jag hängde inte med på vad indexet skulle användas till tror jag.
Du har naturligtvis rätt i att det blir en större operation om man lägger till text i början istället för slutet. Faktum är att det kan bli riktigt kostsamt med en vektor- eller ArrayList-implementation.

Vad innehåller objektet?

för att förtydliga: som jag förstår det så ska det innehålla information om ordet (ipsum i det här fallet) men ordets position är ju redan känt, annars vet man inte vilket index man ska läsa.

Jag kan vara helt ute och cykla nu, är ganska trött, men visst känner man ordet när man hittat indexet, eftersom det står framför..?

Vad jag menar är att indexet inte löser något problem som jag förstår det; för att hitta det måste man ändå arbeta sig igenom textmassan. Stämmer inte det?