Terminalausgabe bunt machen

[snafu]

Hab mich jetzt mal rangewagt:



Und hier gibt's den Code: http://paste.pocoo.org/show/163791/

[Dauerbaustelle]

Ohje, aber dafür nen XML-Parser laden...? :-)

[lunar]

XML ist auch irgendwie keine schöne Wahl …

[Dauerbaustelle]

Wobei das halt sauber und eindeutig ist zur Beschreibung. jagut, man könnte sowas wie **dick** und _underlined_ machen, aber a) hört das bei Farben auf, da würde man dann so Kram wie BB-like-Tag einführen und b) ist das nicht so bequem programmatisch zu erzeugen, würde ich behaupten.

[Leonidas]

Ich find die Idee mit den Tags grundsätzlich gut, weil das einfach zu verstehen und nutzen ist (Reportlab nutzt auch so einen Ansatz), allerdings finde ich das mit dem root-Tag nicht so toll. Außerdem hat man bei XML auch wieder Escaping-Probleme so dass ich mir nicht sicher bin ob nicht ein eigenes, tagbasiertes Markup nicht vielleicht doch besser wäre.

[snafu]

Ich stand genau vor der gleichen Frage. Hatte mir auch die Syntax vom UU-Forum näher angesehen, weil die mir nach anfänglichen Umstellungsproblemen inzwischen sehr zusagt (bis auf ein paar Kleinigkeiten). Das mit dem Root-Tag nervt wirklich. Farbnamen könnte man ja durchaus in eckige oder geschweifte Klammern einbauen. Ich schaue mir gerade AsciiDoc an. Die Einstellmöglichkeiten scheinen auf dem ersten Blick nicht schlecht zu sein und es ist in Python geschrieben, so dass man damit wohl eine eigene Markup-Sprache entwickeln oder sich zumindest ein paar Sachen abgucken könnte. Werd mich dazu wahrscheinlich in den nächsten Tagen nochmal melden.

EDIT: Ich korrigiere, es sind eher die Beispiele in dem Tarball, die mir zusagen, speziell `code-filter.py`.

[sma]

Ich würde ehrlich gesagt nicht extra einen XML-Parser bemühen, um Text in spitzen Klammern zu parsen: http://paste.pocoo.org/show/163934/

Man müsste sich noch überlegen, wie man mit einem "<" im Text umgehen will. Escapen wie in XML? Dann muss man noch < und & unterstützen und vielleicht noch &#XXX;. War mir für das RE-Beispiel zu aufwendig.

Stefan

[snafu]

Ich denke, ich werde mich doch eher an ein alternatives Markup wagen.

Das möchte ich mal ganz **fett** __unterstreichen__ und daher weder --durchstreichen--, noch [[invertieren]], oder so ähnlich.

[lunar]

Wie wäre es mit ReST?

[sma]

http://paste.pocoo.org/show/164236/

Stefan

[snafu]

sma, der Regex-Gott.

Wie würdet ihr Farben parsen? Vielleicht so?

Code: Alles auswählen

Ich bin völlig ~~blue~~besoffen~~blue~~

Doof, oder?

[Defnull]

Ich wäre für [farbe:text text text] oder so etwas. Meistens will man ja nur kurze Bereiche farbig gestalten. Natürlich wäre ein Support für verschachtelung ([red: bla [green: blub] bla]) interessant.

[snafu]

Kennt jemand einen Parser für solche Art von Markup? Ich hab die Klasse aus dem ElementTree-Modul vor allem genutzt, weil ich mir dadurch das Einbinden von Regex-Ausdrücken ersparen konnte. Optimal wäre die Einbindung einer eigenen Grammatik mittels Wörterbuch. Etwa so:

Code: Alles auswählen

{'**': self.attr_cache.append(BOLD), '__': self.attr_cache.append(UNDERLINE), ...}

Natürlich wäre ein Support für verschachtelung ([red: bla [green: blub] bla]) interessant.

"Interessant" heißt hier vermutlich kompliziert. Aber die Unterstützung von Verschachtelungen ist IMHO definitiv notwenig.

Ich werde mich mal näher mit PyParsing befassen...

[sma]

Kennt jemand einen Parser für solche Art von Markup? ...
Ich werde mich mal näher mit PyParsing befassen...

Mein zweites Beispiel finde ich ausreichend. Die regulären Ausdrücke aus einer Tabelle von Sonderzeichen und CSI-Sequenzen zu generieren überlasse ich dem Leser. PyParsing finde ich ist overkill.

Stefan

[Leonidas]

PyParsing finde ich ist overkill.

Dito, würde nicht als Dependency haben wollen. Davon abgesehen bin ich von PyParsing nur mittelmäßig begeistert.

[snafu]

Nur hab ich bei PyParsing eben so Dinge wie `nestedExpr()` gesehen. Ich sträube mich ehrlich gesagt ein bißchen, das in regulären Ausdrücken nachzuimplementieren, wenn es doch schon eine Bibliothek gibt, die sowas unterstützt. Sonst heißt es auch immer, man soll das Rad nicht neu erfinden. Bei so ziemlich jedem Thread, der fragt, wie man bestimmte Teile aus dem Quelltext einer Website holen kann, wird sofort auf ElementTree & Co verwiesen und jetzt plötzlich soll es keine gute Idee sein, PyParsing zu verwenden, weil es Overkill ist? Sorry, aber je mehr ich darüber nachdenke, desto weniger kann ich diese Haltung nachvollziehen.

[Leonidas]

Naja, ElementTree ist teil der Stdlib, daher kostet die verwendung davon nichts, wohingegen PyParsing ein externes Dependency ist.

Also wenn ich sowas machen sollte würde ich mir inzwischen eher funcparserlib, pyPEG oder picoparse anschauen. Wenn ich unbedingt eine Parser-Library nutzen will.

[snafu]

Die Sache ist halt, dass ich reinen Regex-Code persönlich schlecht lesbar und somit auch schlecht wartbar sowie fehleranfällig finde, sobald man dann doch mal irgendeinen Fall vergessen hat. Eben ähnlich wie beim Parsen von HTML. Dass solche Module nicht in der Stdlib integriert sind, ist für mich auch wirklich das einzige Gegenargument. Ich denke aber, man kann vom Benutzer in dem Fall ruhig erwarten, dass er ein Modul via Paketmanager bzw easy_install nachinstalliert, denn das Parsen des Markups ist hier ja ein wesentlicher Bestandteil.

Danke übrigens für die Links. PyParsing hatte ich nur aus dem Grund gewählt, weil mir nichts anderes bekannt war.

[Leonidas]

Die Sache ist halt, dass ich reinen Regex-Code persönlich schlecht lesbar und somit auch schlecht wartbar sowie fehleranfällig finde, sobald man dann doch mal irgendeinen Fall vergessen hat.

Also ich finde meinen Parser in PyParsing direkt noch schlechter lesbar und wartbar, weil der komische Sachen macht und ich immer dem Autor mailen muss, der mir dann ein noch hässlicher ausschauendes Codeschnippsel zurückmailt, das diesen Bug nicht hat.

Wie gesagt: nicht begeistert.

[snafu]

Naja, ich werde mir wahrscheinlich `funcparser` näher ansehen. Da gibt es ja sogar ein Tutorial zum Thema Verkettung. Was auch eine Idee wäre: Erstmal mit einem solchen Hilfstool alles aufbauen bis es läuft und anschließend die relevanten Teile rauskopieren. Mir ist besonders beim `picoparser` aufgefallen, dass der relativ simpel strukturiert ist.

funcparserlib is a library for recursive descent parsing using parser
combinators. The parsers made with its help are LL(*) parsers. It means that
it's very easy to write them without thinking about look-aheads and all that
hardcore parsing stuff. But the recursive descent parsing is a rather slow
method compared to LL(k) or LR(k) algorithms. So the primary domain for
funcparserlib is parsing small languages or external DSLs (domain specific
languages).

Hört sich doch insgesamt ganz okay an.