SynHighlighter erweitern

[Codehunter]

Ich werd irre... Da ist doch tatsächlich ein Quellcodegenerator bei SynEdit dabei (SynGen). Man muss nur erstmal dahinter steigen, wie die Grammarfiles funktionieren die das Ding importieren will. Und der Witz an der Sache: SynGen erzeugt die Hashtable tatsächlich nach einer Art Bruteforce-Methode. Je mehr Keywords eine Sprache hat umso länger braucht das Programm.

Zwar ist der erzeugte Highlighter nicht unbedingt brauchbar weil eine Sprache ja auch aus einer Semantik besteht und nicht nur aus Keywords, Identifiern und Symbolen. Aber: Es erzeugt die Hashtables und die HashKey-Funktion. Die kann man dann einfach rüberkopieren und sich wieder auf die wesentlichen Dinge konzentrieren.

Insofern: Problem gelöst und Danke an alle die sich beteiligt haben!

[stOrM]

Das haette ich Dir sagen können Nur blick ich das Grammar nicht

[Furtbichler]

und wieso baut man nicht einfach eine Hashmap ein? Ich hab mir das Ding vor ewigen Zeiten auch mal angeschaut und den Kopf geschüttelt. Ziemlicher Blödsinn.

[Namenloser]

Zitat von Furtbichler:

und wieso baut man nicht einfach eine Hashmap ein? Ich hab mir das Ding vor ewigen Zeiten auch mal angeschaut und den Kopf geschüttelt. Ziemlicher Blödsinn.

Ich denke mal, da die Map nur ein einziges mal erzeugt wird, hat man mehr Wert auf optimale Verteilung ohne Kollisionen gelegt als auf einfache Einrichtung.

[Furtbichler]

Zitat von NamenLozer:

Zitat von Furtbichler:

und wieso baut man nicht einfach eine Hashmap ein? Ich hab mir das Ding vor ewigen Zeiten auch mal angeschaut und den Kopf geschüttelt. Ziemlicher Blödsinn.

Ich denke mal, da die Map nur ein einziges mal erzeugt wird, hat man mehr Wert auf optimale Verteilung ohne Kollisionen gelegt als auf einfache Einrichtung.

Is klar, aber es geht nicht um die Anzahl der Kollisionen, sondern um die Performance. Jede Hashmap ist gegen Kollisionen immun. Wichtig ist der Load-Factor und jede halbwegs anständige Hashmap-Implementierung wächst automatisch mit.

Bei der Implementierung würde ich persönlich auch eher Wert auf Erweiterbarkeit nehmen, und die Zeit, die ich in die Entwicklung des Codegenerators gesteckt hätte, an anderer Stelle sinnvoller investiert wäre.

Kann man da nichts nachträglich einbauen bzw. ersetzen?

[nahpets]

Hallo,

habe mir vor einiger Zeit einen eigenen Highlighter gebaut für Pascalscript von RemObjects mit Anpassungen für mein Programm. Als Basis habe ich den Highlighter für Pascal/Delphi genommen. Da mir das manuelle Anpassen zu viel Arbeit wurde, habe ich mir ein Pascalscript geschrieben, das aus einer Textdatei Codefragmente erstellt, die per {$I dateiname} in den Quelltext des Highlighters eingebunden werden. Damit kann ich mir die veränderlichen Fragmente eines Highlighter generieren.

Da nicht jeder Pascalscript zur Verfügung hat, habe ich das Pascalscript nach Delphi übertragen und hier rangehängt.

Das Programm benötigt als ersten Parameter den Namen einer Datei, die die zu verwendenen Zeichenfolgen (Schlüsselwörter...) und den Typen für TtkTokenKind enthält, je Zeile: Zeichenfolge|TtkTokenKind . Als zweiten Parameter erwartet es entweder die Zeichenfolge ROPS oder PHP, da es hier Unterschiede beim Aufbau der Hashtable gibt. Der Dateiname muss in der Form SynRopsSyn.Functionen.txt aufgebaut sein, da hieraus auch Teile des Quelltextes generiert werden.

Habe für vier Highlighter entsprechende Dateien beigefügt, die zum Testen und Weiterentwickeln geeignet sein sollten. Das Fragment mit einem Namen in der Form SynHighlighterROPS.PrivateFunc.inc ist im Abschnitt private des Highlighters hinter function KeyComp(const aKey: String): Boolean; einzufügen, das Fragment mit einem Namen in der Form SynHighlighterROPS.IdentFuncTable.inc muss in die procedure TSynROPSSyn.InitIdent; eingefügt werden und das Fragment mit einem Namen in der Form SynHighlighterROPS.FuncSource.inc wird im Implementierungsteil hinter function TSynROPSSyn.KeyComp(const aKey: String): Boolean; eingefügt und ersetzt den gesamten Quelltext bis vor function TSynROPSSyn.AltFunc: TtkTokenKind; .

Für PHP sind generierte Fragmente beigefügt.

Eventuell kann ja jemand, für die Anpassung vorhandener Highlighter, damit was anfangen.

[BUG]

Ich denke, dass eine statische Hashmap erzeugt wird, um den Initialisierungsaufwand beim Start des Programms gering zu halten.
Das Erzeugen einer "idealen" Hashfunktion wird wohl gemacht, um die Struktur flach (=> Array) und gleichzeitig klein (kommt ja alles in den Datenbereich des Programms) zu halten.

Wie sinnvoll das bei höchstens ein paar hundert Keywords pro Sprache ist, muss wohl jeder selber wissen.

Zitat von Bjoerk:

Und auch, wer soll das Programm überhaupt verstehen? Es gibt ein 0..136 Array, in denen aber nur 56 Werte drinstehen können, da es nur 56 KeyWörter gibt???

Ein Hinweis-Kommentar, dass der Code generiert wurde, und ein paar Hinweise zur Funktion wäre vermutlich sehr hilfreich
Wenn du irgendwo in den Speicher gucken würdest wo eine Hashmap liegt, würde die ähnlich aussehen, aber das macht man ja auch nicht.

[Bjoerk]

Zitat von Furtbichler:

und wieso baut man nicht einfach eine Hashmap ein? Ich hab mir das Ding vor ewigen Zeiten auch mal angeschaut und den Kopf geschüttelt. Ziemlicher Blödsinn.

Und auch, wer soll das Programm überhaupt verstehen? Es gibt ein 0..136 Array, in denen aber nur 56 Werte drinstehen können, da es nur 56 KeyWörter gibt???

[nahpets]

Zitat von Bjoerk:

[Und auch, wer soll das Programm überhaupt verstehen? Es gibt ein 0..136 Array, in denen aber nur 56 Werte drinstehen können, da es nur 56 KeyWörter gibt???

Vielleicht, weil man die gleiche Logik auch für andere Highlighter mit mehr (oder weniger) als 56 KeyWörtern verwenden möchte? Man muss ja nicht unbedingt für die Hashmap pro Highlighter eine eigene Logik entwickeln, die auf die konkrete Anzahl von Schlüsselwörten der Sprache ausgelegt ist.

[Codehunter]

Zitat von nahpets:

Vielleicht, weil man die gleiche Logik auch für andere Highlighter mit mehr (oder weniger) als 56 KeyWörtern verwenden möchte? Man muss ja nicht unbedingt für die Hashmap pro Highlighter eine eigene Logik entwickeln, die auf die konkrete Anzahl von Schlüsselwörten der Sprache ausgelegt ist.

Ich vermute, das ganze Konstrukt ist auch historisch gewachsen. Ursprünglich war das ja mwEdit von Martin Waldenburg und das war, soweit ich es heute noch nachvollziehen kann auf der Basis von einem RichEdit.

Das Problem dürfte sein, dass die Interfaces von SynEdit eine gewisse Struktur in den Highlightern vorgeben. Es gab sogar Highlighter-Wrapper, die für die Schnittstellen von SynEdit angepasst waren und intern mit dynamisch verarbeiteten Grammarfiles liefen. Soweit ich mich erinnere war es im Projekt Letterpress. Nur wurde da auch am SynEdit selbst auch viel geschraubt sodass man das nicht ohne weiteres rückportieren kann. Aber einfachere Highlighter wären eine Voraussetzung wenn man SynEdit fit für die Zukunft machen wollte. Sonst verplempert man unnütz Zeit mit dem Hingefrickel von Highlightern statt einen Editor zu schreiben (was in meinem Fall Syn4 wäre)