![]() |
SynHighlighter erweitern
Hallo!
Die Frage richtet sich an die Algorithmus-Experten hier. Bitte schaut euch mal den Source ![]() In Zeile 206 wird ein Array mit Keywords definiert. Das sind die ![]() Das Problem dabei: Das Array wird nicht einfach per 1:1 Vergleich abgefragt sondern über einen Hash-Algorithmus (Zeile 229) verglichen (Zeile 242) und einer ganzen Tabelle von Identifizierungsroutinen (Zeile 254) zugeordnet. Ergänzt man jetzt das Keyword-Array einfach um weitere Schlüsselworte, kommt der Hash-Algorithmus nicht mehr mit seiner Vergleichstabelle zurecht. Mir ist der Mechanismus einfach zu undurchsichtig, vielleicht kann mir da mal einer von euch Tips geben. Grüße Cody |
AW: SynHighlighter erweitern
Die HashKey (außer dem mod 137) ist mir auch nicht klar. Vielleicht schmeißt du einfach die KeyIndices raus und schreibst dir eine IndexOfKeyWords? :)
|
AW: SynHighlighter erweitern
Also ich hab jetzt auch ein paar Stunden über der Sache gehirnt. Wenn ich das richtig verstehe, bilden Keyword-Liste und Hash-Liste ein Zweiergespann. Dieses existiert nur deswegen, weil manche Operationen bei Unicode schlichtweg nicht funktionieren oder grottenlangsam sind.
Jetzt habe ich mir ein kleines Toolchen gebastelt, wo ich links freihändig eine Liste mit Keywords eingeben kann und rechts fertig formatiert ein Stück Pascalcode mit dem Keyword-Array und dem Hash-Array. Das funktioniert jetzt sogar soweit mit den neuen Keywords von PHP5. Einziges Problem dabei: Der Hash-Algorithmus liefert keine eindeutigen Hashes. Bei einer Liste von 100 Keywords hat man mit Sicherheit schon eine oder mehrere Dupletten dabei. Und dann kommt die Hashtabelle in Schwulitäten, denn man muss sich entscheiden auf welchen Eintrag in der Keyword-Tabelle man verweisen will. Also müsste man den Hash-Algo entwas anpassen damit die Hashes eindeutiger würden. |
AW: SynHighlighter erweitern
Ein Hash sollte eigentlich eindeutig sein (nicht eineindeutig, aber eindeutig)
|
AW: SynHighlighter erweitern
Geh mal in deinen Link von oben, dann ins ParentDir und lad dir mal das ganze Project runter. Scheint eine völlig neue Version zu sein. Wenn ich den Code richtig verstanden habe, dann wird das dort jetzt ganz anders gelöst (über hardcodierte functions). Da sollten sich doch einfach neue hinzufügen lassen?
|
AW: SynHighlighter erweitern
Also ich denke die Hash-Funktion ist schon ok.
Wenn du die Hash-Tabelle (KeyIndices) neu aufbauen möchtest, musst du so vorgehen: Schreibe ein eigenes Programm für die Ermittlung der Hashwerte. 1.) Array KeyWords um deine Einträge erweitern 2.) Alle Einträge in KeyIndices auf -1 setzen var // var nicht const ! KeyIndices: array[0..136] of Integer; 3.) Für jeden String in KeyWords berechnest du den Hashwert Der Hashwert liegt zwischen 0 und 136 Zusätzlich zum Hashwert braucht man noch den Index Der Index für 'and' ist z.B. 2. 4.) Prüfe ob KeyIndices[Hashwert] = -1 ist 5a.) Falls ja KeyIndices[Hashwert] := Index 5b.) Falls nein erhöhe den Hashwert wie folgt und prüfe nochmal Hashwert := (Hashwert + 1) mod 137; Die Punkte 5a und 5b lassen sich mit einer While-Schleife codieren
Delphi-Quellcode:
6.) nachdem alle Keywords gehashed wurden lässt du dir den Inhalt
While KeyIndices[Hashwert] <> -1 do
Hashwert := (Hashwert + 1) mod 137; KeyIndices[Hashwert] := Index; von KeyIndices[] anzeigen (in ein TMemo schreiben, damit du die Liste mit 137 Zahlen per Copy & Paste holen kannst) 7.) die neuen KeyWords und KeyIndices in SynHighlighterPHP.pas kopieren. PS: du solltest zuerst versuchen mit den alten Keywords[] die gleichen KeyIndices[] wie im ursprünglichen Sourcecode zu erzeugen. Falls das funktioniert hat, nimmst du die neuen PHP Keywords auf. |
AW: SynHighlighter erweitern
Also ich kenne den SynEdit schon recht lange und recht gut. Historisch war es so, dass zuerst die ANSI-Version da war und dort waren die Highlighter hartcodiert. Seit der Unicode-Version wurden die ein "bisschen" flexibler. Da gibts jetzt auch einen UniSynHighlighter, der variabel anpassbar ist zur Designtime über Properties. Aber der ist nicht 100% auf die Eigenheiten der einzelnen Sprachen anpassbar, sodass manche Feinheiten unter den Tisch fallen. Darum immernoch die spezialisieren Highlighter.
Ich denke, die brauchten einen ganz simplen Hash-Algo, der kurze INT-Hashes liefert die man als Index in einem Array missbrauchen kann. Der jetzige liefert aber nur eine Streubreite von 0..136, was bei knapp 100 Keywords nicht die Wucht ist. Wahrscheinlich wäre es das beste, die ganze Sache mal komplett umzustricken. Wird aber wohl erst nächste Woche. Vielleicht hat ja einer von euch am Wochenende etwas Langeweile? ;-) @shmia: Parallel zu Deiner Antwort kam ich fast zum selben Ergebnis. Hier der Source zu meinem Hash-Pascalcode-Generator:
Delphi-Quellcode:
Schönes WE
procedure TForm1.Button1Click(Sender: TObject);
type KWRec = record Keyword: String; Hash: Integer; end; KWList = array of KWRec; var I, J, iNumWords, iMaxHash: Integer; S, S2: String; C: Char; L: KWList; Indices: array of Integer; SL: TStringList; begin I:= 0; iNumWords:= 0; iMaxHash:= 0; Memo1.Lines.BeginUpdate; try while I < Memo1.Lines.Count do begin S:= Memo1.Lines[I]; S2:= ''; for J:= 1 to Length(S) do begin C:= S[J]; if IsIdentChar(C) then S2:= S2 + C; end; if Trim(S2) = '' then Memo1.Lines.Delete(I) else begin Memo1.Lines[I]:= S2; Inc(I); Inc(iNumWords); end; end; SL:= TStringList.Create; try SL.Assign(Memo1.Lines); SL.Sort; Memo1.Lines.Assign(SL); finally SL.Free; end; SetLength(L, iNumWords); for I:= Low(L) to High(L) do begin S:= Memo1.Lines[I]; L[I].Keyword:= S; L[I].Hash:= HashKey(PChar(S)); iMaxHash:= Max(L[I].Hash, iMaxHash); end; SetLength(Indices, iMaxHash + 1); for I:= Low(Indices) to High(Indices) do begin Indices[I]:= -1; end; Memo2.Lines.BeginUpdate; try Memo2.Lines.Add(' KeyWords: array[0..' + IntToStr(iNumWords - 1) + '] of UnicodeString = ('); for I:= Low(L) to High(L) do begin Indices[L[I].Hash]:= I; S:= ' ''' + L[I].Keyword + ''''; S:= S + StringOfChar(' ', Max(25 - Length(S), 0)); S:= S + '{ Index: ' + IntToStr(I); S:= S + StringOfChar(' ', Max(35 - Length(S), 0)); S:= S + ' | Hash: ' + IntToStr(L[I].Hash); S:= S + StringOfChar(' ', Max(49 - Length(S), 0)); S:= S + '}'; if I < High(L) then S:= S + ','; Memo2.Lines.Add(S); end; Memo2.Lines.Add(' );'); Memo2.Lines.Add(''); Memo2.Lines.Add(' KeyIndices: array[0..' + IntToStr(iMaxHash) + '] of Integer = ('); for I:= Low(Indices) to High(Indices) do begin S:= ' ' + IntToStr(Indices[I]); S:= S + StringOfChar(' ', Max(8 - Length(S), 0)); S:= S + ' { Index: ' + IntToStr(I) + ' }'; if I < High(Indices) then S:= S + ','; Memo2.Lines.Add(S); end; Memo2.Lines.Add(' );'); finally Memo2.Lines.EndUpdate; end; finally Memo1.Lines.EndUpdate; end; end; Cody |
AW: SynHighlighter erweitern
Ich habs grad gelesen eigentlich auch nur weil ich selber gerade etwas am Grübeln bin darüber, wie man dem Ding CSS3 sowie HTML5 beibringen könnte :-D
Also wenn du da was strickst, (am coolsten waere irgendwas automatisiertes was dir am Ende halt den Highlighter komplett rausspucken würde) Dann sag mal bescheid! Schönes WE |
AW: SynHighlighter erweitern
Zitat:
Zum zweiten sind Highlighter immer auch ein Stück weit dem persönlichen Geschmack des Entwicklers unterworfen, wie viele Features man einbauen möchte. Am obigen Beispiel könnte man auch sagen, eingebettete Variablen müssen nicht extra formatiert werden. Was aber richtig ist und wo ich zustimme, alle Arbeiten an der SynEdit-Komponente nützen nichts, wenn die Highlighter die verfügbar sind, nur steinalte Sprachen beherrschen. Da muss man dringend nachlegen. Ich bin nämlich immernoch der Meinung, SynEdit ist leistungsfähiger als Scintilla, zumindest in der Delphi-Welt. Niemand würde einen Texteditor zum Entwickeln einsetzen wenn dieser die betreffende Sprache nicht unterstützt. Leider wird an der Kernkomponente nur wenig gemacht. Es gab einige vielversprechende Forks (Mystix und Letterpress) doch beide sind inzwischen wieder eingeschlafen. Für HTML5 müsste es relativ einfach sein. Denn das basiert ja nicht auf XHTML sondern dem älteren Standard HTML4. Und für den gibts ja schon einen Highlighter. Ich denke, da muss man auch nur ein paar Keywords ergänzen und einige wenige semantische Erweiterungen. Ebenso bei CSS3. Wobei man hier ehrlicherweise sagen muss, dass der verfügbare CSS-Highlighter noch nicht mal CSS2 komplett unterstützt :roll: Für einige Sprachen könnte ich gar keinen Highlighter schreiben, denn manche kenne ich gar nicht. Man muss schon ein bisschen in der jeweiligen Sprache zuhause sein, sonst bekommt man keinen gescheiten Highlighter zusammen. |
AW: SynHighlighter erweitern
@CodeHunter
Da geb ich dir wohl Recht, bei dem was du sagst. Ist halt irgendwie sehr Schade das da nichts großartig weiterentwickelt wird, ich mag die Komponente eigentlich recht gerne. Was den CSS Highlighter z.B. angeht, was ich vermisse sind solche Sachen wie z.B. bei Sublime Text zu finden sind Beispiel:
Code:
Die Farbwerte werden bei Sublime Text z.b. unterschiedlich angezeigt bei dem Highlighter. #red besitzt eine andere Farbe wie auch RGBA Values. Dann wird weiterhin noch unterschieden ob Hex oder HLS werden ebenfalls noch unterschiedlich dargestellt. Prefixes kennt SynEdit Highlighter gar keine. Gut war zu der Zeit wohl auch noch kein Thema... :shock:
body {
color: #red; background: rgba(0, 0, 0, 0.5); } Naja und noch diverse andere Sachen die heute sagen wir mal Standart sind. Problem im Moment ist halt das der CSS Highlighter quasi so gut wie alles in einer Farbe darstellt bis auf wenige Ausnahmen. Da macht highlighten wenig Sinn, da kann man direkt ein Memo nehmen und bei der Textfarbe schwarz auf weiß bleiben :roll: Leider hab ich auch keine Ahnung wie man die Highlighter korrekt erweitert, weil das was du schreibst mit den Hashes usw. das klingt nicht gerade nach, wir erweitern mal eben kurz :shock: |
AW: SynHighlighter erweitern
@stOrM: Jetzt muss ich doch mal fragen, welche Version vom SynEdit du benutzt. Immernoch die ANSI oder bist du schon auf Unicode umgestiegen? Denn in der Unicode-Version vom SynHighlighterCSS hat sich in Sachen CSS3 schon einiges getan. Wobei das was du beschreibst, sicher noch über die Fähigkeiten hinaus geht die im Moment implementiert sind. Aber machbar wärs sicher.
|
AW: SynHighlighter erweitern
Also laut der Readme soll es die Unicode Version sein, kommt direct aus dem SVN.
joa gut Sublime ist was das Highlighten betrifft den SynEdit Saxhen Lichtjahre vorraus waere aber toll, wenn man zumindest ein paar Sachen nachbauen könnte so das die gehighlighteten Sachen einem mal wirklich ins Auge fallen und nich wie ein Brei aussehen. Kann gerne mal nen Screenshot machen? |
AW: SynHighlighter erweitern
Nu ja, abgesehen von der eigentlichen SynEdit-Unit ist SynHighlighterCSS.pas die Datei
![]() |
AW: SynHighlighter erweitern
Liste der Anhänge anzeigen (Anzahl: 1)
Zitat:
Ich hab mal ein Beispiel drangehangen da sieht man wie ich mir ein Highlihjting vorstelle. |
AW: SynHighlighter erweitern
Wie gesagt, "richtig gut" ist weit interpretierbar. Man kann immer einen Vergleich zu einem anderen Editor ziehen, der irgendeinen Teil beim Highlighting anders macht. Ist ja auch immer die Frage, passt das überhaupt in das Konzept von SynEdit, konstruktionsmäßig meine ich. Du kannst da mit dem Highlighter nichts realisieren, was die Core-Komponente nicht hergibt.
Zum Screenshot: Da sehe ich aber auch noch semantische Fehler... Zeile 24, das "linear" in der falschen Farbe oder Zeile 28 das "to". Oder habe ich da jetzt am CSS3 was falsch verstanden? |
AW: SynHighlighter erweitern
Zitat:
Aber ich denke, wenn ein Highlighter für eine spezielle Sprache sei es CSS oder HTML existiert, denke ich sollte eine solche Funktionalitaet betreffend des Highlighten möglichst aller in der Sytax vorkommender Attribute möglich sein sollte. Ob das nun Farblich noch extrem verfeinert werden kann weiss ich nicht. Auf der anderen Seite wie gesagt wenn größtenteils alles eine Farbe hat welchen Sinn bringt dann der Highlighter? Zum Screenshot: Kann ich Dir nicht sagen, nach welchen Kriterien ST2 highlightet, aber ich finds sehr übersichtlich. |
AW: SynHighlighter erweitern
Also ich möchte fast wetten, dass der jetzige Highlighter aus dem SVN in der Lage ist, diesen CSS-Source genauso zu rendern wie in dem Screenshot. Wenn überhaupt, unterscheiden die sich nur in Details. Das mit den Farben ist ja konfigurierbar.
Obwohl ich Sublime bisher nicht kenne außer von dem kleinen Video auf der Website, dann würde ich sagen liegt seine große Stärke weniger beim Highlighting sondern mehr beim Refactoring. Das ist ja wieder mehr eine Baustelle der Core-Komponente und nicht des Highlighters. |
AW: SynHighlighter erweitern
Zitat:
Wenn man das Highlighten in etwa so hinbekommen könnte waers schon genial. Ich frag mich nur wie so ganz hab ich das Konzept des Erweiterns nicht verstanden, zu mal wie du sagst über Hashes auch noch :oops: |
AW: SynHighlighter erweitern
Ja Moment, das mit den Hashes ist ja eine Baustelle des PHP-Highlighters. Der für CSS hat einen ganz anderen Hash-Algorithmus und verwendet auch keine hartcodierte Hashtabelle. Ich könnte jetzt alle SynHighlighter abgrasen nach dem besten Hash-Konzept und dass dann bei PHP und/oder CSS reinstricken. Aber das wär ja, als würde man beim Auto den Motor wechseln wenn mal eine Zündkerze schlapp gemacht hat.
|
AW: SynHighlighter erweitern
Zitat:
|
AW: SynHighlighter erweitern
Kannst du deinen Beispielquelltext mal als ASCII hier reinhängen? Dann schau ich Montag mal, ob der jetzige Highlighter da mitkommt. Ich denke schon dass der das kann. Nur hab ich keine Lust das Ding abzutippen ;-)
|
AW: SynHighlighter erweitern
Zitat:
ggf auch direkt die Farbwerte dazu wenn ich zeitlich hinbekomme. Denk mal bis Morgen habe ich fertig:) |
AW: SynHighlighter erweitern
Um jetzt wieder auf das Eingangsthema zurückzukommen:
Es hilft alles nix, man bräuchte einen besseren Hash-Algorithmus. Mit den in SynEdit (bei den verschiedenen Highlightern) verfügbaren kommt man bei PHP nicht weiter, da die Keywords zu oft gleiche Hashes produzieren. Womöglich ist der ganze Ansatz über Hashes ein Fehler und man sollte lieber 1:1-Vergleiche mit der Keywordliste machen. Muss ich mal testen, in wie weit das negative Auswirkungen auf die Performance hat. Irgendwie kann ich mir nicht vorstellen, dass ein 1:1-String-Vergleich wesentlich langsamer sein sollte als der Umweg über einen Hash. Außerdem ergibt sich ja bei so kleinen Hashes nicht nur das Problem der False-Negatives sondern auch der False-Positives. Sprich, es würden Codeteile als Keyword erkannt die gar keine sind. |
AW: SynHighlighter erweitern
Mal ne Frage:
Hast du auch SynWeb gesehen? Ich bin irgendwie drüber gestolpert liegt bei mir auf der Platte und basiert wohl auf SynEdit habs mir aber noch nicht angesehen, ich habs mal nur gezogen weil da irgendwas von CSS3 sowie Erweiterungen und so weiter stand. |
AW: SynHighlighter erweitern
Primär bin ich erstmal am PHP-Highlighter dran.
SynWeb kannte ich bisher nicht. Musste ich selbst erstmal nachschauen. Da hat jemand verdammt viel Arbeit rein gesteckt. Ist aber im Grunde die selbe Pest wie mit Mystix und Letterpress: Forks, die abgespalten für sich alleine dahin vegetieren. Stand ist 2007, wird also wahrscheinlich schon nicht mehr mit dem aktuellen SynEdit kompatibel sein. Mir erschließt sich das Problem nicht, dass die Leute nicht einfach ProjectMember bei SynEdit werden und ihre Extensions ins Projekt einpflegen. Irgendwann vergammelt der Fork, wie z.B. Letterpress, das als Projekt geschlossen wurde. Und dann war alle Mühe für die Katz. Was gabs nicht alles schon: Codefolding war im Mystix drin, dummerweise nicht Unicode-fähig da zu früh vom Hauptprojekt abgespalten. Refactoring bei Letterpress, leider nun im Nirwana versunken (hab noch eine Kopie davon zum Glück). Es ist schon traurig, dass sich die paar Hanseln, die am SynEdit arbeiten, einfach untereinander nicht einig werden. Leider sind mir, geb ich ehrlich zu, manche Teile von SynEdit einfach zu hoch. Wie dieses komplizierte Hashing. Ich versteh zwar die Gründe, warum das so gemacht wurde. Aber ich versteh die Algorithmen nicht. |
AW: SynHighlighter erweitern
Joa, iss mir auch zu Hoch aber nicht unbekannt. Versuch mal im kleinen Kreis ein "kleines" Projekt auf die Beine zu stellen, da klappts ja schon oft genug nicht weil man sich nicht oder schlecht einig wird.
Es braucht einen guten Haeuptling oftmal :-D Was Synedit angeht ich komm da auch nicht wirklich mit weiter leider, weil irgendwie mag ich das Ding. Wenn ich wüsste wie man den vernüpftig um die Sachen die ich Dir gegeben hatte erweitern könnte waere ich auch froh. Ich guck mir mal die Trial von TMS an die haben glaub ich auch so ein Teil (vermutlich *uggy wie meist, aber Versuch ist es Wert, vielleicht laesst sich der ja besser pimpen :-D) |
AW: SynHighlighter erweitern
Zitat:
Die TAdvMemo Komponente ist an sich nicht sooo schlecht. Sind aber nur relativ wenige Highlighter dabei. Und das Ganze ist natürlich nicht OpenSource, kannst also kein offenes Projekt damit starten. |
AW: SynHighlighter erweitern
Zitat:
Bist du bezüglich meinen Sachen da weiter gekommen irgendwie, weil du ja meintest sollte gehen? |
AW: SynHighlighter erweitern
Zitat:
Erstmal muss ich dahinter steigen, wie dieser blöde Hash-Algo funktioniert. Der steckt ja mehr oder weniger identisch in allen Syn-Highlightern drin. Nur mit anderen Konstanten. Ich vermute, dass die Konstanten in Abhängigkeit von der Keyword-Liste auch geändert werden müssen, damit keine Dupletten entstehen. Darum wieder die Frage an die Algoritmus-Experten hier: Könnt ihr die Sache mal ein wenig für mich erhellen? Der Originalsource findet sich ![]()
Delphi-Quellcode:
Ich verstehe halt die Bedeutung der drei Konstanten 596, 413 und 137 nicht. Wobei ich bei 137 vermute, es ist der höchstmögliche Hashwert plus 1. Doch daraus ergibt sich dann ein Henne-und-Ei-Problem: Den höchsten Hashwert bekommt man nur unter Anwendung der Hash-Routine, welche ja zu ändern wäre :cyclops:
function TSynPHPSyn.HashKey(Str: PWideChar): Cardinal;
begin Result := 0; while IsIdentChar(Str^) do begin Result := Result * 596 + Ord(Str^) * 413; inc(Str); end; Result := Result mod 137; fStringLen := Str - fToIdent; end; |
AW: SynHighlighter erweitern
Ich bleib' bei #2, schmeiß die KeyIndices raus.
Delphi-Quellcode:
type
TIdentFuncTableFunc = type TtkTokenKind; ... function TSynPHPSyn.HashKey(Str: PWideChar): integer; var I: integer; S: AnsiString; begin Result := -1; S:= LowerCase(AnsiString(WideCharToString(Str))); for I:= 0 to Length(KeyWords) - 1 do if AnsiString(KeyWords[I]) = S then begin Result := I; Break; end; // fStringLen ??? // fToIdent ??? // sind keine Variablen der unit ??? end; function TSynPHPSyn.IdentKind(MayBe: PWideChar): TtkTokenKind; var Key: integer; begin Key := HashKey(MayBe); if HashKey(MayBe) > -1 then Result := fIdentFuncTable[Key] else Result := tkIdentifier; end; procedure TSynPHPSyn.InitIdent; var I: Integer; begin for I := Low(fIdentFuncTable) to High(fIdentFuncTable) do if I > High(KeyWords) then ... else ... end; ... |
AW: SynHighlighter erweitern
@Bjoerk: Im Prinzip hast du recht. Ich beiß mich aber gern mal durch solche Probleme durch sonst lernt man ja nix dabei ;-) Schade dass man den ursprünglichen Erfinder des Algorithmus Martin Waldenburg nirgends mehr findet (macht anscheinend nix mehr mit Delphi).
FStringLen und FToIdent sind private-Members der Elternklasse. Ich fands schon immer merkwürdig, dass man bei der Delphi-Vererbung auf diese Weise auf Variablen der Elternklassen zugreifen kann. Aber so ist es nun mal. Die Umwandlung in Ansistring finde ich ein wenig bedenklich. Es würde dadurch die Gefahr von False-Positives steigen denn der Hash-Algo ist ja nach wie vor der selbe. Der Verzicht auf KeyIndices bringt da meiner Meinung nach keine Vorteile. Ich habe mich schon mit zwei Maintainern von SynEdit in Verbindung gesetzt aber anscheinend wissen sie auch nicht sehr viel über den Algorithmus. Wir vermuten aber alle, dass ein Tool verwendet wurde um die Arrays (KeyWords und KeyIndices) sowie die Konstanten im Hash-Algo zu generieren. Das einzige was mir jetzt noch einfiele, wäre die Konstanten per Bruteforce rauszufinden. Aber das ist ja auch nicht gerade die feine englische Art ;-) |
AW: SynHighlighter erweitern
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! |
AW: SynHighlighter erweitern
Das haette ich Dir sagen können :-D Nur blick ich das Grammar nicht :oops:
|
AW: SynHighlighter erweitern
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.
|
AW: SynHighlighter erweitern
Zitat:
|
AW: SynHighlighter erweitern
Zitat:
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? |
AW: SynHighlighter erweitern
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
Delphi-Quellcode:
in den Quelltext des Highlighters eingebunden werden. Damit kann ich mir die veränderlichen Fragmente eines Highlighter generieren.
{$I dateiname}
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
Delphi-Quellcode:
enthält, je Zeile:
TtkTokenKind
Delphi-Quellcode:
. 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
Zeichenfolge|TtkTokenKind
Delphi-Quellcode:
aufgebaut sein, da hieraus auch Teile des Quelltextes generiert werden.
SynRopsSyn.Functionen.txt
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
Delphi-Quellcode:
ist im Abschnitt
SynHighlighterROPS.PrivateFunc.inc
Delphi-Quellcode:
des Highlighters hinter
private
Delphi-Quellcode:
einzufügen, das Fragment mit einem Namen in der Form
function KeyComp(const aKey: String): Boolean;
Delphi-Quellcode:
muss in die
SynHighlighterROPS.IdentFuncTable.inc
Delphi-Quellcode:
eingefügt werden und das Fragment mit einem Namen in der Form
procedure TSynROPSSyn.InitIdent;
Delphi-Quellcode:
wird im Implementierungsteil hinter
SynHighlighterROPS.FuncSource.inc
Delphi-Quellcode:
eingefügt und ersetzt den gesamten Quelltext bis vor
function TSynROPSSyn.KeyComp(const aKey: String): Boolean;
Delphi-Quellcode:
.
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. |
AW: SynHighlighter erweitern
Zitat:
|
AW: SynHighlighter erweitern
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:
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. |
AW: SynHighlighter erweitern
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 22:25 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz