Seite 1 von 2
Pygments - Python Syntax Highlighter
Verfasst: Montag 30. Oktober 2006, 22:24
von mitsuhiko
In den letzten eineinhalb Monaten hat das Pocoo Team unter der Leitung von birkenfeld an einem neuen Modul für Python mit dem Namen pygments gearbeitet. Es stellt Lexer zum highlighten von Quellcode für einige Programmier/Markup/Template Sprachen zur Verfügung.
Heute erschien die erste^Wzweite öffentliche Version von
pygments.
Verwenden kann man es so:
Code: Alles auswählen
from pygments import highlight
from pygments.lexers import PythonLexer
from pygments.formatters import HtmlFormatter
code = 'print "Hello World"'
print highlight(code, PythonLexer(), HtmlFormatter())
Genauere Informationen gibt es in der
Dokumentation und auf der
Webseite. Dort gibts auch eine Demo Sektion zum ausprobieren.
Diese aber bitte nicht als pastebin verwenden, dazu gibts
http://lodgeit.lucumr.pocoo.org/ und
http://paste.e-scribe.com/
Die nutzen beide pygments.
Viel Spaß
Verfasst: Montag 30. Oktober 2006, 22:44
von Leonidas
Könnte man eines dieser Pastebins nicht verwenden und die Paste-Einträge im Wiki löschen/umziehen?
PS: Das ich Pygments super finde, weißt du ja sowieso
Verfasst: Montag 30. Oktober 2006, 22:50
von mitsuhiko
Leonidas hat geschrieben:Könnte man eines dieser Pastebins nicht verwenden und die Paste-Einträge im Wiki löschen/umziehen?
Schreib ein script zum übernehmen und ändere den Link
Verfasst: Montag 30. Oktober 2006, 23:15
von Leonidas
blackbird hat geschrieben:Schreib ein script zum übernehmen und ändere den Link
Das Skript sollte kein Problem sein, stellt sich nur die Frage ob die Snippets überhaupt noch nötig sind. Meist sind sie ja für den Gebrauch im IRC gedacht gewesen und da ist es dann recht egal ob es sie gibt oder nicht.
Was meinst du?
Verfasst: Dienstag 31. Oktober 2006, 10:13
von Y0Gi
Habe es noch unter dem Namen PyKleur in meinen Bookmarks für spätere Betrachtung. Momentan verwende ich auf meiner Site den experimentellen Highlighter von Fredrik Lundh, allerdings ist der nur auf Python-Code beschränkt. Eine von JavaScript abhängige Lösung, wie sie die Sites von etwa CherryPy, TurboGears und mit pudge erzeugte Docs verwenden, gefällt mir nicht, da es ohne JS einfach unbrauchbar ist. Von daher kann ich mir gut vorstellen, in naher Zukunft Pygments einzusetzen
Danke dafür an dieser Stelle.
Verfasst: Dienstag 31. Oktober 2006, 15:19
von mitsuhiko
Y0Gi hat geschrieben:Eine von JavaScript abhängige Lösung, wie sie die Sites von etwa CherryPy, TurboGears und mit pudge erzeugte Docs verwenden, gefällt mir nicht, da es ohne JS einfach unbrauchbar ist.
Der Meinung ist auch Ben von pylons. Er will die pylons docs in Zukunft mit pygments highlighten lassen.
Verfasst: Mittwoch 1. November 2006, 19:19
von Y0Gi
Nach dem Überfliegen der vorhandenen Lexer habe ich keine für folgende Formatierungen gefunden, würde sie aber begrüßen: CSV, JSON, YAML, TCL und Bash/Shell.
Man könnte auch überlegen, Formate wie (etwa Apache-)Logfiles oder iptables-Regeln aufzunehmen.
Vielleicht kann man sich auch von den vorhandenen Lexern inspirieren lassen, die SciTE mitliefert.
P.S.: Ist der Output vom HtmlFormatter auch XHTML-konform?
Verfasst: Mittwoch 1. November 2006, 20:52
von Y0Gi
Update: Ich habe die Integration von Pygments in meine Site nun so gut wie abgeschlossen. Mich stören einige Punkte (insbesondere im Vergleich zum
code colorizer von Fredrik Lundh, den ich bisher benutzte und der nur Python-Code highlighten kann):
- Es wird kein Gebrauch vom <code>-Element gemacht, obwohl es hier definitiv angebracht ist.
- Werden Zeilennummern angefordert, wird unschönerweise eine Tabelle (aber dann sematisch falsch, weil die Zeilennummern alle in einer Zelle stecken) ausgegeben; das geht auch ohne.
- Das helle Lila für Keywords geht mal gar nicht
Ansonsten: Gute Arbeit, auch sehr schöne API.
Update: Und noch eines, aber das ist wirklich gravierend: Die Leerzeilen im Inhalt (also nicht die davor und dahinter), mit Ausnahme solcher in Python-Multiline-Strings, sind verschwunden! Damit wird der Code unleserlich, das geht so nicht
Update 2: An den Lexern liegt es nicht und auch alle Formatter bis auf den HtmlFormatter berücksichtigen die Leerzeilen.
Update 3: Scheinbar liegt es auch nicht am HtmlFormatter, Debug-Ausgaben in selbigem haben das nicht bestätigt. Vielmehr ist Genshi der Übeltäter. Das Problem ist seit etwa drei Wochen bekannt (bzw. existiert ein Ticket). Dazu habe ich
einen Kommentar hinzugefügt. Sorry für den falschen Alarm.
Verfasst: Donnerstag 2. November 2006, 16:37
von birkenfeld
Y0Gi hat geschrieben:Update: Ich habe die Integration von Pygments in meine Site nun so gut wie abgeschlossen. Mich stören einige Punkte (insbesondere im Vergleich zum
code colorizer von Fredrik Lundh, den ich bisher benutzte und der nur Python-Code highlighten kann):
- Es wird kein Gebrauch vom <code>-Element gemacht, obwohl es hier definitiv angebracht ist.
Welchen Vorteil hat <code> vor <pre>? Ja, es ist semantisch vielleicht richtiger, aber das wars auch.
- Werden Zeilennummern angefordert, wird unschönerweise eine Tabelle (aber dann sematisch falsch, weil die Zeilennummern alle in einer Zelle stecken) ausgegeben; das geht auch ohne.
Dein Vorschlag wäre? (nein, ein float geht z.B. nicht, genausowenig, die Zeilennummern direkt in das <pre> zu setzen, denn damit ist copy-and-paste im Eimer, genauso wie bei Einzelzellen für jede Zeile.)
- Das helle Lila für Keywords geht mal gar nicht
man styles.
Übrigens: Bugreports und Verbesserungsvorschläge gehören nicht (nur) in ein Forum, sondern ins Pocoo-Trac
http://trac.pocoo.org, denn da lese ich sie auch sicher.
Ansonsten danke fürs Feedback!
Verfasst: Donnerstag 2. November 2006, 17:14
von Rebecca
birkenfeld hat geschrieben:Welchen Vorteil hat <code> vor <pre>? Ja, es ist semantisch vielleicht richtiger, aber das wars auch.
Fuer Screenreader ist die "richtige" Verwendung der Tags durchaus wichtig.
Verfasst: Donnerstag 2. November 2006, 17:20
von Y0Gi
birkenfeld hat geschrieben:Welchen Vorteil hat <code> vor <pre>? Ja, es ist semantisch vielleicht richtiger, aber das wars auch.
Nicht anstelle von <pre> - das hat ja durch seine standardmäßige Formatierung in Browsern seine Berechtigung (auch wenn die CSS-Eigenschaft "white-space: pre;" das nachbilden kann) - sondern anstelle des <div>.
birkenfeld hat geschrieben:Dein Vorschlag wäre? (nein, ein float geht z.B. nicht, genausowenig, die Zeilennummern direkt in das <pre> zu setzen, denn damit ist copy-and-paste im Eimer, genauso wie bei Einzelzellen für jede Zeile.)
So wie
das hier es eben löst. Eine weitere Möglichkeit wäre die Art, in der pudge Code formatiert.
birkenfeld hat geschrieben:Übrigens: Bugreports und Verbesserungsvorschläge gehören nicht (nur) in ein Forum, sondern ins Pocoo-Trac
http://trac.pocoo.org, denn da lese ich sie auch sicher.
Ich habe es vorgezogen, zunächst hier die Diskussion anzustoßen - wo hier schon mal ein Thread extra für Pygments erstellt wurde.
Verfasst: Donnerstag 2. November 2006, 17:24
von birkenfeld
Y0Gi hat geschrieben:birkenfeld hat geschrieben:Welchen Vorteil hat <code> vor <pre>? Ja, es ist semantisch vielleicht richtiger, aber das wars auch.
Nicht anstelle von <pre> - das hat ja durch seine standardmäßige Formatierung in Browsern seine Berechtigung (auch wenn die CSS-Eigenschaft "white-space: pre;" das nachbilden kann) - sondern anstelle des <div>.
Ist <code> eigentlich nicht ein Inline-Tag?
birkenfeld hat geschrieben:Dein Vorschlag wäre? (nein, ein float geht z.B. nicht, genausowenig, die Zeilennummern direkt in das <pre> zu setzen, denn damit ist copy-and-paste im Eimer, genauso wie bei Einzelzellen für jede Zeile.)
So wie
das hier es eben löst. Eine weitere Möglichkeit wäre die Art, in der pudge Code formatiert.
Kannst du das vielleicht auch näher ausführen? Ich habe keine Lust, mich durch den Code zu wühlen.
Verfasst: Donnerstag 2. November 2006, 17:26
von mitsuhiko
Y0Gi hat geschrieben: - Es wird kein Gebrauch vom <code>-Element gemacht, obwohl es hier definitiv angebracht ist.
<code> ist inline, <pre> ist ein Block. Wenn dann schon <listing>, aber das ist deprecated.
- Werden Zeilennummern angefordert, wird unschönerweise eine Tabelle (aber dann sematisch falsch, weil die Zeilennummern alle in einer Zelle stecken) ausgegeben; das geht auch ohne.
nicht ohne copy/paste zu ruinieren.
- Das helle Lila für Keywords geht mal gar nicht
http://pygments.pocoo.org/docs/styles/
Verfasst: Donnerstag 2. November 2006, 17:31
von mitsuhiko
Y0Gi hat geschrieben:birkenfeld hat geschrieben:Welchen Vorteil hat <code> vor <pre>? Ja, es ist semantisch vielleicht richtiger, aber das wars auch.
Nicht anstelle von <pre> - das hat ja durch seine standardmäßige Formatierung in Browsern seine Berechtigung (auch wenn die CSS-Eigenschaft "white-space: pre;" das nachbilden kann) - sondern anstelle des <div>.
Uuuuuh. Ganz böse. Innerhalb von <code> dürfen nur inline Elemente vorkommen, weder <pre> noch <table> sind das.
birkenfeld hat geschrieben:Dein Vorschlag wäre? (nein, ein float geht z.B. nicht, genausowenig, die Zeilennummern direkt in das <pre> zu setzen, denn damit ist copy-and-paste im Eimer, genauso wie bei Einzelzellen für jede Zeile.)
So wie
das hier es eben löst. Eine weitere Möglichkeit wäre die Art, in der pudge Code formatiert.
Das macht copy/paste kaputt.
Verfasst: Donnerstag 2. November 2006, 18:40
von jens
Y0Gi hat geschrieben:birkenfeld hat geschrieben:Welchen Vorteil hat <code> vor <pre>? Ja, es ist semantisch vielleicht richtiger, aber das wars auch.
Nicht anstelle von <pre> - das hat ja durch seine standardmäßige Formatierung in Browsern seine Berechtigung (auch wenn die CSS-Eigenschaft "white-space: pre;" das nachbilden kann) - sondern anstelle des <div>.
Kann es sein, das "white-space: pre;" oder auch irgendwas mit nowrap nicht im IE 6 geht?
Irgend so ein Problem ist beim PyLucid's altem Python-Only-Syntaxhightligter vorgekommen...
Verfasst: Donnerstag 2. November 2006, 22:24
von Y0Gi
blackbird hat geschrieben:<code> ist inline, <pre> ist ein Block. Wenn dann schon <listing>, aber das ist deprecated.
blackbird hat geschrieben:Uuuuuh. Ganz böse. Innerhalb von <code> dürfen nur inline Elemente vorkommen, weder <pre> noch <table> sind das.
Bleiben immer noch mindestens zwei Optionen:
- <code> mit "white-space: pre;"
- <code> innerhalb von <pre> (und nicht umgekehrt, was ich aber auch nicht meinte), was erlaubt ist
Was <table> angeht: Da Pygments AFAIK nur eine Zeile und zwei Zellen verwendet, lässt sich der Inhalt der zweiten Zelle in <code> einschließen. Würde natürlich nicht mehr funktionieren, wenn man der Semantik halbwegs Respekt zollt und jede Codezeile in einer eigenen Tabellenzeile unterbringt, aber dann dürfte im Folgenden genanntes Copy/Paste auch nicht mehr funktionieren.
blackbird hat geschrieben:nicht ohne copy/paste zu ruinieren.
Ok, das ist ein Grund, der dagegen wiegt, aber eben genannte Einschränkungen erfordert.
jens: Im IE geht so einiges nicht. Wenn ich für jede solche Erfahrung in meinem Leben eine Mark bekommen hätte, könnte ich mir auch bald einen Flug ins Weltall leisten.
Verfasst: Freitag 22. Dezember 2006, 07:18
von mitsuhiko
Sodale. Seit gestern ist
Pygments 0.6 codename Zimtstern zum Download erhältlich
Verfasst: Freitag 22. Dezember 2006, 10:47
von sape
Zimtstern? Wie Zimt und Stern?
Ist das eigentlich auch als "offline" Tool benutzbar bzw. generiert es nur ausschließlich HTML Output oder lässt sich das ganze anpassen das auch anderer Output als HTML generiert wird?
lg
Verfasst: Freitag 22. Dezember 2006, 11:11
von rafael
sape hat geschrieben:Zimtstern? Wie Zimt und Stern?
Ist das eigentlich auch als "offline" Tool benutzbar bzw. generiert es nur ausschließlich HTML Output oder lässt sich das ganze anpassen das auch anderer Output als HTML generiert wird?
lg
Ja, man kann das auch per "pygmentize" in der Konsole laufen lassen und man kriegt dann halt dort den Output.
Verfasst: Freitag 22. Dezember 2006, 14:10
von Leonidas
rafael hat geschrieben:Ja, man kann das auch per "pygmentize" in der Konsole laufen lassen und man kriegt dann halt dort den Output.
Mann kann sich den Output auch in eine Datei schreiben lassen und außerdem kann man als Ausgabeformat auch LaTeX, RTF, ANSI-Kontrollsequenzen wählen.