🚀 go-pugleaf

Toen ik Bastiaan kietelde, kwam er dit uit:
> Dr.Ruud:
>> Bastiaan:

>>> Een expanded tab heeft een lengte die van zijn positie in de regel
>>> afhangt.
>>> Dat is nou juist de niet te berekenen factor. Tenminste, is alleen
>>> te berekenen als je van het begin af de tabs expandeert. Daarom is
>>> het zo onbegrijpelijk dat LIST dat zo snel doet. Hij lijkt dus 16
>>> MB te kunnen
>>> behandelen in minder dan 1 sec. Of... er moet een andere manier
>>> zijn.

>> Zoiets kun je best vanaf het einde doen?
>>
>> Je gaat er initieel van uit dat het laatste teken van de file op de
>> laatste schermpositie komt. Je loopt vervolgens terug in de buffer
>> tot je het scherm af hebt. Als je een tab tegenkomt, dan bekijk je
>> of je het deel wat je al gedaan hebt, kunt laten staan of dat je
>> moet corrigeren. (dit alles alleen als je geen newlines hebt)

> Nee, dat gaat niet.

Ja, dat gaat wel.


> De positie van zeg maar het laatste teken is
> afhankelijk van de filegrootte �n �lle tabs (�n hun positie) in
> de hele file.

Zoek even in wat ik schreef naar het woord "corrigeren". Geef anders
eens precies de structuur aan van een file waarmee het volgens jou
niet kan.

Eigenlijk heb je maar twee soorten: om de 1-7 tekens een tab, en om
de 8+ tekens een tab. Alle andere bestanden zijn daar variaties op.
Het maakt niet uit of er al dan niet CR-LFs in staan.

Het ligt er wel nog aan of je een tab minimaal 1 spatie wil laten
opleveren: 1234567<tab>ABC, staat de A dan op positie 8 (ofwel tab
compression) of liever op 16?


> Ik weet nog wel een manier: zelf een filebuffer beheren.

Dat is onderdeel van elke oplossing die al aan je is voorgesteld.
En die buffer hoeft maar een paar kB groot te zijn. Je leest
alleen het laatste deel van de file (in e1n keer) van schijf.

-- 
Affijn, Ruud   `  -  ?
               + ` ? *
                 ? `     Jvr qvg yrrfg,
               ?  =  `   fgresg wbatre.