Suche Informationen über -- Text - lexer - parser --

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

BlackJack, danke für das Feedback und die Tipps.

lg

EDIT:
BlackJack hat geschrieben:
Mr_Snede hat geschrieben:Kann es sein, dass es unter Python2.5 (debian etch) den SimpleXMLWriter nicht gibt?
Wenn man ihn nicht installiert, dann nicht. :-)
What? Unter Windows wird das bei dem Python2.5 Binary mit dabei.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

sape hat geschrieben:
BlackJack hat geschrieben:
Mr_Snede hat geschrieben:Kann es sein, dass es unter Python2.5 (debian etch) den SimpleXMLWriter nicht gibt?
Wenn man ihn nicht installiert, dann nicht. :-)
What? Unter Windows wird das bei dem Python2.5 Binary mit dabei.
Komisch, ich kann mich auch nicht erinnern, dass der jemals bei Python mitgeliefert wurde.

Habe auch Belege dafür. Vielleicht wird der Rest von ElementTree auch noch aufgenommen, aber erst später (also nicht in Python 2.5) - wie Effbot selbst sagt.

Und dass SimpleXMLWriter in Python 2.5 für Windows dabei ist, scheint mir aber auch recht seltsam zu sein, wenn MvL meint, dass der nicht dabei ist. Schließlich baut er ja die Windows-Builds, wenn ich richtig informiert bin.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Benutzeravatar
Mr_Snede
User
Beiträge: 387
Registriert: Sonntag 8. Februar 2004, 16:02
Wohnort: D-Dorf, Bo

Bei debian Etch ist in Python2.5 folgendes enthalten.

Code: Alles auswählen

/usr/lib/python2.5/xml/etree/ElementInclude.py
/usr/lib/python2.5/xml/etree/ElementPath.py
/usr/lib/python2.5/xml/etree/ElementTree.py
/usr/lib/python2.5/xml/etree/__init__.py
/usr/lib/python2.5/xml/etree/cElementTree.py
Ich dachte SimpleXMLWriter wäre ein Bestandteil von elementtree :

Code: Alles auswählen

ImportError: No module named elementtree.SimpleXMLWriter
@ Jens
Die Überschriften in "=" einzubetten, wird in vielen Wikiengines verwendet (moin, dokuwiki, trac, ...) ich finde es auch recht Bildhaft.
h1. Überschrift
h2. Überschrift
Ist mir zu nahe an einer wirklichen Programmiersprache das gefält mir als Wikisyntax nicht.

Listen sind bis jetzt wie in Moin(oder Dokuwiki, nur das hier eine Einrückungsebene aus 2 Leerzeichen besteht) geplant:

Code: Alles auswählen

 * tolle Liste
  * super Unterpunkt
  * noch besserer Unterpunkt
   * weil richtig weit eingerückt, der beste Unterpunkt
 * bla
 * blub
Wobei ich beim Schreiben der dauCMS Doku festgestellt habe, dass der Spiegelstrich anstelle des Asterix im Wikitext viel besser aussieht.
Aber es ist ja kein Problem beides zu implementieren.

Die Aktuelle Linksyntax entstammt Entes ersten Versuchen.Wir haben schon gesprochen die Syntax gegen die von moin auszutauschen. Da Ente aber diese Syntax schon umgesetzt hatte und wir gerne so weit kommen wollten, mit dauCMS Seiten zu erstellen, haben wir es vorerst dabei gelassen.
Also geplant ist etwas in diese Richtung:

Code: Alles auswählen

[http://www.python-forum.de/posting.php das deutsche Pythonforum] 
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Mr_Snede hat geschrieben:
h1. Überschrift
h2. Überschrift
Ist mir zu nahe an einer wirklichen Programmiersprache das gefält mir als Wikisyntax nicht.
Textile macht das genau so.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Benutzeravatar
Mr_Snede
User
Beiträge: 387
Registriert: Sonntag 8. Februar 2004, 16:02
Wohnort: D-Dorf, Bo

Leonidas hat geschrieben:
Mr_Snede hat geschrieben:
h1. Überschrift
h2. Überschrift
Ist mir zu nahe an einer wirklichen Programmiersprache das gefält mir als Wikisyntax nicht.
Textile macht das genau so.
Daher der Vorschlag vom Jens
Jens hat geschrieben:Die komplette tinyTextile Syntax: http://pylucid.org/index.py/TinyTextileExample/
Aber ehrlich gesagt finde ich die Textile Syntax zum Schreiben und Lesen mehr als sperrig.
Aber ich werde mal seinen Code für die Listen anschauen.

@ Jens
Du hattest ja schon früher mal eine Zusammenarbeit vorgeschlagen.
Ich denke so langsam haben Ente und ich uns in einige Themen eingearbeitet. Womit wir auch wirklich was beitragen könnten.

Zumindest beim Lexer / Parser könnten wir uns mal zusammensetzen.
Einen Kern, der unterschiedliche Wikisyntax parsen kann, wäre schon toll. Sozusagen Syntaxplugins.

So nu gehts aber ab inne Poofe sonst bin ich morgen schon wieder übermüdet :-(
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Mr_Snede hat geschrieben:Listen sind bis jetzt wie in Moin(oder Dokuwiki, nur das hier eine Einrückungsebene aus 2 Leerzeichen besteht) geplant:

Code: Alles auswählen

 * tolle Liste
  * super Unterpunkt
  * noch besserer Unterpunkt
   * weil richtig weit eingerückt, der beste Unterpunkt
 * bla
 * blub
Kann es sein, das bei moin die Anzahl der Leerzeichen zur Einrückung egal ist? Das wäre mir im Grunde am liebsten. Meine tinyTextile Listen gefallen mir nicht mehr so.
Bei den Links sind wie ja schon zusammen. Wobei, ich hab noch interne Links, die momentan so aussehen [[ShortCut]]. Dabei fehlt z.Z. aber noch der Link-Text. Ich weiß noch nicht so genau was besser ist: [[ShortCut Link Text]] oder wie die anderen Links: [ShortCut Link Text]

Also bei den Überschriften, finde ich gerade gut, das sie näher an html liegen. bei den == Headline == ding, hab ich zwei Dinge auszusetzten: Zum einen ist es unnötig den Tag wieder zu schließen. Es würde IMHO reichen:
== Headline 1
=== Headline 2
Außerdem ist mir beim bearbeiten des Python Wikis aufgefallen, das man hin und wieder den Überblick verliert, welche Überschriftsebene man gerade hat. Da sind absolute Zahlen hilfreicher.

Im Grunde ist die Syntax ja recht gleich. Ist die Frage, ob wir nicht alles zusammen unter einem Hut bekommen. Also das wir einen Parser haben, der beide Überschrift-Varianten umsetzten kann.

Wobei, haben wir dann noch einen Unterschied zum moin Wiki Sytnax?

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

Leonidas hat geschrieben:[...]
Und dass SimpleXMLWriter in Python 2.5 für Windows dabei ist, scheint mir aber auch recht seltsam zu sein, wenn MvL meint, dass der nicht dabei ist. Schließlich baut er ja die Windows-Builds, wenn ich richtig informiert bin.
Ups, ich dachte er meintet generell den ET. Sorry mein Fehler.
jens hat geschrieben:[...]Wobei, haben wir dann noch einen Unterschied zum moin Wiki Sytnax?[...]
Die Frage sollte eher lauten ob der Unterschied so gravierend ist und eine Eigene Wiki-Syntax rechtfertigen würde? Welchen vorteil hätte eure Syntax, die nicht auch z.B. die Syntax von dem trac hat oder, oder?
Benutzeravatar
Mr_Snede
User
Beiträge: 387
Registriert: Sonntag 8. Februar 2004, 16:02
Wohnort: D-Dorf, Bo

jens hat geschrieben:Kann es sein, das bei moin die Anzahl der Leerzeichen zur Einrückung egal ist? Das wäre mir im Grunde am liebsten.
Ja: http://wiki.debianforum.de/WikiSandkasten --> Einrückungstiefe Listen

ist ja nicht auch wirklich dumm ;-)
jens hat geschrieben: Bei den Links sind wie ja schon zusammen. Wobei, ich hab noch interne Links,
Stehen bei uns weit oben auf der Todo Liste. Haben wir irgendwie vergessen zu implementieren.
jens hat geschrieben:die momentan so aussehen [[ShortCut]]. Dabei fehlt z.Z. aber noch der Link-Text. Ich weiß noch nicht so genau was besser ist: [[ShortCut Link Text]] oder wie die anderen Links: [ShortCut Link Text]
Ich hätte gerne, dass sie möglichst nahe an der Syntax für externe Links sind.
Ich bin kein Freund von CamelCase.
[intern:dateiname Link Text]
oder:
[Wiki:dateiname Link Text]
würden mir gefallen.
jens hat geschrieben: Also bei den Überschriften, finde ich gerade gut, das sie näher an html liegen.
Wikisyntax finde ich deswegen so gut, weil man von dem html weg kommt. Dein Ansatz ist nur dann schlüssig, wenn man weiß. wie eine Überschrift in html deklariert wird. Ansonsten ist es einfach nur eine eher kryptische Abkürzung.
jens hat geschrieben:bei den == Headline == ding, hab ich zwei Dinge auszusetzten: Zum einen ist es unnötig den Tag wieder zu schließen. Es würde IMHO reichen:
== Headline 1
=== Headline 2
Außerdem ist mir beim bearbeiten des Python Wikis aufgefallen, das man hin und wieder den Überblick verliert, welche Überschriftsebene man gerade hat. Da sind absolute Zahlen hilfreicher.
Ich finde das Einschließen in "=" sehr Übersichtlich, dadurch kann man die Struktur einer Langen Textseite schneller überblicken als bei dem von dir favorisierten Ansatz.
jens hat geschrieben: Im Grunde ist die Syntax ja recht gleich. Ist die Frage, ob wir nicht alles zusammen unter einem Hut bekommen. Also das wir einen Parser haben, der beide Überschrift-Varianten umsetzten kann.
Bei so wenig Unterschied könnte das wirklich praktikabel sein.
jens hat geschrieben: Wobei, haben wir dann noch einen Unterschied zum moin Wiki Sytnax?
Der ist nahezu Null.
AAAAber (das gibt es immer oder?)
''betont (kursiv)''
'''fett'''
Finde ich fürchterlich. Die zwei Auszeichnungen, die man am häufigsten verwendet sind beim Drüberlesen im Wikitext und beim Schreiben gelinde gesagt subobtimal.
//betont (kursiv)//
**fett**
Eignet sich da echt beser.
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Mr_Snede hat geschrieben:Ich bin kein Freund von CamelCase.
[intern:dateiname Link Text]
oder:
[Wiki:dateiname Link Text]
würden mir gefallen.
Zusätzliche Angaben, wie "intern:" und "Wiki:" würde ich vermeiden. Bei PyLucid gibt es im Grunde auch nur die Internen Shortcuts, oder externe Links, mehr nicht.

Die eigentlichen ShortCuts sind ehr interne Angaben. Daraus bilden sich die URLs. Ich möchte keine URLs haben, in der Sonder-/Leerzeichen escaped werden. Deswegen habe ich die Shortcuts eingefügt. Diese leiten sich aus den Seiten-Titeln ab:

Code: Alles auswählen

unicode test -> .../UnicodeTest/
v0.7.2 Ticket List -> .../V072TicketList/
<lucidTag:search/> -> .../LucidTagSearch/
Natürlich ist diese Automatische Konvertierung nicht immer treffend. Aber theoretisch kann der User die Shortcuts auch frei wählen.



Mr_Snede hat geschrieben:
''betont (kursiv)''
'''fett'''
Finde ich fürchterlich. Die zwei Auszeichnungen, die man am häufigsten verwendet sind beim Drüberlesen im Wikitext und beim Schreiben gelinde gesagt subobtimal.
//betont (kursiv)//
**fett**
Eignet sich da echt beser.
Ja, dabei mag ich die moin Syntax auch überhaupt nicht. Ich hab dafür:

Code: Alles auswählen

ein --kleines-- Wort mit small-Tag
ein *fettes* Wort mit strong-Tag
Wobei zwei Zeichen vielleicht besser sind. Also dann doch so:

Code: Alles auswählen

//kursiv//
**fett**
--klein--
Damit stimmen wir in den Punkt vollkommen überein ;)

Vielleicht sollten wir wirklich aus Pygments den RegexLexer nehmen und anpassen, siehe: http://www.python-forum.de/topic-9408.html
Das Endergebnis sollte dann so flexibel sein, das es für uns beide funktioniert. :lol:

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
Mr_Snede
User
Beiträge: 387
Registriert: Sonntag 8. Februar 2004, 16:02
Wohnort: D-Dorf, Bo

Bei
ein --kleines-- Wort mit small-Tag
denke ich eher an durchgestrichenen Text als an Kleinen.

Aber schön, dass es im Grunde nur um Details geht.
Zur (lokalen)Link Syntax werde ich mir mal ein paar Gedanken machen.

Den Thread zu aus Pygments / RegexLexer werde ich mir mal zu Gemüte führen.


Jens hat ne PN
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

@Mr_Snede: Ist das ursprüngliche Thema von EnTe nicht mehr aktuell?! Bin nämlich fertig geworden (Noch ein par Schönheitsfehler ausbessern).
EnTeQuAk
User
Beiträge: 986
Registriert: Freitag 21. Juli 2006, 15:03
Wohnort: Berlin
Kontaktdaten:

@Mr_Snede: Ist das ursprüngliche Thema von EnTe nicht mehr aktuell?! Bin nämlich fertig geworden (Noch ein par Schönheitsfehler ausbessern).
Ab heute wieder extremst aktuell! ;) bin nämlich wieder aus dem Urlaub zurück und kann alle Lösungen in meiner Urlaubswoche (die folgende) mal richtig ausprobieren.

Ich bin extremst interessiert, an deiner Errungenschaft.

@Mr_Snede:
Danke, für die Vertretung :)

@Jens:

Wie Mr_Snede schon gesagt hat. dauCMS wächst und ich habe ja auch gesagt, das mit 0.1 oder 0.2 dauCMS auf PyLucid als Plugin portiert wird.
Das wird allerdings noch einige Zeit beanspruchen, da ich denke, das dauCMS ansich erstmal ein wenig reifen muss (Parser, Lexer etc.)

@Alle zusammen:

DANKE! :)

So nu ab an die Arbeit und alles hier mal auseinander nehmen.
Ich habe den Thread komplett durchgelesen, spare mir aber Kommentare, auf einzelne Sachen. wenn wichtig baue ich sie später mal in die Posts ein :D

MfG EnTeQuAk
EnTeQuAk
User
Beiträge: 986
Registriert: Freitag 21. Juli 2006, 15:03
Wohnort: Berlin
Kontaktdaten:

So... lang lang ists her, das ich wieder was mit Python machen konnte.

Ich habe da auch glatt mal die Nacht durchgemacht und mir etwas gebastelt.

Es ist mehr simpel, als alles andere. Dafür aber sehr flexibel...

Der Gedanke ist folgender:

es gibt eine regex, auf die der Text hin durchsucht wird.
Wird getroffen, wird dieser Text an eine Funktion

Code: Alles auswählen

func = '_' + regexgroupname + '_replacer'
weitergegeben

Mit diesem Text kann die Funktion machen, was sie will...
Im Enddefekt sollte sie aber den ersetzten String zurückgeben ;)

Das ganze schaut im Moment so aus: http://daucms.de/trac/browser/dauCMS/tr ... py?rev=201

Nun ja... ich überlege, ob an die Funktionen der 're.match' weiter gegeben werden sollte... denn wie man z.B. an der 'dauurl_replacer'-Funktion sieht, muss die Funktion den Text dann immernoch selber komplett auseinander nehmen. So wird teilweise überflüssiger Quellcode produziert.


Ich bin aber trotzdem mal auf sape's Parser gespannt.

Meine Version ist übrigens aus BlackJacks Version hervorgegangen, als ich diese einfach mal komplett entschlackt habe und alles entfernt habe, was nur zu entfernen war ;)

Wie mein Parser Performancetechnisch abschneidet... kA... muss noch getestet werden. Es ist immo mehr ne Idee, als alles andere.


MfG EnTeQuAk
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

Tjoa...erstmal vorweg:
Der Lexer Funktioniert soweit. Auch die Generierung des Ast funktioniert soweit (Wenn auch mit ein wenig Fehlern das sich aber auf den Output nicht auswirkt und nur kosmetischer Natur sind). Der Code von mir ist...naja...Suboptimal, kompliziert und schlecht zu warten :-[ Naja, ich weiß jetzt was ich nächstes mal anders machen werde. :mrgreen:

Ich denke mal die Laufzeit ist auch nicht besonders gut bei größeren Projekten.


Das wichtigste ist aber, das ein AST bei diesem Fall total Sinnfrei ist (Wusste ich vorher nicht.):
  • Die Source wird zum Lexer geschickt der automatisch einen Tokenstrom erzeugt (Ausgab sieht so aus wie im Thread gepostet).
    • ``dlex = DaucmsLexer(src)``
    • über delx kann man dann iterieren um sich Zeile für Ziele des streams auszugeben, oder man kann wie bei einer Liste mit [] drauf zurückgreifen.
  • Als nächstest wird ein AST erzeugt mit ``ast = generate_ast(dlex)``
    • Tjoa, um nun den AST in ein anderes Format zu überführen, gibt es eine Funktion die aus dem AST wider ein Tokenstrom erzeugt, dem ``dlex`` ähnelt - Betonung liegt auf ähnelt - (Das habe ich der einfachheitshalber so gewählt, weil der Zugriff auf einen AST nicht ganz trivial ist bzw. ich auch noch nicht in der Lage bin einen AST zu machen der Leicht zu handhaben ist.). ``ast_to_token_stream(ast)``. Darüber wird iteriert und soweiter. Ein beispiel ist in ``test_daucms2bbc.py`` drin, das zeigt wie man daraus BBCode macht.
  • Das Sinnfreie ist an dieser Geschichte nun, das man sich den AST eigentlich gleich sparen könnte und lieber gleich den Strom von ``dlex`` abfragt :roll: Das Ergebnis ist das gleiche.
Mein FAZIT: Nimm BlackJacks Variante. Die ist Kurz, sehr Performant, gut zu warten und anpassbar und durch seinen Code steigt man auch nach einem halben Jahr noch durch, das man von meinen Code nicht sagen kann :D Der "Vorteil" Meiner Variant ist, das man verschiedene Lexer für Markups machen kann (Ableitung Von ``BasisLexer``), die aber nicht mächtiger als die daucms-Wiki-Syntax sein darf (Z.B. reSTR ist nicht möglich!).

Hier mein Code. Habs als 7z Archiv gepackt: http://rapidshare.com/files/15845904/dws.7z.html

lg
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

EnTeQuAk hat geschrieben:[...]
Das ganze schaut im Moment so aus: http://daucms.de/trac/browser/dauCMS/tr ... py?rev=201
[...]
Nice, geht ja doch mit replaces :)
EnTeQuAk hat geschrieben:[...]
Wie mein Parser Performancetechnisch abschneidet... kA... muss noch getestet werden. Es ist immo mehr ne Idee, als alles andere.
[...]
Ich denke von der Performance her sollte das passen ;) Bin da aber kein Profi.

EDIT2: EnTe , Jepp deine Variante gefällt mir sehr gut :)
EnTeQuAk
User
Beiträge: 986
Registriert: Freitag 21. Juli 2006, 15:03
Wohnort: Berlin
Kontaktdaten:

Danke, Danke...

nichts desto trotz, werde ich mir deinen gesamten Code ma durchschauen... werde ihn analysieren und schauen, ob ich was davon brauchen kann.

Der Ansatz ist jedenfalls sehr gut.

Die Generierung von BBCode aus der dauCMS-Wiki-Syntax gefällt mir ebenso sehr gut.

Wenn ich mich reingefitzt habe werde ich ma schaun, ob ich was dazu beitragen kann.

Es ist jedenfalls mehr geworden, als ich gedacht habe :D


Herzlichen Dank, von meiner Seite aus. Und führe das bitte weiter... das verspricht etwas sehr interessantes zu werden :D

MfG EnTeQuAk
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

EnTeQuAk hat geschrieben: nichts desto trotz, werde ich mir deinen gesamten Code ma durchschauen... werde ihn analysieren und schauen, ob ich was davon brauchen kann.
Aber keinen Schock kriegen. Bin leider nicht dazu gekommen den Code zu dokumentieren was ich bereue, da es stellenweise doch ziemlich Strange ist :D
EnTeQuAk hat geschrieben: Der Ansatz ist jedenfalls sehr gut.
In der Entwurfsphasen gefiel mir mein Code auch gut, aber nun nicht mehr so. Mit der Möglichkeit der Ableitung von ``BasisLexer`` um neue Lexer zu implemnetieren die das gleiche Interface nutzen, finde ich persönlich gut, aber den ganzen AST kram ist echt nicht so gewordene wie erhofft und auch überflüssig :-/ -- Ich werde mir demnächst mal doch das Drachenbuch kaufen :D
EnTeQuAk hat geschrieben: Die Generierung von BBCode aus der dauCMS-Wiki-Syntax gefällt mir ebenso sehr gut.
Danke. Dient aber nur als Beispiel, da ich nun nicht nicht nachschlagen wollte für HTML (HTML und XHTML ist schon sehr lange her und BBC habe ich im Kopf ^^). Da sich aber die tags eigentlich fast ähneln, kann man das auch leicht anpassen. EDIT: Aber es ist so konzipiert das es in jedes beliebige Textformat überführt werden kann, das mindestens gleich mächtig ist wie daucms-Wiki-Syntax.
EnTeQuAk hat geschrieben: Herzlichen Dank, von meiner Seite aus. Und führe das bitte weiter... das verspricht etwas sehr interessantes zu werden :D
Auf jedenfall :) Ich werde wenn ich wider Zeit habe einen neune Ansatz versuchen der sauberer ist als mein jetziger. Aber dazu muss ich mich mehr mit regex beschäftigen :D

Aber als nächstes kommt erstmal Ubuntu auf meine Kiste, das wird mich erstmal die nächste Wochen genug beschäftigen ;)

...

Seid ihr eigentlich nun dabei daucms mit pylucid zu fusionieren und beide Wiki-Syntaxen zusammenzuführen?

Und noch eine Frage: Mir ist aufgefallen das ihr auch [[[ fobar ]]]-Tags habt. Sind die dafür da um Listen zu erzeugen?

lg
EnTeQuAk
User
Beiträge: 986
Registriert: Freitag 21. Juli 2006, 15:03
Wohnort: Berlin
Kontaktdaten:

Seid ihr eigentlich nun dabei daucms mit pylucid zu fusionieren und beide Wiki-Syntaxen zusammenzuführen?
Im Moment nein. Eine Direkte Fusionierung wird es meiner Meinung nach nicht geben.
Es wird später mal ein Plugin für PyLucid geben, um es wie dauCMS benutzen zu können. Also Lokal den Content erstellen und diesen in HTML überführen und dann via FTP etc. hochladen.

Allerdings erst später, da zumindest ich, für meinen Teil gerne erstmal eine Stabile Version erreichen möchte.
Und noch eine Frage: Mir ist aufgefallen das ihr auch [[[ fobar ]]]-Tags habt. Sind die dafür da um Listen zu erzeugen?
Die sind nur so zum Spaß da ;)
Die sind Übergangsweise da... unser Listenparser ist noch nicht fertig... um die Dokumentation aber ansehnlicher zu gestalten haben wir diese Tags eingefügt... sie werden aber entfernt, sobald wir offiziell Listen unterstützen.

MfG EnTeQuAk
EnTeQuAk
User
Beiträge: 986
Registriert: Freitag 21. Juli 2006, 15:03
Wohnort: Berlin
Kontaktdaten:

oke.-... das erste, was schonmal nicht ganz ohne Probleme klappt...

Ich habe folgende Regex:

Code: Alles auswählen

scan_re = re.compile(
            r"(?:"
            +  r"(?P<bold>\*\*)"
            +  r"|(?P<italic>\/\/)"
            +  r"|(?P<underline>__)"
            +  r"|(?P<headline>(={1,6})(.*)\1)"
            +  r"|(?P<url>(http|ftp|nntp|news|mailto)\:[^\s'\"]+\S)"
            +  r"|(?P<dauurl>#link\["
            +      r"((?:(?:https?|ftp|nntp|news|mailto)\:[^\s'\"])?(?:www.)?"
            +          r"(?:.*)"
            +      r"(?:\.[a-z]{2}){1,2}(?:[a-zA-Z0-9\/\\\.]*))"
            +      r"(\s[a-zA-Z0-9-_.:\/\\\s]*)?\])"
            +  r"|(?P<email>[-\w._+]+\@[\w.-]+)"
            +  r"|(?P<pre>(\{\{\{|\}\}\}))"
            + r")")
Er trifft alles wunderbar... mit ausnahme der Überschriften (gruppe 'headline')
Warum? Das ist die gleiche Regex, die ich immer verwendet habe...

Hat da jemand eine Idee?

MfG EnTeQuAk

EDIT:
oke... ich habe es gefunden. Die '\1' ist falsch... müsste anders lauten... '\5' oder so... nur da kommt nur quatsch raus ;)
Habe nun einiges verbessert... aber so richtig funktionieren tut es net...
http://daucms.de/trac/browser/dauCMS/tr ... py?rev=206
Benutzeravatar
Luzandro
User
Beiträge: 87
Registriert: Freitag 21. April 2006, 17:03

oke... ich habe es gefunden. Die '\1' ist falsch... müsste anders lauten... '\5' oder so... nur da kommt nur quatsch raus ;)
Du kannst der Gruppe mit den = auch einen Namen geben (sinnvolleren als hier) und diesen bei der Rückreferenz verwenden
EnTeQuAk hat geschrieben:

Code: Alles auswählen

            +  r"|(?P<headline>(?P<foo>={1,6})(.*)(?P=foo)"
[url=http://www.leckse.net/artikel/meta/profilieren]Profilieren im Netz leicht gemacht[/url]
Antworten