Welche Datenstruktur würdet ihr für einen Editor wählen?
-
Ich spiele mit dem Gedanken mir einen einfachen Editor in C99 zu schreiben der auch mit größeren Dateien umgehen kann.
Daher sollte er selbstverständlich nicht die komplette Datei in den Speicher laden, sondern nur einen Bruchteil davon.
Wie z.B. nur den im Editorfeld sichtbaren Bereich, sowie vielleicht noch ein paar Seiten davor und danach. Letzteres für schnelleres Blättern in unmittelbarer Nähe, also nicht das ganze Dokument durch.Welche Datenstruktur würdet ihr hier aber nun wählen?
Ich selbst dachte an eine doppelt verkettete Liste, da sie sehr sparsam ist, was den Speicherbedarf betrifft. Anderseits wäre die Suche in einem Textdokument natürlich sehr aufwendig.
Eine Baumstruktur wäre zwar schneller, aber beim ändern dann noch teurer.Was würdet ihr also nehmen?
-
Daher sollte er selbstverständlich nicht die komplette Datei in den Speicher laden, sondern nur einen Bruchteil davon.
Ist das so selbstverständlich bzw. wird das wirklich so gemacht? Speicherbedarf eines Texteditor interessiert doch heute niemanden mehr? Und was ist wenn jemand einen laaaaaaaangen Text ohne zwischenspeichern schreibt bzw durch copy&paste erzeugt? Dieser Text muss ja dann im Speicher sein. Oder wenn man von Seite 100 wieder an den Anfang springt etc...
-
Eddytor schrieb:
Ist das so selbstverständlich bzw. wird das wirklich so gemacht?
Speicherbedarf eines Texteditor interessiert doch heute niemanden mehr?Keine Ahnung wie es bei anderen Editoren ist, aber zumindest ein Hexeditor sollte in der Lage sein auch Dateien zu öffnen die größer sind, als der verfügbare Arbeitsspeicher.
Und vom Texteditor zum Hexeditor ist es ja nur noch ein relativ kleiner Schritt.
Eventuell möchte ich meinen Editor nämlich erweitern.Dann gäbe es da noch eine Anwendungsmöglichkeit in Embedded Systemen. Da ist der Speicherplatz immer noch knapp.
Und was ist wenn jemand einen laaaaaaaangen Text ohne zwischenspeichern schreibt
Dann müßte die dynamisch anwachsende Liste natürlich mitwachsen, das ist klar.
bzw durch copy&paste erzeugt? Dieser Text muss ja dann im Speicher sein.
Das ist dann aber eher Aufgabe des GUI Toolkits bzw. OS.
Zumindest gilt das, wenn aus anderen Programmen kopiert wird.Oder wenn man von Seite 100 wieder an den Anfang springt etc...
Dann muß man die Liste zurückwandern.
-
C99 schrieb:
Und vom Texteditor zum Hexeditor ist es ja nur noch ein relativ kleiner Schritt.
Ein Hex-Editor hat aber den Vorteil, dass er direkt zu XX% der Datei springen kann. Wenn du bei einem Text-Editor an die Stelle 50% scrollst, muss der Texteditor erstmal die Zeilen (alle Zeilen!) der Datei zählen, bevor er die richtige Stelle finden kann. Die Zeilen in einer Text-Datei sind oft unterschiedlich lang.
Entweder muss der Editor Zeilen zählen oder er hüpft beim Scrollen hin und her und landet an schwer vorhersagbaren Stellen statt der gewünschten.
-
ich kenne diese Technik bisher nur aus reinen Read-Only-Programmen.
Bei einem Editor dürfte es ungleich schwerer werden, da du ja nicht aus der Datei bei Bedarf nachladen kannst, sondern sowieso alles zwischenspeichern musst
-
Ich vermute, ein leicht getunter vector<pair<char*,char*>> also Array von Zeilen wäre angemessen. Zur Sicherheit würde ich aber nochmal Programming Pearls | ISBN: 0201657880 lesen und ein wenig meditieren.
-
afair fanden sich hier http://www.catch22.net/tuts/neatpad/1 ein paar echt gute Querverweise
-
Christoph schrieb:
Die Zeilen in einer Text-Datei sind oft unterschiedlich lang.
Nicht zu vergessen die unicode-Unterstützung.
-
witte schrieb:
Christoph schrieb:
Die Zeilen in einer Text-Datei sind oft unterschiedlich lang.
Nicht zu vergessen die unicode-Unterstützung.
Und eventuell den Umbruch am Fensterrand mit einer Schriftart nicht-fixer Breite.
-
asddd schrieb:
witte schrieb:
Christoph schrieb:
Die Zeilen in einer Text-Datei sind oft unterschiedlich lang.
Nicht zu vergessen die unicode-Unterstützung.
Und eventuell den Umbruch am Fensterrand mit einer Schriftart nicht-fixer Breite.
Das sollte in der Datenhaltung nicht interessieren. Das berücksichtigt man erst beim Zeichnen.
-
Moin,
von dem Thema verstehe ich nichts.
Aber ich glaube, hier ist etwas Interessantes zu lesen zu dem Thema.
http://dhaumann.blogspot.com/2010/02/kate-internals-text-bufferu.htmlDas ist einer der Kate-Entwickler (KDE-Texteditor); ist auf Englisch.
MfG
-
Tim schrieb:
asddd schrieb:
witte schrieb:
Christoph schrieb:
Die Zeilen in einer Text-Datei sind oft unterschiedlich lang.
Nicht zu vergessen die unicode-Unterstützung.
Und eventuell den Umbruch am Fensterrand mit einer Schriftart nicht-fixer Breite.
Das sollte in der Datenhaltung nicht interessieren. Das berücksichtigt man erst beim Zeichnen.Bezog sich aufs vertikale Scrollen.
-
zwutz schrieb:
ich kenne diese Technik bisher nur aus reinen Read-Only-Programmen.
Bei einem Editor dürfte es ungleich schwerer werden, da du ja nicht aus der Datei bei Bedarf nachladen kannst, sondern sowieso alles zwischenspeichern musst
Jeder von euch hat doch sicher schonmal vi probiert?
Da muß es so sein, denn es gab damals schlichtweg kaum Speicherplatz um den ganzen Text ins RAM zu laden.
-
websuche nach
+multicians +mepap
da steht auch was über Datenstukturen, redisplay Strategien etc. speziell für Emacs.
-
std::rope
-
std::rope scheint einige "Disadvantages" zu haben, über die man sich aber im Klaren sein sollte:
Single character replacements in a rope are expensive. A character update requires time roughly logarithmic in the length of the string. It is implemented as two substring operations followed by two concatenations.
MfG SideWinder
-
Hi,
WordStar hat damals mit zwei Stapelspeichern gearbeitet, zumindest im 3.0 noch als getrennte Dateien, die zum einen den Teil vom Beginn bis zum Kursor und die Andere den Teil vom Kursor bis zum Ende (invers gespeichert) enthielten. Beim durch die Datei gehen wird dann von dem einen Stapel genommen und auf den anderen gepackt. Beim Einfügen wird einfach auf dem Beginnstapel was dazugeschrieben.
Hex-Editoren funktionieren (meist) ein wneig anders, da bei ihnen kein Einfügen oder Löschen zwischendurch unterstützt wird, sondern nur die reine Manipulation einzelner Bytes, allenfalls noch Anfügeoperationen. Bei ihnen stellt das aktuve Fenster nur so etwas wie eine große Lupe dar, die über die Datei geschoben wird.
Sicher auch mal ansehenswert aus dem Buch Entwurfsmuster das Fliegengewicht. Dort ist vorgegeben, wie sich der Verfasser das Innere eines Texteditors vorstellt.
Gruß Mümmel