Neuer Highlighter: Rouge statt Coderay
Christian Kruse
- zu diesem forum
- zur info
Hallo alle,
ich habe heute auf einen neuen Syntax-Highlighter umgestellt. Bisher wurde Coderay verwendet; dort gab es aber, trotz umfassender Community-Aktivität in Form von Issues und Pull Requests, seit etwa einem Jahr keinerlei Aktivität. Ich halte diese Bibliothek für tot.
Deshalb habe ich heute auf Rouge umgestellt. Sieht etwas anders aus, kann aber viel mehr Sprachen, unter anderem ist auch Perl wieder dabei. Ich nutze das Github-Theme – bei Bedarf kann das aber durchaus umgestellt werden, im Prinzig[tm] geht jedes Pygments-Theme.
LG,
CK
Hallo Christian Kruse,
Deshalb habe ich heute auf Rouge umgestellt. Sieht etwas anders aus,
aber nicht unbedingt schlechter.
Bis demnächst
Matthias
Tach,
Deshalb habe ich heute auf Rouge umgestellt. Sieht etwas anders aus,
aber nicht unbedingt schlechter.
Code in nicht unterstützten Sprachen
++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-]>>.>---.+++++++..+++.>>.<-.<.+++.------.--------.>>+.>++.
hat im Moment ein anderes Design, als eine fehlende Sprachangabe
++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-]>>.>---.+++++++..+++.>>.<-.<.+++.------.--------.>>+.>++.
Das ist zwar einerseits nett, weil man sieht, dass etwas nicht so funktioniert wie geplant (z.B. bei Tippfehlern), aber andererseits inkonsistent.
mfg
Woodfighter
Hallo woodfighter,
Tach,
Deshalb habe ich heute auf Rouge umgestellt. Sieht etwas anders aus,
aber nicht unbedingt schlechter.
Code in nicht unterstützten Sprachen
++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-]>>.>---.+++++++..+++.>>.<-.<.+++.------.--------.>>+.>++.
hat im Moment ein anderes Design, als eine fehlende Sprachangabe
++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-]>>.>---.+++++++..+++.>>.<-.<.+++.------.--------.>>+.>++.
Das ist zwar einerseits nett, weil man sieht, dass etwas nicht so funktioniert wie geplant (z.B. bei Tippfehlern), aber andererseits inkonsistent.
mfg
Woodfighter
Bis demnächst
Matthias
Hallo woodfighter,
Code in nicht unterstützten Sprachen
++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-]>>.>---.+++++++..+++.>>.<-.<.+++.------.--------.>>+.>++.
hat im Moment ein anderes Design, als eine fehlende Sprachangabe
Das ist ein Bug.
LG,
CK
Tach,
und jetzt wo das CForum Brainfuck-Code (ich hätte doch Ook wählen sollen, aber das Beispiel war mir zu lang) enthält, sollte auch die Unterstützung dafür im Highlighter nur noch eine Frage der Zeit sein…
Danke
Woodfighter
Hallo woodfighter,
und jetzt wo das CForum Brainfuck-Code (ich hätte doch Ook wählen sollen, aber das Beispiel war mir zu lang) enthält, sollte auch die Unterstützung dafür im Highlighter nur noch eine Frage der Zeit sein…
Warum, arbeitest du an einem Patch für Upstream? ;-)
LG,
CK
Tach,
und jetzt wo das CForum Brainfuck-Code (ich hätte doch Ook wählen sollen, aber das Beispiel war mir zu lang) enthält, sollte auch die Unterstützung dafür im Highlighter nur noch eine Frage der Zeit sein…
Warum, arbeitest du an einem Patch für Upstream? ;-)
da gibts ja nicht so viel zu lexen:
module Rouge
module Lexers
class Brainfuck < RegexLexer
title 'brainfuck'
desc 'Lexes brainfuck'
filenames '*.b'
mimetypes 'text/x-brainfuck'
state :root do
rule(/[<>.,+-\[\]]/, Operator)
rule(/[^<>.,+-\[\]]/, Comment)
end
end
end
end
Also, wenn ich korrekt verstehe, wie das funktioniert und die Syntax nicht irgendwo kaputt gemacht habe.
mfg
Woodfighter
Hallo woodfighter,
da gibts ja nicht so viel zu lexen:
Das ist mir bewusst, war aber nicht meine Frage ;-) das Code schreiben ist ja auch die wenigste Arbeit. Es muss Testcases dafür geben, du musst mit dem Autor kommunizieren und auf Änderungswünsche eingehen, etc, pp.
LG,
CK
Tach,
Das ist mir bewusst, war aber nicht meine Frage ;-) das Code schreiben ist ja auch die wenigste Arbeit. Es muss Testcases dafür geben, du musst mit dem Autor kommunizieren und auf Änderungswünsche eingehen, etc, pp.
das ist mir bewusst, deswegen landet der Code ja auch nur hier im Forum und nicht in einem Pull-Request (mal davon abgesehen, dass ich als Maintainer einen solchen vermutlich eh ablehnen würde).
mfg
Woodfighter
@@Christian Kruse
ich habe heute auf einen neuen Syntax-Highlighter [Rouge] umgestellt.
Ist der buggy‽ Kein Syntax-Highlighting bei PHP-Quelltext
Inline: $Rouge.syntaxHighlighting === none;
Block:
$Rouge.syntaxHighlighting === none;
Syntax-Highlighting geht nur dann, wenn <?php
vorangestellt wird …
<?php
$Rouge.syntaxHighlighting === none;
… was nicht dem allgemeinen Anwendungsfall entspricht.
Einen Syntax-Highlighter, der bei PHP versagt, finde ich für dieses Forum ungeeignet.
LLAP 🖖
Tach,
$Rouge.syntaxHighlighting === none;
Syntax-Highlighting geht nur dann, wenn
<?php
vorangestellt wird …<?php $Rouge.syntaxHighlighting === none;
… was nicht dem allgemeinen Anwendungsfall entspricht.
… aber prinzipiell korrekt ist.
Einen Syntax-Highlighter, der bei PHP versagt, finde ich für dieses Forum ungeeignet.
Ein entsprechender Bug (mit prinzipieller Lösung, allerdings nicht für Kramdown) existiert schon bei Rouge: https://forum.selfhtml.org/self/2016/jan/20/rouge-und-php/1659137#m1659137.
mfg
Woodfighter
Hallo,
$Rouge.syntaxHighlighting === none;
Syntax-Highlighting geht nur dann, wenn
<?php
vorangestellt wird …<?php $Rouge.syntaxHighlighting === none;
… was nicht dem allgemeinen Anwendungsfall entspricht.
… aber prinzipiell korrekt ist.
IMO nicht. Ein Syntax-Hilighting sollte schon nach den Regeln der angegebenen Sprache markieren und hervorheben, auch ohne dass die Sprache im Code-Teil nochmal explizit deklariert wird. Javascript-Hilighting funktioniert ja auch ohne das einleitende <script> im Code-Block, und HTML auch ohne ein öffnendes <html> oder eine DOCTYPE-Deklaration.
Sinngemäß das gleiche würde ich bei PHP auch erwarten.
Ein entsprechender Bug (mit prinzipieller Lösung, allerdings nicht für Kramdown) existiert schon bei Rouge: https://forum.selfhtml.org/self/2016/jan/20/rouge-und-php/1659137#m1659137.
Gut. Dann heißt es also abwarten und Kaffee trinken (Tee ist nicht so mein Ding).
Und ja, ich erinnere mich, dass das Thema vor ein paar Tagen schon einmal angesprochen wurde.
So long,
Martin
Tach,
Ein Syntax-Hilighting sollte schon nach den Regeln der angegebenen Sprache markieren und hervorheben, auch ohne dass die Sprache im Code-Teil nochmal explizit deklariert wird.
das tut er ja (und wie gesagt, ich halte das auch für zu strikt), aber die PHP-Datei
Hello World
tut numal das selbe, wie die PHP-Datei
<?php
echo "Hello World"
Rouge setzt hier standardmäßig diese Möglichkeit der Sprache korrekt um.
mfg
Woodfighter
Hi,
Ein Syntax-Hilighting sollte schon nach den Regeln der angegebenen Sprache markieren und hervorheben, auch ohne dass die Sprache im Code-Teil nochmal explizit deklariert wird.
das tut er ja
nein, tut er nicht.
die PHP-Datei
Hello World
tut numal das selbe, wie die PHP-Datei
<?php echo "Hello World"
Ich kann die Argumentation nachvollziehen. Aber das impliziert, dass man jeglichen Text, der außerhalb von <?php ... ?> staht, auch schon als PHP-Code bezeichnen will. Und diese Denkweise halte ich für falsch. Es geht ja um Programmcode.
Rouge setzt hier standardmäßig diese Möglichkeit der Sprache korrekt um.
Tja, wie gesagt ... ich bin da anderer Ansicht. Der Rouge-Highlighter interpretiert das, was mit "php" gekennzeichnet ist, quasi generisch als Inhalt einer PHP-Datei anstatt spezifisch als PHP-Code. Und das finde ich nicht korrekt.
So long,
Martin
@@Der Martin
IMO nicht. Ein Syntax-Hilighting sollte schon nach den Regeln der angegebenen Sprache markieren und hervorheben, auch ohne dass die Sprache im Code-Teil nochmal explizit deklariert wird. Javascript-Hilighting funktioniert ja auch ohne das einleitende <script> im Code-Block, und HTML auch ohne ein öffnendes <html> oder eine DOCTYPE-Deklaration.
Sinngemäß das gleiche würde ich bei PHP auch erwarten.
Full ACK.
Gut. Dann heißt es also abwarten und Kaffee trinken (Tee ist nicht so mein Ding).
Dann zeichnen wir also PHP-Code mit ~~~php
bzw. {: .language-php}
aus – in dem Wissen, dass es momentan nicht gesyntaxhighlightet[1] wird; aber wenn irgendwer irgendwann (nachdem der Bug in Rouge gefixt wurde) das Posting im Archiv liest, es dann richtig ist.
Und ja, ich erinnere mich, dass das Thema vor ein paar Tagen schon einmal angesprochen wurde.
Huch, das ist an mir vorbeigegangen.
LLAP 🖖
PS: keine Sprache für den Code angegeben – was gibt’s denn da rot zu färben? Ah, rouge …
Ich bin stolz auf diese Wortschöpfung. ↩︎
@@Gunnar Bittersmann
PS: keine Sprache für den Code angegeben – was gibt’s denn da rot zu färben? Ah, rouge …
Wenn man denn für {: .language-php}
eine Sprache angibt, dann stellt Rouge das richtig dar.
(Das muss keine bekannte Sprache sein, auch bei {: .language-a}
ist die Darstellung richtig. Wichtig ist .language-
gefolgt von ASCII-Zeichen. {: .language-aä}
geht nicht.)
Warum zum Geier will Rouge bei keiner angegebenen Sprache irgendwelche Regeln anwenden?
Ich frag mich, was bei der Entwicklung von Rouge noch so alles schiefgelaufen ist.
LLAP 🖖
Tach,
Warum zum Geier will Rouge bei keiner angegebenen Sprache irgendwelche Regeln anwenden?
die Lexer von Rouge können Heuristiken zum Erkennen der Sprache enthalten, das hilft dabei Codeblöcke, bei denen keine Sprache angegeben ist, zu färben. Siehe z.B. folgendes Beispiel:
#!/bin/bash
if [ true ]; echo "juhu"; fi
mfg
Woodfighter
@@woodfighter
die Lexer von Rouge können Heuristiken zum Erkennen der Sprache enthalten, das hilft dabei Codeblöcke, bei denen keine Sprache angegeben ist, zu färben.
Also eine Abwägung false positive vs. false negative: bei keiner Angabe nicht färben – oder raten, auf die Gefahr hin, falsch zu raten.
Ich hätte vermutlich anders abgewägt: keine Angabe, also kein Syntax-Highlighting.
LLAP 🖖
Tach,
Also eine Abwägung false positive vs. false negative: bei keiner Angabe nicht färben – oder raten, auf die Gefahr hin, falsch zu raten.
Ich hätte vermutlich anders abgewägt: keine Angabe, also kein Syntax-Highlighting.
ich würde sagen, das hängt davon ab, wie die Heuristiken implementiert sind; wenn wie in meinem Beispiel Code mit einem Shebang beginnt, ist es i.A. kein Raten mehr, aber offenbar sind nicht alle Lexer so konservativ.
mfg
Woodfighter
Tach,
(Das muss keine bekannte Sprache sein, auch bei
{: .language-a}
ist die Darstellung richtig. Wichtig ist.language-
gefolgt von ASCII-Zeichen.{: .language-aä}
geht nicht.)
der richtige Weg zu keinem Highlighting wäre übrigens {:.language-plaintext}
oder {:.language-text}
, dann musst du dich nicht darauf verlassen, dass kein Alias für deinen gewählten String existiert.
mfg
Woodfighter
@@woodfighter
der richtige Weg zu keinem Highlighting wäre übrigens
{:.language-plaintext}
oder{:.language-text}
Der richtige™ Weg zu keinem Highlighting wäre:
Nur dass Rouge das anders sieht.
LLAP 🖖
Tach,
der richtige Weg zu keinem Highlighting wäre übrigens
{:.language-plaintext}
oder{:.language-text}
Der richtige™ Weg zu keinem Highlighting wäre:
das ist eine der legitimen Meinungen.
mfg
Woodfighter
Lieber Gunnar,
[gesyntaxhighlightet] Ich bin stolz auf diese Wortschöpfung.
https://www.google.de/?q=gesyntaxhighlightet
Liebe Grüße,
Felix Riesterer.
@@Felix Riesterer
[gesyntaxhighlightet] Ich bin stolz auf diese Wortschöpfung.
Ich sag ja nicht, dass es meine gewesen wäre. ;-)
Und ich folge keinen Links zu “dangerous services” (Edward Snowden).
LLAP 🖖
Lieber Gunnar,
Und ich folge keinen Links zu “dangerous services” (Edward Snowden).
ich hätte jetzt nicht gewusst, wie ich Dir eine Ergebnisseite auf ixquick verlinken müsste.
Liebe Grüße,
Felix Riesterer.
Halo Felix,
Und ich folge keinen Links zu “dangerous services” (Edward Snowden).
ich hätte jetzt nicht gewusst, wie ich Dir eine Ergebnisseite auf ixquick verlinken müsste.
tja, das hatte ich beim Ausprobieren im letzten November auch schon als gravierenden Nachteil festgestellt, der ixquick für mich unbrauchbar macht.
So long,
Martin
Hallo alle,
ich habe den Hochlichter ein weiteres mal ausgetauscht und verwende nun Pygments. Das ist der wohl bekannteste Hochlichter, allerdings in Python geschrieben. Technisch funktioniert das so, dass pygmentize
als long-running process gestartet wird und der Code dort hinein gepiped wird. Heraus kommt das HTML.
Mal sehen, ob es damit insgesamt besser klappt…
LG,
CK
@@Christian Kruse
Gibt es irgendwo eine Liste, welche Sprachen der verwendete Syntax-Highlighter (welcher ist das zur Zeit noch gerade?) unterstützt?
Ich hab gereade json
probiert – Fehlanzeige. Irgendiwe blöd, wenn für Code eine falsche Sprache angeben muss, nur damit das Syntax-Highlighting nicht versagt.
LLAP 🖖
Hallo Gunnar,
Gibt es irgendwo eine Liste, welche Sprachen der verwendete Syntax-Highlighter (welcher ist das zur Zeit noch gerade?) unterstützt?
Ich habe Pygments doch verlinkt.
LG,
CK
@@Christian Kruse
Gibt es irgendwo eine Liste, welche Sprachen der verwendete Syntax-Highlighter (welcher ist das zur Zeit noch gerade?) unterstützt?
Ich habe Pygments doch verlinkt.
Sicher hast du das in irgendeinem Posting. Ich hatte nur keinen Anhaltspunkt, wonach ich suchen sollte.
Der verwendete Syntax-Highlighter sollte auch in der Hilfe bei der Formatierung Ihrer Beiträge erwähnt sein.
LLAP 🖖
Hallo Gunnar Bittersmann,
Der verwendete Syntax-Highlighter sollte auch in der Hilfe bei der Formatierung Ihrer Beiträge erwähnt sein.
Gute Idee - Mach ich.
Bis demnächst
Matthias
Hallo
Der verwendete Syntax-Highlighter sollte auch in der Hilfe bei der Formatierung Ihrer Beiträge erwähnt sein.
Gute Idee - Mach ich.
Als Forenbenutzer zu wissen, welcher Highlighter im Hintergrund arbeitet, halte ich für nett aber nebensächlich. Was ich wissen will, ist, welche Kennung ich für welche Sprache angeben muss. Bei HTML oder PHP erklärt sich das selbst, aber bei JavaScript habe ich wegen der mehrfachen Umstellungen in der letzten Zeit immer herumprobiert, ob sie nun „javascript“ oder eventuell auch „js“ heißt.
Tschö, Auge
Hi,
[...] aber bei JavaScript habe ich wegen der mehrfachen Umstellungen in der letzten Zeit immer herumprobiert, ob sie nun „javascript“ oder eventuell auch „js“ heißt.
ich würde erwarten, dass beides geht, bin aber im alten Forum ab und zu auf die Nase gefallen. Denn meist habe ich aus Gewohnheit nur "js" angegeben und dann erst in der Vorschau gesehen, dass kein Highlighting stattfand.
Hier geht jetzt wohl beides - sowohl "js" als auch ausgeschrieben "javascript".
So long,
Martin
Hallo Auge,
Als Forenbenutzer zu wissen, welcher Highlighter im Hintergrund arbeitet, halte ich für nett aber nebensächlich. Was ich wissen will, ist, welche Kennung ich für welche Sprache angeben muss. Bei HTML oder PHP erklärt sich das selbst, aber bei JavaScript habe ich wegen der mehrfachen Umstellungen in der letzten Zeit immer herumprobiert, ob sie nun „javascript“ oder eventuell auch „js“ heißt.
Das sehe ich genauso. Ich hätte schon den Schwerpunkt auf die zur Verfügung stehenden Sprachen gelegt ;-)
Bis demnächst
Matthias
Ich hab gereade
json
probiert – Fehlanzeige. Irgendiwe blöd, wenn für Code eine falsche Sprache angeben muss, nur damit das Syntax-Highlighting nicht versagt.
JSON mit JavaScript-Highlighting zu fahren, klingt jetzt nicht gerade nach einem Totalschaden.
@@Mitleser
Ich hab gereade
json
probiert – Fehlanzeige. Irgendiwe blöd, wenn für Code eine falsche Sprache angeben muss, nur damit das Syntax-Highlighting nicht versagt.JSON mit JavaScript-Highlighting zu fahren, klingt jetzt nicht gerade nach einem Totalschaden.
Das nicht. Aber JSON ist längt so universell, dass es nicht unbedingt was mit JavaScript zu tun hat.
LLAP 🖖
Tach!
JSON mit JavaScript-Highlighting zu fahren, klingt jetzt nicht gerade nach einem Totalschaden.
Das nicht. Aber JSON ist längt so universell, dass es nicht unbedingt was mit JavaScript zu tun hat.
Es bleibt aber immer dabei, dass es sich um die Javascript-Objekt-Notation handelt. Der Bezug zu Javascript wird also nicht aufgehoben, egal in welchem Umfeld es eingesetzt wird.
dedlfix.
@@dedlfix
Das nicht. Aber JSON ist längt so universell, dass es nicht unbedingt was mit JavaScript zu tun hat.
Es bleibt aber immer dabei, dass es sich um die Javascript-Objekt-Notation handelt. Der Bezug zu Javascript wird also nicht aufgehoben, egal in welchem Umfeld es eingesetzt wird.
Dennoch hat JSON mit JavaScript so viel zu tun wie reguläre Ausdrücke mit PHP. Für beides (JSON und reguläre Ausdrücke) sollte ein Syntax-Highlighter IMHO entsprechende Sprachen anbieten.
LLAP 🖖
Tach!
Dennoch hat JSON mit JavaScript so viel zu tun wie reguläre Ausdrücke mit PHP.
Äpfel und Birnen. Reguläre Ausdrücke haben ihren Ursprung weder in Syntax noch in Arbeitsweise in PHP. Beide Varianten (ereg und preg) stammen aus anderen Projekten. JSON hingegen hat einen Javascript-Hintergrund.
dedlfix.
@@dedlfix
Dennoch hat JSON mit JavaScript so viel zu tun wie reguläre Ausdrücke mit PHP.
Äpfel und Birnen. Reguläre Ausdrücke haben ihren Ursprung weder in Syntax noch in Arbeitsweise in PHP. Beide Varianten (ereg und preg) stammen aus anderen Projekten. JSON hingegen hat einen Javascript-Hintergrund.
Dann ersetze „PHP“ in meiner Aussage durch „C“ oder was auch immer.
Ich denke schon, dass Äpfel und Birnen hier Obst sind.
LLAP 🖖
Tach,
Dennoch hat JSON mit JavaScript so viel zu tun wie reguläre Ausdrücke mit PHP.
Äpfel und Birnen. Reguläre Ausdrücke haben ihren Ursprung weder in Syntax noch in Arbeitsweise in PHP. Beide Varianten (ereg und preg) stammen aus anderen Projekten. JSON hingegen hat einen Javascript-Hintergrund.
Dann ersetze „PHP“ in meiner Aussage durch „C“ oder was auch immer.
und reguläre Ausdrücke durch was? Diese entstammen schließlich keiner Programmiersprache (auch wenn Perl hier vermutlich lange Zeit die Entwicklung angetrieben hat).
Nicht, dass ich ein JSON-Alias für einen Highlighter nicht sinnvoll fände.
mfg
Woodfighter
@@woodfighter
Dann ersetze „PHP“ in meiner Aussage durch „C“ oder was auch immer.
und reguläre Ausdrücke durch was?
Durch gar nichts. Die sind in dem Vergleich das Äquivalent zu JSON.
Diese entstammen schließlich keiner Programmiersprache (auch wenn Perl hier vermutlich lange Zeit die Entwicklung angetrieben hat).
Hm, dann wohl Perl statt C:
Dennoch hat JSON mit JavaScript so viel zu tun wie reguläre Ausdrücke mit Perl.
LLAP 🖖
Tach,
Dennoch hat JSON mit JavaScript so viel zu tun wie reguläre Ausdrücke mit Perl.
im Moment ist JSON immer auch gültiges Javascript und die Datenstrukturen werden identisch interpretiert (zumindest identisch genug für einen Highlighter), reguläre Ausdrücke mögen zwar häufig aussehen wie (obfuscated) Perl (oder andersherum) aber der Inhalt (und die Bedeutung der Symbole) wäre wohl fast immer anders.
mfg
Woodfighter
@@Christian Kruse
Deshalb habe ich heute auf Rouge umgestellt. Sieht etwas anders aus, kann aber viel mehr Sprachen
Aber mit PHP in HTML kommt der nicht so richtig klar‽
LLAP 🖖
Tach,
Deshalb habe ich heute auf Rouge umgestellt. Sieht etwas anders aus, kann aber viel mehr Sprachen
Aber mit PHP in HTML kommt der nicht so richtig klar‽
tja, ich vermute mal das läuft darauf hinaus, dass es kompliziert wird, wenn man einerseits Texte, die ohne beginnendes PHP-Tag starten, als PHP parsen möchte und gleichzeitig die vollen Sytaxmöglichkeiten von PHP ausnutzen möchte. Der aktuelle Parser ergänzt quasi ein „<?php“ zu Beginn des Blocks, wenn dieser als PHP markiert ist, so wie u.a. du es wolltest. Ohne einen Schalter, um zwischen diesen Varianten zu wählen, dürfte das kompliziert umzusetzen sein.
mfg
Woodfighter
Tach,
Ohne einen Schalter, um zwischen diesen Varianten zu wählen, dürfte das kompliziert umzusetzen sein.
der Lexer kennt einen entsprechenden Schalter, ob man den aus einem Posting heraus setzen kann, ist dann nochmal eine andere Frage (meine Vermutung ist wie beim letzten Mal: im Moment nein).
mfg
Woodfighter