Christians Externes Gedächtnis

Habe mir noch einen anderen Ansatz überlegt und schon mal angefangen, ihn umzusetzen.
Das bisherige Skript ist keinesfalls kürzer oder mit tollen Profi-Funktionen gespickt. Ganz im Gegenteil. Aber es ist leichter nachzuvollziehen, flexibler und kommentiert. ;-)

An ein, zwei Stellen stehe ich gerade auf dem Schlauch und komme nicht weiter. Da mich aber eh gleich meine süße Freundin zu einem lauschigen Hafenspaziergang aus dem Büro abholt, wird die Lösung noch mindestens bis Montag warten müssen. Ich schreibe “mindestens”, weil ich Montag wohl mal wieder am Projekt Style Polizei arbeiten muss und abends wieder mit meinen Hobbykicker-Kollegen hobbykicken werde.

Diese zwei Stellen sind mir nach ein wenig Pause sicher null Rätsel mehr, aber für alle, die mitdenken wollen:
a) Warum wird bei mehrzeiligen Kommentaren der Stern, aber nicht der Slash in $strSoFar übernommen?
b) Warum klappt das Einfügen des FONT-Tags (Zeilen 236 u. 238) so nicht?

Wie gesagt - war wohl ein wenig zu viel Skripten heute, habe schon Dollarzeichen förmige Äuglein…

Meine Fresse - so ein Gewurstel!
Allmählich denke ich darüber nach, ob es nicht noch sehr viel effizientere Methoden gibt, so ein Syntax Highlighting zu realisieren.
Das Skript ist inzwischen abartig lang geworden. Das muss kürzer gehen.
Mein Kumpel Henning hat mir gestern auch schon eine RegExp geschrieben, die sich um mehrzeilige Kommentare kümmert. Die Adaption auf mein Skript habe ich allerdings noch nicht hinbekommen; daher ist sie auch noch nicht in meinem Skript Version 4 enthalten. An ihrer statt findet sich ein umständlicher Code, der einen Profi vermutlich grünlich anlaufen lässt. Aber egal - er funktioniert soweit.
Was nicht toll ist: Keywords innerhalb von Kommentaren werden hervorgehoben.

Hatte gerade den Einfall, dass ich mit “Regeln” an die Sache herangehen könnte und ferner dass es möglicherweise ein besserer Ansatz wäre, den ganzen Code zunächst in Einzelteile zu zerlegen, diese dann - nach Anwendung der “Regeln” - zu (farb)formatieren und den gesamten Code im Anschluss wieder auszugeben. Dazu aber wohl erst später.

So, jetzt habe ich auch die mehrzeiligen Kommentare zu fassen bekommen.

Das regele ich zwar momentan noch recht umständlich, aber es geht wenigstens.
Die Idee, alle Whitespaces im Code durch non-breaking spaces zu ersetzen, war eine ganz schön bescheuerte (wie kam ich eigentlich drauf…?). Diese Ersetzoperation ist jetzt auch rausgeflogen bzw. auskommentiert.

[*schreck* Ich habe gerade einen Bug in meinem getExcerpt-Skript bemerkt, das unklug programmiert ist. Mist, gerade keine Zeit für sowas. Muss warten.]

Ich glaube es zwar selbst kaum, aber ich habe den bisherigen Teil des Tages tatsächlich komplett darauf verwandt, mich mit Regular Expressions herumzuschlagen – und bin letztlich mit wenigen Ausnahmen wieder beim Skriptansatz von gestern gelandet.

Einigermaßen zufrieden bin ich allerdings trotzdem. Das Skript kann hier (leider nicht mehr) als Textdatei eingesehen werden. Hier hingegen wird (leider nicht mehr) das angehübschte Skript gezeigt. Falls ich das Skript weiterentwickele, aktualisiere ich die Dateien ebenfalls.

Wie zu erkennen ist, ersetze ich einige Elemente per str_replace und andere mittels preg_replace. Der Mausereignis-Handler on () zum Beispiel würde – als Keyword in $arCommands untergebracht und mit str_replace verarbeitet – dazu führen, dass die zwei Buchstaben “on” überall, wo sie auftreten(!), in blau angezeigt werden würden, also auch in Kommentaren oder in Funktionsnamen. Anhand des Trace-Strings ist zu sehen, dass das “on” dort nicht hervorgehoben wird.
Mir ist klar, dass das Syntax Highlighting in Flashs Entwicklungsumgebung um einiges intelligenter arbeitet und dass ich theoretisch für alle Keywords RegEx verwenden sollte, aber naja.

Die Anpassung der Farbwerte (z.Zt. nur zwei verschiedene, grün und blau) ist einfach durch eine entsprechende Änderung der zwei Variablen $makeBlue1 und $makeGreen1 zu bewerkstelligen.

Ferner ist zu erkennen, dass ich längst nicht alle ActionScript-Keywords in den zwei Arrays untergebracht habe, die die farbige Hervorhebung regeln. Stefkos Vorschlag, diese in externen Dateien zu lagern, ist sehr gut. Dennoch muss ich noch darüber nachdenken, wie weit ich diese Code Beautification treiben will, geht es doch nur um ein paar gelegentliche Codeschnipsel hier im WeBlog…

Ich habe noch keinen Schimmer, wie ich Kommentare (mehr- oder einzeilig) verschönere, also beispielsweise in grau anzeigen lasse. Ich kann zwar nach /* und */ suchen lassen, aber wie ich den Bereich dazwischen zu fassen bekomme, um ihn nach erfolgreichem Fund verändert anzuzeigen, geht zumindest momentan noch über meinen Horizont (Pattern als Ansatz: /\/\*.*\*\//).

Aufgrund eigenen Bedürfnisses, das durch einen Kommentar an anderer Stelle durch Marcello noch verstärkt wurde, habe ich mir heute mal erste Gedanken zum Thema Syntax Highlighting oder Code-Darstellungsverschönerung gemacht. Es geht um die Zeilen Code, die ich hier im WeBlog veröffentliche. Befehle, Methoden, Eigenschaften und dergleichen sollen farblich hervorgehoben werden, um die Lesbarkeit zu erhöhen.

Mein erster Versuch ist mega-unelegant, selbst für einen PHP-Neuling wie mich, und zeitigt auch nicht das gewünschte Ergebnis. Im wesentlichen habe ich in einem Array die Keywords abgelegt, die gehighlighted werden sollen (z.B. onClipEvent oder _xmouse), und im einem zweiten Array den jeweiligen Ersatzstring (z.B. [font color="#0000FF"] onClipEvent [/font]; HTML-Tag-Klammern ersetzt, da sie sonst hier im WeBlog geparst werden).

Auszug:
$arCommands = array(
“onClipEvent”,
“_x”,
“_xmouse”
);
$arCommandsReplace = array(
“[font color=\"#0000FF\"]onClipEvent[/font]“
}

Mittels str_replace lasse ich dann den an die Funktion beautify ($uglytext)  als String übergebenen “hässlichen” Code durchlaufen und die Keywords ersetzen:

$text = str_replace ($arCommands, $arCommandsReplace, $uglycode);

Die meisten Keywords werden auch wie gewünscht ersetzt, doch eben nicht alle, und das Ergebnis zeigt mir auch, dass die Sache nicht ganz so einfach ist. Ein Beispiel sei genannt: Die beiden Eigenschaften _xmouse und _x werden auch ersetzt - <font color=”#00FFFF”>_x</font>mouse.

Also nur zur Hälfte. Warum? Weil ich in meinem jugendlichen Leichtsinn VOR dem _xmouse-Ersatzstring einen für die Eigenschaft _x im Array definiert habe. Wenn also ein paar Millisekunden nach _xmouse gesucht wird, wird es nicht mehr gefunden, weil es bereits in [HTML]_x[HTML]mouse umgewandelt worden ist.

Gut, Reihenfolge umzudrehen - lange Versionen nach oben - wäre eine Lösung dafür. Aber das ganze Skript ist viel zu lang und plump. Deswegen schaue ich mir jetzt das Thema Reguläre Ausdrücke mal genauer an. Wenn bis 2300 noch etwas dabei herauskommt, landet das Skript hier im WeBlog. Ansonsten manjana…

Ich stand bis eben noch vor dem Problem, dass ich Inhalte eines FMX-Inputfeldes an ein PHP-Skript übergeben und per Mail versenden wollte. Nicht die Datenübergabe hin und her war bockig, sondern die Zeilenumbrüche, die im Inputfeld gesetzt wurden, entfielen in der als text/plain versendeten Email.

Die Umwandlung des User-Kommentarstrings $user_comment mit der folgenden Zeile schaffte Abhilfe, indem der einfache Wagenrücklauf (\r) noch um einen Zeilenvorschub (\n) zu \r\n ergänzt wurde:

str_replace(”\r”, “\r\n”, $user_comment);

Auf gut Deutsch: “Finde alle Vorkommen von “\r” in der Variablen $user_comment und ersetze sie durch “\r\n”.

Mit…

$string = preg_replace(’/\r\n|\r|\n/’, chr(13), $string);

…lässt sich per PHP jedes Vorkommen eines (möglicherweise doppelten) Umbruches in einen einfachen Umbruch verwandeln.