Welche Datenstruktur würdet ihr für einen Editor wählen?

[C99]

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.

[Christoph]

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.

[zwutz]

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

[volkard]

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.

[asddd]

afair fanden sich hier http://www.catch22.net/tuts/neatpad/1 ein paar echt gute Querverweise

[witte]

Christoph schrieb:

Die Zeilen in einer Text-Datei sind oft unterschiedlich lang.

Nicht zu vergessen die unicode-Unterstützung.

[asddd]

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.

[Gast]

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.

[icwiener]

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

Das ist einer der Kate-Entwickler (KDE-Texteditor); ist auf Englisch.

MfG

[asddd]

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.

[vi]

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.

[zum Beispiel]

websuche nach

+multicians +mepap

da steht auch was über Datenstukturen, redisplay Strategien etc. speziell für Emacs.

[verwendenwürder]

std::rope

[SideWinder]

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

[muemmel]

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