[Gelöst] Synedit Undo/Reundo speichern bei Dateiwechsel oder nach Programmende

[aro]

Nachtrag:
Ich habe selber eine Lösung, durch wenige Änderungen und Erweiterungen von Synedit gefunden.
Wenn Sie weiter lesen finden Sie die geänderten Quelltext und eine kurze Demo.
Es wurde für Linux erstellt und auch nur unter Linux getestet !


Ich habe mein Programm Atmel Studio unter Linux im großen und ganzen fertig. Aber es hat noch einen Schönheitsfehler.

Wenn ich im Editor auf eine andere Datei schalte, muss ich die Datei speichern, und bei wieder zurück neu einlesen.
Das klappt. Ich kann auch die Zeile und den Kursor so setzen, wie ich die Datei verlassen habe, aber Undo und Reundo gehen verloren.
Wenn ich dies in der Lazarus IDE tue, kann ich normal Undo / Reundo verwenden, als ob ich die Datei nie verlassen hätte.

10 verschiedene Instanzen von Synedit installieren und immer die eine nach vorn holen scheint mir nicht sinnvoll.
Wie ist das in der Lazarus IDE gelöst ? gibt es da Quellen ?

[Sieben]

Wie ist das in der Lazarus IDE gelöst ? gibt es da Quellen ?

Unter /ide findet sich SourceEditor.pp, und da wiederum gleich zu Anfang:

Code: Alles auswählen

{ This unit builds the TSourceNotebook that the editors are held on.
  It also has a class that controls the editors (TSourceEditor)}

Und da die interne UndoList von TSynEdit offenbar auch kein .Save odgl hat, wird es wohl tatsächlich für jede offene Datei eine Instanz geben.

[theo]

Wie ist das in der Lazarus IDE gelöst ? gibt es da Quellen ?

Wie Sieben schon sagt, verwendet die IDE "Reiter" (Notebook, Pagecontrol) und die Editoren werden nur ausgeblendet.
Verschiedene "Zustände" werden mit der Datei gespeichert (Bookmarks, Haltepunkte, Code Folding..),
Undo-Redo Information "überlebt" das Schließen der Datei aber nicht.

Es gibt auch andere Ansätze.
Meine zweitliebste IDE speichert "von Haus aus", auch ohne GIT etc, eine Diff History, welche das Schließen der Datei überlebt.

[aro]

Danke für die Antworten, aber das war gerade das was ich nicht hören wollte.

Ich werde jetzt einmal testen wie viel Speicher ein Synedit wirklich belegt, um die Konsequenzen zu überdenken.
Irgend wie kann ich mich an meine Zeit in Delphi erinnern, das es da möglich war komplette Objekte zu Speichern und zu laden.
Das könnte es möglicherweise auch in Lazarus geben.
Außerdem habe ich mehrere Quelltext für Synedit runtergeladen und in GitHub einen gefunden, der wahrscheinlich für Delphi geschrieben wurde, und von dem in Lazarus wesentlich abweicht.

Der enthält :

property UndoList: TSynEditUndoList read FUndoList;
property RedoList: TSynEditUndoList read FRedoList;

Damit könnte man die Undo - Aktionen möglicherweise speichern und zurückholen.
Mal sehen ob ich die Komponente vollkommen neu erstellen und so verwenden kann, wie ich es will.

[Sieben]

Irgend wie kann ich mich an meine Zeit in Delphi erinnern, das es da möglich war komplette Objekte zu Speichern und zu laden.
Das könnte es möglicherweise auch in Lazarus geben.

Sicher, alle Nachfahren von TPersistent haben bzw implementieren die Fähigkeit sich zu streamen. Siehe auch TFiler / TReader.

Code: Alles auswählen

property UndoList: TSynEditUndoList read FUndoList;
property RedoList: TSynEditUndoList read FRedoList; 

Ich hab jetzt grad nicht nachgeschaut ob Lazarus TSynEdit die beiden nicht auch als Property zur Verfügung stellt, gehe aber fast davon aus. Problem ist nur, dass sie - zumindest in Lazarus - direkt von TObject abgeleitet sind, sich also erstmal nicht streamen können.

[Warf]

Wenn ich im Editor auf eine andere Datei schalte, muss ich die Datei speichern, und bei wieder zurück neu einlesen.
Das klappt. Ich kann auch die Zeile und den Kursor so setzen, wie ich die Datei verlassen habe, aber Undo und Reundo gehen verloren.

Darf man fragen warum? Das schreiben und lesen von dateien auf die platte ist doch extrem langsam, und source code braucht nicht viel speicher. Der komplette source code von der RTL ist ungefähr 40 MB groß. Der overhead von einem Synedit ist locker weniger als 1kb. Wenn du also absolut jeder sourcecode datei der RTL offen haben würdest auf einmal, würde das grade mal so 50mb RAM kosten.
Das ist jetzt nichts wo ich optimierungsbedarf sehe

EDIT: ich hab grad mal mit die komplette RTL (1592 dateien) geöffnet, und Lazarus verbraucht grade mal 500 MB ram. Zugegeben es ist etwas langsam geworden, aber immernoch benutzbar. Und lazarus lädt alle offenen dateien in den RAM und hat eine editor instanz für jeden offenen tab. Also wenn du eine IDE von vergleichbarem außmaß schreibst, sollte denke ich so bis zu 500 offenen dateien kein problem sein.
Ich weiß nicht was für Projekte die nutzer dieser IDE vorhaben zu machen, aber ich hatte noch nie auch nur mehr als 50 editoren offen

[Timm Thaler]

Also ich würd nicht wollen, dass meine IDE jedes mal beim Wechsel zwischen Dateien diese speichert und wieder einliest.

Und ich würde dringend wollen, dass ich Dateien nebeneinander stellen kann. Die Include mit den Variablendefinitionen oder den Displaystrings neben dem Programmteil in dem drauf zugegriffen wird MUSS sein. Schon deswegen müssen mehrere Instanzen des Editors im Speicher sein.

Lazarus mit Anchordocking und mehreren Editoren macht das schon sehr gut - wenn man einmal weiß wies geht.

Geany mit Plugin "Fenster teilen" macht das leidlich.

Das alte AVR Studio mit Windows MCI Childs konnte das gut. Das neue Atmel Studio dann glaub ich nicht mehr - und ich hab es gehaßt.

[aro]

ich habe mal einen Test gemacht. Ein Formular ein Button und bei jedem Klick wird ein neues Synedit erzeugt und eine Assemblerdatei geladen. Nach jedem neuen Synedit zeigte Linux an, das mehr als 1 MB Arbeitsspeicher neu belegt wurde.

Außerdem benötige ich für jede Assemblierung die aktuelle Version aller asm-Dateien.
Das heißt wenn ich Änderungen vorgenommen habe, muss ich speichern, ganz gleich ob ich eine oder mehrere Instanzen von Synedit laufen lasse.
Außerdem speichere ich nur, wenn seit der letzten Speicherung wirklich Veränderungen vorgenommen wurden.

Mehrere Instanzen von Synedit würden für mich nur Sinn machen, wenn ich die Zeilen direkt aus Synedit lesen würde statt aus der Datei. Dann müsste ich aber für jede Datei ein Synedit starten, egal ob ich die Datei überhaupt sehen will.

Inzwischen habe ich einen Ansatz gefunden, wie ich die Daten aus Undo speichern kann und arbeite gerade daran die Daten zurück zuholen.
Sollte das nicht klappen, dann bleibt mir die Variante mit mehreren Instanzen ja immer noch.

[Sieben]

Damit sagst du jetzt aber schon, dass für dich die Lazarus-IDE bzw ihr Umgang mit Source-Dateien 'keinen Sinn macht' - das Verhalten bzw die Anforderungen, die du beschreibst, sind exakt dieselben. Auch da müssen vor jedem neuen Lauf die Dateien auf Platte gespeichert werden, und sie werden nur neu abgespeichert, wenn sie auch verändert wurden. Aber die IDE hält sie durch die parallelen Instanzen eben auch simultan und verzögerungsfrei vor, während du immer wieder nachladen musst. Und ein Speicherbedarf von 1MB ist doch wirklich nix mehr heutzutage, dazu wurde hier ja auch schon...

Mehrere Instanzen von Synedit würden für mich nur Sinn machen, wenn ich die Zeilen direkt aus Synedit lesen würde statt aus der Datei. Dann müsste ich aber für jede Datei ein Synedit starten, egal ob ich die Datei überhaupt sehen will.

Und genau deshalb würde das keinen Sinn machen. Die Undo/Redo-Listen speichern zu können fände ich nur in einem Falle sinnvoll - wenn du sie auch in der nächsten Sitzung wieder zur Verfügung stellen wolltest. Das hätte aber auch wieder Fallstricke, zB die zwischenzeitliche Veränderung mit einem anderen Editor.

[Warf]

ich habe mal einen Test gemacht. Ein Formular ein Button und bei jedem Klick wird ein neues Synedit erzeugt und eine Assemblerdatei geladen. Nach jedem neuen Synedit zeigte Linux an, das mehr als 1 MB Arbeitsspeicher neu belegt wurde.

Kann ich nicht reproduzieren. Schaust du eventuell auf den virtuellen Speicherverbrauch? Denn der ist absolut irrelevant, du kannst 200GB virtuellen speicherverbrauch haben ohne das auch nur 1MB tatsächlich auf dem RAM liegt.
Ich hab einfach mal einfach nur synedits erstellt, ohne inhalt zu laden und hier sind die ergebnisse:

Code: Alles auswählen

Anzahl SynEdits, Virtueller Speicher (KB), Physischer Speicher (B)
0, 361300, 76080
1, 361676, 76080
2, 361708, 77936
3, 361708, 77936
4, 361740, 77936
5, 361772, 77936
6, 361804, 77936
7, 372828, 80908
8, 372860, 80908
9, 372892, 80908
10, 372924, 80908

Wie du sehen kannst, mehrere KB virtueller speicher alloziiert, die tatsächliche physische speicherauslastung geht aber erst nach der erstellung von 5 synedits um 3kb hoch (eine page). Also verbraucht ein synedit etwa 600 bytes.
Und selbst wenn, 1MB pro datei ist doch nix. Selbst mein Raspi hat 1GB ram. Selbst wenn man also 500 dateien öffnen würde (was ich noch nie gemacht hab) wäre der RAM erst zur hälfte ausgelastet.

Außerdem benötige ich für jede Assemblierung die aktuelle Version aller asm-Dateien.
Das heißt wenn ich Änderungen vorgenommen habe, muss ich speichern, ganz gleich ob ich eine oder mehrere Instanzen von Synedit laufen lasse.

Ne das heist lediglich das du vor der assemblierung die aktuelle version brauchst. Ich hab auch mal ne IDE geschrieben und da hab ichs einfach so gemacht: die compilierungs funktion ist einmal alle editoren durchgegangen und hat das gespeichert was noch nicht gespeichert war.

Mehrere Instanzen von Synedit würden für mich nur Sinn machen, wenn ich die Zeilen direkt aus Synedit lesen würde statt aus der Datei. Dann müsste ich aber für jede Datei ein Synedit starten, egal ob ich die Datei überhaupt sehen will.

Sie lohnen sich allein schon weil es einfacher zu managen ist. In deinem aktuellen ansatz musst du alle meta informationen speichern, cursor position, selection, code folding, etc. Wenn du das syn edit einfach offen lässt, dann fällt dieser code einfach weg.

Und von was für Speicherauslastungen reden wir hier? Denkst du jemand wird mehr als 50 dateien offen haben? Selbst wenn wir den virtuellen speicher von 1MB annehmen, eine Lazarus anwendung ohne irgendwas verbraucht bei mir 350 mb virtuellen speicher, wenn 50 editoren a 1MB offen sind (also 50mb extra), erhöt das den gesammten Speicherverbrauch deiner anwendung grade mal um 14%.
Du musst dir also im klaren sein das du arbeit reinsteckst die du sonst nicht hättest um 14% virtuellen speicherverbrauch zu reduzieren, in dem sehr unwahrscheinlichen scenario in dem jemand 50 editoren offen hat. In einem realistischeren scenario (5-6 Dateien offen) sprechen wir hier von vielleicht 1%-2%.

Und mal ganz davon abgesehen, die Platte ist das bottle neck des gesammten rechners. Je mehr du auf die platte schreibst und davon liest, desto mehr verlangsamst du alle anderen programme die die platte benutzen. Du tauschst also ein paar MB virtuellen speicher verbauch (und ein paar KB physischen) gegen performance von sowohl deiner anwendung (damit wird das datei wechseln locker um einen faktor 1000 langsamer) sowie des gesammten rechners. Plus du machst dir extra Arbeit. Persönlich sehe ich absolut keinen Grund die dateien auf der Platte zu speichern.

PS: von meiner erfahrung mit der IDE die ich mal geschrieben hab, macht die Symboltabelle und generell die ganzen parser datenstrukturen, die für code navigation, completion und highlighting benötigt werden eh viel mehr vom Speicherverbrauch aus als die tatsächlich offenen Dateien.

[aro]

Hallo, ich kann die Werte nicht nachvollziehen.
Wenn ich eine Assembler - Datei von 10 KB lade und dazu kommen noch die ganzen Daten von Highlighter, Undo, Reundo und Stringverwaltung, dann sind 600 Byte doch wohl sehr unrealistisch.

Aber wie gesagt, ich schaue einfach, ob ich eine vernünftige Lösung finde.
Zeit habe ich mehr als genug.

[Warf]

Hallo, ich kann die Werte nicht nachvollziehen.
Wenn ich eine Assembler - Datei von 10 KB lade und dazu kommen noch die ganzen Daten von Highlighter, Undo, Reundo und Stringverwaltung, dann sind 600 Byte doch wohl sehr unrealistisch.

Ich habe einen leeren editor geöffnet. Aber ich habe auch grad mal eine 3kb datei geladen und darin einige änderungen gemacht um die undo liste zu füllen (bestimmt so 30-50 änderungen).
Größe leerer editor: 358072KB Virtuell 73872B Physisch
Größe nach dem öffnen/editieren: 369100KB Virtuell 77540B Physisch.
Ich kann verstehen wie man hier wenn man den virtuellen speicher anschaut, es so aussieht als wären 11mb dazu gekommen, das hat aber nix mit dem tatsächlichen speicherverbrauch zu tun. Wie du beim Physischen speicher sehen kannst sind weniger als 4kb mehr dazu gekommen. Da die Datei davon allein 3KB ausmacht, bedeutet das die undo liste weniger als 1kb ausmacht.

Und wenn man mal drüber nachdenkt, woher soll der speicher herkommen? Eine undo group im synedit hat die folgenden items:

Code: Alles auswählen

FItems: Array of TSynEditUndoItem;
    FCount, FCapacity: Integer;
    FReason: TSynEditorCommand;

Undo items sind z.b.:

Code: Alles auswählen

 TSynEditUndoSelCaret = class(TSynEditUndoItem)
  private
    FCaretPos, FBeginPos, FEndPos: TPoint;
    FBlockMode: TSynSelectionMode;
    [...]

  { TSynEditUndoIndent }

  TSynEditUndoIndent = class(TSynEditUndoItem)
  public
    FPosY1, FPosY2, FCnt, FTabCnt: Integer;
    [...]

  { TSynEditUndoUnIndent }

  TSynEditUndoUnIndent = class(TSynEditUndoItem)
  public
    FPosY1, FPosY2: Integer;
    FText: String;
    [...]

Keines dieser elemente ist sonderlich groß. Wenn wir von einem string mit 8 chars ausgehen der geädert wurde, dann ist das höchste der gefühle 2 integer und dieser string (8 chars + pointer + refcount = 24 byte).
Ich denke es ist also fair zu sagen das eine undo gruppe 100 bytes, wahrscheinlich deutlich weniger, zieht. Der default Max-Undo wert ist 1024, d.h. das höchste der Gefühle für die undo liste ist 100kb.

Zum highlighter, der zieht richtig wenig, da das synedit so gebaut ist das es nur im sichtbaren bereich highlighted. D.h. wenn du eine richtige wall of text hast mit 40 zeilen a 60 zeichen wobei sich bei jedem das highlighting ändert, brauchst du 2400 highlighter strukturen. Die enthalten die folgenden attribute:

Code: Alles auswählen

    FBackground: TColor;
    FForeground: TColor;
    FFrameColor: TColor;
    FFrameEdges: TSynFrameEdges;
    FFrameStyle: TSynLineStyle;
    fStyle: TFontStyles;
    fStyleMask: TFontStyles;

Das sind 28 bytes. Plus noch eine positionsinfo (TPoint) von 8 bytes sind 36 bytes. Damit sind wir also bei weiteren 86KB.

Also im worst case scenario, mit 1024 undo schritten die alle samt 100 byte ziehen und einer kompletten wall of text in der jedes zeichen einen eigenen highlighter hat, sind wir bei unter 200 kb. D.h. um 100MB voll zu bekommen muss man schon 500 editoren offen haben.

Wie gesagt. Lazarus macht es genau so, und ich kann problemlos 1500 dateien in Lazarus öffnen und das zieht grade mal 500mb insgesammt, wobei Lazarus mit nur einem Editor allein schon 200mb oder so zieht. Und Lazarus maintained intern noch für alle offenen dateien und der includes eine Symboltabelle, und anderen kram, der die speicherauslastung in die höhe treibt.

PS: Woran du auch denken solltest, deine optimierung wird nix bringen, denn wenn du regelmäßig die gleichen Dateien liest und schreibst, merkt der Linux Kernel das und lädt die daten eh in den RAM. Du sparst also nix, außer das du performance einbüst

[martin_frb]

Tools wie "top" (linux) oder OS memory info zeigen immer zu viel Speicher an.
Wenn FPC auch nur ein einziges Byte reservieren will, fordert es vom OS *immer* mindestens eine ganze "page" an. Fpc hat dann einen internen Mem-Manager der das Memory unterverteilt.

Auch entstehen im Memory Lücken, die aber dann für weitere Instancen genutzt werden können.
Z.b beim Laden: SynEdit nutzt eine Liste, die wächst. Dabei wird die Liste "re-allokiert". Der alte Platz der Liste ist frei, aber das OS sieht den Speicher noch als belegt.

Der FPC MemManager zeigt
200 kb pro SynEdit (ohne Highlighter) mit 100 Zeilen Text. Dann je 30 KB für weitere 100 Zeilen.
Selbst wenn mit HL und großem Text 1 MB per SynEdit belegt würden, Computer des letzten Jahrzehnt haben alle mehrere GB. => 1000 Editoren per GB. Und was nicht gebraucht wird geht in swap file (genau so schnell wie wenn man per Hand speichert).

Etwas überrascht 30 kb für 100 Zeilen (a 60 Zeichen) => 6 Kb Raw data.
- Aber 100 Strings, und FPC overhead per string... Mem und String Header, je 10 bis 20 bytes (?). Dann aufgerundet auf vielfaches von 16....
- Einträge in der "StringList"


---
Undo liste zwischenspeichern....
=> Die undo liste funktioniert nur wenn der text nicht verändert wurde.
Wird der Text im gespeichertem File geändert, und wieder geladen, dann wird die alte Undo liste Unsinn machen.....

Allerdings, Code um die Undo liste zu streamen wäre ggf trotzdem interessant....

[aro]

Hallo,

Ich habe jetzt nur Antworten bekommen, die mir alle klar machen wollen, das Synedit eigentlich nicht viel Speicher verbraucht, der Wechsel der Datei Unsinn ist, weil mehrere Instanzen den Speicherverbrauch überhaupt nicht wesentlich verschlechtern und sich der Aufwand niemals lohnt.
Wenn man davon ausgeht, das die Speicherung und Wiederherstellung von Undo unter Lazarus derzeit gar nicht möglich ist, verwundern mich die Antworten nicht, denn es gab bisher überhaupt keine Alternative zu mehreren Instanzen.

1. funktioniert das unter Delphi problemlos - allerdings nur unter Windows und ich arbeite nur noch unter Linux!
2. wenn man sich den Quelltext anschaut, sieht man sehr schnell, warum es unter Lazarus nicht funktionieren kann.
3. Durch wenige Erweiterungen und Veränderungen, habe ich das Problem in kurzer Zeit, sehr zufriedenstellend gelöst!

Derzeit habe ich die Testphase noch nicht abgeschlossen. Es gibt ja fast unendlich viele Kombinationen, wie man den Text in Synedit verändern kann und alles will sorgfältig getestet werden.

Bei Interesse werde ich die geänderten Quelltexte veröffentlichen.

[fliegermichl]

3. Durch wenige Erweiterungen und Veränderungen, habe ich das Problem in kurzer Zeit, sehr zufriedenstellend gelöst!

So gefällt mir das! Thumbs up