amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Forum und Interna > [ code ] Test-Thread [ - Suche - Neue Beiträge - Registrieren - Login - ]

1 -2- 3 [ - Beitrag schreiben - ]

11.04.2006, 12:46 Uhr

Holger
Posts: 8116
Nutzer
Verstehe. Hat wohl was damit zu tun, welche Schlüsselworte man kennt und auch benutzt/ausprobiert.
Also C/C++ Highlighting sollte schon void erkennen. Und C++ ohne class, public, protected oder private ist kein C++ ;)

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

11.04.2006, 12:49 Uhr

Holger
Posts: 8116
Nutzer
Der Vollständigkeit halber hier noch mal alle C++-Schlüsselwörter

asm auto bool break case catch char class const_cast const
continue default delete double do dynamic_cast else enum
explicit extern float for friend goto if inline int long
mutable namespace new operator private protected public
register reinterpret_cast return short signed sizeof
static static_cast struct switch template this throw
try typedef typeid typename union unsigned using virtual
void volatile wchar_t while


Einmal in den Parser/Highlighter eingebaut, sollte man erstmal ne Weile Ruhe haben...

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

11.04.2006, 12:49 Uhr

_PAB_
Posts: 3016
Nutzer
@Holger:
Nach pOS-Kommentar habe ich Rebol implementiert und dabei selbst die fehlenden C++-Schlüsselworte gesehen - ist daher soeben erledigt worden.
Danke trotzdem für den Hinweis - wenn nochwas fehlt: einfach hier posten.

[ - Antworten - Zitieren - Direktlink - ]

11.04.2006, 13:06 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von _PAB_:
@Holger:
Nach pOS-Kommentar habe ich Rebol implementiert und dabei selbst die fehlenden C++-Schlüsselworte gesehen - ist daher soeben erledigt worden.
Danke trotzdem für den Hinweis - wenn nochwas fehlt: einfach hier posten.


Fällt mir nur die bekannte Schwäche mit dem fehlenden Kontext ein (Literals und Operatoren in Kommentaren, etc.)
C++ code:
// print int values
printf("int: %i, %i, %i, %in", int_array);
// another example
printf("http://www.somesite.org/index%i.htmln", 42);

Willst Du Dich damit selbst beschäftigen oder soll ich versuchen, den Code meines Highlighters zu konvertieren? Da ich noch nie was mit php gemachte habe, ist das vermutlich für mich fast genauso aufwendig, wie für Dich den nicht gerade schön strkturierten JavaScript-Code zu verstehen (bzw. es komplett selbst zu schreiben).

Die Frage ist, wer weniger Zeit für sowas hat ;)

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

11.04.2006, 13:13 Uhr

_PAB_
Posts: 3016
Nutzer
@Holger:
Beim fehlenden Context kann ich derzeit nichts machen - das würde bei weitem zu aufwändig.
Ich arbeite derzeit nur mit Schlüsselworten und Sonderzeichen sowie einfache String-/Zahl-Erkennung.

[ - Antworten - Zitieren - Direktlink - ]

11.04.2006, 17:56 Uhr

Holger
Posts: 8116
Nutzer
@_PAB_:
Sieht der Code immer noch so aus?
Oder hat er sich schon deutlich verändert?
Vielleicht finde ich ja doch ein bisserl Zeit...

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

11.04.2006, 18:47 Uhr

_PAB_
Posts: 3016
Nutzer
@Holger:
Der derzeitige PHP-Code ist hier zu finden:
http://www.amiga-news.de/forum/thread.php?id=20908&BoardID=2#207489

[ Dieser Beitrag wurde von _PAB_ am 11.04.2006 um 19:02 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

23.04.2006, 18:47 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von _PAB_:
@Holger:
Der derzeitige PHP-Code ist hier zu finden:
http://www.amiga-news.de/forum/thread.php?id=20908&BoardID=2#207489

Ich hab den code mal überarbeitet bei unveränderter Funktionalität, sprich,
das Kontext-Problem ist immer noch vorhanden. Dafür sind viele Ausdrücke
aufgeräumt und diverse Fehler korrigiert.

Auf den ersten Blick scheint die Gleichbehandlung verschiedener Sprachen
bezüglich gemeinsamer Schlüsselwörter eine nützliche Optimierung zu sein.
Auf den zweiten ist der Verlust an Übersicht untragbar, weil man immer
sämtliche Sprachen im Überblick haben muß (wer kennt schon alle?), um
Fehler zu suchen. Und selbst dann findet man nicht wirklich alle.

Im Endeffekt wurden bei allen Sprachen falsche keywords angenommen und
andere fehlten...

Deshalb habe ich für jede Sprache eine eigene Liste von Keywords eingebaut
und für C, C++, Java, Php, Perl aus entsprechender Dokumentation entnommen,
allerdings für Perl und Php abgespeckt, weil es einfach zu viele sind.

Basic und Rebol habe ich erst mal nicht angefaßt.

Bevor ich was am Kontext mache, habe ich allerdings eine wichtige Frage:
basiert das aktuelle Feature, daß [i] etc nicht interpetiert werden, auf
dem Fakt, daß [ als Separator hervorgehoben wird?
In dem Fall wäre es ja problematisch, wenn es innerhalb von Kommentaren
oder Strings nicht mehr hervorgehoben wird.
Würde es funktionieren, wenn an dieser Stelle ein Backslash eingefügt wird?

(Ich hab ja den Rest vom AN-Forum Skript nicht zur Hand, um das selber
herauszufinden...)

Tests und entspr Feedback sind natürlich willkommen, am Besten, bevor ich
den nächsten Schritt mache.

mfg

Meine ersten Gehversuche in PHP...
php code:
// define style here
$keyword = '[blue][b]${1}[/b][/blue]';
$libfunc = '[blue]${1}[/blue]';
$literal = '[green]${1}[/green]';
$preproc = '[red]${1}[/red]';
$comment = '[gray]${1}[/gray]';
$op_sep  = '[black]${1}[/black]';

// end of artistic part, now the worker

while (preg_match ("/^(.*?)\s*[code language="?([^"]*)"?\]\s*(.*?)\s*\[\/code\]\r?\n?(.*?)$/is", $out, $matches)) {
  $lang = $matches[2];
  $code = $matches[3];
  $code = str_replace ("[", "[", $code);
  $code = html_entity_decode ($code);
  //sgml document & html declaration tags
  if (preg_match ("/^(X?HTML|PHP|ASP|HSC|JSP)$/i", $lang)) {
    $keywords ="a|abbr|acronym|address|applet|area|b|base|basefont";
    $keywords.="|bdo|big|blockquote|body|br|button|caption|center";
    $keywords.="|cite|code|col|colgroup|dd|del|dfn|dir|div|dl|dt|em";
    $keywords.="|fieldset|font|form|frame|frameset|h[1-6]|head|hr";
    $keywords.="|html|i|iframe|img|input|ins|isindex|kbd|label";
    $keywords.="|legend|li|link|map|menu|meta|noframes|noscript";
    $keywords.="|object|ol|optgroup|option|p|param|pre|q|s|samp";
    $keywords.="|script|select|small|span|strike|strong|style|sub";
    $keywords.="|sup|table|tbody|td|textarea|tfoot|th|thead|title";
    $keywords.="|tr|tt|u|ul|var";
    $code = preg_replace ("/((?:[\[\]{}(),;=+\:.@~|^%&]|(?<![\/*])\/(?![\/*]|(?:${keywords})>)|(?<!\/)\*(?!\/))+)/i", $op_sep, $code);
    $code = preg_replace ("/(<!--.*?-->)/s", $comment, $code);
    $code = preg_replace ('/(<!w[^>]*+>)/s', $comment, $code);
    $code = preg_replace ('/(<?w[^>]*?>)/s', $comment, $code);
    $code = preg_replace ('/(?<=<\/)('.$keywords.')>/is', $keyword.'>', $code);
    $code = preg_replace ('/<('.$keywords.')b(?=[^>]*+>)/is', '<'.$keyword, $code);
    $code = preg_replace ("/([!?<>-]+)/", $op_sep, $code);
  } else
  // all operators and separators (excludes e.g.  $ ' " _)
  $code = preg_replace ("/((?:[\[\]{}()<>,;=+\-?:.@!~|^%&]|(?<![\/*])\/(?![\/*])|(?<!\/)\*(?!\/))+)/", $op_sep, $code);
  //c-style comments
  if (preg_match ("/^(C(\+\+)?|Java|Javascript|PHP|JSP)$/i", $lang)) {
    $code = preg_replace ("/(\/\/[^rn]*)/s", $comment, $code);
    $code = preg_replace ("/(\/\*.*?\*\/)/s", $comment, $code);
  }
  // C and C++
  if (preg_match ("/^(C(\+\+)?)$/i", $lang)) {
    //preprocessor
    $code = preg_replace ("/^(\s*+\#(?:include|define|ifdef|endif|else|pragma))\b/m", $preproc, $code);

    $keywords ="auto|break|case|char|const|continue|default|do|double|else";
    $keywords.="|enum|extern|float|for|goto|if|int|long|register|return";
    $keywords.="|short|signed|sizeof|static|struct|switch|typedef|union";
    $keywords.="|unsigned|void|volatile|while";
    if(preg_match ("/^C\+\+$/i", $lang)) // C++ only
    {
      $keywords.="|asm|bool|catch|class|const_cast|delete|dynamic_cast";
      $keywords.="|explicit|friend|inline|mutable|namespace|new|operator";
      $keywords.="|private|protected|public|reinterpret_cast|static_cast";
      $keywords.="|template|this|throw|try|typeid|typename|using|virtual";
      $keywords.="|wchar_t";
    }
    $code = preg_replace ("/\b(".$keywords.")\b/", $keyword, $code);

    $code = preg_replace ("/\b(U?(?:BYTE|WORD|LONG)|[AB]PTR|BOOL|TRUE|FALSE|NULL)\b/", $libfunc, $code);
    if (preg_match ("/^(C\+\+)$/i", $lang)) {
      $code = preg_replace ("/\b(cout|cin|endl)\b/", $libfunc, $code);
    }
  }
  if (preg_match ("/^Java$/i", $lang)) {
    $keywords ="abstract|boolean|break|byte|case|catch|char|class";
    $keywords.="|continue|default|do|double|else|extends|final|finally";
    $keywords.="|float|for|if|implements|import|instanceof|int|interface";
    $keywords.="|long|native|new|package|private|protected|public|return";
    $keywords.="|short|static|strictfp|super|switch|synchronized|this|throw";
    $keywords.="|throws|transient|try|void|volatile|while|assert";
    // the following are reserved but unused
    $keywords.="|goto|const";
    $code = preg_replace ("/\b(".$keywords.")\b/", $keyword, $code);
    $code = preg_replace ("/\b(true|false|null)\b/", $literal, $code);
  }
  if (preg_match ("/^PHP$/i", $lang)) {
    // case insensitive keywords
    $keywords ="array|as|bool|boolean|break|case|compact|continue|count";
    $keywords.="|current|default|define|defined|die|do|double|doubleval";
    $keywords.="|each|echo|else|elseif|empty|end|eregi?(?:_replace)?";
    $keywords.="|eval|exit|extract|float|floatval|for|foreach|function";
    $keywords.="|gettype|if|in_array|include(?:_once)?|int|integer|intval";
    $keywords.="|isset|key|leak|list|list|mail|next|object|pos|prev";
    $keywords.="|print(?:f|_r)?|range|readfile|real|require(?:_once)?";
    $keywords.="|reset|return|serialize|settype|shuffle|sizeof|sleep";
    $keywords.="|(?:nat(?:case)?|u?[ak]?r?)?sort|spliti?|sql_regcase";
    $keywords.="|string|strval|switch|uniqid|unserialize|unset|usleep";
    $keywords.="|var_dump|var_export|virtual|while|preg_(?:match|replace)";
    $code = preg_replace ("/\b(".$keywords.")\b/i", $keyword, $code);
    // case sensitive keywords (constants)
    $keywords ="NULL|PHP_OS|PHP_VERSION|TRUE|FALSE|E_ERROR|E_WARNING";
    $keywords.="|E_PARSE|E_NOTICE|E_CORE_ERROR|E_CORE_WARNING|E_STRICT";
    $code = preg_replace ("/\b(".$keywords.")\b/", $keyword, $code);
    // php script comments, C-style comments are already handled above
    $code = preg_replace ("/(\#[^rn]*)/s", $comment, $code);
  }
  if (preg_match ("/^Perl$/i", $lang)) {
    $keywords ="abs|atan2|bless|caller|chomp|chop|chr|continue";
    $keywords.="|cos|crypt|dbmclose|dbmopen|defined|delete|die";
    $keywords.="|do|dump|each|eval|exists|exit|exp|formline";
    $keywords.="|gmtime|goto|grep|hex|import|index|int|join";
    $keywords.="|keys|last|lc|lcfirst|length|local|localtime|log";
    $keywords.="|map|my|next|no|oct|ord|our|pack|package|pop|pos";
    $keywords.="|push|quotemeta|rand|redo|ref|require|reset";
    $keywords.="|return|reverse|rindex|scalar|shift|sin|sort";
    $keywords.="|splice|split|sprintf|sqrt|srand|study|sub|substr";
    $keywords.="|tie|tied|time|times|uc|ucfirst|undef|unpack";
    $keywords.="|unshift|untie|use|values|wantarray";
    $code = preg_replace ("/\b(".$keywords.")\b/", $keyword, $code);
  }
  if (preg_match ("/^JavaScript$/i", $lang)) {
    $keywords ="as|break|case|catch|class|const|continue|default|delete|";
    $keywords.="do|else|export|extends|finally|for|function|if|import";
    $keywords.="|in|instanceof|is|namespace|new|package|private|public";
    $keywords.="|return|super|switch|this|throw|try|typeof|use|var";
    $keywords.="|void|while|with";
    // the following are reserved but unused
    $keywords.="|abstract|debugger|enum|goto|implements|interface|native";
    $keywords.="|protected|synchronized|throws|transient|volatile";
    $code = preg_replace ("/\b(".$keywords.")\b/", $keyword, $code);
    $code = preg_replace ("/\b(true|false|null)\b/", $literal, $code);
  }
  if (preg_match ("/^(BASIC)$/i", $lang)) {
    $code = preg_replace ("/\b(if|do|else|elsif|end|for|next|repeat|until|wend|while)\b/i", $keyword, $code);
    $code = preg_replace ("/(\bREM\b[^rn]*)/s", $comment, $code);
  }
  if (preg_match ("/^(Rebol)$/i", $lang)) {
    $code = preg_replace ("/\b(any|binary|close|delete|dir|do|error|exists|foreach|forever|function|if|loop|make-dir|modified|not|print|quit|read|reduce|rename|save|send|size|until|wait|write)\b/i", $keyword, $code);
  }
  $code = preg_replace ("/("(?:[^"\n\r\\]*+(?:\\[^\r\n\\]|\\\\)?+)*+")/", $literal, $code);
  $code = preg_replace ("/('[^'\n\r]*+')/", $literal, $code);
  $code = preg_replace ("/(\d+)/", $literal, $code);

  $code = htmlentities ($code);
  $out = $matches[1].'</font><blockquote>'.get_last_font().$lang.' code:</font><hr><font face="Courier New, Courier, monospace" color="#400080"><pre>'.$code.'</pre></font><hr></blockquote>'.get_last_font().$matches[4];
}
// ---- Ohne Syntax-Highlighting
$out = preg_replace ("/[code\]\s*(.*?)\s*\[\/code\]\r?\n?/is", '</font><blockquote>'.get_last_font ().'code:</font><hr><font face="Courier New, Courier, monospace" color="#400080"><pre>${1}</pre></font><hr></blockquote>'.get_last_font(), $out);


--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

25.04.2006, 01:15 Uhr

_PAB_
Posts: 3016
Nutzer
@Holger:
Also was die Überschaubarkeit angeht, ist Dein Code zwar anders und evtl. klarer strukturiert, aber er wird durch die andere Fallunterscheidung auch länger und damit weniger überschaubar.
Ich finde es nimmt sich nichts, ob so oder anders.
Wichtig wäre mir eher, welche Wörter in welcher Sprache noch fehlen bzw. zuviel sind.

Was ich aber sicher übernehmen werde, weil es eine gute Idee ist, das sind die Ersetzungs-Strings mittels Variablen auszulagern, so hat man das zentral.

[ Dieser Beitrag wurde von _PAB_ am 25.04.2006 um 01:19 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

25.04.2006, 12:51 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von _PAB_:
@Holger:
Also was die Überschaubarkeit angeht, ist Dein Code zwar anders und evtl. klarer strukturiert, aber er wird durch die andere Fallunterscheidung auch länger und damit weniger überschaubar.

Ich weiß, noch besser wäre es imho, den code in Funktionen aufzuteilen. Dann könnte man auch Späße wie, JavaScript innerhalb von Html oder Html innerhalb von Java-Dokumentationskommentaren erkennen, implementieren.
Da ich als Ausgangsbasis aber nur Deinen Codeausschnitt habe, der offenbar aus einer größeren Funktion stammt, kann ich das nicht machen.

Für mich ist meine Variante trotzdem übersichtlicher, weil ich die keyword-Listen direkt mit den Spezifikationen vergleichen kann.
Zitat:
Wichtig wäre mir eher, welche Wörter in welcher Sprache noch fehlen bzw. zuviel sind.
Im meinem geposteten Code sind C, C++, Java und JavaScript vollständig. Perl und Php sind abgespeckt, weil die Listen zu groß geworden wären, aber die grundlegenden sind imho vorhanden.
Basic habe ich nicht angefaßt, weil es da zu viele Dialekte gibt. Und von rebol wußte ich erstmal zu wenig.
Zitat:
Was ich aber sicher übernehmen werde, weil es eine gute Idee ist, das sind die Ersetzungs-Strings mittels Variablen auszulagern, so hat man das zentral.
Man könnte das auch noch weiter auslagern, bis hin zu externen Dateien. Allerdings habe ich ja für solche Optionen nicht den restlichen AN-Code.

Ich denke, es wäre auch besser, mehr single-quote strings für regexp zu benutzen, dann braucht man nicht so viele Backslashes. Nur wenn man Variablen integrieren will, sind double-quotes möglicherweise besser, allerdings wenn man sie die meiste Zeit per '.' verbindet...

Du hast die Frage zur [i] Interpretation noch nicht beantwortet. Muß ich Backslashes einführen, wenn ich eckige Klammern innerhalb von Kommentaren nicht mehr schwarz färbe, bzw. funktioniert das Escapen dann überhaupt?

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

25.04.2006, 12:57 Uhr

Holger
Posts: 8116
Nutzer
Mit weiter auslagern meinte ich v a auch die keyword-Listen. Wenn die nicht mehr innerhalb der Funktion stehen, hat man auch nicht mehr das Problem, daß die Funktion durch meine Trennung der Sprachen größer, sprich unübersichtlicher wird.

Ach so, die tags bei Html sind imho auch vollständig.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ Dieser Beitrag wurde von Holger am 25.04.2006 um 12:58 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

25.04.2006, 23:45 Uhr

_PAB_
Posts: 3016
Nutzer
@Holger:
> Du hast die Frage zur [i] Interpretation noch nicht beantwortet.
> Muß ich Backslashes einführen, wenn ich eckige Klammern innerhalb von Kommentaren nicht mehr schwarz färbe, bzw. funktioniert das Escapen dann überhaupt?

Du müßtest mit dem Backslash escapen, die [ wird dann in ein "[\;" umgewandelt und nach dem Syntax-Highlighting wieder zurück konvertiert. Es darf also etwas wie "[\;" an dieser Stelle auch nicht angefaßt werden. (Einfach diese seltsame Schreibweise ignorieren, ich mußte mir was aus den Fingern saugen, was eindeutig ist und nicht mit etwas anderem kollidiert.)
Das sollte aber wohl gewährleistet sein, wenn Du innerhalb von Kommentaren alles Highlighting abstellt.

Eine Auslagerung in Funktionen müßte problemlos für Dich machbar sein.
Du kannst neue Funktionen deklarieren - der restliche Code mache die bekannten Smilies, Schriftvarianten usw. - ist keine Zauberei, nur eine ellenlange Liste mir Regexps.

[ Dieser Beitrag wurde von _PAB_ am 25.04.2006 um 23:50 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

26.04.2006, 01:20 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von _PAB_:
Du müßtest mit dem Backslash escapen, die [ wird dann in ein "[\;" umgewandelt und nach dem Syntax-Highlighting wieder zurück konvertiert. Es darf also etwas wie "[\;" an dieser Stelle auch nicht angefaßt werden. (Einfach diese seltsame Schreibweise ignorieren, ich mußte mir was aus den Fingern saugen, was eindeutig ist und nicht mit etwas anderem kollidiert.)
Das sollte aber wohl gewährleistet sein, wenn Du innerhalb von Kommentaren alles Highlighting abstellt.

Hmm, mir geht's ja darum, was ich während des Syntax-Highlightings machen muß, das, was evtl. vorher passiert, hilft da ja nicht.
Es muß nur so sein, daß hinterher keine Audrücke in eckigen Klammern ungewollt in Html-Code umgewandelt werden.

Wie gesagt, momentan passiert das von selbst, da durch das Schwarzfärben keine Audrücke, die zufällig mit Formatierungscodes übereinstimmen, mehr existieren können. Wenn schon vorher [ Kombinationen in &‌#91; umgewandelt werden, müßte ich also im Syntax-Highlighting im Bedarfsfall auch [ in &‌#91; umwandeln.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

26.04.2006, 13:49 Uhr

_PAB_
Posts: 3016
Nutzer
@Holger:
Ich dachte eigentlich, ich hätte mich klar ausgedrückt:
> Du müßtest mit dem Backslash escapen, die [ wird dann in ein "[\;"
> umgewandelt und nach dem Syntax-Highlighting wieder zurück konvertiert.

Jetzt sehe ich, was man vielleicht falsch verstehen könnte:
mit "nach dem Syntax-Highlighing" meinte ich eigentlich "nach der kompletten Konvertierung".

Ein einfaches Escapen der [ in Kommentaren reicht aus, allerdings mußt Du zusätzlich für die schon ge-escapten und in "[\;" umgewandelten [ darauf achten, daß Du diese Zeichenkette "[\;" nicht irgendwo anders zerstörst.

Von "&‌#91;" hatte ich übrigens nichts geschrieben...

[ Dieser Beitrag wurde von _PAB_ am 26.04.2006 um 13:51 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

26.04.2006, 17:06 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von _PAB_:
Ein einfaches Escapen der [ in Kommentaren reicht aus, allerdings mußt Du zusätzlich für die schon ge-escapten und in "[\;" umgewandelten [ darauf achten, daß Du diese Zeichenkette "[\;" nicht irgendwo anders zerstörst.

Von "&‌#91;" hatte ich übrigens nichts geschrieben...


Mißverständnis, Du meinst also wirklich diese Zeichensequenz mit dem Doppelbackslash? Ich versteh immer noch nicht ganz, wo die herkommt.

Wenn der Ersetzungsprozeß, der "[" in "[\;" umwandelt, erst *nach* dem Syntax-Highlighting stattfindet, warum muß ich dann die Existenz etwaiger "[\;"-Sequenzen berücksichtigen?

Wenn er dagegen vorher stattfindet, wieso kann ich dann "[" benutzen, wenn der Code danach die Substitute "[\;" erwartet?

Findet die Ersetzung von "[" in "[\;" nun vor oder nach dem Syntax-Highlighting Part statt?
Oder meinst Du noch etwas anderes?

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

27.04.2006, 16:27 Uhr

_PAB_
Posts: 3016
Nutzer
@Holger:
Erstmal: "[\;" enthält im Speicher nur einen einfachen Backslash.
Die escapten [ also [ werden in obiges umgewandelt, sowohl vor wie nach dem Syntax-Highlighting.
Und Du kannst zusätzlich noch [ während des Syntax-Highlightings mit [ escapen, wenn nötig.
Mehr mußt Du nicht beachten.

[ Dieser Beitrag wurde von _PAB_ am 27.04.2006 um 16:28 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

27.04.2006, 16:52 Uhr

Holger
Posts: 8116
Nutzer
@_PAB_:
Verstehe.
Wobei ja innerhalb von [code] das Escapen unnötig geworden ist, bzw. sein soll, weil der Syntax-Higlighter das automatisch macht. D.h. da sollten keine Escapes drin vorkommen, es sei denn, die [ Sequenz ist zufällig entstanden. Da fallen mir aber außer einigen Basic-Dialekten keine Fälle ein, wo das passieren kann.
Als Arbeitsgrundlage ist das jetzt zumind. brauchbar. Jetzt muß ich nur mal wieder ein paar Stunden Zeit finden.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

27.04.2006, 22:31 Uhr

_PAB_
Posts: 3016
Nutzer
@Holger:
Viel Spaß !
;-)

[ - Antworten - Zitieren - Direktlink - ]

30.04.2006, 15:45 Uhr

Holger
Posts: 8116
Nutzer
Also so wird's nix.
In Quelltexten können durchaus auch Folgen von [ vorkommen, z.B. innerhalb eines strings, der einen regulären Ausdruck beinhaltet. Da ich nicht weiß, ob das Forum einen Doppelbackslash als Escape des Backslashes verkraften würde, weiß ich nicht, wie ich da noch ein Unterscheidungsmerkmal einbauen kann.
Vor allem dann nicht, wenn der code wirklich schon vorher umgewandelt wird. Ich könnte jetzt noch die Vorkommen des magischen &...; Ausdrucks ersetzen, aber dann erzeugt das wieder neue potentielle Probleme.

Also am besten nochmal Problem /Zielstellung definieren:
Meine Meinung nach sollten innerhalb von [code] keinerlei Formatierungen interpretiert werden. Demzufolge sollten auch keinerlei Backslashes vor eckigen Klammern interpretiert werden, gibt ja nix zu escapen. Oder anders gesagt: der User soll source-code ohne weitere Nachbearbeitung posten können, und der code soll unverändert (nur bunt) zu sehen sein.

Dazu ein Vorschlag (falls wir bei der obigen Definition einer Meinung sind):
Statt Zeichenfolgen zu benutzen, von denen man nur hoffen kann, daß sie nicht benutzt werden, oder neue Arten von Escapes zu erfinden, können wir innerhalb des Skriptes Ascii-Zeichen außerhalb des erlaubten Bereichs benutzen, z.B. x02 x03 etc.

Diese sollten niemals im Posting selbst vorkommen, man kann sie auch zur Sicherheit gnadenlos am Anfang der Verarbeitung rausfiltern.

Dann sollten zuerst alle Vorkommen von [ im Posting durch z.B. x02 ersetzt werden und ggf. noch weitere Bearbeitungsschritte, z.B. Ersetzen von Backticks durch x03 etc. durchgeführt werden.

Dann gehen [code] Segmente zum Syntax-Highlighter, wo ich (nur innerhalb des code-Teils) die Ersetzungen von [ rückgängig mache, dafür für einfache [ einfüge, zumind. da, wo potentielle Konflikte entstehen könnten.

Dann geht das Posting zur restlichen Verarbeitung inkl. Umwandeln nach Html, und als letzten Schritt werden x02 durch [ ersetzt und ggf die anderen Zeichen, Backtick etc.

Ich müßte nur wissen, welche Umwandlungen vor dem Aufruf des Syntax-Highlighter schon durchgeführt wurden (und diese müssen halt reversibel sein, schon wegen der Eindeutigkeit). Ansonsten ist der Code zu 99% fertig (nicht die Amiga-üblichen 99% ;) )

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

03.05.2006, 00:13 Uhr

_PAB_
Posts: 3016
Nutzer
@Holger:
Irgendwo muß man auch mal eine Grenze ziehen.
Der Aufwand darf den Nutzen nicht übersteigen.
Ein "[" in einem Quelltext ist schon äußerst selten und die eventuelle falsche Darstellung in Kombination mit einem sprachbezogenen Syntax-Highlighting würde ich schon in Kauf nehmen - wenn man solch einen Fall hat, kann man auch getrost auf das [code]-Tag ohne Syntax-Highlighting zurückgreifen.

Von daher brauchen wir keinerlei zusätzliche Sonderbehandlung und Du kannst ein [i] oder ähnliches in einem Kommentar simpel mit einem Backslash escapen, falls es unbedingt sein muß.

[ - Antworten - Zitieren - Direktlink - ]

03.05.2006, 13:13 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von _PAB_:
@Holger:
Irgendwo muß man auch mal eine Grenze ziehen.
Der Aufwand darf den Nutzen nicht übersteigen.

Gewiss doch, aber wo ist da ein höherer Aufwand, wenn Du die Zeichenfolge [ mit "x02" statt "[\;" ersetzt?
Und wenn Du diese Ersetzung nur einmal statt zweimal vornimmst, sinkt der Aufwand statt zu steigen.
Zitat:
Ein "[" in einem Quelltext ist schon äußerst selten
Es kommt so gut wie gar nicht vor. Aber "\[" kommt dafür häufiger vor. Wenn nicht mal die Testprogramme korrekt dagestellt werden, hat's kein Sinn. So soll das Script als Mindestanforderung sich selbst korrekt darstellen können -- kann es inzwischen auch, aber eben nicht, solange die Behandlung der Sequenzen nicht eindeutig ist.
Zitat:
und die eventuelle falsche Darstellung in Kombination mit einem sprachbezogenen Syntax-Highlighting würde ich schon in Kauf nehmen - wenn man solch einen Fall hat, kann man auch getrost auf das [code]-Tag ohne Syntax-Highlighting zurückgreifen.
Dann muß man zum einen immer erst mal ausprobieren, ob das Highlighting funktioniert, zum anderen versagt es also immer genau dann, wenn der source-code komplizierter wird.
Wozu brauch ich es dann noch, wenn es nur bei einfachen code funktioniert, den ich auf einen Blick überschauen kann?
Zitat:
Von daher brauchen wir keinerlei zusätzliche Sonderbehandlung und Du kannst ein [i] oder ähnliches in einem Kommentar simpel mit einem Backslash escapen, falls es unbedingt sein muß.
Und wie escape ich [ ?
Ich will ja nicht, daß ein Backslash aus dem Code verschwindet.
Außerdem stellt \ innerhalb eines Strings eine gültige escape-Sequenz dar, die ich dementsprechend farbig hervorhebe.

Dann steht für die nachfolgende Bearbeitung des Postings also z.B. in dem Text...

Übrigens hast Du in dem Punkt recht, wir brauchen "keinerlei zusätzliche Sonderbehandlung". Mein Vorschlag beinhaltete eine saubere Lösung als Ersatz für die jetzigen Zeichenkombinationen ala "[\;". Für diese wolltest Du eine Sonderbehandlung haben.

Na ja, der Code existiert so weit und ich bin natürlich für jeden Vorschlag offen...

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

05.05.2006, 01:48 Uhr

_PAB_
Posts: 3016
Nutzer
Umgekehrt wird ein Schuh draus :-)
Ich bin für Vorschläge offen und ich verlange keine Sonderbehandlung von irgendwas, wollte Dich nur darauf aufmerksam machen, welche Probleme entstehen könnten.

Was ist denn der Vorteil von "x02" ?
Meinst Du damit das nicht-druckbare ASCII-Zeichen 02 = STX (Start of Text)
oder meinst Du damit die Zeichenfolge, die im Speicher wie oben genannter String aussieht ?

Die Idee mit dem nicht-druckbaren Zeichen, welches dann in der weiteren Syntaxanalyse nicht weiter behandelt wird, gefällt mir eigentlich ganz gut... allerdings würde ich dann ein "x1A" besser finden, da es für Substitute steht.

[ Dieser Beitrag wurde von _PAB_ am 05.05.2006 um 02:03 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

05.05.2006, 14:15 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von _PAB_:
Meinst Du damit das nicht-druckbare ASCII-Zeichen 02 = STX (Start of Text)

Genau das, wobei mir konkrete Werte/Bedeutungen relativ egal waren. Hab halt beim Wertebereich unten angefangen.
Zitat:
Die Idee mit dem nicht-druckbaren Zeichen, welches dann in der weiteren Syntaxanalyse nicht weiter behandelt wird, gefällt mir eigentlich ganz gut... allerdings würde ich dann ein "x1A" besser finden, da es für Substitute steht.
Bild: http://www.math.tu-berlin.de/~pietsch/icon/thumbs.gif
Zitat:
Umgekehrt wird ein Schuh draus :-)
Ich bin für Vorschläge offen und ich verlange keine Sonderbehandlung von irgendwas, wollte Dich nur darauf aufmerksam machen, welche Probleme entstehen könnten.

Potentielle Probleme laufen eben leider oft auf Sonderbehandlungen hinaus. Aber jetzt nähern wir uns ja einer Lösung, die ohne auskommt, denke ich.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

06.05.2006, 14:26 Uhr

_PAB_
Posts: 3016
Nutzer
@Holger:
Ok, also machen wir das so, daß [ durch zwei Substitute-Zeichen ersetzt werden (=ASCII dec 26 / hex 1A).
Der Sinn der Sache ist, daß alle in der Zukunft möglichen Ersetzungen dann durch ein erstes Substitute-Zeichen eingeleitet werden und darauf ein weiteres Zeichen folgt, welches die Art der Ersetzung kennzeichnet.

[ Dieser Beitrag wurde von _PAB_ am 06.05.2006 um 14:30 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

06.05.2006, 14:41 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von _PAB_:
@Holger:
Ok, also machen wir das so, daß [ durch zwei Substitute-Zeichen ersetzt werden (=ASCII dec 26 / hex 1A).
Der Sinn der Sache ist, daß alle in der Zukunft möglichen Ersetzungen dann durch ein erstes Substitute-Zeichen eingeleitet werden und darauf ein weiteres Zeichen folgt, welches die Art der Ersetzung kennzeichnet.


Ok, und als Präzisierung: das Ersetzen von [ passiert möglichst früh in der Verarbeitungskette, sprich, sie hat zum Zeitpunkt des Syntax Highlightings schon stattgefunden.

Ich muß ja dann "x1Ax1A" wieder nach " [" und dann "[" nach "x1Ax1A" konvertieren, damit sich eckige Klammern innerhalb von Source-Code immer wie escaped verhalten.

Und das sollte es dann auch schon gewesen sein...

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

06.05.2006, 16:05 Uhr

_PAB_
Posts: 3016
Nutzer
@Holger:
Du mußt im Syntax-Highlighting nichts weiter machen, als eine [ zu escapen, also in [ zu konvertieren, falls gewünscht.
Alternativ kannst Du auch gleich in zwei Substitutes konvertieren, falls es dadurch für Dich einfacher wird.
Der Rest ist dann meine Aufgabe...

[ - Antworten - Zitieren - Direktlink - ]

07.05.2006, 10:45 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von _PAB_:
Alternativ kannst Du auch gleich in zwei Substitutes konvertieren, falls es dadurch für Dich einfacher wird.


Ja, definitiv. Es geht, wie ich schon zu erklären versucht habe, darum, daß nach dem Syntax-Highlighting in dem Ergebnis [ Kombinationen auftreten können, die keine Escapes sein sollen.
Einfach, weil nach einem Backslash eine Hervorhebung anfängt oder aufhört.

Deshalb muß die Behandlung von Escapes ("[") vor dem Syntax-Highlighting stattfinden, damit ich davon ausgehen kann, daß [ nach dem Highlighting nicht mehr als Escape aufgefaßt wird. Und im Gegenzug muß ich natürlich schon vorhandene Substitutes wie [ behandeln, aber das ist kein Problem.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

07.05.2006, 12:56 Uhr

_PAB_
Posts: 3016
Nutzer
@Holger:
Ich denke, ich hatte Dich schon verstanden...
Die Ersetzung mit den Substitutes ist ab sofort aktiv.
Übrigens muß man nur solche Klammern ersetzen, die zu einem derzeit gültigen BB-Code Tag gehören.

[ Dieser Beitrag wurde von _PAB_ am 07.05.2006 um 13:01 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

07.05.2006, 14:10 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von _PAB_:
Übrigens muß man nur solche Klammern ersetzen, die zu einem derzeit gültigen BB-Code Tag gehören.

Einschl. schließender Tags, vermute ich mal.
Aber ich denke, generelles Ersetzen ist besser, für den Fall, daß die Liste der gültigen Tags sich mal ändert...

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

07.05.2006, 16:41 Uhr

_PAB_
Posts: 3016
Nutzer
@Holger:
Nein, nur öffnende Tags.
Schließende Tags ohne zugehöriges öffnendes Tag werden ignoriert.
Sicherheitshalber kannst Du aber theoretisch auch alle Klammern auf ersetzen, wobei mit das lieber wäre, wenn es nur vorhandene Tags betrifft, da ich die beiden Listen (mittels Such-String) gleichzeitig pflegen kann.

Derzeit sieht mein Code zur Ersetzung von escapten Tags ("[...]") so aus:
PHP code:
$search = "(quote|code[^\]]*|url[^\]]*|email|img|list[^\]]*|item|\*|br|hr|b|i|u|f[12345]|verdana|arial|courier|comic|blue|red|green|yellow|white|gray|black|center)";
$out = preg_replace ("/\\\[(?=\/?${search}\])/is", "x1Ax1A", $out);


[ Dieser Beitrag wurde von _PAB_ am 07.05.2006 um 16:48 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]


1 -2- 3 [ - Beitrag schreiben - ]


amiga-news.de Forum > Forum und Interna > [ code ] Test-Thread [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten.
.