ZFX + Developia

Wenn man durch eine Textdatei scrollen möchte, ist das normalerweise ganz einfach: Schlicht den vorherigen oder nächsten Zeilenumbruch suchen, und an die Spitze des Dokuments bringen.

Mit Word Wrap wird die Sache aber ungleich komplizierter: Jetzt werden Zeilenumbrüche dynamisch erzeugt. Anstatt beim Runterscrollen nach dem nächsten Newline-Buchstaben zu suchen, müssen nun die Buchstaben über die Zeile mitgezählt und der letzte Wortbeginn vermerkt werden. Beim Hochscrollen ist es noch etwas komplizierter (weil rückwärts).

Das an sich wäre ja nicht schlimm, aber nun habe ich den Zeilenumbruch-Quelltext schon dreifach: Einmal beim Anzeigen (wenn die Buchstaben auf dem Bildschirm ausgegeben werden müssen); einmal beim Runterscrollen (wenn die nächsten Zeilenumbrüche gefunden werden müssen); einmal beim Hochscrollen (nur rückwärts). WTF.

Wie löst man das elegant?

Die meisten Editoren dürften nicht direkt auf den "Rohdaten" arbeiten, sondern den Text in einer zweckmäßigeren Datenstruktur im Speicher halten. Deine Probleme vereinfachen sich z.B. stark wenn man den Text als ein Array mit Zeilen-Objekten verwaltet. Dann braucht man die Linebreaks nicht mehr explizit suchen weil sie grundsätzlich am Ende jeden Zeilen-Strings sind (beim letzten allerdings optional). Statt dessen kann man die Zeilen direkt adressieren.

Beim Scrollen mit word-wrap kann man einfach jedes mal von der ersten Zeile an den Text durchgehen und die "visuellen Zeilen" (also echte Zeilen + visuelle Umbrüche) zählen bis man die gesuchte Position erreicht. Das ist zwar bei vielen Zeilen nicht mehr effizient, aber für ein paar tausend Zeilen juckt das keinen (ich hab auch schon öfter bemerkt das Editoren träge werden wenn man bei langen Dokumenten Word-Wrap einschaltet). Natürlich kann man die "visuellen Zeilennummern" auch cachen und wiederverwenden solange sich nichts an ihnen ändert. Aber dann muss man halt aufpassen das man die betroffenen Zeilen auch wirklich aktualisiert wenn der Text verändert wird. Deshalb würde ich drauf verzichten solange es auch ohne geht.

Ja; klingt sinnig. Dummerweise habe ich absolut null „echte“ Zeilenumbrüche in der Datei, sondern nur Word Wrap :( Das vorausberechnen ist zwecklos; bedeutet mindestens eine Minute Wartezeit bei jeder Änderung der Fenstergröße.

Eine Optimierung, die ganz gut funktioniert: Wenn der Renderer den Text formatiert, spuckt er nebenbei die Adresse jedes Zeilenbeginns mit aus. Beim Herunterscrollen kann darauf zugegriffen werden (sofern die beabsichtigte Zeile noch auf dem Bildschirm liegt). Aber fürs Hochscrollen funktioniert auch das nicht :(

Je mehr ich darüber nachdenke, desto kaputter sieht die Situation aus: Word Wrapping ist ein streng sequentielles Problem. Man kann nicht mitten im Text anfangen zu rechnen sondern muss immer zum letzten bekannten Zeilenumbruch zurück. Fuck :(

Oh, also ist dein Text quasi nur eine sehr lange Zeile... das ist natürlich ein unbequemer Extremfall. Ohne Word-Wrap wäre das allerdings ganz einfach und effizient lösbar... kannst du vielleicht einfach drauf verzichten? Den Text also so anzeigen wie es die Hex-Editoren tun. Evtl. reicht es ja schon ein nettes Symbol (z.B. die Unicode-Ellipse "…") hinter den Zeilen anzuzeigen an deren Ende ein Wort umgebrochen wird.

Sternmull hat geschrieben:Oh, also ist dein Text quasi nur eine sehr lange Zeile...

Perfekt getroffen :) Verzichten möchte ich ungern, weil der Word Wrap eigentlich sogar das Wichtigste ist, um Muster identifizieren zu können. Ich hacke jetzt eine Kopie der Suche rein und muss sie später eben an drei Stellen warten; es wird sich sowieso noch jede Menge an der Formatierung ändern, fürchte ich …

Du könntest die Sache auch vereinfachen wenn du zeichenweise scrollst statt "zeilenweise" und das wordwrapping wirklich nur für die Anzeige nutzt. Dann braucht man keine umgebrochenen Zeilen mehr berechnen um von der Scroll-Position an den Textausschnitt für die Anzeige zu kommen und hat trotzdem das word-wrap-feature bei der Darstellung. Bei der Darstellung würde man also von irgend einer Zeichen-Position an den Text mit word-wrapping darstellen bis das Fenster voll ist oder man am Text-Ende angekommen ist.

Wie wäre es, wenn du die Aufteilung des Textes in Worte einmalig zu Begin machst und in einer entsprechenden Datenstruktur ablegst? Wenn der Text editiert wird musst du diese Datenstruktur nicht immer komplett neu aufbauen. Das Problem die Worte in Zeilen zusammenzufassen dürfte sich dann stark vereinfachen. Natürlich wäre es immer noch nicht beliebig skalierbar.

Du solltest den Text beim Laden genau 1x analysieren und eine Tabelle anlegen. Finde jeden möglichen Umbruch heraus (Whitespaces, Minus, Klammern..?) und speicher den Pixelabstand (für den Renderer), Start und Ende des Worts im String. Das sollte relativ schnell gehen.

Jetzt kannst du die einzelnen Zeilen sehr schnell zusammebauen. Du hast eine feste Zeilenbreite und kannst durch die gespeicherten Breiten sehr einfach durch Addition entlang des Textes feststellen, wenn etwas nicht mehr in dei Zeile passt und nacheinander die einzelnen Zeilen anlegen.
Ich wüsste nicht, warum das mehrere Sekunden rechen sollte, selbst wenn man 100MB Text hat, ist man in einer Iteration druch. Man analysiert den Text ja nicht mehr, sondern ratter genau 1x drüber.
Hat man die einzelnen Zeilen, ist die restliche Verwaltung einfach.

Viel hässlicher ist, dass man den Text 3x im Speicher hat für sowas :-/

Hmpf. Kristof.. sry, ich hätte den Thread zu ende lesen sollen -..- ich sag genau das, was du auch möchtest. Ich weiß aber nicht, warum das nicht beliebig skalierbar sein soll

DerAlbi hat geschrieben:Ich weiß aber nicht, warum das nicht beliebig skalierbar sein soll

Weil der Rechen- und Speicheraufwand eben immer noch im Mittel mit der Textlänge skaliert. D.h. es hat die gleiche Komplexität wie das direkte suchen nach Wortgrenzen, nur mit einem anderen Faktor. Dieser Aufwand fällt jedes mal an wenn sich die Fensterbreite ändert (Position der Umbrüche verschiebt sich) oder sich der Text ändert.
Das Speichern der Wortgrenzen führt auch noch zu einem nicht ganz unerheblichen zusätzlichen Speicheraufwand: Du willst drei Integer ablegen. Selbst wenn man das auf 8bit Pixel-Breite, 8bit Buchtaben-Anzahl und 32bit Position reduzieren könnte wären das noch 6Bytes pro Wort. Englische Wörter sind im Mittel ungefähr 5,1 Zeichen lang. D.h. selbst mit diesem minimalistischen Speicherlayout würde man den Speicherbedarf bei utf-8 kodiertem englischem Text grob verdoppeln.

Wenn man statt dessen einfach Zeichenweise scrollt und das word-wrapping nur für die Anzeige verwendet, braucht man das wordrwapping wirklich nur für den Teil berechnen der angezeigt wird. Außerdem braucht man auch nur den Teil des Textes laden der angezeigt wird. Dort ist der Rechen- und Speicheraufwand also nur abhängig von der größe des Anzeigebereiches und skaliert somit für beliebig große Texte.

Jah, ich denk das mit dem Zeichenweise hat schon was.. scheint schlauer und schneller zu sein.
Allerdings finde ich nicht, dass das _lineare_ skalieren des Speicherverbrauchs mit dem Aufwand irgendwie relevant ist... quadratisch oder kubisch wär schlimm... aber linear? Naja ist egal: Zeichenweise rockt.

Krishty hat geschrieben:Wenn man durch eine Textdatei scrollen möchte, ist das normalerweise ganz einfach: Schlicht den vorherigen oder nächsten Zeilenumbruch suchen, und an die Spitze des Dokuments bringen.

Schon das verstehe ich nicht ganz. Was ist die "Spitze des Dokuments"?

Das an sich wäre ja nicht schlimm, aber nun habe ich den Zeilenumbruch-Quelltext schon dreifach: Einmal beim Anzeigen (wenn die Buchstaben auf dem Bildschirm ausgegeben werden müssen); einmal beim Runterscrollen (wenn die nächsten Zeilenumbrüche gefunden werden müssen); einmal beim Hochscrollen (nur rückwärts). WTF.

Geht es darum, dass jeder der drei Fälle eine andere Logik hat, oder darum dass du dieselbe Logik nicht mehrmals anwenden willst?

Wie löst man das elegant?

Nun Word z. B. hat eine Absatz, Zeile, Wort, Glyph Logik, soweit ich mich erinnere (da kann man mit .NET gegen programmieren, daher ist das bekannt) Word bricht aber auch nicht am Fensterrand um sondern am Seitenrand. Zeilenumbrüche ändern sich nur wenn man was tippt. Dann aber in jeder Zeile. Das geht schon in Richtung einiger Kommentare hier, nur wird das deine Definition von elegant sicher nicht erfüllen.

Sternmull hat geschrieben: Das Speichern der Wortgrenzen führt auch noch zu einem nicht ganz unerheblichen zusätzlichen Speicheraufwand: Du willst drei Integer ablegen. Selbst wenn man das auf 8bit Pixel-Breite, 8bit Buchtaben-Anzahl und 32bit Position reduzieren könnte wären das noch 6Bytes pro Wort. Englische Wörter sind im Mittel ungefähr 5,1 Zeichen lang. D.h. selbst mit diesem minimalistischen Speicherlayout würde man den Speicherbedarf bei utf-8 kodiertem englischem Text grob verdoppeln.

Tjo, das war ja schon früher immer so, dass man was entweder speichern oder neu ausrechnen konnte. Mir ist schon klar dass bei neuerer Hardware Ausrechnen oft attraktiver als Speichern geworden ist, aber erstens würde Krishty das natürlich "richtig" implementieren und zweitens müsste man es halt ausprobieren. Spätestens wenn man die Wortgerenzen noch für was anderes braucht, könnte es sich schon rechnen.

Aber ich glaube die Frage ist auch ein bisschen ob hier ein Texteditor programmiert werden soll, oder ob es um ein Tool für genau eine Aufgabe (Scrollen?) geht.

Sternmull hat geschrieben:Oh, also ist dein Text quasi nur eine sehr lange Zeile... das ist natürlich ein unbequemer Extremfall. Ohne Word-Wrap wäre das allerdings ganz einfach und effizient lösbar... kannst du vielleicht einfach drauf verzichten? Den Text also so anzeigen wie es die Hex-Editoren tun. Evtl. reicht es ja schon ein nettes Symbol (z.B. die Unicode-Ellipse "…") hinter den Zeilen anzuzeigen an deren Ende ein Wort umgebrochen wird.

Verzichten wäre sehr schmerzhaft, weil es sich dafür zu natürlich anfühlt. Die Ellipse hilft auch nicht weiter: Selbst wenn das letzte Wort mit einer Ellipse endet, weiß ich noch nicht, wie viele Worte insgesamt in die Zeile passen, weil sie alle unterschiedliche Längen haben :(

kristof und Albi hast du schon mit abgefertigt ( ;) ), also gehe ich nicht näher drauf ein.

Was genau verstehst du unter zeichenweisem Scrollen?

Alexander Kornrumpf hat geschrieben:

Krishty hat geschrieben:Wenn man durch eine Textdatei scrollen möchte, ist das normalerweise ganz einfach: Schlicht den vorherigen oder nächsten Zeilenumbruch suchen, und an die Spitze des Dokuments bringen.

Schon das verstehe ich nicht ganz. Was ist die "Spitze des Dokuments"?

Die linke obere Ecke des Bildschirms; entschuldige!

Das an sich wäre ja nicht schlimm, aber nun habe ich den Zeilenumbruch-Quelltext schon dreifach: Einmal beim Anzeigen (wenn die Buchstaben auf dem Bildschirm ausgegeben werden müssen); einmal beim Runterscrollen (wenn die nächsten Zeilenumbrüche gefunden werden müssen); einmal beim Hochscrollen (nur rückwärts). WTF.

Geht es darum, dass jeder der drei Fälle eine andere Logik hat, oder darum dass du dieselbe Logik nicht mehrmals anwenden willst?

Die drei Fälle haben zu 90 % gleiche Logik, aber man muss sie im Quelltext unterschiedlich formulieren. Dann bleiben drei Funktionen, die untereinander zu 50 % gleich aussehen und zu 90 % gleiche Logik enthalten. Das Resultat ist, dass drei Viertel der Zeilen überflüssig und ein Wartungs-Alptraum sind.

Wie löst man das elegant?

Nun Word z. B. hat eine Absatz, Zeile, Wort, Glyph Logik, soweit ich mich erinnere (da kann man mit .NET gegen programmieren, daher ist das bekannt) Word bricht aber auch nicht am Fensterrand um sondern am Seitenrand. Zeilenumbrüche ändern sich nur wenn man was tippt. Dann aber in jeder Zeile. Das geht schon in Richtung einiger Kommentare hier, nur wird das deine Definition von elegant sicher nicht erfüllen.

Bei Word ist es anders, weil das „fetter“ ist: die benutzen ihre Formatierungs-Engine nicht nur zum Hoch- und Runterscrollen, sondern für Vorschau, Abschnitte, Tabellen, usw. Vor allem tun sie in der inneren Schleife viel mehr und viel komplexere Dinge. Sie können also eine Schnittstelle verfassen, die das Iterieren vorwärts und rückwärts über Umbruchpunkte erlaubt, und bestimmte Ereignisse daran koppelt. Alles, was Formatierung braucht, nutzt dann diese Schnittstelle und ist recht flott formuliert.
Wenn ich so eine Schnittstelle implementiere, hat sie am Ende mehr Zeilen und Variablen als wenn ich einfach meine drei fast gleichen Funktionen ausschreibe. Mein Anwendungsfall ist eklig, aber noch nicht eklig genug um den Break-Even-Point für so eine Architektur zu erreichen.

Aber ich glaube die Frage ist auch ein bisschen ob hier ein Texteditor programmiert werden soll, oder ob es um ein Tool für genau eine Aufgabe (Scrollen?) geht.

Es geht um einen Hex-Editor, der die Bytes nach Zweck gruppiert. Man kann sich die Bytes in einer Datei als eine gigantische Zeile Text vorstellen, und Byte-Gruppen wären in dieser Vorstellung Wörter. Ich habe also eine Datei mit einer guten Million Wörter über ein gutes Dutzend Millionen Buchstaben aber ohne einen einzigen Zeilenumbruch. Davon sind aber nur rund 100 Wörter gleichzeitig auf dem Bildschirm zu sehen, und man braucht Scrolling um durch die Datei zu navigieren.

Mit "zeichenweisem Scrollen" meine ich einfach das der lange String von Zeichen X an gelesen wird und per Word-Wrapping ins Ausgabefenster gemalt wird bis das voll ist.

Wenn der String in einem Encoding abgespeichert ist das eine feste Anzahl von Bytes pro Zeichen belegt, ist es ja trivial zum Xten Zeichen zu springen. Außerdem kann man die Scroll-Leiste vernünftig anzeigen ohne die Zeilen/Wörter/Umgebrochenen Zeilen oder so was zählen zu müssen, man braucht ja nur die String-Länge zu kennen. Wie oben erwähnt braucht man die Datei dann auch nicht mehr komlett in den RAM laden, sondern braucht nur noch das Häppchen was man anzeigen will. Trotz allem lässt sich der angezeigte Textausschnitt aber ja immer noch mit Word-Wrapping darstellen. Und wenn dir das ausreicht, dann wäre das eine effiziente und einfache Lösung für das Problem.
Bei Bedarf kann man die aktuelle Anzeige-Position natürlich immer noch auf die nächste Wortgrenze aufrunden. Und eine Seite runter/hoch zu scrollen sollte auch nicht schwer sein. Der Kern der Idee ist aber das man auf definierte Zeilenanfänge verzichtet die erst mal sequenziell und abhängig von der Fensterbreite berechnet werden müssen.

Scrollbars kann ich mit Word Wrap sowieso nie und nimmer abbilden; die springen sowieso zum Zeichen. Damit habe ich mich abgefunden. Es geht jetzt ausschließlich ums Scrollen um eine feste Anzahl Zeilen hoch oder runter (Mausrad; Klick auf Pfeiltaste oben/unten; Seite auf/ab; usw).

Nehmen wir an, das Fenster wäre breit genug zum Anzeigen von fünf Buchstaben:
   _ _ _
  |12345|
  |     |
  |     |
  |_ _ _|

Nehmen wir weiterhin an, xx, o, g, iii, und oo und wären einzelne Wörter, die nacheinander angezeigt werden sollen. Ohne Leerzeichen weil’s einfacher ist (und ich auch in meinem speziellen Fall keine habe). Wir beginnen mit Zeichen 0 in der linken oberen Ecke:
   _ _ _
  |xxo  |
  |giii |
  |oo   |
  |_ _ _|

Jetzt wird eine Zeile heruntergescrollt (z.B., weil der Benutzer beim Markieren den unteren Bildrand erreicht). Zeichenweise müsste jetzt zu Zeichen 5 gesprungen werden:
   _ _ _
  |iioo |
  |     |
  |     |
  |_ _ _|

Jetzt fehlt ein i im Wort iii! Logischerweise muss der Wortanfang links oben stehen. Also Zeichen 4:
   _ _ _
  |iiioo|
  |     |
  |     |
  |_ _ _|

Hübscher. Aber vergleich das nochmal mit der Ausgangssituation:
   _ _ _
  |xxo  |
  |giii |
  |oo   |
  |_ _ _|

Der Benutzer wollte eine Zeile herunterscrollen. Stattdessen ist er zwei Zeilen gesprungen!

Und nicht nur das: Je nachdem, welche Worte nach dem oo folgten, hat sich die Formatierung ab dieser Zeile völlig geändert.

Der Bildschirm scrollt also nicht nur unregelmäßig, sondern das Dokument geht im Rauschen unter, weil die Wörter beim Durchscrollen ständig von links nach rechts und zurück fliegen! (Dazu kommen noch technische Probleme mit Wörtern, die länger als eine Zeile sind.)

Habe ich ausprobiert; war völlig inakzeptabel.

Bisher löse ich das so, dass ich den Quelltext, der die Formatierung vornimmt, zu dem fürs Scrollen kopiere, und ihn abbrechen lasse, wenn er die gewollte Zeile erreicht. Ich schaue dann, an welchem Wort er abgebrochen hat, und das wandert nach links oben. Funktioniert gut. Aber jetzt muss ich Änderungen an der Formatierung an zwei Stellen pflegen.

(Hier habe ich noch eine Vereinfachung, die aber nicht in allen Fällen funktioniert, und die ich darum erstmal vorenthalte.)

Aber das ist noch nicht das Ende. Das war jetzt Scrollen nach unten. Der Benutzer kann auch hochscrollen – und dann läuft die verdammte Chose rückwärts ab! Also wird der Quelltext erneut kopiert, und die dritte Version formatiert von hinten nach vorne. Macht genau das Gleiche, aber der Quelltext ist ganz anders. Ab jetzt ist Wartung quasi unmöglich. Das ist mein Dilemma.

Ich würde gern wissen, wie andere Programme sowas ohne Quelltextduplizierung oder -triplizierung ( :D ) machen. Aber die wissen es bestimmt auch nicht besser, denn es ist immernoch … streng sequenziell.

Ich denke ich verstehe. Kannst du den Quelltext nicht so schreiben das er nicht kopiert werden muss, sondern sich wiederverwenden lässt? Dann hätte sich dein Problem doch eigentlich gelöst. Kern dürfte ja ein Ding sein das Wortgrenzen identifiziert damit man die vorwärts und rückwärts durchgehen kann. Da drauf dann ein Ding was das Layout erstellt indem es so viele Wörter konsumiert wie auf eine Zeile passen (oder eben ein sehr langes konsumiert und es auf mehrere Zeilen aufteilt).
Das ist jetzt zwar nicht ganz trivial, sollte sich doch aber so implementieren lassen das es sich leicht an verschiedenen Stellen einbinden lässt.

Ich glaube das Vorwärts/Rückwärts Ding wirst du im allgemeinen Fall nicht los. Kann man sich ja leicht überlegen. Wenn du an irgendeiner Position im Text bist, dann kann es im Allgemeinen sein, dass du rückwärts zu Text scrollst, den du noch nie angezeigt hast. Was willst du da machen außer "rückwärts Rendern"? Selbst wenn du vorwärts rendern wolltest wüsstest du nicht ab wo.

Müsste ich es aber implementieren, dann würde ich beim Anzeigen für den aktuellen Screen (!) die Linebreak-Positionen speichern und beim Vorwärts-Scrollen nachschlagen. Käme mir einfach richtig vor, es so zu machen. Braucht natürlich auch ein wenig Programmlogik, aber jedenfalls nur maximal soviel Speicher wie Bildschirmzeilen.

Alexander Kornrumpf hat geschrieben:Müsste ich es aber implementieren, dann würde ich beim Anzeigen für den aktuellen Screen (!) die Linebreak-Positionen speichern und beim Vorwärts-Scrollen nachschlagen. Käme mir einfach richtig vor, es so zu machen. Braucht natürlich auch ein wenig Programmlogik, aber jedenfalls nur maximal soviel Speicher wie Bildschirmzeilen.

Ja; das meinte ich mit

Krishty hat geschrieben:(Hier habe ich noch eine Vereinfachung, die aber nicht in allen Fällen funktioniert, und die ich darum erstmal vorenthalte.)

Ich überlege auch, ob ich nicht schon drei Zeilen vorher anfange zu rendern, damit ich zumindest für die Maus auf fertige Werte zugreifen kann. Ich benutze aber auch irre gerne die „Bild aufwärts“-Taste und Gott das wird langsam :( Was ich auch mache ist und bleibt eine Mikrooptimierung.

kann sein dass ich jetzt weit am thema vorbeilabere.
gibt es denn nicht bereits eine umgesetzte lösung auf die du zurückgreifen kannst?
wenn ich es umsetzen müsste, wäre mein erster gedanke den ganzen text in einer baumstruktur darzustellen. jedes wort ein blatt (wenn es ein überlanges ist, evtl noch trennen). der darüberliegende node würde eine zeile repräsentieren. evtl. danach noch linien zu blöcken zusammenfassen. dabei auf jeder stufe die länge kalkulieren.

evtl würde es ein einfacher binärer wörterbaum auch tun der immer die länge kalkuliert? beim resizen müsste der baum durchlaufen werden und immer der erste node der reinpasst kommt in die neue zeile. wenn er nicht passt, nächste stufe tiefer und schauen ob das passt. die resultat-zeilen müssten nur die node referenzen und nicht den text speichern.

http://www.catch22.net
Auf der Seite gibt es unter anderem ein gutes Tutorial für einen Texteditor, da werden alle diese Probleme behandelt.

Der Mensch hat da auch einen fertigen Hexeditor, der Code ist verfügbar. MIT Lizenz.
Wenn ich mir die Feature Liste so durchlese steht da was von:

Custom types & structure viewer
- TypeView provides a structured view on top of a file's raw hex bytes
- Underlying structure of a file can interpreted and modified through the TypeView window
- Supports full C syntax for structure definitions
- Structures can be edited within HexEdit, or in an external source editor

Wenn ich Dich richtig verstanden habe willst Du einen normalen HexEditor aber die Bytes nicht "klassisch" anzeigen sondern irgendwie anders. Lohnt sich vielleicht sich diesen mal an zu gucken.
http://www.catch22.net/software/hexedit

Ja; den hatte ich mir schon angesehen und er bietet nicht, was ich brauche (direkt die Bytes zu formatieren). Auch auf das Tutorial war ich schon gestoßen, aber mit dem speziellen Problem hilft es mir nicht weiter.

Krishty hat geschrieben:Aber das ist noch nicht das Ende. Das war jetzt Scrollen nach unten. Der Benutzer kann auch hochscrollen – und dann läuft die verdammte Chose rückwärts ab! Also wird der Quelltext erneut kopiert, und die dritte Version formatiert von hinten nach vorne. Macht genau das Gleiche, aber der Quelltext ist ganz anders.

Bist du sicher, dass der Code dafür korrekt ist?
Sowas zu implementieren kommt mir nämlich um ein Vielfaches aufwändiger vor, als für das runter scrollen. Man muss im worst-case auf alle Daten bis zum Anfang der Datei zugreifen.

Den Code zum Formatieren und zum Runterscrollen dagegen dürfte eigentlich nicht so schwer sein, zu vereinheitlichen. Mach doch einfach ein bool Parameter in die Formatierungsfunktion rein, sodass sie die fürs Scrollen notwendige Information hergibt. Oder speicher einfach für jede angezeigte Zeile, an welchem Zeichen sie beginnt.

Helmut hat geschrieben:

Krishty hat geschrieben:Aber das ist noch nicht das Ende. Das war jetzt Scrollen nach unten. Der Benutzer kann auch hochscrollen – und dann läuft die verdammte Chose rückwärts ab! Also wird der Quelltext erneut kopiert, und die dritte Version formatiert von hinten nach vorne. Macht genau das Gleiche, aber der Quelltext ist ganz anders.

Bist du sicher, dass der Code dafür korrekt ist?
Sowas zu implementieren kommt mir nämlich um ein Vielfaches aufwändiger vor, als für das runter scrollen. Man muss im worst-case auf alle Daten bis zum Anfang der Datei zugreifen.

Man hat aber bereits einen Ausgangspunkt, von dem man aus vorheriger Formatierung weiß, dass dort eine Zeile beginnt. Darum kann man zurücklaufen und einfach prüfen, wie viel noch in die vorherige Zeile passt.

Nun, angenommen du hast eine sehr lange Datei, die so endet:
...xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxgggiiiiy
Und dein Editor stellt das dar: Was soll nun angezeigt werden, wenn eine Zeile hochgescrollt wird? Es ist unmöglich das zu entscheiden, ohne den gesamten Inhalt der Datei zu kennen.

Wie wäre es mit "verarsche"?
Also, dass man nur in den ersten n Zeilen die Daten exakt darstellt, also soweit, wie man in 2 oder 3 Minuten als Mensch scrollen kann.
Wenn man jetzt irgendwas auf der Hälfte der Datei darstellen will, dann schätzt man die Position der Daten und rechnet das Wordwrapping dann vor- oder zurück für den gewünschten Bereich aus.

Hm... müsste das nicht doch gehen? Man müsste halt rückwärts suchen, bis man entweder genügend Wörter zusammen hat, um eine Zeile vollzumachen, oder bei längerem Wort als Zeile den ersten möglichen Umbruch findet. Und in letzterem Fall müsste man dann halt das Langwort über Zeilen verteilen und rechtsbündig ausrichten, dann kann man die Zeilen anzeigen. Müsste theoretisch deterministisch sein, also immer die selben Zeilen ergeben.

Helmut hat geschrieben:Es ist unmöglich das zu entscheiden, ohne den gesamten Inhalt der Datei zu kennen.

Ja; da hast du recht. Weil das lange Wort ja wieder durch ein Kurzes davor eingerückt sein könnte. Verdammt.

Ich überlege gerade, „echte“ Zeilenumbrüche einzufügen (tatsächlich benutze ich die sehr häufig wenn ich an Hex-Daten arbeite). Dann müsste die Formatierung nur bis zum letzten bekannten Zeilenumbruch zurückrechnen statt bis an den Dateianfang … ich muss aber erstmal prüfen, ob das zur Benutzerführung passt.

Das lange Wort kann doch eben *nicht* eingerückt sein. Du zumindest nicht nach der Standard-Zeilenumbruch-Logik, bei der man eine neue Zeile anfängt, sobald das nächste Wort nicht mehr vollständig auf die Zeile passt. Daher fangen Länger-Als-Zeile-Wörter immer am Anfang einer Zeile an.

Krishty hat geschrieben:

Helmut hat geschrieben:

Krishty hat geschrieben:Aber das ist noch nicht das Ende. Das war jetzt Scrollen nach unten. Der Benutzer kann auch hochscrollen – und dann läuft die verdammte Chose rückwärts ab! Also wird der Quelltext erneut kopiert, und die dritte Version formatiert von hinten nach vorne. Macht genau das Gleiche, aber der Quelltext ist ganz anders.

Bist du sicher, dass der Code dafür korrekt ist?
Sowas zu implementieren kommt mir nämlich um ein Vielfaches aufwändiger vor, als für das runter scrollen. Man muss im worst-case auf alle Daten bis zum Anfang der Datei zugreifen.

Man hat aber bereits einen Ausgangspunkt, von dem man aus vorheriger Formatierung weiß, dass dort eine Zeile beginnt. Darum kann man zurücklaufen und einfach prüfen, wie viel noch in die vorherige Zeile passt.

Ich hatte zunächst das gleiche angenommen, wie Du, Krishty, und hab etwas gebraucht um zu raffen, was Helmut meint. So wie du deinen Anwendungsfall beschreibst halte ich das aber für erträglich es "falsch" zu machen.

Wenn man runter scrollt, scrollt man ja zu Text, den man aktuell sieht, der darf natürlich visuell nicht springen (wie du irgendwo weiter oben beschrieben hattest). Scrollt man dagegen hoch, so müsste man sich schon gemerkt haben, wo die Zeilenumbrüche vorher waren, um es negativ zu bemerken.

Das einzige was schlimmes passieren kann ist dass man bis zur ersten Zeile (bzw. zum nächsten harten newline, aber das hast du ja nicht) scrollt und in der dann nur ein Wort steht. Bzw. anders gesagt: wenn du rückwärts bis zu einen harten newline scrollst, darfst du nicht ab da wieder stumpf vorwärts rendern, sondern musst den ersten weichen Umbruch danach beibehalten.

Andererseits: mit der Argumentation lässt sich natürlich auch begründen bei jeder Änderung der Fenstergröße den gesamten Text neu umzubrechen, damit hast du dein ursprüngliches Ziel ja auch irgendwie erreicht :)

BTW: Ich habe gerade mal probiert was passiert wenn ich dieses Fenster hier in der Größe ändere. MMn gibt es zwei logische Fixpunkte für das neu-umbrechen: obere linke Ecke oder aktuelle Cursorposition. Das Fenster hier implementiert keins von beidem. Ich sehe irgendeinen Teil meines getippten Textes. Ein Muster bezüglich der Frage welchen Teil kann ich nicht erkennen. Sprich: Die anderen machen es auch falsch!