spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »BlueCobold«

Komma-separiert ist übrigens in einer Sprache, die Komma als Inhalt zulässt, vielleicht keine so gute Idee... Genau genommen hast Du auch schon Trenner und musst keine künstlichen einführen: Spitze Klammern und Leerzeichen innerhalb von spitzen Klammern.
Du kannst jedenfalls keine Regel finden, die Leerzeichen einfach wieder einfügt, denn dem User ist es ja freigestellt folgenden Source zu schreiben:
mein <e/>Text ist <e/> eine Pein<e/> für Jedermann<e/>!

Die Kommas waren hier nur zur Veranschaulichung. Getrennt wird nach:


Und da teilweise auch nur innerhalb von <...>. Der Tokenizer macht seinen Job schon gut, kannst dir ja mal die Tests ansehen, da siehst du genau welche Tokens rauskommen.

Zitat von »Sacaldur«

Die Leerzeichen müssen ohnehin nochmal gesondert betrachtet werden: Hat man mehrere Whitespaces in HTML hintereinander, werden diese im Normalfall zu einem zusammengefasst oder weggelassen, abhängig vom Kontext. Whitespacess können aber auch über HTML-Entitäten definiert werden, wie &nbsp;. Der HTML-Code Hello &nbsp; World! würde in einem einzelnen Leerzeichen resultieren, nicht aber in 3 Leerzeichen. pre-Elemente (sofern nicht per CSS angepasst) sorgen bspw. dafür, dass die Whitespaces in ihnen nicht zusammengefasst werden. Und auch über mehrere HTML-Entitäten kann man mehrere Leerzeichen hintereinander hinbekommen.

Jup das ist soweit bekannt, berücksichtige aber noch nicht, da man auch am Ende einfach eine Ersetzung einbauen kann.

Zitat von »Sacaldur«

Eine Frage zu Markdown:
Wie würde *Hello*World*! ausgewertet werden?
Ist das Bindestrich auch ein Formatierungssymbol? Wenn ja, wie würde -Probe-Wort- ausgewertet werden?
Wenn die Formatierungszeichen in der Mitte nicht berücksichtigt, weil sie zwischen 2 Buchstaben stehen, dann wird es ohnehin schwieriger, die Übersetzung durchzuführen. Immerhin müsstest du manuell Leerzeichen einfügen, die vom Benutzer nicht unbedingt eingegeben wurden, damit die Formatierung richtig übernommen wird.

Das ist ein Problem welches ich bei meinen Programmcode Compilern auch noch nicht hatte. Für Md und HTML darf der Compiler nicht so "strickt" sein. Mit Md -> HTML habe ich noch nicht angefangen, aber da wird er wohl das erste * finden, ab da ein Element einfügen und bei dem * in der Mitte wieder schließen. Das letzte bleibt dann offen (bzw. wird ganz am Ende entsprechend geschlossen, damit der HTML Code zumindest keine Elemente nach dem Editor im Browser kaputt macht). Also wenig Intelligenz hier.

Zitat von »Sacaldur«

Darf ich in diesem Sinne die Frage in den Raum werfen, warum Markdown verwendet wird? Gibt es dafür bestimmte Vorgaben (ein anderes Programm verwendet dies) oder könntest du auch bspw. BB-Code verwenden?

Naja eigentlich könnte ich auch gleich HTML speichern, das würde auch funktionieren. Ziel ist aber neben der HTML Anzeige im Browser, auch eine rein Textbasierte Form exportieren zu können. Und da finde ich Md als quasi Standard am besten.

Ich denke ich werde die Leerzeichen jetzt einfach drin lassen und vor dem zerlegen in Tokens "aufräumen", also alle mehrfachen Leerzeichen rauswerfen und Tabs können auch einfach gelöscht werden. Zeilenumbrüche kann ich dann auch einfach durch ein Leerzeichen ersetzen (vor dem ganzen), dann hab ich damit auch kein Problem mehr. Ich teste heute abend oder halt morgen

Zitat von »BlueCobold«

Zitat von »DeKugelschieber«

Der Tokenizer macht seinen Job schon gut, kannst dir ja mal die Tests ansehen, da siehst du genau welche Tokens rauskommen.

Nun, wenn das so ist, hast Du eigentlich also gar kein Problem mit Leerzeichen!?

Wenn ich sie jetzt drin lasse vermutlich nicht. Werde ich dann sehen

Zitat von »Sacaldur«

Zitat von »DeKugelschieber«

Zitat von »Sacaldur«

Die Leerzeichen müssen ohnehin nochmal gesondert betrachtet werden: Hat man mehrere Whitespaces in HTML hintereinander, werden diese im Normalfall zu einem zusammengefasst oder weggelassen, abhängig vom Kontext. Whitespacess können aber auch über HTML-Entitäten definiert werden, wie &nbsp;. Der HTML-Code Hello &nbsp; World! würde in einem einzelnen Leerzeichen resultieren, nicht aber in 3 Leerzeichen. pre-Elemente (sofern nicht per CSS angepasst) sorgen bspw. dafür, dass die Whitespaces in ihnen nicht zusammengefasst werden. Und auch über mehrere HTML-Entitäten kann man mehrere Leerzeichen hintereinander hinbekommen.

Jup das ist soweit bekannt, berücksichtige aber noch nicht, da man auch am Ende einfach eine Ersetzung einbauen kann.

Allerdings werden die Whitespaces, so wie ich es bisher verstanden habe, einfach weggeschmissen. Wie will man dann wissen, wie viele Leerzeichen in einem pre-Element mal vorhanden waren?

Hmm also whitespaces drin lassen wird auch nicht wirklich funktionieren, da Einrückung im HTML keine Bedeutung hat. pre ist ein Sonderfall den der Tokenizer evt. irgendwann mal berücksichtigen kann. Vorerst brauche ich das aber nicht und wird somit auch nicht unterstützt. Irgendwo muss ich die Grenze ziehen.

Zitat von »Sacaldur«

Zitat von »DeKugelschieber«

Zitat von »Sacaldur«

Eine Frage zu Markdown:
Wie würde *Hello*World*! ausgewertet werden?
Ist das Bindestrich auch ein Formatierungssymbol? Wenn ja, wie würde -Probe-Wort- ausgewertet werden?
Wenn die Formatierungszeichen in der Mitte nicht berücksichtigt, weil sie zwischen 2 Buchstaben stehen, dann wird es ohnehin schwieriger, die Übersetzung durchzuführen. Immerhin müsstest du manuell Leerzeichen einfügen, die vom Benutzer nicht unbedingt eingegeben wurden, damit die Formatierung richtig übernommen wird.

Das ist ein Problem welches ich bei meinen Programmcode Compilern auch noch nicht hatte. Für Md und HTML darf der Compiler nicht so "strickt" sein. Mit Md -> HTML habe ich noch nicht angefangen, aber da wird er wohl das erste * finden, ab da ein Element einfügen und bei dem * in der Mitte wieder schließen. Das letzte bleibt dann offen (bzw. wird ganz am Ende entsprechend geschlossen, damit der HTML Code zumindest keine Elemente nach dem Editor im Browser kaputt macht). Also wenig Intelligenz hier.

Hast du auch die Möglichkeit des Escapens von formatierenden Symbolen (bspw. *) vorgesehen? Mal angenommen, der Benutzer gibt "<b>Benutzer*innen</b>" ein, würde das ein "*Benutzer*innen*" oder "*Benutzer\*innen*" erzeugen? Wenn das Markdown nicht manuell vom Benutzer eingegeben werden kann, dürftests du dir aber auch ein paar Erwartungshaltungen Seitens des Benutzers vom Hals halten, wie das "Formatieren" von Inhalten mit "---" oder "***" irgendwo mitten im Text.

Genau Zeichen wie * und Co werden escaped. Aber wie gesagt habe ich mit dem Md zu HTML Compiler noch nicht begonnen, erst das eine dann das andere Nutzer sollen später im "Experten" Modus schon Md direkt eingeben können, was aber kein Problem des Compilers ist. Hier wird der JavaScript Editor direkt in HTML umwandeln. Die ganze Entwicklung von dem Compiler hier findet vor dem Hintergrund der Informationsplattform Entwicklung statt, also nicht ganz kontextfrei. Der Compiler soll nur möglichst robust sein, muss aber nicht alles unterstützen was irgendwie denkbar ist. Erstmal soll es überhaupt funktionieren.

Zitat von »Sacaldur«

Zitat von »DeKugelschieber«

Zitat von »Sacaldur«

Darf ich in diesem Sinne die Frage in den Raum werfen, warum Markdown verwendet wird? Gibt es dafür bestimmte Vorgaben (ein anderes Programm verwendet dies) oder könntest du auch bspw. BB-Code verwenden?

Naja eigentlich könnte ich auch gleich HTML speichern, das würde auch funktionieren. Ziel ist aber neben der HTML Anzeige im Browser, auch eine rein Textbasierte Form exportieren zu können. Und da finde ich Md als quasi Standard am besten.

Einerseits wäre es wahrscheinlich sinnvoll, das, was der Benutzer eingibt, auch so in der Datenbank zu speichern. Wenn er BB-Code eingibt, wäre das BB-Code, bei HTML wäre es HTML usw. Die Übersetzung würde dann nur noch bei der Darstellung des Inhalts stattfinden, nicht als Zwischenschritt beim Speichern und Laden. So bekommt der Benutzer beim Überarbeiten seiner Eingabe auch wieder das, was er selbst eingegeben hat.
Sobald dies so gemacht wird, wird mit dem Zwischenschritt Markdown nur noch dafür gesorgt, dass nur noch ein Teil der Möglichkeiten von HTML verwendet werden kann. Statt also eine Übersetzung zu Markdown durchzuführen, kann man genauso eine "Übersetzung" von dem eingegebenen HTML in bereinigtes HTML (ungewünschte Elemente entfernt etc.) übersetzt.
Will man auch reinen Text ausgeben können, hat man entweder den Schritt Markdown zu Text, oder den Schritt HTML zu Text.

Insgesamt würde ich dir eher dazu raten, wenn der Benutzer HTML eingeben kann, dass dieses Gespeichert und vor dem Ausliefern "bereinigt" wird.

Das ist die einfachere Lösung und ich werde darauf auch ausweichen, wenn das hier zu kompliziert wird. Verkaufsargument für die Plattform soll auch Unabhängigkeit der Daten von der Software sein, da bietet sich Md als "zukunftsicheres" Format, welches auch ohne weitere Software gut gelesen werden kann an. Möchte der Kunde z.B. das System wechseln, aber die Daten nicht migrieren kann er die Md Dokumentation gut weiter benutzten.
Der Kram wird übrigens nicht in einer Datenbank sondern in Git abgelegt. Ich hab das mit dem Linux Repo getestet, die Suchgeschwindigkeit von Git ist einfach hervorragend und wahrscheinlich sogar besser als so manche Datenbank. Und das alles über alle Änderungen hinweg! Beispiel ";" im Linux Repo suchen findet mehrere Millionen Einträge im 1 bis maximal 2 stelligen ms Bereich.

Aber sollte wirklich alles nicht klappen so wie ich mir das vorstelle speichere ich HTML halt direkt und lasse das alles. Das ist die einfache Ausweichlösung. Bevorzugen würde ich aber wirklich die Umwandlung, auch wenn es mehr Arbeit ist.