RegEx != RegEx? PHP ereg liefert immer nur REG_BADRPT

[cruiser]

Code:

(^\[|$)

Da die RegEx nicht ungreedy gesetzt ist müsst sie ja per default greedy sein, also sie viele Daten mitnehmen wie geht... also prüfst du nach dem Anfang eines neuen Block oder dem Ende der Zeile...

(ungetestet)

[alcaeus]

Hallo Matthias,

versuch mal das:

Code:

preg_match_all("/^\[code\]([^\[]*?)/msi", $source, $codeParts);

Du suchst einfach alles, was keine [ ist ;)
Du hast dann aber ein Problem, wenn eine eckige Klammer im Text vorkommt ;)

Greetz
alcaeus

[MathiasSimmack]

Zu einfach, :stupid:, den hatte ich schon. Wenn ich das ergänze, dann nimmt er auch Leerzeilen innerhalb der gesuchten Sektion als Ende, und das soll er ja nicht. Sorry, mein Fehler, :oops:, hätte ich erwähnen müssen.

@alca: Kann ich auch nicht machen, ;), da eben auch eckige Klammern innerhalb des Textes vorkommen können.

[cruiser]

Code:

preg_match_all("/^\[code\](.*)(\[?)/msi", $source, $codeParts);

Dann nimm den ;) der ist nun auch getestet ;)


/Edit: aber auch nich so richtig :/ :pale: *hrrrm*

[alcaeus]

Dann bleibt dir wohl nichts anderes uebrig, als die ersten Sektionen mit deiner Regex auszulesen, und die letzte dann anhand der Position der gefundenen Sektionen im Ursprungsstring zu bestimmen.
Das $ matcht in Multiline-Expressions naemlich immer das Zeilenende, das kannst du nicht verhindern. Von daher gibt es afair keinen gesunden Weg, das Stringende zu bestimmen ;)

Greetz
alcaeus

[MathiasSimmack]

\Z oder \z müsste korrekt sein, wenn ich nicht irre. Zumindest funktioniert die Idee. Ich habe noch einen Bug drin, aber der hat mit einer anderen Sache zu tun :mrgreen:.

[MathiasSimmack]

Klappt. Ich habe fertig. :stupid: Ich habe gerade eine Miniklasse für einen zweiteiligen Inno Setup-Highlighter geschrieben. Der nutzt GeSHi, formatiert aber Skript- und Pascalteil separat. Darum die Auftrennung der

Zitat:

Datei mit INI-ähnlichen Sektionen

:zwinker: Es gibt nämlich einige Schlüsselworte der anderen Sektionen (FileName, usw.), die ich persönlich auch manchmal als Variablennamen in der [Code]-Sektion nutze. Und die sollten da natürlich nicht als Schlüsselwort formatiert werden.

Also, herzlichen Dank an alle Mitwürgenden. :mrgreen:

[cruiser]

/Edit: zu viel probiert und nicht mitgelesen, vergesst es :/

[MathiasSimmack]

Wieso? Ich habe noch eine Kleinigkeit gefunden. Wenn unmittelbar hintereinander zwei [Code]-Sektionen folgen, ignoriert er die zweite. Folgen gleich drei [Code]-Sektionen aufeinander, ignoriert er die mittlere. :gruebel:

[MathiasSimmack]

Damit geht es

Code:

"/^\[code\](.*?)(^\[[^code]|\Z)/msi"

:stupid:


Jetzt benötige ich nur noch eine Möglichkeit, Kommentare und Prä-Prozessor-Anweisungen zu finden, die sich direkt am Dateianfang befinden. Das gehört aber mehr zu GeSHi. Die folgenden Zeilen werden bspw. so formatiert:

Code:

; Kommentar
[color=red]#define ISPP "bla"[/color]

Dreh ich es um, würde die ISPP-Anweisung schwarz sein, und der Kommentar gefärbt werden. Füge ich am Anfang eine Leerzeile ein, dann wird beides korrekt gefärbt. Ich schätze, dass hier irgendwo das Problem liegt:

Code:

2 => array(
   GESHI_SEARCH => '^;.*$',
   GESHI_REPLACE => '\\0',
   GESHI_MODIFIERS => 'm',
   GESHI_BEFORE => '',
   GESHI_AFTER => ''
)

btw, COMMENT_SINGLE (stellt GeSHi für Zeilenkommentare zur Verfügung) kann ich nicht nutzen. Ich habe auch nicht mehr daran gedacht, dass das Semikolon auch als Trennzeichen in den einzelnen Sektionen benutzt wird. Man hat mich daran erinnert. ;) Folglich würde alles hinter einem Semikolon als Kommentar miss-interpretiert werden.

Code:

[Files]
Source: "bla.exe"[color=green]; DestDir: "{app}"[/color]

Darum der Umweg über reguläre Ausdrücke.