Wie würdet ihr einen Editor schreiben? Jede Zeile als ein Objekt?

Athar schrieb:

Objekteditor schrieb:

Dann würden die Farbwerte der entsprechenden Wörter verändert werden. Das ist sogar einfacher als das Nachschauen bei solchen Ranges, ob nicht irgendein Range schon mit dem gefunden Suchmuster überlappt.

Nö, denn der zu hervorherbende Text kann mitten in einem Wort anfangen und dort
auch wieder aufhören.

Ok, dann müßte ich dafür ein neues Wortobjekt dazwischen einfügen und das alte in zwei neue Wörter aufspalten, sowie den Textstring entsprechend umkopieren.

Und wie schon gesagt - Wörter und Ranges sind das gleiche, nur dass du beim Wortansatz auch dann eine neue Range anfängst, wenn das gar nicht nötig wäre (eben an Wortgrenzen, an denen sich die Formatierung nicht ändert).

Naja, deine Ranges sind alle indirekt, sie sind kein Teil des Textstrings, z.b. einer Zeile.
Das ist bei mir anders, bei mir gehört die Farbe zu den Wörtern als Eigenschaft.
Und die einzelnen Wörter bilden dann den Textstring bzw, die Zeile.

Ich werfe mal noch zwei Begriffe in den Raum:

Fliegengewicht und Kompositum.

Die beiden Muster scheinen mir für einen Editor nützlich zu sein.

zwutz

Objekteditor schrieb:

Ich vergaß völlig.
Wenn du mehrere Ranges hast, dann verlierst du da natürlich auch Speicherplatz für die Adressen, falls du das in einer dynamischen Liste abspeicherst.

das hast du auch bei deinem Konzept. Oder willst du die Wortgrenzen jedesmal neu ermitteln? Auch halte ich dann das löschen/einfügen von Textabschnitten für ziemlich kritisch. Die Anzahl der Objekte tut sein übriges. Im schlimmsten Fall hast du so viele Objekte wie Zeichen

Ranges sind im Regelfall genau gleich zu deinem Konzept. Nur mit dem Vorteil, dass du beliebige Ranges auch über mehrere Wörter und Zeilen hinweg definieren kannst. Ganze Datei markieren: Eine Range anlegen. Bei deinem Konzept Millionen von Objekten durchlaufen und Status setzen

zwutz schrieb:

Objekteditor schrieb:

Ich vergaß völlig.
Wenn du mehrere Ranges hast, dann verlierst du da natürlich auch Speicherplatz für die Adressen, falls du das in einer dynamischen Liste abspeicherst.

das hast du auch bei deinem Konzept.

Hab ich ja oben geschrieben.

Ganze Datei markieren: Eine Range anlegen. Bei deinem Konzept Millionen von Objekten durchlaufen und Status setzen

Ok, dieses Argument hat mich überzeugt, ich werde Ranges nutzen.

Objekteditor schrieb:

Ganze Datei markieren: Eine Range anlegen. Bei deinem Konzept Millionen von Objekten durchlaufen und Status setzen

Ok, dieses Argument hat mich überzeugt, ich werde Ranges nutzen.

Noch etwas.

Allerdings müssen die Ranges dann ja über Objektgrenzen hinweg funktionieren.
Wenn bei euch jede Zeile ein Objekt ist, dann könnt ihr die Ranges nicht an die Objekte binden, wenn sie auch über die Objektgrenzen hinweg funktionieren sollen.

Das sehe ich kritisch.

Eventuell wäre es sinnvoll zwei Arten von Ranges einzuführen, eine die an Objekte gekoppelt sind, also an die Zeilen und die Zeilen statisch einfärbt.
Statisch weil ein C++ Schlüsselwort wie z.B. while ja auch nach dem markieren mit der Maus und wieder los lassen ein Schlüsselwort bleibt.
Und eine extra Range die nur zum Markieren da ist.

Wobei die Range zum Markieren dann beim Zeichnen die höhere Priorität hat, als die statischen Objektgebundenen Ranges.

hustbaer

Schmeiss alles in einen Blob, und mach dann Indexe/Lookup Tabellen für Dinge wie Zeilenumbrüche, Farben oder markierte Bereiche.

hustbaer schrieb:

Schmeiss alles in einen Blob, und mach dann Indexe/Lookup Tabellen für Dinge wie Zeilenumbrüche, Farben oder markierte Bereiche.

Sorry das ist Blödsinn.
Jedes Wort/Sonderzeichen als ein Objekt zu behandeln ist auch Unsinn.
Speicher dein Dokument als Liste von Zeilen.
Styleinformationen zusammen mit den Zeicheninformationen zu speichern ist auch eine Schlechte Idee.

hustbaer

gastantwort schrieb:

hustbaer schrieb:

Schmeiss alles in einen Blob, und mach dann Indexe/Lookup Tabellen für Dinge wie Zeilenumbrüche, Farben oder markierte Bereiche.

Sorry das ist Blödsinn.

Das ist Blödsinn ... weil?

hustbaer schrieb:

gastantwort schrieb:

hustbaer schrieb:

Schmeiss alles in einen Blob, und mach dann Indexe/Lookup Tabellen für Dinge wie Zeilenumbrüche, Farben oder markierte Bereiche.

Sorry das ist Blödsinn.

Das ist Blödsinn ... weil?

Denk mal darüber nach was passiert wenn du am Anfang der Datei dann was anfügst.

Wir suchen also eine Datenstruktur, bei der man:
* überall schnell große Teile einfügen und löschen kann
* überall schnell hinspringen kann (gehe zu zeile...)
* schnell sequentiell durch gehen kann, zum parsen
* noch was?

hustbaer

gastantwort schrieb:

hustbaer schrieb:

gastantwort schrieb:

hustbaer schrieb:

Schmeiss alles in einen Blob, und mach dann Indexe/Lookup Tabellen für Dinge wie Zeilenumbrüche, Farben oder markierte Bereiche.

Sorry das ist Blödsinn.

Das ist Blödsinn ... weil?

Denk mal darüber nach was passiert wenn du am Anfang der Datei dann was anfügst.

Na dann dauert es ein wenig. Ist das so schlimm?

OK, zugegeben, das skaliert nicht beliebig.

Zeilen (nur) in einer Linked-List zu halten ist aber auch irgendwie Blödsinn.

Zumindest braucht man einen guten Index "in" diese Liste. Sonst wird das recht langweilig wenn der User mit "go to line" in die Mitte des Files springen will.

hustbaer

@NEEDE:
Ich denke ein leicht modifizierter B-Baum würde sich anbieten.

Die Keys stören etwas, denn wenn man als Key die Zeilennummer verwenden will, dann müsste man bei jedem INSERT alle folgenden Zeilennummern updaten.

Andrerseits kommt so ein Baum auch gut ohne Keys aus, also einfach weg damit.

Jetzt stört nur noch, dass man - da man ja keine Keys mehr hat - erst wieder den ganzen Baum durchackern müsste, wenn man Zeile Nummer X sucht.

Das liesse sich allerdings umgehen, indem man in jeder Node die grösse "ihres" Teilbaums abspeichert (=Anzahl der Werte=Zeilen). Ich denke das sollte ohne all zu schlimmen Overhead bei INSERT/DELETE möglich sein.

hustbaer schrieb:

gastantwort schrieb:

hustbaer schrieb:

gastantwort schrieb:

hustbaer schrieb:

Schmeiss alles in einen Blob, und mach dann Indexe/Lookup Tabellen für Dinge wie Zeilenumbrüche, Farben oder markierte Bereiche.

Sorry das ist Blödsinn.

Das ist Blödsinn ... weil?

Denk mal darüber nach was passiert wenn du am Anfang der Datei dann was anfügst.

Na dann dauert es ein wenig. Ist das so schlimm?

Ne das dauert nicht nur ein wenig, das ist extrem langsam, bei jedem gedrückten Zeichen musst du ein paar hundert kilobyte (für kleine Dateoen) im Speicher rumschieben und je größer die Datei offensichtlich desto langsamer. Und jetzt überleg mal wieviele Zeichen man in der Regel pro Sekunde/Minute hintereinander schreibt...

Im übrigen benutzt man auch keine verkettete Liste für die Zeilen sondern auch ein indexbasiertes array. Google mal nach GapBuffer

volkard

gastantwort schrieb:

Im übrigen benutzt man auch keine verkettete Liste für die Zeilen sondern auch ein indexbasiertes array. Google mal nach GapBuffer

Fail.

Wutz

Das ist Blödsinn, da sich BLOBs üblicherweise nicht indizieren lassen.

volkard schrieb:

gastantwort schrieb:

Im übrigen benutzt man auch keine verkettete Liste für die Zeilen sondern auch ein indexbasiertes array. Google mal nach GapBuffer

Fail.

Haben alle deine zweiundzwanzigtausend Posts so wenig Inhalt?

hustbaer

@volkard:
Hihi, ja.

@Wutz:
Wieso sollte man einen BLOB nicht indizieren können?

std::vector<char> blob; // der BLOB
std::vector<size_t> lineStartOffsets; // der Index

hustbaer

gastantwort schrieb:

volkard schrieb:

gastantwort schrieb:

Im übrigen benutzt man auch keine verkettete Liste für die Zeilen sondern auch ein indexbasiertes array. Google mal nach GapBuffer

Fail.

Haben alle deine zweiundzwanzigtausend Posts so wenig Inhalt?

Ach der Inhalt passt schon. Du hast halt Unsinn gepostet.
Googel vielleicht selbst mal nach GapBuffer, und lies nach was das ist.

Vielleicht wird dir dann auffallen, dass dabei eben gerade nichts in Zeilen unterteilt wird. Sondern der ganze Text in einem grossen Stück abgelegt wird.

Nur dass man eben nicht Zeichenweise einfügt, sondern gleich Platz auf Vorrat schafft, damit man schnell weitere Zeichen dazutippen kann.

hustbaer schrieb:

gastantwort schrieb:

volkard schrieb:

gastantwort schrieb:

Im übrigen benutzt man auch keine verkettete Liste für die Zeilen sondern auch ein indexbasiertes array. Google mal nach GapBuffer

Fail.

Haben alle deine zweiundzwanzigtausend Posts so wenig Inhalt?

Ach der Inhalt passt schon. Du hast halt Unsinn gepostet.
Googel vielleicht selbst mal nach GapBuffer, und lies nach was das ist.

Vielleicht wird dir dann auffallen, dass dabei eben gerade nichts in Zeilen unterteilt wird. Sondern der ganze Text in einem grossen Stück abgelegt wird.

Falsch, jede Zeile ist ein GapBuffer. Dass die Dokumente zeilenbasiert gemanagt werden steht außer Frage. Du hast dich offenbar nicht mehr als 5 Minuten mit dem Thema beschäftigt, sonst wärst du wohl auch gar nicht mit deinem KindergartenBLOB gekommen

hustbaer

gastantwort schrieb:

hustbaer schrieb:

gastantwort schrieb:

volkard schrieb:

gastantwort schrieb:

Im übrigen benutzt man auch keine verkettete Liste für die Zeilen sondern auch ein indexbasiertes array. Google mal nach GapBuffer

Fail.

Haben alle deine zweiundzwanzigtausend Posts so wenig Inhalt?

Ach der Inhalt passt schon. Du hast halt Unsinn gepostet.
Googel vielleicht selbst mal nach GapBuffer, und lies nach was das ist.

Vielleicht wird dir dann auffallen, dass dabei eben gerade nichts in Zeilen unterteilt wird. Sondern der ganze Text in einem grossen Stück abgelegt wird.

Falsch, jede Zeile ist ein GapBuffer. Dass die Dokumente zeilenbasiert gemanagt werden steht außer Frage. Du hast dich offenbar nicht mehr als 5 Minuten mit dem Thema beschäftigt, sonst wärst du wohl auch gar nicht mit deinem KindergartenBLOB gekommen

ROFL
Jede Zeilt ist ein Gap-Buffer = der grösste Unsinn den ich seit langem gelesen habe