search

gaenseklein / slidenotes

0 stars 0 forks source link

kommentartag in md-code einführen #54

Closed gaenseklein closed 5 years ago

gaenseklein commented 6 years ago

es soll möglich sein, per // kommentare einzufügen. das heißt: per // wird der text bis zum ende der zeile als kommentar markiert und nicht in der ausgabe angezeigt und auch sonst nicht interpretiert. Das gilt überall dort, wo md-code implementiert wird, sollte aber auch von anderen modulen möglichst eingehalten werden. oder soll das generell gelten?

gaenseklein commented 5 years ago

parse-probleme: das zeichen für kommentare // ist ein valides zeichen innerhalb von sources/urls bei images und links. gleichzeitig sollten aber links und images auch auskommentiert werden können denke ich mal. wenn ich es als letztes nehme werden alle one-line elemente trotzdem geparsed auch wenn ich sie auskommentiert habe. das betrifft images, links, inlinecode, pagebreak, anchors. alle anderen per-line elemente brauchen einen line-anfang, werden also eh nicht interpretiert wenn am anfang der zeile // steht - machen also keine probleme. kommentare müssen daher logischerweise vor allen one-line elementen geparsed werden, aber aufpassen, dass sie keine image-source oder url sind.

valide urls: http:// https:// file:/// some/url//is/not/valid/or/is/it? was ist mit //url/to/somewhere?

ich habs jetzt erstmal so implementiert, dass nach einem doppelpunkt vor dem // geguckt wird. ist dort eins ist es kein kommentar. damit sind alle obigen fälle abgedeckt, da er nach dem ersten // vom file:/// direkt zum letzten springt und nicht zum zweiten (weil er die ersten // bereits als part of url interpretiert). so kann nicht nur images und links benutzt werden sondern auch urls im text geschrieben werden (die werden sonst ja auch als kommentar interpretiert).

nächstes problem sind die inlinecodes (codeblöcke dürften kein problem sein, da sie vom parsen ausgenommen werden). hier ist wieder das henne-ei prinzip - welches soll zuerst geparsed werden? wenn ich inlinecode zuerst parse ist es möglich, innerhalb von inlinecode // zu schreiben. dann ist es aber nicht mehr möglich, inlinecode auszukommentieren oder? bzw. dann wird im kommentar trotzdem ein inlinecode geparsed. ist das schlimm? ja ist es. das muss gelöst werden, sonst kommt es im editor zu folgenden fehlern:

bleibt mir wohl nichts übrig als das abzufragen nachdem der kommentar gemacht wurde: in der map insertedhtmlinline abfragen und alle elemente die im kommentar stehen werden überschrieben durch ein "deleted"-typen ohne html und md-code. das ist zwar nicht so elegant wie die aus dem array rauszunehmen aber sonst muss ich die aus allen arrays rausfiltern, was fehleranfällig ist und evtl. sogar länger dauert. in der perror muss ich alle errors rausnehmen, welche in einem kommentar stehen würden. das ist mit einem splice getan.

funktioniert jetzt.

gaenseklein commented 5 years ago

die behandlung innerhalb der datenblöcke ist den jeweiligen plugins überlassen, es sei denn sie lassen md-code zu. dann sind sie ebenfalls als kommentare geparsed. kommentare werden in headers ebenfalls standardmäßig angezeigt header wurde nicht gesperrt vorm parsen, aber das war ein bug. um es zu ermöglichen, bpsw. optionen im header wirklich auszukommentieren - sprich das sie auch nicht verarbeitet werden - müssen sie noch aus den datenobjecten entfernt werden. am besten direkt beim hinzufügen des dataobjects. done. damit sie im editor angezeigt werden werden sie an der stelle der map hinzugefügt, wo sie auch im datenobject behandelt werden. done

gaenseklein commented 5 years ago

@jochmann denke, das ist erledigt. bitte mal kurz testen und sagen, ob die funktionalität dem entspricht was du dir vorstellst. würde das issue schließen.

jochmann commented 5 years ago

kommentare sollten nur durch // am zeilenanfang ausgelöst werden und erstrecken sich bis zum nächsten return-zeichen (absatz). Ausnahme: in sections in der auszeichnungszeile dürfen // als letzter teil der auszeichnungssyntax stehen.



im fließtext finde ich kommentare unglücklich, weil sie keinen "close-tag" haben. die Konvention bei JavaScript ist auch, dass // sich auf eine Zeile erstreckt. auch in Präsentationsprogrammen gibt es nur ein extra textfeld für kommentare, kein hin-und-her im Fließtext. lass uns an dieser stelle nicht unnötig komplexität mit weiteren closing-tags reinbringen.

für den parser ist mir noch eingefallen (weiß nicht, wie das aktuell aussieht):

leerzeile wird <p>, etc - nur ein umbruch heißt <br> innerhalb von <p>etc

> On 1. Dec 2018, at 04:13, gaenseklein <notifications@github.com> wrote:
> 
> @jochmann <https://github.com/jochmann>
> denke, das ist erledigt. bitte mal kurz testen und sagen, ob die funktionalität dem entspricht was du dir vorstellst. würde das issue schließen.
> 
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub <https://github.com/gaenseklein/slidenotes/issues/54#issuecomment-443394827>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB6hBBvynKGq4HCI2LjYKMcXgOJBWnVhks5u0fPOgaJpZM4Y0Uz7>.
>
gaenseklein commented 5 years ago

ok, also kommentare nur an den zeilenanfang und in plugin-headern. die konvention bei javascript ist, dass alles ab kommentar-// bis zum zeilenende als kommentar interpretiert wird und nicht als gültiger code. so hab ich das momentan einfach umgesetzt. aber ein kommentar muss nicht am zeilenanfang stehen sodern irgendwo nur nicht in einer geöffneten anweisung - also bspw. "//" wird nicht als kommentar angesehen oder bla(//) auch nicht. ähnlichen fall haben wir halt mit den sourcen. wenn aber bei uns die regel gilt, dass nur ganze zeilen als kommentar interpretiert werden ausser in headern von ´´´ dann ists kein problem das zu parsen.

gaenseklein commented 5 years ago

habs jetzt wie oben besprochen umgesetzt. kommentare gehen nur noch über ganze zeile und innerhalb von section-headern.