• Hallo liebe Userinnen und User,

    nach bereits längeren Planungen und Vorbereitungen sind wir nun von vBulletin auf Xenforo umgestiegen. Die Umstellung musste leider aufgrund der Serverprobleme der letzten Tage notgedrungen vorverlegt werden. Das neue Forum ist soweit voll funktionsfähig, allerdings sind noch nicht alle der gewohnten Funktionen vorhanden. Nach Möglichkeit werden wir sie in den nächsten Wochen nachrüsten. Dafür sollte es nun einige der Probleme lösen, die wir in den letzten Tagen, Wochen und Monaten hatten. Auch der Server ist nun potenter als bei unserem alten Hoster, wodurch wir nun langfristig den Tank mit Bytes vollgetankt haben.

    Anfangs mag die neue Boardsoftware etwas ungewohnt sein, aber man findet sich recht schnell ein. Wir wissen, dass ihr alle Gewohnheitstiere seid, aber gebt dem neuen Board eine Chance.
    Sollte etwas der neuen oder auch gewohnten Funktionen unklar sein, könnt ihr den "Wo issn da der Button zu"-Thread im Feedback nutzen. Bugs meldet ihr bitte im Bugtracker, es wird sicher welche geben die uns noch nicht aufgefallen sind. Ich werde das dann versuchen, halbwegs im Startbeitrag übersichtlich zu halten, was an Arbeit noch aussteht.

    Neu ist, dass die Boardsoftware deutlich besser für Mobiltelefone und diverse Endgeräte geeignet ist und nun auch im mobilen Style alle Funktionen verfügbar sind. Am Desktop findet ihr oben rechts sowohl den Umschalter zwischen hellem und dunklem Style. Am Handy ist der Hell-/Dunkelschalter am Ende der Seite. Damit sollte zukünftig jeder sein Board so konfigurieren können, wie es ihm am liebsten ist.


    Die restlichen Funktionen sollten eigentlich soweit wie gewohnt funktionieren. Einfach mal ein wenig damit spielen oder bei Unklarheiten im Thread nachfragen. Viel Spaß im ngb 2.0.

IT-Talents.de Code Competitions

theSplit

1998
Teammitglied

Registriert
3 Aug. 2014
Beiträge
27.283
Hallo,

so gut wie jeden Monat finden auf mit jeweils einem Monatsthema statt.
So gut wie jeder kann an den Wettbewerben teilnehmen und es gibt Sach- und Geldpreise zu gewinnen und es gibt Feedback zu den Code-Abgaben - das einzige was für die Abgabe und Einreichung an die Jury zu beachten ist, es ist ein Account bei IT-Talents erforderlich.

Dabei wird jeden Monat ein neues Thema vorgegeben das bearbeitet werden kann. Es ist nicht erforderlich bei jedem Thema mitzumachen um sich zu qualifizieren. Jedes Thema ist ein in sich geschlossener Wettbewerb/Ausschreibung.

Neben der Vorgabe eines Kernthemas werden gewissen Randvorgaben gegeben, das heißt zum Beispiel das nur gewisse Programmiersprachen erlaubt sind - dies ist allerdings sehr breit gefächert und variiert von Aufgabe zu Aufgabe, aber in der Regel sind es die "üblichen" Verdächtigen mit denen entwickelt werden darf.

Fragen können in der aller Regel auch eingereicht werden, es gibt auf den unten verlinken Seiten Ansprechpartner zu den Wettbewerben.

Ab und an sind die Aufgaben mal mit GUI, mal Konsolenanwendungen, mal Web bzw. Mobile-Apps, mal mit Basisdaten oder gar Online-Datenquellen die es anzuzapfen gilt, mal können auch Frameworks verwendet werden und vielem mehr.
Es gibt gewisse Vorgaben, aber die endgültige Umsetzung und Herangehensweise wie ein Problem zu lösen ist, wird dem Teilnehmer/euch selbst überlassen. Spielraum gibt es in aller Regel auch so das auch Zusatzfeatures mit einfließen können.

Laufzeit der Wettbewerbe ist immer ein ganzer Monat, Details finden sich aber auf der Seite einer jeweiligen Competition.

Nach Abgabe von Quellcode bei IT-Talents, wird dieser - wie auch die Features und natürlich auch die Funktionalität, bewertet.
Dies Erfolgt per Email direkt wie auch die Bekanntgabe ob man gewonnen hat oder nicht.

---------------------------------------------

Ich würde gern an dieser Stelle ein Sammelthema aufmachen, in dem alte und neue Competitions besprochen werden können und man sich vielleicht ein wenig darüber austauscht.
Selbst wer nicht an den Wettbewerben direkt teilnehmen möchte, kann so vielleicht genaueres darüber erfahren wie andere so eine Aufgabe lösen würden bzw. gelöst haben.

Veröffentlichung von Quellcode sollte hier nicht erforderlich sein und dies sollte jedem selbst überlassen sein, es wäre jedoch schön wenn man sich über Themen/Competitions austauschen könnte, ob alte oder neue sollte hierbei keine Rolle spielen.

Es wäre vielleicht auch eine Idee, gemeinsam, alte Competitions nachzuprogrammieren, wer Lust und Zeit hat, auch wenn es dann nichts mehr abzugrasen gibt. Die Herausforderung ein Problem mittels Code zu lösen bzw. bearbeiten zu lassen, bleibt bestehen.

Nur noch eines ist dazu zu sagen, die Bandbreite der Themen ist recht groß und auch der "Schwierigkeitsgrad" - kommt natürlich auf das allgemeine Verständnis in den Themengebieten an.

---------------------------------------------

Hier die Verlinkungen auf die Seite der Wettbewerbe, zum aktuellen Wettbewerb und zu vorherigen/Archiv - aktuell befindet sich alles auf einer Seite.

----



----



----



---------------------------------------------

Viel Spaß, Erfolg und gutes Gelingen!

Und vielleicht ein paar "hitzige" Diskussionen zu den Themen. :cool:
 
Zuletzt bearbeitet:

drfuture

Zeitreisender
Teammitglied

Registriert
14 Juli 2013
Beiträge
7.766
Ort
in der Zukunft
Klingt interessant :) - wenn sich was rührt kann man den dann auch anpinnen.
Kannst du vielleich für jeden Monat einen Beitrag für das laufende Thema erstellen? Dann kann man das als Marker grün markieren ;)
 

Brother John

(schein)heilig
Teammitglied

Registriert
1 Aug. 2013
Beiträge
235
Code Competition für April 2017: Parsergenerator Markdown

Den finde ich spontan sehr interessant. Es geht darum, einen Parsergenerator von (einer Teilmenge von) Markdown nach HTML zu schreiben.

Teilmenge heißt: Absätze, Überschriften, Listen, Zitatblöcke, fett, kursiv. Also durchaus ein übersichtlicher Umfang.

Frameworks zu verwenden ist erlaubt, und das ist der interessante Punkt. Ich suche schon länger nach einem Grund, mal was mit zu machen. Das würde gut passen. Und die Woche nach Ostern ist Urlaub.

Im Sinne der hitzigen Diskussion ;): Was mich ein bisschen gruselt, ist, dass sie schreiben:
{INPUT}
Es bietet sich die Verwendung von regulären Ausdrücken (Regular Expressions) an.
Wir wissen doch:
I had a problem and tried to solve it with regex. Now I have two problems.
[SUB]Quelle: alte Programmiererweisheit[/SUB]
 

Stingray

Neu angemeldet

Registriert
30 Mai 2015
Beiträge
23
Bedeutet Framework, daß man dann more/less nur in/out baut?
 

theSplit

1998
Teammitglied

Registriert
3 Aug. 2014
Beiträge
27.283
  • Thread Starter Thread Starter
  • #5


So wie ich es verstehe, geht es ja darum einen Parser selbst zu schreiben.

Das heißt dass das Einlesen von Markup behandelt wird, wie auch die Ausgabe/Umwandlung nach HTML.

Aber ich würde von fertigen Bibliotheken eher abraten die beispielsweise schon Markdown Parsing implementieren.
Wenn man das selbst noch bestimmen/aufbauen/definieren muß in einem Framework, sieht es vielleicht wieder anders aus.
 

Brother John

(schein)heilig
Teammitglied

Registriert
1 Aug. 2013
Beiträge
235
Nach Ostern ist Zeit und Urlaub, hab ich gesagt, gell. Also wirds so langsam Zeit für die ersten Überlegungen.

Das ursprüngliche Markdown ist ja nicht spezifiziert, bzw. die »Spezifikation« ist die ursprüngliche Perl-Implementierung. Einen Parser ohne Spec zu schreiben, macht natürlich wenig Spaß. Und durch Perl-Code mag ich mich genauso wenig graben. Zum Glück gibts . An die Spec werde ich mich halten.

Ein bisschen spec-gestöbert hab ich schon; und wow, Markdown schaut auf Anhieb so extrem simpel aus, aber hat es ganz schön in sich. Intuitiv menschenlesbar ist offenbar ne blöde Anforderung, wenn’s auch eindeutig maschinen-parsebar sein soll. Einen vollständigen CommonMark-Parser zu schreiben, würde in richtig Arbeit ausarten.

Todo:

  1. Markdown verstehen. Auch wenn die Aufgabe nur einen kleinen Teil davon fordert, will ich mir keine Türen zusperren. Der Parser muss so gebaut sein, dass man ihn möglichst stressfrei erweitern oder Richtung umbauen kann. Weil eigentlich bin ich eher reST- als Markdown-Fan.
  2. Daraus ergeben sich die Details der Datenstruktur (AST: abstract syntax tree), die der Parser erzeugen soll. Auf den Punkt gebracht: es wird ein Baum aus Textschnipseln mit ein paar Annotationen dran. Und ausnahmsweise brauch ich mich nicht mit einem Typsystem in den Quelldaten rumschlagen, das man im C++-Code wieder abbilden wollen würde. Strings, Strings überall. :)
  3. Parsingstrategie entwicklen. Lässt sich alles in einem Parsingdurchgang abfrühstücken oder brauchts mehrere? Ist Pre-/Postprocessing nötig/sinnvoll? Irgendwo ist jedenfalls ein Grenze, wo man manche Details separat behandeln sollte, weil die Grammatik unnötig kompliziert werden würde, wenn man die dort mit reinpackt.
  4. Grammatik/Parser schreiben, a.k.a. Spaß haben mit Spirit.
  5. Iterator bzw. Visitor schreiben, um über den erzeugten Baum zu laufen. HTML-Ausgabe hinten dran klemmen.

Technisch wird’s wie schon erwähnt C++ mit Boost Spirit X3. Und wahrscheinlich bietet es sich an, das Projekt in eine eigene Parser-Lib, eine Mini-HTML-Writer-Lib und ein Mini-Kommoandozeilenfrontend zu zerlegen.

Der erste Code wird aber erst nach Ostern das Licht der Welt erblicken. Bis dahin bin ich mit Eier suchen beschäftigt. :D

Ich seh das wie theSplit. Einen vorhandenen Markdown-Parser an einen vorhandenen HTML-Writer zu kleben, ist für die Competition wohl ein bisschen dünn. Sie sagen ja auch in der Überschrift:
Erstelle Deinen eigenen Markdown-Parser
 

theSplit

1998
Teammitglied

Registriert
3 Aug. 2014
Beiträge
27.283
  • Thread Starter Thread Starter
  • #7
Ich werde auch an der Challenge teilnehmen, hier mal meine Gedanken dazu (nicht sonderlich fachlich terminiert ;) ):

Für meinen Ansatz habe ich es erst einmal so gewählt, dass nicht mit RegEx gearbeitet wird, sondern Zeichen für Zeichen (mach ich komischerweise oft so, hat aber auch ein paar Tücken...) verarbeitet werden. Ist für mich der aktuell einfachste Ansatz, ohne sich ein RegEx ähnliches Library zu schreiben. Ich bin davon auch nicht unbedingt ein Fan um ganz ehrlich zu sein, was RegEx durch seine Zeichenlogik theoretisch "korrektes" Markup voraussetzt um die "Boundaries" der Expression einzuhalten. Bei meinem Ansatz kann ich da vielleicht noch etwas "mogeln" bzw. ausbessern.

Der Parser ist relativ simpel, was mir aktuell noch aufstößt, ob "WhiteSpace-Stripping" am Zeilenanfang stattfinden soll, um Beispielsweise sicherzustellen das wir immer mit einem "gültigen Wert" anfangen. Also zum Beispiel das die Zeile wirklich mit einem "#" oder "*" oder was auch immer beginnt und nicht mit Leerzeichen vorne weg.

Dann wäre die Frage, da müsste ich mir einmal die Spezifikation nochmal genauer ansehen, ob solche Zeichen wie die Header ("#") nur am Zeilenanfang auftauchen und gültig sind oder ob diese auch frei im Text auftauchen können und dann "ignoriert" werden. Meines Verständnisses nach werden Headlines ja nicht innerhalb des "Textes" definiert, sondern beispielsweise nur am Zeilenanfang.

Im weiteren wäre mein Gedanke die Daten "on the fly" auszuwerten - heißt ein einziger Lese- und Schreibvorgang, zwischengespeichert werden aktuell nur die Informationen über die HTML Knoten die vor dem eigentlichen, formatierten, Inhalt eingebunden werden sollen, wie auch die Logik wann ein Element geschlossen wird.

In der Regel läutet ein Zeilenende, soweit ich das bisher nachvollziehe, auch oftmals ein "Tag"-Ende ein. Ausnahmen wäre aber Paragraphen und Zitate, würde ich meinen - ich glaube aber das Github, zum Beispiel, es irgendwie so handhabt, das für jede Zeile ein neuer "p"-HTMLTag generiert wird, aber da würde ich nochmal die Markup Spezifikation wälzen. Aber entscheident sollte ja hierbei sein, auf die nächste Zeile zu schauen ob "anhängende" Textdaten vorliegen oder ein anderes Markup Element generiert werden soll.

Ich wollte es aber auch so wie @BrotherJohn handhaben:
- ein Kommadozeilenprogramm, mit Input und Output Parameter
- relativ einfacher Parser und Writerlogik (sequentieller Einlesevorgang mit paralleler Ausgabe, MarkupElemente identifizieren, HTML Baum mit linearer Struktur aufbauen und beobachten, HTML Schreiben, Inhalte schreiben, Markup schließen, HTML je nach Fall schließen usw.)

Als Vorlagen habe ich einmal ein einfaches Dokument erstellt, basierend auf der Erklärungsseite zur Competition, und später nen richtigen Github Text, der zwar mehr Elemente enthält, aber alle gesuchten anzutreffen sind.

Bei Interesse kann ich das auch mal hier veröffentlichen.

Ist das einzige Problem das ich für den Wettbewerb anzumerken habe, dass kein Beispiel gemacht wurde mit ein oder zwei Testdateien, einfach um sich daran zu orientieren wie viel Logik erforderlich sein muß. Oder auch noch einen Link zur Markdown Spezifikation oder ähnlichem, man wird ein wenig ins "kalte Wasser" geschmissen. ;)
 

darksider3

NGBler

Registriert
18 Sep. 2013
Beiträge
392
Ort
/dev/sda
Es gibt keine wirkliche standardisierte Spezifikation von Markdown "itself". Es gibt ein Dokument vom . Es gibt dann aber noch das RFC 7764, was MultiMarkdown, Github Flavoured Markdown, CommonMark und Pandoc standardisiert(vlt. sogar noch eins mehr...?)

Aber "ursprünglich" wurde Recht wenig Vorgegeben. Deshalb gibt's ja auch so viele Varianten.
Du kannst im Prinzip einfach alles stumpf durchparsen und davon ausgehen, dass jemand immer korrekt die Tags(#) setzt, oder aber die Vorgabe machen.
Da man aber einen Header nicht terminieren/beenden kann, ist es auch durchaus logisch anzunehmen, dass man solche nur am Zeilenanfang valide machen kann, gerade auch weil kein Escaping(``) gegeben ist. Das ist zumindest beim GFM so. Ursprünglich wurde mit # terminiert(wenn man es so wollte.)

Whitespaces am Zeilenanfang würde ich einfach wie Text behandeln, beim Parsen aber einen Hinweis(WARNING: FILE X LINE X, first char in line is space!) ausgeben. Oder komplett durchweg ignorieren, aber auf keinen Fall rausnehmen.


Justmy2cents.
mfg
 
Zuletzt bearbeitet:

theSplit

1998
Teammitglied

Registriert
3 Aug. 2014
Beiträge
27.283
  • Thread Starter Thread Starter
  • #9
Habe schon ein ersten Testlauf gemacht und nach einigen Stunden frickeln, lüppt es auch.... das ganze läuft sogar ohne einen Buffer in jeglicher Form - allerdings gibt es Probleme wenn "Markdown" Elemente innerhalb des Textes auftauchen, aber nur "beschrieben" sind.

Das ganze will ich nur mal Showcasen, wie gut oder schlecht die Erkennung aktuell mit einer "on-the-fly" Parser-Writer Base ist (~300 Zeilen Code bisher, nur ein paar generelle Code-Outline/Kommentare).


Testinput:

[src=html5]#Markdown Parser

##Erstelle Deinen eigenen Markdown-Parser und wandle Markdown-Code in HTML-Code um.
**Du hast noch: 22 Tage 10 Stunden 59 Minuten 15 Sekunden**

#{ABOUT}
Was ist eigentlich ein Parser?

Mit **Hilfe von Parsern wird eine Eingabe zerlegt, analysiert und daraus eine Ausgabe in einem anderen Format erstellt**. In *der Regel wird* also *eine (Text-)Eingabe in eine neue Struktur übersetzt*.
Und so soll es auch bei dieser Code Competition sein. Du sollst einen Parser (=Übersetzer) schreiben, der Markdown-Dokumente in HTML-Quellocde übersetzt.

##{INPUT}
* Es bietet sich die Verwendung von regulären Ausdrücken (Regular Expressions) an.

Deine Abgabe soll:

* Die Eingabe eines mit Markdown strukturierten Dokuments erlauben. Hierbei ist die Eingabe über einen Textbereich in einer GUI möglich, aber auch das Einlesen einer Datei (über eine GUI, oder über die Kommandozeile).
* Folgende Markdown-Syntax soll berücksichtigt werden und entsprechend in HTML-Code umgewandelt werden:

Markdown-Zeichen HMTL-Code
# h1-Überschrift
## h2-Überschrift
* Ein Stern am Anfang einer Zeile beginnt eine Auflistung (Jedes Element einer Liste wird mit einem Stern gekennzeichnet)
**fetter_text** Ein fett geschriebener Text wird mit zwei Sternen (**) eingeleitet und wieder beendet.
*kursiver_text* Kursiv geschriebener Text wird mit einem Stern eingeleitet und einem Stern beendet (*)
> Ein Zitat wird durch ein > am Zeilenanfang eingeleitet
Leerzeile Ein Paragraph wird durch eine Leerzeile zwischen Textblücken angegeben.


#{REVIEW}

**Worauf achten wir bei der Bewertung Deiner Abgabe?**

* Funktionalität: Lässt sich das Programm bedienen? Tut die Anwendung oder die Funktion, was sie soll? Wie umfangreich sind die Funktionen?
* Code-Qualität: Ist der Code sinnvoll strukturiert und effizient?
* Code-Lesbarkeit / Dokumentation: Lässt sich der Quellcode nachvollziehen? Ist der Code kommentiert?
* Setup: Ist das System einfach einzurichten / aufzusetzen? (z.B. mittels guter Dokumentation, Docker, Vagrant, Skripte, o.ä.)
* Welche Zusatzfeatures wurden eingebaut?

**Wie bewerten wir?**

##{POST}
[/src]


Output:

[src=html5]<h1>Markdown Parser</h1>

<h2>Erstelle Deinen eigenen Markdown-Parser und wandle Markdown-Code in HTML-Code um.</h2>
<p><strong>Du hast noch: 22 Tage 10 Stunden 59 Minuten 15 Sekunden</strong></p>

<h1>{ABOUT}</h1>
<p>Was ist eigentlich ein Parser?</p>

<p>Mit <strong>Hilfe von Parsern wird eine Eingabe zerlegt, analysiert und daraus eine Ausgabe in einem anderen Format erstellt</strong>. In <em>der Regel wird</em> also eine (Text-)Eingabe in eine neue Struktur übersetzt.
Und so soll es auch bei dieser Code Competition sein. Du sollst einen Parser (=Übersetzer) schreiben, der Markdown-Dokumente in HTML-Quellocde übersetzt.</p>

<h2>{INPUT}</h2>
<ul><li>Es bietet sich die Verwendung von regulären Ausdrücken (Regular Expressions) an.</li></ul>

<p>Deine Abgabe soll:</p>

<ul><li>Die Eingabe eines mit Markdown strukturierten Dokuments erlauben. Hierbei ist die Eingabe über einen Textbereich in einer GUI möglich, aber auch das Einlesen einer Datei (über eine GUI, oder über die Kommandozeile).</li>
<li>Folgende Markdown-Syntax soll berücksichtigt werden und entsprechend in HTML-Code umgewandelt werden:</li></ul>

<p>Markdown-Zeichen HMTL-Code
<h1> h1-Überschrift</h1>
<h2> h2-Überschrift</h2>
<ul><li> Ein Stern am Anfang einer Zeile beginnt eine Auflistung (Jedes Element einer Liste wird mit einem Stern gekennzeichnet)</li></ul>
<strong>fetter_text</strong> Ein fett geschriebener Text wird mit zwei Sternen () eingeleitet und wieder beendet.
<em>kursiver_text</em> Kursiv geschriebener Text wird mit einem Stern eingeleitet und einem Stern beendet ()
<blockquote><pre><code> Ein Zitat wird durch ein > am Zeilenanfang eingeleitet</code></pre></blockquote>
Leerzeile Ein Paragraph wird durch eine Leerzeile zwischen Textblücken angegeben.</p>


<h1>{REVIEW}</h1>

<p><strong>Worauf achten wir bei der Bewertung Deiner Abgabe?</strong></p>

<ul><li>Funktionalität: Lässt sich das Programm bedienen? Tut die Anwendung oder die Funktion, was sie soll? Wie umfangreich sind die Funktionen?</li>
<li>Code-Qualität: Ist der Code sinnvoll strukturiert und effizient?</li>
<li>Code-Lesbarkeit / Dokumentation: Lässt sich der Quellcode nachvollziehen? Ist der Code kommentiert?</li>
<li>Setup: Ist das System einfach einzurichten / aufzusetzen? (z.B. mittels guter Dokumentation, Docker, Vagrant, Skripte, o.ä.)</li>
<li>Welche Zusatzfeatures wurden eingebaut?</li></ul>

<p><strong>Wie bewerten wir?</strong></p>

<h2>{POST}</h2>[/src]

Schon gut bei finde ich, aber es gibt noch ein paar kleinere Bugs... :)

Zum Beispiel die doppelten "em" bzw. "*" im ersten Absatz wie in der Vorlage vereinbart, dort wird nur das erste aktuell ausgewertet.

PS: Das ganze habe ich aber schon gestern angefangen, aber auch nur für 3 Stunden circa.
 

GoPro

visual basic

Registriert
25 Juni 2016
Beiträge
90
Mir scheint, dass der Herausforderung bei Regex liegt, mehr, als da ein paar Ersetzungen in Zeichenketten vorzunehmen.
Aufzählungen, 2 Arten von Überschriften und Absätze wirken jetzt nicht so furchteinflössend.

Aber mir ist der Nutzen von Regex nicht so klar. Mir ist das 2 oder 3 mal untergekommen und Dank Internet hat es funktioniert. Aber Wem wird da was durch erleichtert.
Klar, man kann Filter für Zeichenketten sehr kurz schreiben. Aber für wen lohnt sich der Aufwand?
Manchmal währe bei Vorlesungen/Vorträgen Steno auch praktisch, aber das werde ich dennoch deswegen nicht lernen.
Gibt es da Laufzeitvorteile? Ich sehe da eine enorm steile Lernkurve, aber nicht den Nutzen.
Vielleicht gibt es hier jemanden aus der Praxis, wo ,man das sinnvoll einsetztß
 

Brother John

(schein)heilig
Teammitglied

Registriert
1 Aug. 2013
Beiträge
235
Dann haben wir ja schonmal zwei recht verschiedene Ansätze. TheSplit konzentriert sich auf den Lowlevel-Parsingprozess und ich mich darauf, eine effiziente Grammatik zu definieren.

Zum selben Ergebnis müssten wir trotzdem kommen. Zumindest halbwegs. Die Aufgabenstellung hat da echt ein paar Kanten. Weil was da steht, widerspricht in Teilen der Spec. Z.B. dürfen im echten Markdown/CommonMark Blockquotes bis zu drei Leerzeichen vor dem > haben. Die Aufgabe sagt: „am Zeilenanfang“. Andererseits ist so eine oberflächlich ungenaue Beschreibung genau das, was ich in der echten Welt von einem Auftraggeber erwarten würde. Also im Zweifel für den Angeklagten, oder? Dann ist es halt Teil der Aufgabe, mit solchen Unklarheiten zurecht zu kommen.

@theSplit
Für 3h Arbeit ist das doch schon sehr ordentlich! :) Ich hab mir auch ein kleines Testdokument mit Grenzfällen gebaut (siehe unten). Schau doch mal, was dein Parser draus macht.

Testdokument.md
Code:
# Ein Testdokument

Absätze sind die grundlegenden Blockelemente.

Ein neuer Absatz braucht mindestens eine Leerzeile.


Mehrere geht genauso und führen zum gleichen Ergebnis.

Einen Absatz darf man beliebig
umbrechen. Es bleibt ein einzelner Absatz ohne (!) Zeilenumbruch. Bonus: Harte Zeilenumbrüche innerhalb eines Absatzes (aber nicht am Absatzanfang oder -ende) macht man am Zeilenende mit einem Backslash oder mindestens zwei Leerzeichen. Ja, Leerzeichen. Vollkommen bescheuerte Idee, finde ich, aber so ists festgelegt.

Führende Leerzeichen sind ok
          und werden entfernt.

   Ausnahme: Bei der ersten Zeile eines Absatzes dürfen es max. 3 LZ sein, sonst wird ein Codeblock draus – der von der Aufgabe nicht gefordert ist. Also könnte man auf die Spezialbehandlung für erste Zeilen verzichten.

Viel Inline-Formatierung ist ja nicht gefordert: **Fett** und *kursiv*. Was kann man denn damit noch anstellen ... Wer sagt eigentlich, dass man immer nur ganze Wörter formatieren will: Donau*dampf*schifffahrts**kapitäns**mütze.

In der Aufgabe steht nichts von geschachtelter Formatierung, Aber ***fettkursiv*** oder **fett und *kursiv*** ist ja nicht sooo weit aus der Welt. Trotzdem würde ich das als Bonus ansehen.

Inline-Formatierung wird der Reihe nach geparst und dangling Sternchen bleiben simple Sternchen. Beispiel: In *C++* (kursiv) wird der Pointer mit einem Sternchen (*) markiert. Der komplette Regelsatz ist relativ komplex und steht hier: http://spec.commonmark.org/0.27/#emphasis-and-strong-emphasis

Zu den Überschriften: Da die Aufgabenstellung so vage ist, alles laut Spec.

### Laut Aufgabenstellung ist dies keine Überschrift, sondern ein normaler Absatz (da nur H1 und H2 gefordert sind).

#Auch ein normaler Absatz, da mindestens ein Leerzeichen nach dem # stehen muss.

# normale H1-Überschrift
#    genauso normale H1-Überschrift
# auch eine normale H1 mit optionalem schließenden Hash #
# auch das ist eine normale H1, die Anzahl der Schließhashes muss nicht übereinstimmen ##

## normale H2
## H2: keine Schließhashes, da nicht per Leerzeichen getrennt####
## H2: keine Schließhashes, da noch ## Text danach

Spec sagt: “The opening # character may be indented 0-3 spaces.”

 # H1
  # H1
   # H1
    # keine H1. Eigentlich ein Codeblock, aber der ist von der Aufgabe nicht gefordert. Ich würde es als normalen Absatz interpretieren.

Mehrzeilige Überschriften geht nicht. Leerzeilen vor/nach Überschriften sind optional.

Ein Absatz.
## Eine H2
Noch ein Absatz. ##

Nicht von den Hashes am Ende verwirren lassen!


## > Das hier ist eine interessant formatierte H2-Überschrift <

Und wenn wir schon bei den spitzen Klammern sind:

> Ein Zitatabsatz

Oder umgebrochen:

> Auch das ist
> ein einzelner Zitatabsatz (ohne harten Zeilenumbruch!).

Normale Zeilenumbrüche werden genauso behandelt wie im Fließtext.

> Ein einzelner Zitatabsatz
mit Umbruch.

Man kann das natürlich auch kombinieren:

> Das mit dem Zitieren
schaut auf Anhieb einfach aus.
> Isses aber nich. Denn dieser ganze Block hier
> ist ein einzelner Zitatabsatz.

Leerzeilen trennen Zitate.

> Zitat 1

> Zitat 2

Im Vergleich zu:

> Ein einzelnes Zitat.
>
> Es hat zwei Absätze.

Eines noch:

> Das Leerzeichen nach der spitzen Klammer
>ist optional.


## Listen

Lasst uns Sachen auflisten; weil man mit Listen trotz der *am Zeilenanfang*-Einschränkung sooo viel Mist bauen kann! :D

* eins
* zwei
* drei

So weit, so einfach.

* eins
* **zwei** in fett
* *drei* in kursiv
* *Nein, das ist
* nicht kursiv*. Das sind zwei Listenpunkte mit jeweils einem Stern im Text.

Folgendes

*ist laut Spec
*keine Liste, sondern ein Absatz, der zwei Sternchen im Text hat. Wichtig: Kein kursiv wegen dem Zeilenumbruch direkt vor dem zweiten Stern!

Apropos Absätze:

* langweiliger kurzer Listenpunkt
* Der hier ist ein bisschen länglicher.

  V.a. hat er einen zweiten Absatz.
* noch ein Punkt
* und noch einer

Huch!

*

Ein einzelner Stern!? Das ist eine Liste mit einem einzelnen leeren Listenpunkt.

Aber Vorsicht! Ein leerer Listenpunkt
*
unterbricht nicht einen Absatz! Das da eine Zeile höher ist ein simpler Stern.

Alles was leer ist, ist ein wunderschöner Grenzfall. Z.B.:

*
  Was ist das denn?
* Na logisch! Ein Listenpunkt mit führender Leerzeile.
* Todo: Nachlesen, was mit dem Zeilenumbruch passieren soll. Schlucken wie in normalen Absätzen? Oder bleibt der?

Ein leerer Punkt in einer Liste? Logisch:

* eins
*
* drei

Leere Zeilen sind auch was Feines. Sie trennen normalerweise Absätze. In Listen sieht das ein bisschen anders aus.

* Leerzeilen

* zwischen Listenpunkten
* sind erlaubt


* auch mehrere Leerzeilen

Das da oben ist eine einzelne Liste.

* Die Aufgabenstellung fordert den Listenpunkt *am Zeilenanfang*.
  * Das hier ist also keine geschachtelte Liste (im Gegensatz zur Spec).

Sondern? Ähm ... Ich würde sagen: eine Liste mit einem einzelnen Absatz in einem einzelnen Listenpunkt. Der Absatz enthält einen weichen Zeilenumbruch und ein dangling Sternchen.

@GoPro
Regex sind oft sehr nützlich um kurze Sachen sehr kompakt zu validieren. Z.B. hast du mit
Code:
^[_a-zA-Z][_a-zA-Z0-9]*$
einen guten Teil der Validierung für einen gültigen C++-Identifier erledigt. Der muss mindestens ein Zeichen lang sein, mit Unterstrich oder Buchstabe anfangen und danach dürften beliebig viele Zeichen aus Unterstrich, Buchstabe oder Zahl folgen. Wenn du das alternativ als Schleife hinschreibst, ist das deutlich länger und weniger lesbar.

Oder du weißt, dass Zeilen in deinen Serverlogs irgendwo das Datum im Format YYYY-MM-DD enthalten und willst darauf zugreifen (\w ist eine Wortgrenze und \d ist eine Zahl, die runden Klammer ziehen dir das gefundene Pattern als direkt zugreifbare Gruppe raus):
Code:
\w(\d{4}-\d{2}-\d{2})\w
Validierung von E-Mail-Adressen macht man auch gerne mit Regex. Halte ich aber für grenzwertig, weil du solche Regex ohne erweiterte Syntax schon nicht mehr verstehen kannst, die dir Zeilenumbrüche und Kommentare erlaubt.

Das Laufzeitverhalten kommt ganz auf die Implementierung und die Situation an. Je nachdem kannst du mit Regex sehr schnell oder sehr langsam sein.
 

theSplit

1998
Teammitglied

Registriert
3 Aug. 2014
Beiträge
27.283
  • Thread Starter Thread Starter
  • #12
Nene, so schnell und gut bin ich auch nicht, insgesamt hab ich gestern ja auch noch 6 Stunden und heute daran gearbeitet, aber bei weitem nicht so schicke "Testaufgaben" erstellt wie du sie dir vorbereitet hast.
Ich habe es mir relativ einfach gemacht und einen normalen "Markdown" Text bzw. Beispiele zur Hand genommen. Siehe Github und andere Seiten wenn man einfach mal nach "Markdown Example" sucht.

Also, ich kann dir folgenden Output anbieten: :)

[src=html5]<h1> BROTHER JOHNS TESTDOKUMENT ERGEBNIS</h1>

<h1> Ein Testdokument</h1>

<p>Absätze sind die grundlegenden Blockelemente.</p>

<p>Ein neuer Absatz braucht mindestens eine Leerzeile.</p>


<p>Mehrere geht genauso und führen zum gleichen Ergebnis.</p>

<p>Einen Absatz darf man beliebig<br/>
umbrechen. Es bleibt ein einzelner Absatz ohne (!) Zeilenumbruch. Bonus: Harte Zeilenumbrüche innerhalb eines Absatzes (aber nicht am Absatzanfang oder -ende) macht man am Zeilenende mit einem Backslash oder mindestens zwei Leerzeichen. Ja, Leerzeichen. Vollkommen bescheuerte Idee, finde ich, aber so ists festgelegt.</p>

<p>Führende Leerzeichen sind ok<br/>
und werden entfernt.</p>

<p> Ausnahme: Bei der ersten Zeile eines Absatzes dürfen es max. 3 LZ sein, sonst wird ein Codeblock draus – der von der Aufgabe nicht gefordert ist. Also könnte man auf die Spezialbehandlung für erste Zeilen verzichten.</p>

<p>Viel Inline-Formatierung ist ja nicht gefordert: <strong>Fett</strong> und <em>kursiv</em>. Was kann man denn damit noch anstellen ... Wer sagt eigentlich, dass man immer nur ganze Wörter formatieren will: Donau<em>dampf</em>schifffahrts<strong>kapitäns</strong>mütze.</p>

<p>In der Aufgabe steht nichts von geschachtelter Formatierung, Aber <strong></strong><em>fettkursiv</em></strong></em> oder <strong>fett und </strong><em>kursiv</em></strong></em> ist ja nicht sooo weit aus der Welt. Trotzdem würde ich das als Bonus ansehen.</p>

<p>Inline-Formatierung wird der Reihe nach geparst und dangling Sternchen bleiben simple Sternchen. Beispiel: In <em>C++</em> (kursiv) wird der Pointer mit einem Sternchen (*) markiert. Der komplette Regelsatz ist relativ komplex und steht hier: http://spec.commonmark.org/0.27/#emphasis-and-strong-emphasis</p>

<p>Zu den Überschriften: Da die Aufgabenstellung so vage ist, alles laut Spec.</p>

<h3> Laut Aufgabenstellung ist dies keine Überschrift, sondern ein normaler Absatz (da nur H1 und H2 gefordert sind).</h3>

<h1>Auch ein normaler Absatz, da mindestens ein Leerzeichen nach dem # stehen muss.</h1>

<h1> normale H1-Überschrift</h1>
<h1> genauso normale H1-Überschrift</h1>
<h1> auch eine normale H1 mit optionalem schließenden Hash #</h1>
<h1> auch das ist eine normale H1, die Anzahl der Schließhashes muss nicht übereinstimmen ##</h1>

<h2> normale H2</h2>
<h2> H2: keine Schließhashes, da nicht per Leerzeichen getrennt####</h2>
<h2> H2: keine Schließhashes, da noch ## Text danach</h2>

<p>Spec sagt: “The opening # character may be indented 0-3 spaces.”</p>

<p> # H1<br/>
# H1<br/>
# H1<br/>
# keine H1. Eigentlich ein Codeblock, aber der ist von der Aufgabe nicht gefordert. Ich würde es als normalen Absatz interpretieren.</p>

<p>Mehrzeilige Überschriften geht nicht. Leerzeilen vor/nach Überschriften sind optional.</p>

<p>Ein Absatz.<br/>
<h2> Eine H2</h2>
Noch ein Absatz. ##</p>

<p>Nicht von den Hashes am Ende verwirren lassen!</p>


<h2> > Das hier ist eine interessant formatierte H2-Überschrift <</h2>

<p>Und wenn wir schon bei den spitzen Klammern sind:</p>

<blockquote><pre><code> Ein Zitatabsatz</code></pre></blockquote>

<p>Oder umgebrochen:</p>

<blockquote><pre><code> Auch das ist
ein einzelner Zitatabsatz (ohne harten Zeilenumbruch!).</code></pre></blockquote>

<p>Normale Zeilenumbrüche werden genauso behandelt wie im Fließtext.</p>

<blockquote><pre><code> Ein einzelner Zitatabsatz</code></pre></blockquote>
<p>mit Umbruch.</p>

<p>Man kann das natürlich auch kombinieren:</p>

<blockquote><pre><code> Das mit dem Zitieren</code></pre></blockquote>
<p>schaut auf Anhieb einfach aus.<br/>
<blockquote><pre><code> Isses aber nich. Denn dieser ganze Block hier
ist ein einzelner Zitatabsatz.</code></pre></blockquote></p>

<p>Leerzeilen trennen Zitate.</p>

<blockquote><pre><code> Zitat 1</code></pre></blockquote>

<blockquote><pre><code> Zitat 2</code></pre></blockquote>

<p>Im Vergleich zu:</p>

<blockquote><pre><code> Ein einzelnes Zitat.

Es hat zwei Absätze.</code></pre></blockquote>

<p>Eines noch:</p>

<blockquote><pre><code> Das Leerzeichen nach der spitzen Klammer
ist optional.</code></pre></blockquote>


<h2> Listen</h2>

<p>Lasst uns Sachen auflisten; weil man mit Listen trotz der <em>am Zeilenanfang</em>-Einschränkung sooo viel Mist bauen kann! :D</p>

<ul><li>eins</li>
<li>zwei</li>
<li>drei</li></ul>

<p>So weit, so einfach.</p>

<ul><li>eins</li>
<p><strong></strong><em>zwei</em></strong> in fett</em><br/>
</em>**drei</em> in kursiv<br/>
**Nein, das ist<br/>
<ul><li>nicht kursiv*. Das sind zwei Listenpunkte mit jeweils einem Stern im Text.</li></ul></p>

<p>Folgendes</p>

*ist laut Spec
*keine Liste, sondern ein Absatz, der zwei Sternchen im Text hat. Wichtig: Kein kursiv wegen dem Zeilenumbruch direkt vor dem zweiten Stern!

<p>Apropos Absätze:</p>

<ul><li>langweiliger kurzer Listenpunkt</li>
<li>Der hier ist ein bisschen länglicher.</li></ul>

<p> V.a. hat er einen zweiten Absatz.<br/>
<ul><li>noch ein Punkt</li>
<li>und noch einer</li></ul></p>

<p>Huch!</p>

*

<p>Ein einzelner Stern!? Das ist eine Liste mit einem einzelnen leeren Listenpunkt.</p>

<p>Aber Vorsicht! Ein leerer Listenpunkt<br/>
</p>*
<p>unterbricht nicht einen Absatz! Das da eine Zeile höher ist ein simpler Stern.</p>

<p>Alles was leer ist, ist ein wunderschöner Grenzfall. Z.B.:</p>

*
<p> Was ist das denn?<br/>
<ul><li>Na logisch! Ein Listenpunkt mit führender Leerzeile.</li>
<li>Todo: Nachlesen, was mit dem Zeilenumbruch passieren soll. Schlucken wie in normalen Absätzen? Oder bleibt der?</li></ul></p>

<p>Ein leerer Punkt in einer Liste? Logisch:</p>

<ul><li>eins</li></ul>
*
<li>drei</li></ul>

<p>Leere Zeilen sind auch was Feines. Sie trennen normalerweise Absätze. In Listen sieht das ein bisschen anders aus.</p>

<ul><li>Leerzeilen</li></ul>

<li>zwischen Listenpunkten</li>
<li>sind erlaubt</li></ul>


<li>auch mehrere Leerzeilen</li></ul>

<p>Das da oben ist eine einzelne Liste.</p>

<ul><li>Die Aufgabenstellung fordert den Listenpunkt <em>am Zeilenanfang</em>.</li></ul>
<p> * Das hier ist also keine geschachtelte Liste (im Gegensatz zur Spec).</p>

<p>Sondern? Ähm ... Ich würde sagen: eine Liste mit einem einzelnen Absatz in einem einzelnen Listenpunkt. Der Absatz enthält einen weichen Zeilenumbruch und ein dangling Sternchen.</p>[/src]

Im übrigen sehr schön geschrieben *neidisch bin* :cool:

Ich glaube das verwirrenste für meinen Parser, die "Dangling" Sterne - leere Listenelemente (weil nicht nach "newline" geprüft wird, sondern Leerzeichen) und ähnliches um ein Objekt als "valide" zu beschreiben, ansonsten könnte das nämlich auch "kursiver Text" sein + deine gemischte Formatierung.

Wie du siehst habe ich auch keine White-Space stripping für die Header Elemente, eigentlich bleibt alles "intakt". Kann aber muß nicht gewollt sein, kann man aber auch noch mit einbinden denke ich... zumindest das erste Space nach einer Raute bzw. in Header-Elementen...

Im Browser werden übrigens die Spaces "ignoriert" die am Anfang der Zeile sind.

*Edit:
Hier gibt es auch noch einen guten Überblick was die Elemente eventuell machen können sollten, aber soweit bin ich auch noch nicht ;)




*Edit2:

Und ein Update, jetzt passt es auch mit dem verschachtelten Tags und Bonus aus Brother Johns Testdokument ;)
Und auch die Orphanen "*" werden auch teilweise einbezogen. Und Zitate werden besser behandelt...


[src=html5]<h1> BROTHER JOHNS TESTDOKUMENT</h1>

<h1> Ein Testdokument</h1>

<p>Absätze sind die grundlegenden Blockelemente.</p>

<p>Ein neuer Absatz braucht mindestens eine Leerzeile.</p>


<p>Mehrere geht genauso und führen zum gleichen Ergebnis.</p>

<p>Einen Absatz darf man beliebig<br/>
umbrechen. Es bleibt ein einzelner Absatz ohne (!) Zeilenumbruch. Bonus: Harte Zeilenumbrüche innerhalb eines Absatzes (aber nicht am Absatzanfang oder -ende) macht man am Zeilenende mit einem Backslash oder mindestens zwei Leerzeichen. Ja, Leerzeichen. Vollkommen bescheuerte Idee, finde ich, aber so ists festgelegt.</p>

<p>Führende Leerzeichen sind ok<br/>
und werden entfernt.</p>

<p> Ausnahme: Bei der ersten Zeile eines Absatzes dürfen es max. 3 LZ sein, sonst wird ein Codeblock draus – der von der Aufgabe nicht gefordert ist. Also könnte man auf die Spezialbehandlung für erste Zeilen verzichten.</p>

<p>Viel Inline-Formatierung ist ja nicht gefordert: <strong>Fett</strong> und <em>kursiv</em>. Was kann man denn damit noch anstellen ... Wer sagt eigentlich, dass man immer nur ganze Wörter formatieren will: Donau<em>dampf</em>schifffahrts<strong>kapitäns</strong>mütze.</p>

<p>In der Aufgabe steht nichts von geschachtelter Formatierung, Aber <strong><em>fettkursiv</em></strong> oder **fett und *kursiv* ist ja nicht sooo weit aus der Welt. Trotzdem würde ich das als Bonus ansehen.</p>

<p>Inline-Formatierung wird der Reihe nach geparst und dangling Sternchen bleiben simple Sternchen. Beispiel: In <em>C++</em> (kursiv) wird der Pointer mit einem Sternchen (*) markiert. Der komplette Regelsatz ist relativ komplex und steht hier: http://spec.commonmark.org/0.27/#emphasis-and-strong-emphasis</p>

<p>Zu den Überschriften: Da die Aufgabenstellung so vage ist, alles laut Spec.</p>

<h3> Laut Aufgabenstellung ist dies keine Überschrift, sondern ein normaler Absatz (da nur H1 und H2 gefordert sind).</h3>

<h1>Auch ein normaler Absatz, da mindestens ein Leerzeichen nach dem # stehen muss.</h1>

<h1> normale H1-Überschrift</h1>
<h1> genauso normale H1-Überschrift</h1>
<h1> auch eine normale H1 mit optionalem schließenden Hash #</h1>
<h1> auch das ist eine normale H1, die Anzahl der Schließhashes muss nicht übereinstimmen ##</h1>

<h2> normale H2</h2>
<h2> H2: keine Schließhashes, da nicht per Leerzeichen getrennt####</h2>
<h2> H2: keine Schließhashes, da noch ## Text danach</h2>

<p>Spec sagt: “The opening # character may be indented 0-3 spaces.”</p>

<p> # H1<br/>
# H1<br/>
# H1<br/>
# keine H1. Eigentlich ein Codeblock, aber der ist von der Aufgabe nicht gefordert. Ich würde es als normalen Absatz interpretieren.</p>

<p>Mehrzeilige Überschriften geht nicht. Leerzeilen vor/nach Überschriften sind optional.</p>

<p>Ein Absatz.<br/>
<h2> Eine H2</h2>
Noch ein Absatz. ##</p>

<p>Nicht von den Hashes am Ende verwirren lassen!</p>


<h2> > Das hier ist eine interessant formatierte H2-Überschrift <</h2>

<p>Und wenn wir schon bei den spitzen Klammern sind:</p>

<blockquote><pre><code> Ein Zitatabsatz</code></pre></blockquote>

<p>Oder umgebrochen:</p>

<blockquote><pre><code> Auch das ist<br/>
ein einzelner Zitatabsatz (ohne harten Zeilenumbruch!).</code></pre></blockquote>

<p>Normale Zeilenumbrüche werden genauso behandelt wie im Fließtext.</p>

<blockquote><pre><code> Ein einzelner Zitatabsatz<br/>
mit Umbruch.</code></pre></blockquote>

<p>Man kann das natürlich auch kombinieren:</p>

<blockquote><pre><code> Das mit dem Zitieren<br/>
schaut auf Anhieb einfach aus.<br/>
Isses aber nich. Denn dieser ganze Block hier<br/>
ist ein einzelner Zitatabsatz.</code></pre></blockquote>

<p>Leerzeilen trennen Zitate.</p>

<blockquote><pre><code> Zitat 1</code></pre></blockquote>

<blockquote><pre><code> Zitat 2</code></pre></blockquote>

<p>Im Vergleich zu:</p>

<blockquote><pre><code> Ein einzelnes Zitat.<br/>
<br/>
Es hat zwei Absätze.</code></pre></blockquote>

<p>Eines noch:</p>

<blockquote><pre><code> Das Leerzeichen nach der spitzen Klammer<br/>
ist optional.</code></pre></blockquote>


<h2> Listen</h2>

<p>Lasst uns Sachen auflisten; weil man mit Listen trotz der <em>am Zeilenanfang</em>-Einschränkung sooo viel Mist bauen kann! :D</p>

<ul><li>eins</li>
<li>zwei</li>
<li>drei</li></ul>

<p>So weit, so einfach.</p>

<ul><li>eins</li>
<li><strong>zwei</strong> in fett</li>
<ul><li><em>drei</em> in kursiv</li>
<ul><li>*Nein, das ist</li>
<li>nicht kursiv*. Das sind zwei Listenpunkte mit jeweils einem Stern im Text.</li></ul>

<p>Folgendes</p>

*ist laut Spec
*keine Liste, sondern ein Absatz, der zwei Sternchen im Text hat. Wichtig: Kein kursiv wegen dem Zeilenumbruch direkt vor dem zweiten Stern!

<p>Apropos Absätze:</p>

<ul><li>langweiliger kurzer Listenpunkt</li>
<li>Der hier ist ein bisschen länglicher.</li></ul>

<p> V.a. hat er einen zweiten Absatz.<br/>
<ul><li>noch ein Punkt</li>
<li>und noch einer</li></ul></p>

<p>Huch!</p>

<ul><li></li></ul>
<p>Ein einzelner Stern!? Das ist eine Liste mit einem einzelnen leeren Listenpunkt.</p>

<p>Aber Vorsicht! Ein leerer Listenpunkt<br/>
<ul><li>unterbricht nicht einen Absatz! Das da eine Zeile höher ist ein simpler Stern.</li></ul></p>

<p>Alles was leer ist, ist ein wunderschöner Grenzfall. Z.B.:</p>

<ul><li> Was ist das denn?</li>
<li>Na logisch! Ein Listenpunkt mit führender Leerzeile.</li>
<li>Todo: Nachlesen, was mit dem Zeilenumbruch passieren soll. Schlucken wie in normalen Absätzen? Oder bleibt der?</li></ul>

<p>Ein leerer Punkt in einer Liste? Logisch:</p>

<ul><li>eins</li></ul>
<li>* drei</li></ul>

<p>Leere Zeilen sind auch was Feines. Sie trennen normalerweise Absätze. In Listen sieht das ein bisschen anders aus.</p>

<ul><li>Leerzeilen</li></ul>

<li>zwischen Listenpunkten</li>
<li>sind erlaubt</li></ul>


<li>auch mehrere Leerzeilen</li></ul>

<p>Das da oben ist eine einzelne Liste.</p>

<ul><li>Die Aufgabenstellung fordert den Listenpunkt <em>am Zeilenanfang</em>.</li></ul>
<p> * Das hier ist also keine geschachtelte Liste (im Gegensatz zur Spec).</p>

<p>Sondern? Ähm ... Ich würde sagen: eine Liste mit einem einzelnen Absatz in einem einzelnen Listenpunkt. Der Absatz enthält einen weichen Zeilenumbruch und ein dangling Sternchen.</p>[/src]
 
Zuletzt bearbeitet:

theSplit

1998
Teammitglied

Registriert
3 Aug. 2014
Beiträge
27.283
  • Thread Starter Thread Starter
  • #13
Auch auf die Gefahr hin, diesen Thread mit meinem Kram zuzuspammen, hier mal der letzte Stand, mit dem ich zufrieden bin:

Einmal den Input und dann der Output, ich habe mich bewusst nicht nur auf Brother Johns - zum Teil Corner Case Situationen allein bezogen, auch wenn ich sagen muß das mir das Dokument in vielerlei Hinsicht auch die Augen geöffnet hat, was man so noch alles berücksichtigen muß bzw. könnte.

Ich glaube die verschiedenen Fälle sind ganz gut abgedeckt - und immer noch ohne einen Zeichenpuffer zu verwenden und on-the-fly.

Wenn daran Interesse besteht würde ich auf manche Punkte eingehen, zum Beispiel warum ich manche Vorschläge die Brother John gegeben hatte, brechen würde oder warum etwas anders aussieht als bei ihm vorgeschlagen.

Spontan fallen mir zum Beispiel ein:
- keine Implementierung von fett und kursiv, nur fett, kursive und fettkursiv aber kein Mischen von fett und kursiv
- Listen innerhalb von Paragraphen - warum sollen Sternchen, die nicht der Formatierung von Textschnitten dienen, anders behandelt werden
- Zeileumbrüche in Paragraphen, ich setzte zum Beispiel voraus, dass die neue Zeile mit einem Space beginnt, ansonsten haben wir keinen Umbruch - aber wir verwenden den automatischen Umbruch im Browser wenn dieser die Zeile nicht ebenfalls "zusammenführt"
- Zeilenumbrüche in Zitat-Blöcken, ja, schon drin, aber es gibt auch andere Punkte - zum Beispiel das ein Zitat das mit ">" fortgesetzt wird, zusammenhängt, fehlt dieses, machen wir einen harten Umbruch
usw...


Input, das einfachere Testdokument von mir, eines aus dem Web und dem Bruder seins ;)

[src=html5]#Markdown Parser

##Erstelle Deinen eigenen Markdown-Parser und wandle Markdown-Code in HTML-Code um.
**Du hast noch: 22 Tage 10 Stunden 59 Minuten 15 Sekunden**

#{ABOUT}
Was ist eigentlich ein Parser?

Mit **Hilfe von Parsern wird eine Eingabe zerlegt, analysiert und daraus eine Ausgabe in einem anderen Format erstellt**. In *der Regel wird* also *eine (Text-)Eingabe in eine neue Struktur übersetzt*.
Und *so **soll** es* auch bei dieser ***Code Competition*** sein. Du sollst **einen Parser (=Übersetzer) schreiben**, der **Markdown-Dokumente in HTML-Quellocde übersetzt**.

##{INPUT}
* Es bietet sich die Verwendung von regulären Ausdrücken (*Regular Expressions*) an.

Deine Abgabe soll:

* Die Eingabe eines mit Markdown strukturierten Dokuments erlauben. Hierbei ist die Eingabe über einen Textbereich in einer GUI möglich, aber auch das Einlesen einer Datei (über eine GUI, oder über die Kommandozeile).
Folgende Markdown-Syntax soll berücksichtigt werden und entsprechend in HTML-Code umgewandelt werden:

Markdown-Zeichen HMTL-Code
# h1-Überschrift
## h2-Überschrift
* Ein Stern am Anfang einer Zeile beginnt eine Auflistung (Jedes Element einer Liste wird mit einem Stern gekennzeichnet)

**fetter_text** Ein fett geschriebener Text wird mit zwei Sternen (**) eingeleitet und wieder beendet.

*kursiver_text* Kursiv geschriebener Text wird mit einem Stern eingeleitet und einem Stern beendet (*)

> Ein Zitat wird durch ein > am Zeilenanfang eingeleitet
> Und hier geht das Zitat in eine neue Zeile über

Leerzeile Ein Paragraph wird durch eine Leerzeile zwischen Textblücken angegeben.


#{REVIEW}

**Worauf achten wir bei der Bewertung Deiner Abgabe?**

* Funktionalität: Lässt sich das Programm bedienen? Tut die Anwendung oder die Funktion, was sie soll? Wie umfangreich sind die Funktionen?
* Code-Qualität: Ist der Code sinnvoll strukturiert und effizient?
* Code-Lesbarkeit / Dokumentation: Lässt sich der Quellcode nachvollziehen? Ist der Code kommentiert?
* Setup: Ist das System einfach einzurichten / aufzusetzen? (z.B. mittels guter Dokumentation, Docker, Vagrant, Skripte, o.ä.)
* Welche Zusatzfeatures wurden eingebaut?

**Wie bewerten wir?**

##{POST}


# NEW CONTENT


# An exhibit of Markdown

This note demonstrates some of what [Markdown][1] is capable of doing.

*Note: Feel free to play with this page. Unlike regular notes, this doesn't automatically save itself.*

## Basic formatting

Paragraphs can be written like so. A paragraph is the basic block of Markdown. A paragraph is what text will turn into when there is no reason it should become anything else.

Paragraphs must be separated by a blank line. Basic formatting of *italics* and **bold** is supported. This *can be **nested** like* so.

## Lists

### Ordered list

1. Item 1
2. A second item
3. Number 3
4. Ⅳ

*Note: the fourth item uses the Unicode character for [Roman numeral four][2].*

### Unordered list

* An item
* Another item
* Yet another item
* And there's more...

## Paragraph modifiers

### Code block

Code blocks are very useful for developers and other people who look at code or other things that are written in plain text. As you can see, it uses a fixed-width font.

You can also make `inline code` to add code into other things.

### Quote

> Here is a quote. What this is should be self explanatory. Quotes are automatically indented when they are used.

## Headings

There are six levels of headings. They correspond with the six levels of HTML headings. You've probably noticed them already in the page. Each level down uses one more hash character.

### Headings *can* also contain **formatting**

### They can even contain `inline code`

Of course, demonstrating what headings look like messes up the structure of the page.

I don't recommend using more than three or four levels of headings here, because, when you're smallest heading isn't too small, and you're largest heading isn't too big, and you want each size up to look noticeably larger and more important, there there are only so many sizes that you can use.

## URLs

URLs can be made in a handful of ways:

* A named link to [MarkItDown][3]. The easiest way to do these is to select what you want to make a link and hit `Ctrl+L`.
* Another named link to [MarkItDown](http://www.markitdown.net/)
* Sometimes you just want a URL like <http://www.markitdown.net/>.

## Horizontal rule

A horizontal rule is a line that goes across the middle of the page.

---

It's sometimes handy for breaking things up.

## Images

Markdown can also contain images. I'll need to add something here sometime.

## Finally

There's actually a lot more to Markdown than this. See the official [introduction][4] and [syntax][5] for more information. However, be aware that this is not using the official implementation, and this might work subtly differently in some of the little things.


[1]: http://daringfireball.net/projects/markdown/
[2]: http://www.fileformat.info/info/unicode/char/2163/index.htm
[3]: http://www.markitdown.net/
[4]: http://daringfireball.net/projects/markdown/basics
[5]: http://daringfireball.net/projects/markdown/syntax



#### TEXT

It's very easy to make some words **bold** and other words *italic* with Markdown. You can even [link to Google!](http://google.com)

#### LISTS

Sometimes you want numbered lists:

1. One
2. Two
3. Three

Sometimes you want bullet points:

* Start a line with a star
* Profit!

Alternatively,

- Dashes work just as well
- And if you have sub points, put two spaces before the dash or star:
- Like this
- And this

#### HEADINGS AND quote

# Structured documents

Sometimes it's useful to have different levels of headings to structure your documents. Start lines with a `#` to create headings. Multiple `##` in a row denote smaller heading sizes.

### This is a third-tier heading

You can use one `#` all the way up to `######` six for different heading sizes.

If you'd like to quote someone, use the > character before the line:

> Coffee. The finest organic suspension ever devised... I beat the Borg with it.
> - Captain Janeway


# BROTHER JOHNS TESTDOKUMENT

# Ein Testdokument

Absätze sind die grundlegenden Blockelemente.

Ein neuer Absatz braucht mindestens eine Leerzeile.


Mehrere geht genauso und führen zum gleichen Ergebnis.

Einen Absatz darf man beliebig
umbrechen. Es bleibt ein einzelner Absatz ohne (!) Zeilenumbruch. Bonus: Harte Zeilenumbrüche innerhalb eines Absatzes (aber nicht am Absatzanfang oder -ende) macht man am Zeilenende mit einem Backslash oder mindestens zwei Leerzeichen. Ja, Leerzeichen. Vollkommen bescheuerte Idee, finde ich, aber so ists festgelegt.

Führende Leerzeichen sind ok
und werden entfernt.

Ausnahme: Bei der ersten Zeile eines Absatzes dürfen es max. 3 LZ sein, sonst wird ein Codeblock draus – der von der Aufgabe nicht gefordert ist. Also könnte man auf die Spezialbehandlung für erste Zeilen verzichten.

Viel Inline-Formatierung ist ja nicht gefordert: **Fett** und *kursiv*. Was kann man denn damit noch anstellen ... Wer sagt eigentlich, dass man immer nur ganze Wörter formatieren will: Donau*dampf*schifffahrts**kapitäns**mütze.

In der Aufgabe steht nichts von geschachtelter Formatierung, Aber ***fettkursiv*** oder **fett und *kursiv*** ist ja nicht sooo weit aus der Welt. Trotzdem würde ich das als Bonus ansehen.

Inline-Formatierung wird der Reihe nach geparst und dangling Sternchen bleiben simple Sternchen. Beispiel: In *C++* (kursiv) wird der Pointer mit einem Sternchen (*) markiert. Der komplette Regelsatz ist relativ komplex und steht hier: http://spec.commonmark.org/0.27/#emphasis-and-strong-emphasis

Zu den Überschriften: Da die Aufgabenstellung so vage ist, alles laut Spec.

### Laut Aufgabenstellung ist dies keine Überschrift, sondern ein normaler Absatz (da nur H1 und H2 gefordert sind).

#Auch ein normaler Absatz, da mindestens ein Leerzeichen nach dem # stehen muss.

# normale H1-Überschrift
# genauso normale H1-Überschrift
# auch eine normale H1 mit optionalem schließenden Hash #
# auch das ist eine normale H1, die Anzahl der Schließhashes muss nicht übereinstimmen ##

## normale H2
## H2: keine Schließhashes, da nicht per Leerzeichen getrennt####
## H2: keine Schließhashes, da noch ## Text danach

Spec sagt: “The opening # character may be indented 0-3 spaces.”

# H1
# H1
# H1
# keine H1. Eigentlich ein Codeblock, aber der ist von der Aufgabe nicht gefordert. Ich würde es als normalen Absatz interpretieren.

Mehrzeilige Überschriften geht nicht. Leerzeilen vor/nach Überschriften sind optional.

Ein Absatz.
## Eine H2
Noch ein Absatz. ##

Nicht von den Hashes am Ende verwirren lassen!


## > Das hier ist eine interessant formatierte H2-Überschrift <

Und wenn wir schon bei den spitzen Klammern sind:

> Ein Zitatabsatz

Oder umgebrochen:

> Auch das ist
> ein einzelner Zitatabsatz (ohne harten Zeilenumbruch!).

Normale Zeilenumbrüche werden genauso behandelt wie im Fließtext.

> Ein einzelner Zitatabsatz
mit Umbruch.

Man kann das natürlich auch kombinieren:

> Das mit dem Zitieren
schaut auf Anhieb einfach aus.
> Isses aber nich. Denn dieser ganze Block hier
> ist ein einzelner Zitatabsatz.

Leerzeilen trennen Zitate.

> Zitat 1

> Zitat 2

Im Vergleich zu:

> Ein einzelnes Zitat.
>
> Es hat zwei Absätze.

Eines noch:

> Das Leerzeichen nach der spitzen Klammer
>ist optional.


## Listen

Lasst uns Sachen auflisten; weil man mit Listen trotz der *am Zeilenanfang*-Einschränkung sooo viel Mist bauen kann! :D

* eins
* zwei
* drei

So weit, so einfach.

* eins
* **zwei** in fett
* *drei* in kursiv
* *Nein, das ist
* nicht kursiv*. Das sind zwei Listenpunkte mit jeweils einem Stern im Text.

Folgendes

*ist laut Spec
*keine Liste, sondern ein Absatz, der zwei Sternchen im Text hat. Wichtig: Kein kursiv wegen dem Zeilenumbruch direkt vor dem zweiten Stern!

Apropos Absätze:

* langweiliger kurzer Listenpunkt
* Der hier ist ein bisschen länglicher.

V.a. hat er einen zweiten Absatz.
* noch ein Punkt
* und noch einer

Huch!

*

Ein einzelner Stern!? Das ist eine Liste mit einem einzelnen leeren Listenpunkt.

Aber Vorsicht! Ein leerer Listenpunkt
*
unterbricht nicht einen Absatz! Das da eine Zeile höher ist ein simpler Stern.

Alles was leer ist, ist ein wunderschöner Grenzfall. Z.B.:

*
Was ist das denn?
* Na logisch! Ein Listenpunkt mit führender Leerzeile.
* Todo: Nachlesen, was mit dem Zeilenumbruch passieren soll. Schlucken wie in normalen Absätzen? Oder bleibt der?

Ein leerer Punkt in einer Liste? Logisch:

* eins
*
* drei

Leere Zeilen sind auch was Feines. Sie trennen normalerweise Absätze. In Listen sieht das ein bisschen anders aus.

* Leerzeilen

* zwischen Listenpunkten
* sind erlaubt


* auch mehrere Leerzeilen

Das da oben ist eine einzelne Liste.

* Die Aufgabenstellung fordert den Listenpunkt *am Zeilenanfang*.
* Das hier ist also keine geschachtelte Liste (im Gegensatz zur Spec).

Sondern? Ähm ... Ich würde sagen: eine Liste mit einem einzelnen Absatz in einem einzelnen Listenpunkt. Der Absatz enthält einen weichen Zeilenumbruch und ein dangling Sternchen.
[/src]


Und die Ausgabe dazu:

[src=html5]<h1>Markdown Parser</h1>

<h2>Erstelle Deinen eigenen Markdown-Parser und wandle Markdown-Code in HTML-Code um.</h2>
<p><strong>Du hast noch: 22 Tage 10 Stunden 59 Minuten 15 Sekunden</strong></p>

<h1>{ABOUT}</h1>
<p>Was ist eigentlich ein Parser?</p>

<p>Mit <strong>Hilfe von Parsern wird eine Eingabe zerlegt, analysiert und daraus eine Ausgabe in einem anderen Format erstellt</strong>. In <em>der Regel wird</em> also <em>eine (Text-)Eingabe in eine neue Struktur übersetzt</em>.
Und <em>so <strong>soll</strong> es</em> auch bei dieser <strong><em>Code Competition</em></strong> sein. Du sollst <strong>einen Parser (=Übersetzer) schreiben</strong>, der <strong>Markdown-Dokumente in HTML-Quellocde übersetzt</strong>.</p>

<h2>{INPUT}</h2>
<ul><li>Es bietet sich die Verwendung von regulären Ausdrücken (<em>Regular Expressions</em>) an.</li></ul>

<p>Deine Abgabe soll:</p>

<ul><li>Die Eingabe eines mit Markdown strukturierten Dokuments erlauben. Hierbei ist die Eingabe über einen Textbereich in einer GUI möglich, aber auch das Einlesen einer Datei (über eine GUI, oder über die Kommandozeile).</li></ul>
<p>Folgende Markdown-Syntax soll berücksichtigt werden und entsprechend in HTML-Code umgewandelt werden:</p>

<p>Markdown-Zeichen HMTL-Code
<h1> h1-Überschrift</h1>
<h2> h2-Überschrift</h2>
<ul><li> Ein Stern am Anfang einer Zeile beginnt eine Auflistung (Jedes Element einer Liste wird mit einem Stern gekennzeichnet)</li></ul></p>

<p><strong>fetter_text</strong> Ein fett geschriebener Text wird mit zwei Sternen (**) eingeleitet und wieder beendet.</p>

<p><em>kursiver_text</em> Kursiv geschriebener Text wird mit einem Stern eingeleitet und einem Stern beendet (*)</p>

<blockquote><pre><code> Ein Zitat wird durch ein > am Zeilenanfang eingeleitet<br/>
Und hier geht das Zitat in eine neue Zeile über</code></pre></blockquote>

<p>Leerzeile Ein Paragraph wird durch eine Leerzeile zwischen Textblücken angegeben.</p>


<h1>{REVIEW}</h1>

<p><strong>Worauf achten wir bei der Bewertung Deiner Abgabe?</strong></p>

<ul><li>Funktionalität: Lässt sich das Programm bedienen? Tut die Anwendung oder die Funktion, was sie soll? Wie umfangreich sind die Funktionen?</li>
<li>Code-Qualität: Ist der Code sinnvoll strukturiert und effizient?</li>
<li>Code-Lesbarkeit / Dokumentation: Lässt sich der Quellcode nachvollziehen? Ist der Code kommentiert?</li>
<li>Setup: Ist das System einfach einzurichten / aufzusetzen? (z.B. mittels guter Dokumentation, Docker, Vagrant, Skripte, o.ä.)</li>
<li>Welche Zusatzfeatures wurden eingebaut?</li></ul>

<p><strong>Wie bewerten wir?</strong></p>

<h2>{POST}</h2>


<h1> NEW CONTENT</h1>


<h1> An exhibit of Markdown</h1>

<p>This note demonstrates some of what [Markdown][1] is capable of doing.</p>

<p><em>Note: Feel free to play with this page. Unlike regular notes, this doesn't automatically save itself.</em></p>

<h2> Basic formatting</h2>

<p>Paragraphs can be written like so. A paragraph is the basic block of Markdown. A paragraph is what text will turn into when there is no reason it should become anything else.</p>

<p>Paragraphs must be separated by a blank line. Basic formatting of <em>italics</em> and <strong>bold</strong> is supported. This <em>can be <strong>nested</strong> like</em> so.</p>

<h2> Lists</h2>

<h3> Ordered list</h3>

<p>1. Item 1
2. A second item
3. Number 3
4. Ⅳ</p>

<p><em>Note: the fourth item uses the Unicode character for [Roman numeral four][2].</em></p>

<h3> Unordered list</h3>

<ul><li>An item</li>
<li>Another item</li>
<li>Yet another item</li>
<li>And there's more...</li></ul>

<h2> Paragraph modifiers</h2>

<h3> Code block</h3>

<p> Code blocks are very useful for developers and other people who look at code or other things that are written in plain text. As you can see, it uses a fixed-width font.</p>

<p>You can also make `inline code` to add code into other things.</p>

<h3> Quote</h3>

<blockquote><pre><code> Here is a quote. What this is should be self explanatory. Quotes are automatically indented when they are used.</code></pre></blockquote>

<h2> Headings</h2>

<p>There are six levels of headings. They correspond with the six levels of HTML headings. You've probably noticed them already in the page. Each level down uses one more hash character.</p>

<h3> Headings <p><em>can</em> also contain <strong>formatting</strong></p></h3>

<h3> They can even contain `inline code`</h3>

<p>Of course, demonstrating what headings look like messes up the structure of the page.</p>

<p>I don't recommend using more than three or four levels of headings here, because, when you're smallest heading isn't too small, and you're largest heading isn't too big, and you want each size up to look noticeably larger and more important, there there are only so many sizes that you can use.</p>

<h2> URLs</h2>

<p>URLs can be made in a handful of ways:</p>

<ul><li>A named link to [MarkItDown][3]. The easiest way to do these is to select what you want to make a link and hit `Ctrl+L`.</li>
<li>Another named link to [MarkItDown](http://www.markitdown.net/)</li>
<li>Sometimes you just want a URL like <http://www.markitdown.net/>.</li></ul>

<h2> Horizontal rule</h2>

<p>A horizontal rule is a line that goes across the middle of the page.</p>

<p>---</p>

<p>It's sometimes handy for breaking things up.</p>

<h2> Images</h2>

<p>Markdown can also contain images. I'll need to add something here sometime.</p>

<h2> Finally</h2>

<p>There's actually a lot more to Markdown than this. See the official [introduction][4] and [syntax][5] for more information. However, be aware that this is not using the official implementation, and this might work subtly differently in some of the little things.</p>


<p> [1]: http://daringfireball.net/projects/markdown/<br/>
[2]: http://www.fileformat.info/info/unicode/char/2163/index.htm<br/>
[3]: http://www.markitdown.net/<br/>
[4]: http://daringfireball.net/projects/markdown/basics<br/>
[5]: http://daringfireball.net/projects/markdown/syntax</p>



<h4> TEXT</h4>

<p>It's very easy to make some words <strong>bold</strong> and other words <em>italic</em> with Markdown. You can even [link to Google!](http://google.com)</p>

<h4> LISTS</h4>

<p>Sometimes you want numbered lists:</p>

<p>1. One
2. Two
3. Three</p>

<p>Sometimes you want bullet points:</p>

<ul><li>Start a line with a star</li>
<li>Profit!</li></ul>

<p>Alternatively,</p>

<p>- Dashes work just as well
- And if you have sub points, put two spaces before the dash or star:<br/>
- Like this<br/>
- And this</p>

<h4> HEADINGS AND quote</h4>

<h1> Structured documents</h1>

<p>Sometimes it's useful to have different levels of headings to structure your documents. Start lines with a `#` to create headings. Multiple `##` in a row denote smaller heading sizes.</p>

<h3> This is a third-tier heading</h3>

<p>You can use one `#` all the way up to `######` six for different heading sizes.</p>

<p>If you'd like to quote someone, use the > character before the line:</p>

<blockquote><pre><code> Coffee. The finest organic suspension ever devised... I beat the Borg with it.<br/>
- Captain Janeway</code></pre></blockquote>


<h1> BROTHER JOHNS TESTDOKUMENT</h1>

<h1> Ein Testdokument</h1>

<p>Absätze sind die grundlegenden Blockelemente.</p>

<p>Ein neuer Absatz braucht mindestens eine Leerzeile.</p>


<p>Mehrere geht genauso und führen zum gleichen Ergebnis.</p>

<p>Einen Absatz darf man beliebig
umbrechen. Es bleibt ein einzelner Absatz ohne (!) Zeilenumbruch. Bonus: Harte Zeilenumbrüche innerhalb eines Absatzes (aber nicht am Absatzanfang oder -ende) macht man am Zeilenende mit einem Backslash oder mindestens zwei Leerzeichen. Ja, Leerzeichen. Vollkommen bescheuerte Idee, finde ich, aber so ists festgelegt.</p>

<p>Führende Leerzeichen sind ok<br/>
und werden entfernt.</p>

<p> Ausnahme: Bei der ersten Zeile eines Absatzes dürfen es max. 3 LZ sein, sonst wird ein Codeblock draus – der von der Aufgabe nicht gefordert ist. Also könnte man auf die Spezialbehandlung für erste Zeilen verzichten.</p>

<p>Viel Inline-Formatierung ist ja nicht gefordert: <strong>Fett</strong> und <em>kursiv</em>. Was kann man denn damit noch anstellen ... Wer sagt eigentlich, dass man immer nur ganze Wörter formatieren will: Donau<em>dampf</em>schifffahrts<strong>kapitäns</strong>mütze.</p>

<p>In der Aufgabe steht nichts von geschachtelter Formatierung, Aber <strong><em>fettkursiv</em></strong> oder **fett und *kursiv*** ist ja nicht sooo weit aus der Welt. Trotzdem würde ich das als Bonus ansehen.</p>

<p>Inline-Formatierung wird der Reihe nach geparst und dangling Sternchen bleiben simple Sternchen. Beispiel: In <em>C++</em> (kursiv) wird der Pointer mit einem Sternchen (*) markiert. Der komplette Regelsatz ist relativ komplex und steht hier: http://spec.commonmark.org/0.27/#emphasis-and-strong-emphasis</p>

<p>Zu den Überschriften: Da die Aufgabenstellung so vage ist, alles laut Spec.</p>

<h3> Laut Aufgabenstellung ist dies keine Überschrift, sondern ein normaler Absatz (da nur H1 und H2 gefordert sind).</h3>

<h1>Auch ein normaler Absatz, da mindestens ein Leerzeichen nach dem # stehen muss.</h1>

<h1> normale H1-Überschrift</h1>
<h1> genauso normale H1-Überschrift</h1>
<h1> auch eine normale H1 mit optionalem schließenden Hash #</h1>
<h1> auch das ist eine normale H1, die Anzahl der Schließhashes muss nicht übereinstimmen ##</h1>

<h2> normale H2</h2>
<h2> H2: keine Schließhashes, da nicht per Leerzeichen getrennt####</h2>
<h2> H2: keine Schließhashes, da noch ## Text danach</h2>

<p>Spec sagt: “The opening # character may be indented 0-3 spaces.”</p>

<p> # H1<br/>
# H1<br/>
# H1<br/>
# keine H1. Eigentlich ein Codeblock, aber der ist von der Aufgabe nicht gefordert. Ich würde es als normalen Absatz interpretieren.</p>

<p>Mehrzeilige Überschriften geht nicht. Leerzeilen vor/nach Überschriften sind optional.</p>

<p>Ein Absatz.
<h2> Eine H2</h2>
Noch ein Absatz. ##</p>

<p>Nicht von den Hashes am Ende verwirren lassen!</p>


<h2> > Das hier ist eine interessant formatierte H2-Überschrift <</h2>

<p>Und wenn wir schon bei den spitzen Klammern sind:</p>

<blockquote><pre><code> Ein Zitatabsatz</code></pre></blockquote>

<p>Oder umgebrochen:</p>

<blockquote><pre><code> Auch das ist<br/>
ein einzelner Zitatabsatz (ohne harten Zeilenumbruch!).</code></pre></blockquote>

<p>Normale Zeilenumbrüche werden genauso behandelt wie im Fließtext.</p>

<blockquote><pre><code> Ein einzelner Zitatabsatz
mit Umbruch.</code></pre></blockquote>

<p>Man kann das natürlich auch kombinieren:</p>

<blockquote><pre><code> Das mit dem Zitieren
schaut auf Anhieb einfach aus.<br/>
Isses aber nich. Denn dieser ganze Block hier<br/>
ist ein einzelner Zitatabsatz.</code></pre></blockquote>

<p>Leerzeilen trennen Zitate.</p>

<blockquote><pre><code> Zitat 1</code></pre></blockquote>

<blockquote><pre><code> Zitat 2</code></pre></blockquote>

<p>Im Vergleich zu:</p>

<blockquote><pre><code> Ein einzelnes Zitat.<br/>
<br/>
Es hat zwei Absätze.</code></pre></blockquote>

<p>Eines noch:</p>

<blockquote><pre><code> Das Leerzeichen nach der spitzen Klammer<br/>
ist optional.</code></pre></blockquote>


<h2> Listen</h2>

<p>Lasst uns Sachen auflisten; weil man mit Listen trotz der <em>am Zeilenanfang</em>-Einschränkung sooo viel Mist bauen kann! :D</p>

<ul><li>eins</li>
<li>zwei</li>
<li>drei</li></ul>

<p>So weit, so einfach.</p>

<ul><li>eins</li>
<li><strong>zwei</strong> in fett</li>
<li><em>drei</em> in kursiv</li>
<li>*Nein, das ist</li>
<li>nicht kursiv*. Das sind zwei Listenpunkte mit jeweils einem Stern im Text.</li></ul>

<p>Folgendes</p>

<p>*ist laut Spec
*keine Liste, sondern ein Absatz, der zwei Sternchen im Text hat. Wichtig: Kein kursiv wegen dem Zeilenumbruch direkt vor dem zweiten Stern!</p>

<p>Apropos Absätze:</p>

<ul><li>langweiliger kurzer Listenpunkt</li>
<li>Der hier ist ein bisschen länglicher.</li></ul>

<p> V.a. hat er einen zweiten Absatz.
<ul><li>noch ein Punkt</li>
<li>und noch einer</li></ul></p>

<p>Huch!</p>

<ul><li></li></ul>

<p>Ein einzelner Stern!? Das ist eine Liste mit einem einzelnen leeren Listenpunkt.</p>

<p>Aber Vorsicht! Ein leerer Listenpunkt
</p><ul><li></li></ul>
<p>unterbricht nicht einen Absatz! Das da eine Zeile höher ist ein simpler Stern.</p>

<p>Alles was leer ist, ist ein wunderschöner Grenzfall. Z.B.:</p>

<ul><li></li></ul>
<p> Was ist das denn?
<ul><li>Na logisch! Ein Listenpunkt mit führender Leerzeile.</li>
<li>Todo: Nachlesen, was mit dem Zeilenumbruch passieren soll. Schlucken wie in normalen Absätzen? Oder bleibt der?</li></ul></p>

<p>Ein leerer Punkt in einer Liste? Logisch:</p>

<ul><li>eins</li>
<li></li>
<li>drei</li></ul>

<p>Leere Zeilen sind auch was Feines. Sie trennen normalerweise Absätze. In Listen sieht das ein bisschen anders aus.</p>

<ul><li>Leerzeilen</li></ul>

<ul><li>zwischen Listenpunkten</li>
<li>sind erlaubt</li></ul>


<ul><li>auch mehrere Leerzeilen</li></ul>

<p>Das da oben ist eine einzelne Liste.</p>

<ul><li>Die Aufgabenstellung fordert den Listenpunkt <em>am Zeilenanfang</em>.</li></ul>
<p> * Das hier ist also keine geschachtelte Liste (im Gegensatz zur Spec).</p>

<p>Sondern? Ähm ... Ich würde sagen: eine Liste mit einem einzelnen Absatz in einem einzelnen Listenpunkt. Der Absatz enthält einen weichen Zeilenumbruch und ein dangling Sternchen.</p>[/src]


Feedback ist natürlich willkommen :)

PS: Die Formatierung ist bestimmt weg, weil die Daten sehr lang sind....

Und ein Case fehlt noch aktuell, sehe ich gerade:
[src=html5]<p>Aber Vorsicht! Ein leerer Listenpunkt
</p><ul><li></li></ul>
<p>unterbricht nicht einen Absatz! Das da eine Zeile höher ist ein simpler Stern.</p>[/src]

Der Paragraph wird noch geschlossen und ein neuer eröffnent, irgendwie sollte das ja zusammenhängen.... :)
 

Brother John

(schein)heilig
Teammitglied

Registriert
1 Aug. 2013
Beiträge
235
theSplit schrieb:
Auch auf die Gefahr hin, diesen Thread mit meinem Kram zuzuspammen
Hey, es war/ist Osterwochenende. Die Menschheit ist noch mit Eier finden, Bauchumfang erhöhen und Verwandtschaft tätscheln beschäftigt. ;) Da kannst du an Postingfrequenz nix weltbewegendes erwarten. Bei mir hat sichs inzwischen ausgeostert und ich werde wohl heute Abend die ersten Zeilen Code tippseln.

theSplit schrieb:
Ich glaube die verschiedenen Fälle sind ganz gut abgedeckt
Finde ich auch. Wenn du simples und vernünftiges Markdown fütterst, kommst du ziemlich weit. Gerade bei den Listen-Grenzfällen ist der WTF-Faktor ja oft schon hoch. Warum sollte jemand solches Zeug in seinen Live-Dokumenten haben?

Ein paar Gedanken, die mir beim Output durchscrollen kamen:

  • Dass du Whitespace nicht konsequent putzt, finde ich ok mit Fußnote. Und zwar ist es ok bei *dieser* Architektur, wo du bewusst keine Flexibilität beim Ausgabeformat eingebaut hast. HTML ist gesetzt, und dann ist auch die Argumentation vollkommen ok, Dinge nicht zu tun, die der Browser (oder sagen wir: eine HTML-Render-Engine) sowieso übernimmt.
  • Im Post von gestern fällt mir schon folgendes auf: Auch wenn manche Konstrukte deinen Parser grob durcheinander gebracht haben, hat er sich immer wieder relativ flott gefangen und einen neuen Einstiegspunkt gefunden, von dem aus es korrekt weiter ging. Das deutet stark darauf hin, dass deine grundsätzliche Herangehensweise solide ist.
  • Alle Zitate sind als <blockquote><pre><code> ausgezeichnet. Aber ein Zitat ist doch weder zwingend pre-formatted noch ein Codeblock. …
  • Die <br/> finde ich ein bisschen inkonsequent gesetzt. Zumindest in meinem Testdok dürfte kein einziges vorkommen. Harte br-Zeilenumbrüche sind nach ursprünglichem Gruber-Markdown nur Zeilen mit 2+ Leerzeichen am Ende. CommonMark hat alternativ den Backslash eingeführt. Beides hatte ich nicht drin.
  • Bei den Listen, ja da ist viel fieses Zeug dabei. Kann ich v.a. für ne Wettbewerbsaufgabe verstehen, dass du da einige Stellen abschneidest. Wie würdest du’s einschätzen: Die ganzen Sonderfälle spec-konform zu verarbeiten, ist das einfach nur geradlinige Implementierarbeit oder müsstest du an deine Architektur nochmal ran?

Ganz allgemein: Dass Markdown so ein fluffiges, oft beliebiges Format ist, macht das Parsen nicht einfacher. Das einzig wahre Markdown gibts halt nicht, und weil ja auch die Aufgabenstellung Bedingungen stellt, die von Grubers ursprünglicher Perl-Implementierung abweichen, parsen wir eh nur sowas ähnliches wie Markdown. Prinzipiell ist jedes Detail diskutabel. Deswegen halte ich die CommonMark-Spec so hoch: Es ist zwar nicht ganz Ur-Markdown (was auch immer genau das ist), aber es ist die beste und professionellste komplette Spezifikation, die wir haben. Deswegen würde ich’s im Zweifel so machen, wie es dort steht.
 

theSplit

1998
Teammitglied

Registriert
3 Aug. 2014
Beiträge
27.283
  • Thread Starter Thread Starter
  • #15
Hey, es war/ist Osterwochenende. Die Menschheit ist noch mit Eier finden, Bauchumfang erhöhen und Verwandtschaft tätscheln beschäftigt. ;) Da kannst du an Postingfrequenz nix weltbewegendes erwarten. Bei mir hat sichs inzwischen ausgeostert und ich werde wohl heute Abend die ersten Zeilen Code tippseln.

Ich muß herzlich darüber lachen.... das nenn ich Sinn für Humor. :T

Im großen und ganzen habe ich mich an das Markdown von John Gruber orientiert.


bzw. auch hier der Cheat Sheet:


Das "blockquote pre code"-Konstrukt hatte ich irgendwo im Netz gefunden, ich glaube es war w3schools... da ich das Zitat-HTML-Element bisher selten bis gar nicht verwendet habe, hatte ich dies einfach "übernommen".
Es wären aber nur zwei Strings in einer Liste/Array die man abändern muß und man hätte dann zum Beispiel "blockquote p" oder nur "blockquote", zum Beispiel, als Wrapper für den Inhalt. Aber ich sehe gerade auch, selbst auf (ja nicht die beste Seite dafür.... aber komischerweise poppt die Seite immer wieder auf wenn man nach so etwas sucht) - wird aber auch "nur" blockquote verwendet.

Whitespace-Stripping am Anfang der Zeile, hier könnte man die Regel einführen dass das erste Leerzeichen einer Zeile bzw. nach einem Element "übergangen" wird. Jenes wäre schnell implementiert.

Die <br/> folgend allerdings einer bzw. zwei festen Regel für Paragraphen und Zitaten, dort wird zum Beispiel überprüft ob die nächste Zeile ein Leerzeichen enthält oder nicht, bzw. ob wir einen Quote-Markdown haben das zu einem Zitat gehört. Anders wäre zum Beispiel ein Quote Element mit mehreren Leerzeilen innerhalb des Zitats nicht möglich gewesen.
Ansonsten bleibt, zumindest in Firefox, der Aufbau erhalten, so das zum Beispiel ein zusammenhängender Zitatsatz, der über zwei Zeilen geht, auch nicht nur auf eine Zeile geschrieben wird. Was an dem <pre> liegen könnte das ich verwendet habe, dass müsste ich nochmal prüfen.

Wo ich aber nicht ein Fan von bin, zwei Leerzeichen am Ende eines Textes, mancher "Code"-Editor hat ja zum Beispiel den Befehl, Whitespace am Ende einer Zeile zu entfernen, daher halte ich diese Formatierung für nicht zeitgemäß oder gar sicher, weil es auch nicht optisch hervor sticht - es sei denn man lässt derartige "Symbole" abbilden im Text. Zum Beispiel Notepad++ macht/kann das. Über einen Backslash könnte man allerdings reden, halte ich für die einzig "sichere" und praktikabel anwendbare Variante, oder man verlässt sich auf "mein", leider ein wenig intransparentes, System mit dem Leerzeichen am Zeilenanfang in Paragraphen und Zitaten bzw. auch ob man ">" verwendet (ist eine Abfrage und da müsste ich nochmal ohne "pre" schauen, was mehr Sinn macht).

Mit den Listen war es gar nicht so schwer, es sieht nur kompliziert aus. Ich speichere zum Beispiel ob ein offener "<ul><li>" besteht, ob es sich um ein "Eltern" oder "kind" Element/Knoten handelt und auch wichtig, ob die Liste schon beendet wurde. Zum Beispiel wenn eine Liste nach einer anderen erstellt wird aber diese nicht zusammenhängen, da kann man nicht nur allein darauf schauen ob nicht schon ein "<ul><li>" verfügbar wäre.

Und um auf deine Frage einzugehen: Nach welcher Spec richtet man sich (CommonMark müsste ich mal googlen) und was genau stellst du dir darunter vor, welche "Sonderfälle", sowas wie genestete Listen und andere Elemente die nicht in der Aufgabe stehen?

*Update:
Also das "pre" hat nichts daran gerüttelt das Zeilen, im Browser, die mit einem normalen Zeilenumbruch daherkommen NICHT zusammengefügt werden, das vereinfacht einiges... weil ich auch hier keinen Grund sehe "dagegen" zu optimieren. Also kann man dann auch ein harten Zeilenumbruch setzen, oder es ganz lassen. Aktuell jedenfalls. Das mit dem Leerzeichen macht dann auch nicht viel Sinn, der Break kommt im Browser (Firefox) automatisch und daran wird auch nicht gerüttelt. Entscheided der Browser nun, das wir den Text nun doch "zusammenfügen", soll das wohl so sein.... ;)

Habe nun auch die ersten Leerzeichen nach Tags wegfallen lassen, falls vorhanden, damit die Zeilen ordentlich eingerückt sind, macht auch die Ausgabe ein klein wenig kompakter.
 
Zuletzt bearbeitet:

Brother John

(schein)heilig
Teammitglied

Registriert
1 Aug. 2013
Beiträge
235
Im großen und ganzen habe ich mich an das Markdown von John Gruber orientiert.
Dann mach’s doch komplett anstatt nur »im großen und ganzen«. Weil wenn nicht, ist heimlich still und leise sofort noch ein Markdown-Dialekt entstanden ( ). Auch wenn wir hier nur mit Spielbeispielen rumbasteln, kann man den schlechten Angewohnheiten ja gleich vorbeugen. Manche Sachen wegzulassen halte ich für ok, weil ein vollständiger Markdown-Parser ein größerer Batzen Arbeit ist. Aber warum Sachen anders implementieren?

Jaja, die 2+-Leerzeichen-Regel für harte Zeilenumbrüche. Finde ich auch extremst bescheuert. Aber ist halt Markdown. Sieh’s mal so rum: Dass die Regeln des Formats zu mieser Usability führen, ist doch nicht dein Problem als Parser-Implementierer. Mal davon abgesehen, dass man sich auch im Gruber-Markdown mit einem echten <br> behelfen kann, wenn man wirklich einen sicheren, harten Zeilenumbruch braucht. HTML ist ja überall erlaubt.

und was genau stellst du dir darunter vor, welche "Sonderfälle", sowas wie genestete Listen und andere Elemente die nicht in der Aufgabe stehen?
Ich hatte v.a. die Spezialfälle in meinem Testdokument im Auge. Die könnte man zum Großteil sogar noch als Teil der Aufgabe interpretieren. Implizit ausgeschlossen sind ja eigentlich nur geschachtelte Listen.


In meinem Bastelkeller fängt die Sache auch an, Formen anzunehmen. Absätze und Listen gehen, Listenpunkte mit mehreren Absätzen schaut auch gut aus, genauso weiche Zeilenumbrüche. Wahrscheinlich. Es gibt noch keine Ausgabe, aber die Testfälle sind grün. :D

Was ich bisher gelernt habe: Grammatik schreiben ist hart! Weil’s eine ganz andere, ungewohnte Art zu denken braucht. Grammatiken sind zum Großteil deklarativ. Mein objektorientiert/prozedural geprägtes Hirn will den Scheiß ständig hinschmeißen und es auf gewohnte Art runterprogrammieren. Deswegen will mir auch die Frage nicht aus dem Kopf gehen, ob ein Parserframework wie Spirit für ein Format vom Kaliber Markdown wirklich das richtige Tool ist. Ob da was dran ist oder mir nur das ungemütliche, weil ungewohnte, Denkmodell ein Vorurteil reindrückt, da bin ich mir nicht sicher.

Über kontextfreie vs. kontextsensitive Grammatiken mach ich mir auch so meine Gedanken. Haben will man eigentlich ersteres, weils schön einfach und eindeutig ist. Markdown ist zweiteres, aber wie! Es gibt mindestens zwei Arten von Kontext. Markdown nimmt die natürlich beide mit.

Die einfach Art von Kontext: Wenn ich Token X parse und als semantisches Element E interpretiere, aber nur, wenn danach (oder davor, ist das gleiche in grün) Token Y folgt, ist das nicht mehr frei von Kontext. Ich muss einen Lookahead machen – also in den Kontext namens »Zukunft« schauen – um meinen aktuellen Zustand eindeutig interpretieren zu können. Markdown-Beispiel:
[src=cpp]const auto paragraph_separator =
eoi // end-of-input; oder
| (eol >> +eol) // end-of-line gefolgt von 1-n eol
// also effektiv 1-n Leerzeilen; oder
| (eol >> &lit("* "); // einzelnes eol, falls danach ein "* "
// (ein Listenstart) kommt[/src]
Der letzte Fall ist der kontextabhängige. Warum klappt ein simples Zeilenende gefolgt von einem "* " nicht? Weil ich dann das "* " schon als Teil von paragraph_separator geparst habe. Das ist falsch. Und wenn ich weiterparse, stehe ich schon nach dem Listenstart und kann deshalb nicht mehr erkennen, dass hier eine Liste angefangen haben sollte. Auch nicht gerade richtig.

Das ist aber nur der simple Fall von Kontext. Dann gibt es noch den, der von den Inputdaten abhängt. Sowas hat Markdown auch, z.B. bei Listen mit mehreren Absätzen:
Code:
* Punkt 1, Absatz 1

  Punkt 1, Absatz 2
* Punkt 2

Aber:

1. Punkt 1, Absatz 1

   Punkt 1, Absatz 2
2. Punkt 2
Folgeabsätze desselben Listenpunkts müssen soweit eingerückt werden wie der Listenmarker breit ist: 2 Leerzeichen in der ersten Liste (weil Listenmarker »* «), 3 in der zweiten (weil Marker »1. «). Ja, pfui bäh! Jetzt müsste ich meiner Grammatik also beibringen zu erkennen und zu speichern, wie breit der doofe Marker ist, und das beeinflusst das weitere Parse-Ergebnis. Ob/wie man sowas in Spirit modelliert, weiß ich noch nicht.
 

theSplit

1998
Teammitglied

Registriert
3 Aug. 2014
Beiträge
27.283
  • Thread Starter Thread Starter
  • #17
Hi :)

Freut mich das die Aufgabe nicht so straight forward ist, auch für dich! ;) - Im guten gesprochen, zeigt das die Aufgabe nicht einfach bzw. trival ist.

Wenn du dich dann noch in eine neue Bibliothek AUCH noch einarbeiten mußt, ist das vielleicht ohnehin noch etwas schwerer, weil einmal die Bibliothek "nutzen lernen und verstehen muss wie die Konzepte sind" und jenes Wissen dann auch erfolgreich auf die Syntax anzuwenden, gemeistert werden muss.

Ich kann dir soviel verraten, ich habe es auch mit einer, ich nenn es mal "look ahead-detection" für gewisse Sachen gelöst, zu mal ich nur einen einzigen Durchgang der Daten mache und nicht einen analytischen und einen hm, wie nennt man es dann, die Analyse ausführenden Abschnitt teile. Anders könnte ich zum Beispiel nicht unterscheiden, ob Markdown korrekt geschlossen wird und damit "valide" ist.

Ich habe mir aber auch schon überlegt, ob ich am Ende einer Zeile nicht nur auf den Beginn der nächsten Zeile schauen sollte, sondern auch auf die darauf folgende um dann Elemente zu erkennen die zusammenhängenden würden, also in dem Fall Listen zum Beispiel - die du ja wirklich sehr detailliert ausgeleuchtet hast. :)

Allerdings sehe ich eine leere Zeile auch als Trennelement an, will ich Elemente verknüpfen, setze ich keine leeren Zeilen dazwischen, genau auch die Regel nach der zwei Paragraphen getrennt werden.

Den Widerspruch den du glaube ich "entdeckt" hast, ist mir in ähnlicher Form auch schon beim testen aufgefallen, aber ich weiß jetzt nicht aus dem stehgreif welcher Punkt das genau gewesen ist, es bezog sich glaube auf Zitate und Paragaphen und deren Absätze oder vielleicht doch auf die Zitatidee, Zitate durch leere Zeilen zu trennen, aber auch zu berücksichtigen ob wir nicht ein Zitat mit einem Absatz haben.

Dieses Markdown von dir zum Beispiel:
[src=text]>Oder umgebrochen:

> Auch das ist
> ein einzelner Zitatabsatz (ohne harten Zeilenumbruch!). ### 1


verus:


Normale Zeilenumbrüche werden genauso behandelt wie im Fließtext.

> Ein einzelner Zitatabsatz
mit Umbruch. ### 2 Genau hier hängt meiner Meinung nach der Satz "zusammen", auch wenn kein Whitespace am Zeilenanfang der zweiten Zeile ist, wird aber vom Browser

Man kann das natürlich auch kombinieren:

> Das mit dem Zitieren
schaut auf Anhieb einfach aus.
> Isses aber nich. Denn dieser ganze Block hier
> ist ein einzelner Zitatabsatz. #3 [/src]

#1) Diese Regel hab ich genau umgekehrt behandel, ich und nehme das ">" als Anlass das wir einen neuen Abschnitt haben und forciere einen Umbruch
#2) GENAU hier entscheide ich mich dafür, das es zusammengehört, weil: Es folgt kein > Zeichen, die Zeilen könnten alles "zusammengefügt werden" auch wenn kein Whitespace am Zeilenanfang da ist, das gibt dem ">" mehr Bedeutung, finde ich - kann aber auch von der Spezification abweichen! - Aber auch der Browser rendert dies anders,
#3) Die erste Zeile gehört nach meiner "Logik" zusammen, Zeile 3 und 4 haben ein ">", sind also neue Punkte innerhalb eines zusammenhängenden Zitats.


Was mir aber auch aufgefallen ist:

[src=text]*.................................. <<
Was ist das denn?
* Na logisch! Ein Listenpunkt mit führender Leerzeile.
* Todo: Nachlesen, was mit dem Zeilenumbruch passieren soll. Schlucken wie in normalen Absätzen? Oder bleibt der?

Ein leerer Punkt in einer Liste? Logisch:

* eins
*............................. <<
* drei[/src]

<< - Hier gibt es kein Leerzeichen das anführt, dennoch meinst du eine Liste liegt vor, dafür müsste allerdings auch ein Leerzeichen darauf folgen, eigentlich wäre dieser Stern also nicht valide um als Listenpunkt zu gelten, wir nehmen es an, "weil wir uns innerhalb einer Liste befinden", oder ist es gar kursive Formatierung die über ein Zeilenende hinaus geht?


In deinem zwieten Beispiel...

[src=text]* Punkt 1, Absatz 1

Punkt 1, Absatz 2
* Punkt 2

Aber:

1. Punkt 1, Absatz 1

Punkt 1, Absatz 2
2. Punkt 2[/src]

Rein von den Gebrauch von Aufzählungen(!) im Sprachgebrauch:
[src=text]- dies ist ein Punkt
- dieser ist der zweite Punkt und hier machen wir den Satz jetzt mal etwas länger, aber eigentlich fasse ich doch den Sinn von etwas zusammen bzw nenne etwas
- dies ist ein weiteres Merkmal
- Attribute
[/src]

Im Gegensatz zu so etwas hier:

[src=text]1. Dokumentation (eine Liste mit zwei Punkten, die erste ebenfalls mit zwei Unterpunkten)

__Gute Dokumentation ist wichtig, das haben schon viele andere Programmierer erfahren die sich in etwas einarbeiten wollten, aber keine Dokumentation vorgefunden haben.

__Häufig sind wir aber meist recht faul wenn es darum geht, Code zu dokumentieren, da dies nicht zum eigentlichen Wert der Software beiträgt
__Kommentare werden in der Regel nicht bezahlt und sind auch keine Feautres, sie können aber dazu führen das die Wartungkosten gesenkt und Fehler schneller identifiziert werden können.


__1a. Features?
____Kommentare?

__2b. Einfach?
____Auch kommentieren will gelernt sein und es ist eine Kunst gute und verständlich für andere zu kommentieren.

2. Eine weitere Überschrift
__Mehr-
__zeiliger
__Text

__Absatzt[/src]


Ist ja ein Unterschied. Wobei gut, man kann auch eine Aufzählung ohne "Gedankenstriche" machen und stattdessen Nummerieren. Aber ich habe selten gesehen das "Gedankenstriche" für eine benannte Aufzählung und mit Fließtexten verwendet werden, in denen Absätze vorkommen. Häufiger liegt der Fall meiner Meinung nach bei richtigen "Aufzählungen". Wo man sich auch auf Punkte oder Abschnitte beziehen will.

Im übrigen zieht sich diese "Theorie" vielleicht auch durch Office Software - Gedankenstriche haben meist einen ein oder mehrzeiligen zusammenhängen Satz und zum Beispiel Open Office lässt dies nicht einmal zu, glaube ich zu wissen.

Bei Listenelemente sehe ich es allerdings auch so, das man keine Liste nimmt um Aufzählungen zu machen mit Beschreibungen, sondern eher einen Absatz wähl.

Ich finde aber, man kann, wenn man gute Argumente hat - klassisch nach dem von dir verlinkten Beispiel, auch gegen einen Standard gehen, wenn es gute Gründe dafür gibt - und die Whitespaces am "Ende" sind in vielen Editoren oder Office Dokumenten so gut wie unsichtbar. Daher würde ich NUR und ausschließlich auf die Backslash Regel bestehen und andersherum nur Whitespace am "Zeilenanfang" bzw. nach einem Listenelement akzeptieren.

Je nach Markdown Element kann Whitespace der Formatierung dienen wie du selbst ja aufzeigst - oder eben auch ein Stilmittel sein bzw. sogar beabsichtigt, von mir aus wie auch ein Tab oder Spaces am Anfang zum Einrücken von Code oder anderen Dingen. Wie gesagt würde ich das an dem Typ festmachen mit dem etwas eingeleitet wird.


Wenn du magst, kannst du ja auch mal eine HTML Ausgabe posten wenn sie startklar ist, würde mich auch interessieren was sich bei dir entwickelt. :)


Zu deiner Idee/Hinweis deine Testcases abzuarbeiten bzw. auszuarbeiten, könnte ich gern versuchen. :)
Theoretisch kann man über mehrere Zeilen vorweg parsen bzw. es versuchen, sagen wir mal 3 maximal 4 Zeilen und diese beobachten wie die sich darlegen, eigentlich sind dabei immer nur die ersten 10 Zeichen, bzw. in verschalteten Listen die "Tiefe", interessant, aber so einfach lässt sich eine Datei ja nicht direkt analysieren.. das man in Zeilen umherspringt meine ich ;)

Aber man könnte mit solche Analyse Punkten zumindest die Strukturen generell und die von Listen erfassen, aber wenn man die ersten 10 Zeichen beobachtet, natürlich auch noch erfassen ob wir den beginn einer Liste haben oder uns in einer befinden könnten.... aber ich glaube das würde ich jetzt aktuell nicht mehr direkt so umsetzen, dann lieber das Look-Ahead über 3-4 Zeilen vorwärts.

Und ein Kerngedanke vielleicht noch: theoretisch lebt HTML ja von seiner "Kompaktheit". Das man also nicht fünfzig leere Zeilen zwischen zwei Absätzen oder in Paragraphen oder Zitaten hat, sondern das man höchstens eine, vielleicht maximal 2 leere Zeilen nach einer Überschrift hat. Aber Markdown sehe ich auch als Tool an, um zu Dokumentieren bzw. Texte mit einfachen syntaktischen Elementen zu generieren (auf zweitem Blick), nicht um ein Office Dokument durch HTML zu ersetzen oder Bücher zu schreiben, in der mal 50 Zeilen "weiß" sind oder eine Leerseite dazwischen gemacht wird, damit es schöner aussieht. ;)

Edit: Achso und wie sagt(e) Knuth - "Premature optimization is the root of all evil!" in diesem Fall kann das auch auf das Zusammenfassen von Elementen bezogen sein oder ähnlichem :p
Oder auch, nicht zu "komplex" denken, auch wenn ich letztens mal die Diskussion hatte, dass es genug "DAUs" gibt, die ein System nicht wie "intented" gebrauchen :D

Vielleicht lieber mal nen Tag mehr erstellen... und nicht alles durchoptimieren was hinterher vielleicht gar keinen Sinn macht oder nicht so genutzt werden würde, ein paar "Spielregeln" kann man auch vorgeben an die man sich halten muß! Und das ist auch gut so. ;)

Im schlimmsten Fall macht der Parser dann halt "gar nix". ;)
 
Zuletzt bearbeitet:

Brother John

(schein)heilig
Teammitglied

Registriert
1 Aug. 2013
Beiträge
235
… Es ist unglaublich, wie faul man im Urlaub sein kann … Seeehr angenehm! :D Aber irgendwann musste es dann doch weiterparsen.

Straight forward ist Spirit zwar wirklich noch nicht, aber langsam lässt das Gefühl nach, den Parser prozedural selber schreiben zu wollen. Fein. Ich will ja schließlich was lernen bei dem Ganzen. Inzwischen gibt es auch Testcases mit Ausgabe. Dabei ist nebenher der HTML-Generator entstanden. Und zwar wirklich nebenher. Bei solchen Tests ist es am sinnvollsten, erwartete mit tatsächlicher Ausgabe zu vergleichen. Wenns nicht passt hat man nämlich zwei diffbare Texte in der Hand, was beim Fehler suchen ungemein hilft. Eigentlich wollte ich dafür ein simples Plaintextformat erzeugen, aber habe unterwegs gemerkt, dass HTML genau den Anspruch erfüllt. Deswegen besteht im Moment der etwas schräge Zustand, dass der Output-Generator in der Testsuite implementiert ist. :)

Falls jemand mit dem spielen will: CMake, C++14-Compiler, Boost, . Die Testsuite ist das einzige, das irgendwas tut. Um nur mal in Markdown-Input vs. HTML-Output reinzuschauen, reicht auch ein Blick in die . Alle Testcases machen genau die Gegenüberstellung; und alle sind momentan grün.

theSplit schrieb:
Ich finde aber, man kann, wenn man gute Argumente hat - klassisch nach dem von dir verlinkten Beispiel, auch gegen einen Standard gehen, wenn es gute Gründe dafür gibt
Ja … nein … kommt drauf an, was du machst. Sprache oder Parser bauen? Wenn du eine eigene Sprache entwirfst, die sich an einen Markdown-Dialekt anlehnt, dann ja, kannst du. Solltest du mit guten Gründen auch. Wenn du einen Parser für einen bestimmten Markdown-Dialekt schreibst, darfst du nicht. Dann ist eine Abweichung vom Standard ein Fehler in der Parserimplementierung, vollkommen egal wie gut begründet.

<< - Hier gibt es kein Leerzeichen das anführt, dennoch meinst du eine Liste liegt vor, dafür müsste allerdings auch ein Leerzeichen darauf folgen
Das ist offenbar dialektabhängig. Die sagt, es ist kein Leerzeichen nach dem Listenpunkt nötig, bzw. die Anzahl der Leerzeichen spielt keine Rolle. verlangt genau das Leerzeichen.

Zitate sind offenbar auch unterschiedlich. Gruber macht aus dem hier:
Code:
> A quote
with a line break
> and a different kind of linebreak

> A new quote - maybe ;)
> that looks a bit cleaner.
>
> Oh, and it has a second paragraph.
das da:
Code:
<blockquote>
  <p>A quote
with a line break
and a different kind of linebreak</p>

<p>A new quote - maybe ;)
that looks a bit cleaner.</p>

<p>Oh, and it has a second paragraph.</p>
</blockquote>
In CommonMark sind das zwei Zitate, getrennt durch die erste Leerzeile.
 

theSplit

1998
Teammitglied

Registriert
3 Aug. 2014
Beiträge
27.283
  • Thread Starter Thread Starter
  • #19
Wie kommst du voran @Brother John? Genießt du das Wochenende oder schuftest du schwer bzw. gehört das Schuften zum genießen oder auch (schon wieder) zum Wettbewerb? :p

Ich habe heute mal die erwähnten Quotes in Angriff genommen die du hier schilderst, so wird der Inhalt noch zusätzlich in einen Paragraphen eingebunden.

Das einzige Problem das ich so nicht lösen konnte bisher:

Leere Zitatzeichen, weil der Parser nun nicht weiß ob wir nur ein Zitat haben, oder ob wir nur ein ">" in einem Paragraphen wrappen sollen weil kein Leerzeichen darauf folgt.
Ziemlich tricky... jedenfalls für mich...

Habe mir auch mal die Commonmark Spezifikation angesehen, scheint ja gut dokumentiert zu sein, auch was Sonderfälle angeht.... allerdings, gibt es auch hier wohl noch Probleme:


Und genau sowas ist mir beim erarbeiten deiner Testcases auch schon mehr oder minder untergekommen. Irgendwo steht halt ein "if" zu viel oder zu wenig oder der Case wird noch komplexer oder schließt sich aus (oder ich mache es mir zu einfach?). ;)

Edit:
Mir ist da aber noch etwas aufgefallen, zur "Preoptimization" ;)

Folgender Fall:
[src=text]* Leerzeilen

* zwischen Listenpunkten
* sind erlaubt


* auch mehrere Leerzeilen[/src]

Ist das nun eine Liste? - Vielleicht ist hier auch der Fall korrekt, dass es sich um zwei Listen handelt bzw. sogar 3!
Selbst wenn diese nicht getrennt sind, du nimmst damit vieles "vorweg" wenn du entscheidest, es handele sich um eine lange Liste. Im besten Fall würde ich, für den Angeklagten von zwei Listen bzw. eher noch 3 ausgehen! - Eine Liste hängt "zusammen". Auch hier sollte das gleiche System wie für Paragraphen beibehalten werden.

Auch machtein normaler Zeilenumbruch im Fluss des Browsers bei einer Liste keinen direkten Unterschied bei der Darstellung, außer man setzt einen harten Break dazwischen.


Edit2:

Hier noch etwas zum Testen:

[src=text]> A quote
with a line break
> and a different kind of linebreak

> A new quote - maybe ;)
> that looks a bit cleaner.
>
> Oh, and it has a second paragraph.

a empty quote:

>

which becomes completely ignored...

Or what is that here:

*
*

Two stars, wrapped into one paragraph? No, its a list of two empty elements.


In comparison to

*

*

*

The last one is not at the start of the line.

With a preceeding whitespace

> A soft line break
if we have a preceeding space in front of a line

> Versus this
> here, those are two totally indenpented lines
> and here is the hard line break too, cause we are citing and FORCE a wrap

But also:

> A new citation
a new line
another line, all ending with soft linebreaks[/src]


ergibt bei mir aktuell:

[src=html5]<blockquote><p>A quote
with a line break<br/>
and a different kind of linebreak</p></blockquote>

<blockquote><p>A new quote - maybe ;)<br/>
that looks a bit cleaner.</p>
<br/>
<p>Oh, and it has a second paragraph.</p></blockquote>

<p>a empty quote:</p>



<p>which becomes completely ignored...</p>

<p>Or what is that here:</p>

<ul><li></li>
<li></li></ul>

<p>Two stars, wrapped into one paragraph? No, its a list of two empty elements.</p>


<p>In comparison to</p>

<ul><li></li></ul>

<ul><li></li></ul>

<p>*</p>

<p>The last one is not at the start of the line.</p>

<p>With a preceeding whitespace</p>

<blockquote><p>A soft line break<br/>
if we have a preceeding space in front of a line</p></blockquote>

<blockquote><p>Versus this<br/>
here, those are two totally indenpented lines<br/>
and here is the hard line break too, cause we are citing and FORCE a wrap</p></blockquote>

<p>But also:</p>

<blockquote><p>A new citation <!-- hier könnte man theoretisch auch einen <br/> setzen, weil das nächste Zeichen kein Leerzeichen ist und der satz "verschmelzen" könnte. -->
a new line
another line, all ending with soft linebreaks</p></blockquote>[/src]
 
Zuletzt bearbeitet:

MurmeltierS

Neu angemeldet

Registriert
9 Apr. 2017
Beiträge
21
Hallo miteinander,
ich werde ebenfalls teilnehmen und nutze ausschließlich "Vanilla" JS.

Hier mal aktuelle Parsing-Ergebnisse

markdown:
[src=html4strict]
# markdown to html
## by *Kevin Sieger*

Dieser effiziente markdown-Parser, welcher **fetten**
sowie *kurisven* Text unterstützt ist komplett in JavaScript
geschrieben und benötigt keine API oder Frameworks.

* Außerdem werden
* unnummerierte Aufzählungen
* unterstützt

>Blockquotes funktionieren sowohl
>in der Ausführlichen Variante mit einem '>'
>in jeder Zeile

>Als auch in dieser "faulen Variante" mit nur einem Zitat-
Beginn am Anfang

Zusätzliche unterstütze markdown-Syntax:

1. Sogar **nummerierte**
2. Aufzählungen werden richtig umgewandelt
3. und als *Ordered List* (ol) in HTML ausgegeben

24. Aufzählungen können bei einer beliebigen Zahl
25. begonnen werden und werden korrekt übernommen

[Links](http://www.it-talents.de) werden ebenfalls unterstützt, sowohl im [Fließtext](http://www.it-talents.de "IT-Talents") als auch als ausgeschriebene URL <http://kevinsieger.de>

Bilder können ebenfalls eingefügt werden:
![it-taltens](http://kevinsieger.de/ittalents.png "logo")
**Zum Ausprobieren kann der Text live editiert werden!**

[/src]

HTML:
[src=html4strict]
<p>
<h1>markdown to html</h1>
<h2>by <i>Kevin Sieger</i></h2>
</p>

<p>
Dieser effiziente markdown-Parser, welcher <b>fetten</b><br/>
sowie <i>kurisven</i> Text unterstützt ist komplett in JavaScript<br/>
geschrieben und benötigt keine API oder Frameworks.</p>

<p>
<ul>
<li>Außerdem werden</li>
<li>unnummerierte Aufzählungen</li>
<li>unterstützt</li>
</ul>
<blockquote>Blockquotes funktionieren sowohl in der Ausführlichen Variante mit einem '>' in jeder Zeile<br/>
</blockquote>
<blockquote>Als auch in dieser "faulen Variante" mit nur einem Zitat-<br/>
Beginn am Anfang<br/>
</blockquote>
</p>

<p>
Zusätzliche unterstütze markdown-Syntax:</p>

<p>
<ol>
<li value="1">Sogar <b>nummerierte</b></li>
<li value="2">Aufzählungen werden richtig umgewandelt</li>
<li value="3">und als <i>Ordered List</i> (ol) in HTML ausgegeben</li>
</ol>
</p>

<p>
<ol>
<li value="24">Aufzählungen können bei einer beliebigen Zahl</li>
<li value="25">begonnen werden und werden korrekt übernommen</li>
</ol>
</p>

<p>
<a href="http://www.it-talents.de" title="">Links</a> werden ebenfalls unterstützt, sowohl im <a href="http://www.it-talents.de " title="IT-Talents">Fließtext</a> als auch als ausgeschriebene URL <a href="http://kevinsieger.de">http://kevinsieger.de</a> </p>

<p>
Bilder können ebenfalls eingefügt werden:<br/>
<img src="http://kevinsieger.de/ittalents.png" alt="it-taltens" title="logo"/><br/>
<b>Zum Ausprobieren kann der Text live editiert werden!</b><br/>
</p>
[/src]

Ich nutze hauptsächlich RegExp um zu parsen und benötige so momentan 35 Zeilen Code, wobei das natürlich realtiv gesehen werden muss, da RegExp mir einiges "abnimmt".

mfg
Kevin
 
Oben