Änderung von datensyntax

der abschluss-tag ist für daten-tags verbindlich - d.h. in der zeile darf sonst nichts stehen. auch kein kommentar, nichts. nur die drei zeichen. ja. abschluss immer mitin eigener Zeile. ich würde allerdings die tags als "section-tags" bezeichnen. Und im HTML auch mit
auszeichnen. eventuell kennzeichnen wir bestehende semantische einheiten direkt oder als tochterelement? also für Tabellen und
für die datenvisualisierungen. bei code macht ein tochterelement im HTML mehr sinn, denke ich, weil code kein block-element ist.
... start ist immer (alles in einer Zeile) mit ```VARIABLE:subvariable(optional) TITEL(optional) // kommentar(optional) bei code können wir uns damit die manuelle auszeichnung der sprache (für color-coding) offenhalten: > um im code-block das zeichen ` zu schreiben muss es durch ein \ ausgeklammert werden. so kann auch im code-block datenheader etc. stehen - sie müssen nur das erste ` ausklammern - also bspw. \``` ich würde in code-sections auch im Fließtext(!) alle markdown-charaktere vom parser ignorieren lassen und als reguläre zeichen behandeln, außer ``` im fließtext also : dies ist mein ```<html><body>Beispiel wo * ignoriert wird</html></body>``` > alles, was nicht durch ein plugin als datenstruktur gekennzeichnet ist wird als "code" aufgefasst. dadurch bleibt die kompatiblität mit der "code"-schreibweise von markdown gewährleistet. hier würde ich eher als "default" auf den nackten <section> tag zurück fallen für die interne logik. ``` ist also gleich ```layout > code erlaubt keine inneren datentags bzw. keine innere verschachtelung. die nächste zeile mit drei ` am anfang wird als codeende interpretiert. egal ob es ein datahead ist oder nicht. wollen wir vielleicht innere verschachtelung von sections ganz allgemein verbieten? wenn unbedingt nötig für ein total wichtiges standard-layout-problem, würde ich verschränkung mindestens auf ```layout begrenzen. lieber noch ganz darauf verzichten. irgendwann macht ein WYSIWYG-tool einfach mehr sinn für leute, die extreme kontrolle über das layout haben wollen. > On 1. Dec 2018, at 17:38, gaenseklein <notifications@github.com> wrote: > > @jochmann <https://github.com/jochmann> wenn es weitere syntax-änderungsvorschläge gibt wäre jetzt noch ein guter zeitpunkt. ich habe manche sachen hardgecoded - wie eben bspw. die buttons fürs einfügen von datenstruktur-texten. wenn das flexibler gestaltet werden soll - also in zukunft vielleicht doch noch mal die syntax geändert werden soll - würde ich das jetzt gerne wissen und dann dementsprechend ändern. das ist möglich, aber verkompliziert die stelle, die sonst ein ein-zeiler pro plugin ist. allgemein sollten syntax-änderungen vor dem ersten start abgeschlossen sein imho und danach nur noch erweitert, aber nicht mehr verändert/gelöscht werden (es sei denn es gibt n krassen versionssprung der das rechtfertigt) um abwärtskompatiblität zu gewährleisten. > wichtig zu wissen bei der jetzigen syntax: > > der abschluss-tag ``` ist für daten-tags verbindlich - d.h. in der zeile darf sonst nichts stehen. auch kein kommentar, nichts. nur die drei zeichen. > alles, was nicht durch ein plugin als datenstruktur gekennzeichnet ist wird als "code" aufgefasst. dadurch bleibt die kompatiblität mit der "code"-schreibweise von markdown gewährleistet. > code erlaubt keine inneren datentags bzw. keine innere verschachtelung. die nächste zeile mit drei ` am anfang wird als codeende interpretiert. egal ob es ein datahead ist oder nicht. > um im code-block das zeichen ` zu schreiben muss es durch ein \ ausgeklammert werden. so kann auch im code-block datenheader etc. stehen - sie müssen nur das erste ` ausklammern - also bspw. \``` > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub <https://github.com/gaenseklein/slidenotes/issues/55#issuecomment-443439022>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB6hBFB60ZXLL5AU32Iz20TLargqU_wtks5u0rCggaJpZM4Y8kFO>. > gaenseklein commented 5 years ago ok, aus datentags <data> werden sectiontags <section>. die datentags zu ändern (also bei table aus <section> direkt ein <table>) könnte arbeit sein, aber müsste eigentlich gehen. als tochterelement ist es ja jetzt schon so - also da wird ja ne html-tabelle eingefügt wenn du ```table benutzt. muss ich mir nochmal angucken wie das grad gelöst ist. code ist bisher als alleinstehendes element da. das kann ich natürlich noch in ein anderes tag deiner wahl packen. start ist immer (alles in einer Zeile) mit ```VARIABLE:subvariable(optional) TITEL(optional) // kommentar(optional) aktueller stand ist: ```pluginname (optional) variabler-text nach-pluginwahl (optional) //kommentar (optional) wenn ein reines ``` ohne alles steht wird es als code interpretiert. wenn der pluginname nicht in den aktivierten plugins vorhanden ist - ebenfalls code und der variable-text (die konfig-möglichkeit für die plugins) ist der rest der zeile. ein kommentar beendet den variablen-text, ansonsten das zeilenende. dadurch ist bspw. ```chart line möglich. ein standardisiertes variable:subvariable system inkl. titel halte ich für nicht sinnvoll. die plugins können derart anders sein, dass ein standard da kaum sinn macht. und du willst es auch nicht komplizierter machen als nötig. daher überlege ich bspw. auch ```linechart zu ermöglichen und nicht nur ```chart line. den usern aber aufzudrücken, sich dafür ne syntax zu merken führt ja weg vom easy-peasy-stil. und was den titel angeht: als alternative zum Titel in den chart-header zu packen würd ich den Titel einfach komplett weglassen wenn du es nicht in der datenstruktur der chart haben willst. es gibt bereits einen titel-tag und der kann auch besser gelayoutet werden als innerhalb der chart. ansonsten wüsste ich auf anhieb kein einziges plugin, was überhaupt titel hat? also einfach die titel-option der chart nicht benutzen und den titel vor die chart schreiben. der variable text ist eher für die zukunft gedacht, dass wir da erweiterbar bleiben was plugins angeht. bei code können wir uns damit die manuelle auszeichnung der sprache (für color-coding) offenhalten: ´´´code:python Mein Pythonbeispiel // mit extra Schlangenöl brauchen wir nicht mal. ein ´´´python würde ausreichen, da es wohl kaum ein plugin namens python geben wird. das 'code:' ist überflüssig und nicht github-md-konform. die einzige angabe die ein codeblock noch braucht ist python. macht imho keinen sinn da die github-md-version zu verlassen. wir wollen sie ja möglichst erweitern, nicht ändern. ich würde in code-sections auch im Fließtext(!) alle markdown-charaktere vom parser ignorieren lassen und als reguläre zeichen behandeln, außer im fließtext also : dies ist meinBeispiel wo * ignoriert wird``` war schlampig formuliert von mir. wenn du innerhalb eines code-blocks die ´´´ an den anfang der zeile schreiben willst (weil du zum beispiel den nicht-interpretierten md-code für chart-erstellung anzeigen willst) musst du das erste ausklammern. ansonsten würde es da ja enden. das ist github-md-konform und eigentlich nicht der rede wert. hier (nur ) würde ich eher als "default" auf den nackten <section> tag zurück fallen für die interne logik. ist also gleich ```layout würd ich nicht machen. ist nicht github-konform und gibt keine not dazu. kann ich natürlich ändern und dann nur noch ´´´code python bspw. als gültig interpretieren lassen, aber warum willst du da den standard verlassen? wollen wir vielleicht innere verschachtelung von sections ganz allgemein verbieten? warum? damits bequemer zu programmieren ist? es gibt nicht viele innere verschachtelungen (zur zeit). aber es gibt sie. spontan fallen mir layout und hidden ein, welche eine verschachtelung erfordern. aber vielleicht kommen da in zukunft noch welche dazu. warum sich die möglichkeit dazu verbieten? layout und hidden haben beide wichtige use-cases und auch wenn es damit theoretisch möglich ist eine immense verschachtelung aufzubauen macht das praktisch keinen sinn. mehr als drei ebenen sehe ich einfach nicht. und auch das wird seltenst benutzt. (hidden-layout-chart-layoutend-hiddenend beispielsweise) jochmann commented 5 years ago wahrscheinlich ist es am einfachsten für die interne HTML-Logik (und das darauf setzende CSS!), wenn als parent element für die Sektionen immer(!) eine steht und NUR bei den durch daten besonders ausgezeichneten dann die jeweiligen tochter-elemente (code, table, etc). sofern nichts dagegen spricht, lass uns lieber alles per abgrenzen und tochterelemente nach Bedarf zufügen. deswegen ist auch die logik konsistent, dass ```alleine für steht. Hier weichen wir aus gutem Grund von GitHub ab. Das am häufigsten benötigte (Layout) sollte am leichtesten zu tippen sein. Und es sieht im Schriftbild klarer aus. ```(optional-pluginname) sollte als default immer eine variable für den titel mitführen. Die brauchen wir, um später im Outline (der Inhalts-Übersicht) einzelne Sektionen auch wiederzuerkennen. Wenn da nur "code #5" steht und du es nicht benennen kannst, ist ja völlig intransparent, was der Inhalt ist. eine Sektion mit Plugin (jede Tabelle, Grafik, Codebeispiel, eigentlich auch Zitate) sollte referenzierbar sein. Deswegen würde ich denen eine "unnamed code sample no3" Benennung automatisch verpassen und den usern die Option geben, Titel zu vergeben. wohlgemerkt, nur bei "semantischen" sections. nicht für layout. die user müssen sich unbedingt dafür eine syntax merken, die sollte nur transparent und logisch sein, und immer mit defaults arbeiten, die der user dann mit der richtigen syntax überschreiben kann. so lernst du die syntax nach und nach, weil das programm dich wie ein tutorial mit den fallbacks und context-hilfe immer begleitet. ```pluginname:variable titel // kommmentar finde ich schon sehr transparent und es sieht im schriftbild auch total klar aus. für ```code ist der fallback (fehlen der angegebenen variable): auto-erkennung ```code:python heißt, der code-highlighter behandelt alles als python ```table braucht keine variable, also auch kein fallback nötig. vielleicht fallen uns später aber sachen ein, wie wir verschiedene table-layouts anbieten wollen. die syntax gibt das jetzt her. ```chart hat als fallback die bar-chart > On 3. Dec 2018, at 02:14, gaenseklein <notifications@github.com> wrote: > > ok, aus datentags <data> werden sectiontags <section>. > die datentags zu ändern (also bei table aus <section> direkt ein <table>) könnte arbeit sein, aber müsste eigentlich gehen. als tochterelement ist es ja jetzt schon so - also da wird ja ne html-tabelle eingefügt wenn du ```table benutzt. muss ich mir nochmal angucken wie das grad gelöst ist. > code ist bisher als alleinstehendes element da. das kann ich natürlich noch in ein anderes tag deiner wahl packen. > > start ist immer (alles in einer Zeile) mit ```VARIABLE:subvariable(optional) TITEL(optional) // kommentar(optional) > > aktueller stand ist: ```pluginname (optional) variabler-text nach-pluginwahl (optional) //kommentar (optional) > wenn ein reines ``` ohne alles steht wird es als code interpretiert. wenn der pluginname nicht in den aktivierten plugins vorhanden ist - ebenfalls code und der variable-text (die konfig-möglichkeit für die plugins) ist der rest der zeile. ein kommentar beendet den variablen-text, ansonsten das zeilenende. > dadurch ist bspw. ```chart line möglich. > ein standardisiertes variable:subvariable system inkl. titel halte ich für nicht sinnvoll. die plugins können derart anders sein, dass ein standard da kaum sinn macht. und du willst es auch nicht komplizierter machen als nötig. daher überlege ich bspw. auch ```linechart zu ermöglichen und nicht nur ```chart line. den usern aber aufzudrücken, sich dafür ne syntax zu merken führt ja weg vom easy-peasy-stil. > und was den titel angeht: als alternative zum Titel in den chart-header zu packen würd ich den Titel einfach komplett weglassen wenn du es nicht in der datenstruktur der chart haben willst. es gibt bereits einen titel-tag und der kann auch besser gelayoutet werden als innerhalb der chart. ansonsten wüsste ich auf anhieb kein einziges plugin, was überhaupt titel hat? also einfach die titel-option der chart nicht benutzen und den titel vor die chart schreiben. > der variable text ist eher für die zukunft gedacht, dass wir da erweiterbar bleiben was plugins angeht. > > bei code können wir uns damit die manuelle auszeichnung der sprache (für color-coding) offenhalten: ´´´code:python Mein Pythonbeispiel // mit extra Schlangenöl > > brauchen wir nicht mal. ein ´´´python würde ausreichen, da es wohl kaum ein plugin namens python geben wird. das 'code:' ist überflüssig und nicht github-md-konform. die einzige angabe die ein codeblock noch braucht ist python. macht imho keinen sinn da die github-md-version zu verlassen. wir wollen sie ja möglichst erweitern, nicht ändern. > > ich würde in code-sections auch im Fließtext(!) alle markdown-charaktere vom parser ignorieren lassen und als reguläre zeichen behandeln, außer im fließtext also : dies ist meinBeispiel wo * ignoriert wird``` > > war schlampig formuliert von mir. wenn du innerhalb eines code-blocks die ´´´ an den anfang der zeile schreiben willst (weil du zum beispiel den nicht-interpretierten md-code für chart-erstellung anzeigen willst) musst du das erste ausklammern. ansonsten würde es da ja enden. das ist github-md-konform und eigentlich nicht der rede wert. > > hier (nur ) würde ich eher als "default" auf den nackten <section> tag zurück fallen für die interne logik. ist also gleich ```layout > > würd ich nicht machen. ist nicht github-konform und gibt keine not dazu. kann ich natürlich ändern und dann nur noch ´´´code python bspw. als gültig interpretieren lassen, aber warum willst du da den standard verlassen? > > wollen wir vielleicht innere verschachtelung von sections ganz allgemein verbieten? > > warum? damits bequemer zu programmieren ist? > es gibt nicht viele innere verschachtelungen (zur zeit). aber es gibt sie. spontan fallen mir layout und hidden ein, welche eine verschachtelung erfordern. aber vielleicht kommen da in zukunft noch welche dazu. warum sich die möglichkeit dazu verbieten? > layout und hidden haben beide wichtige use-cases und auch wenn es damit theoretisch möglich ist eine immense verschachtelung aufzubauen macht das praktisch keinen sinn. mehr als drei ebenen sehe ich einfach nicht. und auch das wird seltenst benutzt. (hidden-layout-chart-layoutend-hiddenend beispielsweise) > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub <https://github.com/gaenseklein/slidenotes/issues/55#issuecomment-443561068>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB6hBGw_vIGYV0yoGEWCMjU0xz5MECdqks5u1HragaJpZM4Y8kFO>. > gaenseklein commented 5 years ago wahrscheinlich ist es am einfachsten für die interne HTML-Logik (und das darauf setzende CSS!), wenn als parent element für die Sektionen immer(!) eine steht und NUR bei den durch daten besonders ausgezeichneten dann die jeweiligen tochter-elemente (code, table, etc). sofern nichts dagegen spricht, lass uns lieber alles per abgrenzen und tochterelemente nach Bedarf zufügen. glaub ich nicht. dem html ists eigentlich egal, dem css auch. mein programm dagegen findets natürlich schick, alle datenobjekte als <section> (bzw. momentan noch <data>) zu haben. deswegen ist auch die logik konsistent, dass ``alleine für ` steht. ne, denn ne section wie wir sie dachten ist was anderes und wird anders interpretiert als bspw. ne tabelle. wenn immer sections steht, dann braucht das, was wir als <section> hatten n eigenen identifier. bspw. n internes <layout> oder<section class="layout">. ´´´code steht für <section><header></header><code id="N+1"> stimmt nicht. code steht für <code id="n+1"> - zumindest momentan. und das macht auch sinn, es sei denn ich behandel das eben auch als datenobject. (dann muss ich das programm an der stelle umschreiben). header macht gar keinen sinn, weil es in der präsentation gar keine header gibt für code. es sei denn du fügst das neu ein. Hier weichen wir aus gutem Grund von GitHub ab. Das am häufigsten benötigte (Layout) sollte am leichtesten zu tippen sein. und welches ist das am häufigsten benötigte? Layout? echt? dachte, das ist eher was für die, die gerne mehr kontrolle und so haben wollen. also für die advanced user. für ne simple slidenote solltest du das nie brauchen. denke tatsächlich, chart wird das meistgenutzte werden und dann teilts sich auf in programmierer, admins und co(code), mathematiker(latex), studis, werber und ähnliche (hidden). Und es sieht im Schriftbild klarer aus. das ist dem user momentan selbst überlassen: auch ´´´code wird ja als code interpretiert. ´´´(optional-pluginname) sollte als default immer eine variable für den titel mitführen. Die brauchen wir, um später im Outline (der Inhalts-Übersicht) einzelne Sektionen auch wiederzuerkennen. Wenn da nur "code #5" steht und du es nicht benennen kannst, ist ja völlig intransparent, was der Inhalt ist. eine Sektion mit Plugin (jede Tabelle, Grafik, Codebeispiel, eigentlich auch Zitate) sollte referenzierbar sein. Deswegen würde ich denen eine "unnamed code sample no3" Benennung automatisch verpassen und den usern die Option geben, Titel zu vergeben. wohlgemerkt, nur bei "semantischen" sections. nicht für layout. die user müssen sich unbedingt dafür eine syntax merken, die sollte nur transparent und logisch sein, und immer mit defaults arbeiten, die der user dann mit der richtigen syntax überschreiben kann. so lernst du die syntax nach und nach, weil das programm dich wie ein tutorial mit den fallbacks und context-hilfe immer begleitet. für eine indexierung würde ich eher nach titeln suchen und diese verwenden. dafür braucht es keine extra-titel. für die referenzierung auch nicht. ´´´pluginname:variable titel // kommmentar finde ich schon sehr transparent und es sieht im schriftbild auch total klar aus. beschränkt aber auf eine variable oder du musst mit , ; oder : arbeiten was die übersicht irgendwann ad absurdum führt. da ich nicht sehe, wofür der titel wirklich gebraucht wird sehe ich den als optionale variable an. und wenn du eh schon so arbeiten willst dann nimm doch lieber den guten alten standard: pluginname:variablenname=variablencontent;variable2=variablencontent usw. und übersichtlicher wäre es dann sogar pluginname variable1=soundso; title="ach du jeh"; tippen. aber du siehst schon hoffentlich, dass das overkill ist für die meisten sachen. für ´´´code ist der fallback (fehlen der angegebenen variable): auto-erkennung ´´´code:python heißt, der code-highlighter behandelt alles als python github-standard ist: ´´´python für python und ohne alles autoerkennung. bei uns hab ich die variable noch nicht eingeführt, würd sie aber einfügen können und dabei würde ich ´´´ćode python und ´´´python gleich behandeln. von mir aus auch ´´´code:python. ´´´table braucht keine variable, also auch kein fallback nötig. vielleicht fallen uns später aber sachen ein, wie wir verschiedene table-layouts anbieten wollen. die syntax gibt das jetzt her. die syntax tut es beim bisherigen auch hergeben und ich sehe immer noch keine verbesserung für den user darin, dass er dafür eine syntax lernen muss. latex braucht auch (noch) keine variablen, hidden auch nicht, könnte sie aber noch bekommen, section hat left, right oder middle. ´´´chart hat als fallback die bar-chart muss ich dann ändern, weil momentan ist es line-chart. aber das ist trivial. aber chart ist ein beispiel, wo evtl. noch mehr sachen eingefügt werden könnten wenn wir das ermöglichen wollen. da wäre viel möglich über die header zu steuern. jochmann commented 5 years ago hier hat github lauter code verschluckt, das musst du mir bitte noch mal ausformulieren. besser noch, wir telefonieren nächste woche zu den grundsatzfragen mit screensharing gaenseklein commented 5 years ago hab das überarbeitet. ich verwende übrigens ständig ´ anstelle von ` hier bei github um mir das auskommentieren zu sparen - es ist hoffentlich klar, was damit gemeint ist. jochmann commented 5 years ago wahrscheinlich ist es am einfachsten für die interne HTML-Logik (und das darauf setzende CSS!), wenn als parent element für die Sektionen immer(!) eine steht und NUR bei den durch daten besonders ausgezeichneten dann die jeweiligen tochter-elemente (code, table, etc). sofern nichts dagegen spricht, lass uns lieber alles per abgrenzen und tochterelemente nach Bedarf zufügen. glaub ich nicht. dem html ists eigentlich egal, dem css auch. mein programm dagegen findets natürlich schick, alle datenobjekte als <section> (bzw. momentan noch <data>) zu haben. hast recht, einfacher ist es nicht. als parent finde ich passender als deswegen ist auch die logik konsistent, dass ``alleine für ` steht. ne, denn ne section wie wir sie dachten ist was anderes und wird anders interpretiert als bspw. ne tabelle. wenn immer sections steht, dann braucht das, was wir als <section> hatten n eigenen identifier. bspw. n internes <layout> oder<section class="layout">. hast recht, wir müssen sections klassifizieren nach deren inhalt. vorschlag: alles mit data-type (kannst du auch wie Klassen im CSS ansteuern) ... ... etc https://www.w3schools.com/tags/att_global_data.asp ´´code steht für <section><header></header><code id="N+1"> stimmt nicht. code steht für <code id="n+1"> - zumindest momentan. und das macht auch sinn, es sei denn ich behandel das eben auch als datenobject. (dann muss ich das programm an der stelle umschreiben). header macht gar keinen sinn, weil es in der präsentation gar keine header gibt für code. es sei denn du fügst das neu ein. hast recht, header einfügen macht keinen Sinn. Wir regeln die Klassifizierung über data-* attributes einheitlich sollte aber jeder dieser Einschübe (egal ob code oder layout) als im HTML definiert sein. Hier weichen wir aus gutem Grund von GitHub ab. Das am häufigsten benötigte (Layout) sollte am leichtesten zu tippen sein. und welches ist das am häufigsten benötigte? Layout? echt? dachte, das ist eher was für die, die gerne mehr kontrolle und so haben wollen. also für die advanced user. für ne simple slidenote solltest du das nie brauchen. denke tatsächlich, chart wird das meistgenutzte werden und dann teilts sich auf in programmierer, admins und co(code), mathematiker(latex), studis, werber und ähnliche (hidden). Und es sieht im Schriftbild klarer aus. das ist dem user momentan selbst überlassen: auch ´´´code wird ja als code interpretiert. ich denke, dass in den mentalen Modellen der user jede Sektion als Layoutbestandteil interpretiert wird, es aber Sonderfälle dafür gibt. Dann ist code ein Sonderfall von Layout und ´´´ wird, weil unmodifiziert, als Standardfall wahrgenommen ´´´(optional-pluginname) sollte als default immer eine variable für den titel mitführen. Die brauchen wir, um später im Outline (der Inhalts-Übersicht) einzelne Sektionen auch wiederzuerkennen. Wenn da nur "code #5" steht und du es nicht benennen kannst, ist ja völlig intransparent, was der Inhalt ist. eine Sektion mit Plugin (jede Tabelle, Grafik, Codebeispiel, eigentlich auch Zitate) sollte referenzierbar sein. Deswegen würde ich denen eine "unnamed code sample no3" Benennung automatisch verpassen und den usern die Option geben, Titel zu vergeben. wohlgemerkt, nur bei "semantischen" sections. nicht für layout. die user müssen sich unbedingt dafür eine syntax merken, die sollte nur transparent und logisch sein, und immer mit defaults arbeiten, die der user dann mit der richtigen syntax überschreiben kann. so lernst du die syntax nach und nach, weil das programm dich wie ein tutorial mit den fallbacks und context-hilfe immer begleitet. für eine indexierung würde ich eher nach titeln suchen und diese verwenden. dafür braucht es keine extra-titel. für die referenzierung auch nicht. dann zwingst du die Leute aber, sichtbaren Text in der Präsentation zu verwenden, wo sie eigentlich nur im Outliner die Referenz für sich nachhalten wollen. ´´´pluginname:variable titel // kommmentar finde ich schon sehr transparent und es sieht im schriftbild auch total klar aus. beschränkt aber auf eine variable oder du musst mit , ; oder : arbeiten was die übersicht irgendwann ad absurdum führt. da ich nicht sehe, wofür der titel wirklich gebraucht wird sehe ich den als optionale variable an. und wenn du eh schon so arbeiten willst dann nimm doch lieber den guten alten standard: pluginname:variablenname=variablencontent;variable2=variablencontent usw. und übersichtlicher wäre es dann sogar pluginname variable1=soundso; title="ach du jeh"; tippen. aber du siehst schon hoffentlich, dass das overkill ist für die meisten sachen. ich wüsste keinen Fall, wo wir eine Verschachtelung von plugin-Variablen zulassen wollen. Mit plugin-Variablen soll nur zwischen den Optionen ausgewählt werden, die ein Plugin anbietet. das ist eine "oder" auswahl, keine "und" auswahl. also reicht plugin:variable aus. nenn sie vielleicht plugin:option1 wenn das Wort "Variable" hier zu Missverständnissen führt. habe ich einen use case übersehen? für ´´´code ist der fallback (fehlen der angegebenen variable): auto-erkennung ´´´code:python heißt, der code-highlighter behandelt alles als python github-standard ist: ´´´python für python und ohne alles autoerkennung. bei uns hab ich die variable noch nicht eingeführt, würd sie aber einfügen können und dabei würde ich ´´´ćode python und ´´´python gleich behandeln. von mir aus auch ´´´code:python. richtig. ohne alles=autoerkennung. :python ist die manuelle Auswahl aus den Optionen. ´´´table braucht keine variable, also auch kein fallback nötig. vielleicht fallen uns später aber sachen ein, wie wir verschiedene table-layouts anbieten wollen. die syntax gibt das jetzt her. die syntax tut es beim bisherigen auch hergeben und ich sehe immer noch keine verbesserung für den user darin, dass er dafür eine syntax lernen muss. latex braucht auch (noch) keine variablen, hidden auch nicht, könnte sie aber noch bekommen, section hat left, right oder middle. ´´´chart hat als fallback die bar-chart muss ich dann ändern, weil momentan ist es line-chart. aber das ist trivial. aber chart ist ein beispiel, wo evtl. noch mehr sachen eingefügt werden könnten wenn wir das ermöglichen wollen. da wäre viel möglich über die header zu steuern. den fallback für chart können wir auch bei line-chart belassen. grundsätzlich finde ich die Logik gut, dass plugins nur mit oder-Auswahl (wie radio button) von Optionen kommen und wenn es nicht ausgewählte Optionen gibt, wir per default eine vorgeben. der vorteil, die syntax so zu modellieren, liegt in der internen konsistenz. und darin, dass du nicht alle teile der syntax lernen musst (z.B. kannst du auch auf Referenz oder Kommentierungen deiner Plugins verzichten) sondern nur die, mit denen du auch arbeitest. und der erste lern-schritt ist: oh, wenn ich ´´´schreibe kann ich sektionen für meine Folien einsetzen oh, wenn ich ´´´um den Namen eines Plugins ergänze, kann ich besondere Sektionen einfügen, die meinen dort enthaltenen Text automatisch umwandeln oh, wenn ich den Namen eines Plugins um :Option1 ergänze, kann ich bestimmen, wie mein Text umgewandelt werden soll und so weiter gaenseklein commented 5 years ago bitte anstelle von ` immer ´ hier im github verwenden (oder '). das erleichtert das einfügen als zitat ;) <section> anstelle von <data> ist noch nicht umgesetzt, aber mach ich noch. da herrscht kein diskussionsbedarf. wir müssen sections klassifizieren nach deren inhalt. vorschlag: alles mit data-type (kannst du auch wie Klassen im CSS ansteuern) klingt ok, ob klasse oder data-type ist mir egal - ich brauch nur was, um die voneinander zu unterscheiden. ich kann auch irgendwas selbstdefiniertes nehmen glaub ich, da die unterscheidung nur innerhalb des javascripts bei der weiteren verwendung wichtig ist - oder hab ich da was übersehen? ich denke, dass in den mentalen Modellen der user jede Sektion als Layoutbestandteil interpretiert wird, es aber Sonderfälle dafür gibt. Dann ist code ein Sonderfall von Layout und ´´´ wird, weil unmodifiziert, als Standardfall wahrgenommen ok. ich würde zwar den layout als sonderfall deklarieren und default ist code, aber egal. mir gings nur darum, nicht ohne grund von der github-syntax abzuweichen. aber ist im endeffekt auch trivial. dann zwingst du die Leute aber, sichtbaren Text in der Präsentation zu verwenden, wo sie eigentlich nur im Outliner die Referenz für sich nachhalten wollen. ok, also die referenz ist nur für den outliner und nicht für die präsentation. würde das thema referenzierung gerne erst abgeklärt haben bevor ich da weiter dran arbeite. ich hab mich schon gefragt, was in einer präsentation bspw. bei einem klick auf [mein link zum code1](code1) (oder wie auch immer du das nachher schreiben willst) überhaupt passieren soll. in der präsentation macht das kaum sinn, da es ja nicht eine seite ist, wo dann zu code1 gescrollt werden kann sondern wenn dann wird die seite/slide mit code1 aufgerufen. im outliner ist das was anderes, aber da macht ein von usern gesetzter link keinen sinn - oder doch??? ich wüsste keinen Fall, wo wir eine Verschachtelung von plugin-Variablen zulassen wollen. Mit plugin-Variablen soll nur zwischen den Optionen ausgewählt werden, die ein Plugin anbietet. das ist eine "oder" auswahl, keine "und" auswahl. also reicht plugin:variable aus. nenn sie vielleicht ´´´plugin:option1 wenn das Wort "Variable" hier zu Missverständnissen führt. habe ich einen use case übersehen? ich will halt zukunftssicherheit haben (erweiterbarkeit) und da stört mich das extrem. momentan hab ich glaube ich nicht mehr als eine variable pro plugin, aber das kann sich ja ändern. beispielsweise hast du mit deinen frei wählbaren referenzen bereits eine zweite variable eingeführt. da diese nicht wirklich eine variable des plugins ist sondern allgemein der section könnte natürlich auch eine andere syntax dafür eingeführt werden - bspw. {eindeutiger-referenz-name} oder ähnliches in der zeile. bei dem chart-plugin überlege ich bspw. ob ich da noch ne zweite variable einführe, die die art der datensyntax vorgibt. datensyntax (aus csv's) sind ja leider nicht einheitlich sondern können verschieden sein. in deiner gif hattest du bspw. eine vertikale ausrichtung: achsenlabel1, achsenlabel2 januar,10 februar,20 märz,30 denkbar ist aber auch horizontal: achsenlabel1, achsenlabel2 januar,februar,märz 10,20,30 obige beispiele sind relativ einfach automatisch zu erkennen (mehr als zwei linien = vertikal, zwei linien = horizontal) bei mehr als einem datensatz (bspw. vergleich statistik von 2010 und 2011 oder echte daten, gemittelter wert) wirds da schon komplizierter, daher hatte ich mir extra eine syntax ausgedacht mit ##achsenlabel und ###datensatzlabel. und wenn der user jetzt im head angeben kann, dass er eine datensyntax nimmt macht es das für das programm einfacher (es weiß, welche datensyntax kommt und muss nicht raten) und für den user weniger frustrierend. da hättest du bereits dann eine zweite variable, da die erste ja bereits sagt, ob es eine line, eine bar oder pie chart ist. (gibt noch mehr chart-arten aber die drei hab ich als wichtigste erstmal genommen) ich will jetzt hier nicht die chart diskuttieren (dafür anderes issue benutzen bitte wegen übersichtlichkeit) sondern das nur als beispiel aufzeigen, dass eben doch etwas kommen könnte, was wir bisher nicht bedacht haben. ich finde da eine non-syntax-schreibweise userfreundlicher. also bspw.: ´´´chart line vertical anstelle ´´´chart:line&data:vertical oder sogar ´´´chart:type=line&datastructure=vertical&ref="temperature-changes from 1940-2018"&datasetlabel1="realdata"&datasetlabel2="..." für mich als informatiker ist natürlich die letzte schreibweise die logischste, für user aber eher nicht oder? aber wie gesagt, nicht die chart jetzt hier diskutieren sondern nur sehen, dass eben doch da mehr drinne steckt, als wir auf den ersten blick sehen können. richtig. ohne alles=autoerkennung. :python ist die manuelle Auswahl aus den Optionen. ja, das schon. aber muss der doppelpunkt sein? wäre es für den user nicht schöner, wenn ´´´code python und ´´´code:python und ´´´python gleichwertig sind? der vorteil, die syntax so zu modellieren, liegt in der internen konsistenz. und darin, dass du nicht alle teile der syntax lernen musst (z.B. kannst du auch auf Referenz oder Kommentierungen deiner Plugins verzichten) sondern nur die, mit denen du auch arbeitest. und der erste lern-schritt ist: oh, wenn ich ´´´schreibe kann ich sektionen für meine Folien einsetzen oh, wenn ich ´´´um den Namen eines Plugins ergänze, kann ich besondere Sektionen einfügen, die meinen dort enthaltenen Text automatisch umwandeln oh, wenn ich den Namen eines Plugins um :Option1 ergänze, kann ich bestimmen, wie mein Text umgewandelt werden soll und so weiter ja ich sehe was du meinst. wenn ich eine eigene syntax von neu schreiben würde würd ichs auch so machen. aber wir verwenden ja markdown und wollten uns so eng an den standard halten wie möglich. wenn du meinst, dass es das hier wert ist die github-syntax zu verlassen mach ich das. ich sehe das zwar anders, aber will mich nicht daran aufhängen. ist halt die frage, ob wir mehr user haben, die markdown noch garnicht kennen (und die sich über diese variante quasi freuen) oder mehr user, die sich ärgern, dass sie ihren md-code noch nachträglich ändern müssen nachdem sie ihn per copy-paste in die slidenote eingefügt haben. die neue syntax ist halt nicht kompatibel zu github und muss bei jedem copy-paste zwischen github und slidenote angepasst werden (in beide richtungen). das wollte ich vermeiden, damit die user ihre geschriebenen sachen direkt bei beidem verwenden können. jochmann commented 5 years ago bitte anstelle von ` immer ´ hier im github verwenden (oder '). das erleichtert das einfügen als zitat ;) <section> anstelle von <data> ist noch nicht umgesetzt, aber mach ich noch. da herrscht kein diskussionsbedarf. wir müssen sections klassifizieren nach deren inhalt. vorschlag: alles mit data-type (kannst du auch wie Klassen im CSS ansteuern) klingt ok, ob klasse oder data-type ist mir egal - ich brauch nur was, um die voneinander zu unterscheiden. ich kann auch irgendwas selbstdefiniertes nehmen glaub ich, da die unterscheidung nur innerhalb des javascripts bei der weiteren verwendung wichtig ist - oder hab ich da was übersehen? du kannst den Inhalt von data-type auch im CSS abgreifen und ausgelesen anzeigen. das ist der Vorteil gegenüber Klassen. Ist außerdem "semantischer". Würde erst mal damit arbeiten. ich denke, dass in den mentalen Modellen der user jede Sektion als Layoutbestandteil interpretiert wird, es aber Sonderfälle dafür gibt. Dann ist code ein Sonderfall von Layout und ´´´ wird, weil unmodifiziert, als Standardfall wahrgenommen ok. ich würde zwar den layout als sonderfall deklarieren und default ist code, aber egal. mir gings nur darum, nicht ohne grund von der github-syntax abzuweichen. aber ist im endeffekt auch trivial. dann zwingst du die Leute aber, sichtbaren Text in der Präsentation zu verwenden, wo sie eigentlich nur im Outliner die Referenz für sich nachhalten wollen. ok, also die referenz ist nur für den outliner und nicht für die präsentation. würde das thema referenzierung gerne erst abgeklärt haben bevor ich da weiter dran arbeite. ich hab mich schon gefragt, was in einer präsentation bspw. bei einem klick auf [mein link zum code1](code1) (oder wie auch immer du das nachher schreiben willst) überhaupt passieren soll. in der präsentation macht das kaum sinn, da es ja nicht eine seite ist, wo dann zu code1 gescrollt werden kann sondern wenn dann wird die seite/slide mit code1 aufgerufen. im outliner ist das was anderes, aber da macht ein von usern gesetzter link keinen sinn - oder doch??? der Outliner ist eine Funktionalität, die wir gerne komplett auf einen späteren release verschieben können. Es soll Nutzern die Möglichkeit geben, sich anhand von Titeln und Refernz-Beschreibungen in einem langen Dokument zurecht zu finden. Wie ein automatisch erstelltes Inhaltsverzeichnis: Die Links im Outliner/Inhaltsverzeichnis sollen auf Klick dann den Curser im Textfeld an die dortige Position versetzen. Im besten Fall bekommen wir das irgendwie auch in die Präsentation übertragen, wo die Funktionalität von internen Links dann allerdings eher die eines Hypertext-Wikis ist. Bei Klick auf einen Internen Link sollte die Präsentation dann auf die Folie springen, wo der zugehörige Anker sich befindet. Deswegen müssen wir für Tabellen, Codebeispielen und Zitaten etc mit automatisch vergebenen IDs arbeiten, dass es immer nur einen Anker gibt - aber beliebig viele Links, die darauf verweisen. ich wüsste keinen Fall, wo wir eine Verschachtelung von plugin-Variablen zulassen wollen. Mit plugin-Variablen soll nur zwischen den Optionen ausgewählt werden, die ein Plugin anbietet. das ist eine "oder" auswahl, keine "und" auswahl. also reicht plugin:variable aus. nenn sie vielleicht ´´´plugin:option1 wenn das Wort "Variable" hier zu Missverständnissen führt. habe ich einen use case übersehen? ich will halt zukunftssicherheit haben (erweiterbarkeit) und da stört mich das extrem. momentan hab ich glaube ich nicht mehr als eine variable pro plugin, aber das kann sich ja ändern. beispielsweise hast du mit deinen frei wählbaren referenzen bereits eine zweite variable eingeführt. da diese nicht wirklich eine variable des plugins ist sondern allgemein der section könnte natürlich auch eine andere syntax dafür eingeführt werden - bspw. {eindeutiger-referenz-name} oder ähnliches in der zeile. ich würde dafür plädieren, schlichtheit in der syntax von vornherein festzulegen. Falls du weitere Variablen haben willst, kannst du ja immer noch mit plugin:foo:bar:what die syntax erweitern. ich würde so weit es geht aber auf einen doppelpunkt beschränken wollen. richtig, die frei wählbare referenz ist keine variable des plugins sondern bezieht sich auf das Elternelement deswegen steht sie ja auch frei, ohne koppelung hinter der spezifizierung des plugins für die section. liest sich zumindest gut - wir sollten aber bei so grundsätzlichen fragen vielleicht ein paar user tests mit prototyping (papierschnipsel oder powerpoint) durchführen, falls es später nicht mehr einfach zu ändern ist. bei dem chart-plugin überlege ich bspw. ob ich da noch ne zweite variable einführe, die die art der datensyntax vorgibt. datensyntax (aus csv's) sind ja leider nicht einheitlich sondern können verschieden sein. in deiner gif hattest du bspw. eine vertikale ausrichtung: achsenlabel1, achsenlabel2 januar,10 februar,20 märz,30 ich hatte mich kurz in standards zum import von CSV eingelesen und da waren die beispiele alle vertikal. vor allem aber sind die achsenlabel teil des csv, meine ich. aus der erinnerung: ich konnte anhand von deiner syntax im context-helper keine richtigen Kuchen-Diagramme erstellen. Als ich mein vertikales Beispiel nahm, klappte es. denkbar ist aber auch horizontal: achsenlabel1, achsenlabel2 januar,februar,märz 10,20,30 obige beispiele sind relativ einfach automatisch zu erkennen (mehr als zwei linien = vertikal, zwei linien = horizontal) bei mehr als einem datensatz (bspw. vergleich statistik von 2010 und 2011 oder echte daten, gemittelter wert) wirds da schon komplizierter, daher hatte ich mir extra eine syntax ausgedacht mit ##achsenlabel und ###datensatzlabel. und wenn der user jetzt im head angeben kann, dass er eine datensyntax nimmt macht es das für das programm einfacher (es weiß, welche datensyntax kommt und muss nicht raten) und für den user weniger frustrierend. da hättest du bereits dann eine zweite variable, da die erste ja bereits sagt, ob es eine line, eine bar oder pie chart ist. (gibt noch mehr chart-arten aber die drei hab ich als wichtigste erstmal genommen) ich will jetzt hier nicht die chart diskuttieren (dafür anderes issue benutzen bitte wegen übersichtlichkeit) sondern das nur als beispiel aufzeigen, dass eben doch etwas kommen könnte, was wir bisher nicht bedacht haben. ich finde da eine non-syntax-schreibweise userfreundlicher. also bspw.: ´´´chart line vertical anstelle ´´´chart:line&data:vertical oder sogar ´´´chart:type=line&datastructure=vertical&ref="temperature-changes from 1940-2018"&datasetlabel1="realdata"&datasetlabel2="..." für mich als informatiker ist natürlich die letzte schreibweise die logischste, für user aber eher nicht oder? auf jeden fall die zweite Schreibweise. Wer so irre Datenmanipulation betreibt, kann sich auch in minimalistische Syntax einlesen. Ist außerdem Konform mit URL-Daten-Syntax. Die dritte finde ich auch gut lesbar und logisch, aber da musst du dir mehr Klassennamen merken, um sie schreiben zu können. aber wie gesagt, nicht die chart jetzt hier diskutieren sondern nur sehen, dass eben doch da mehr drinne steckt, als wir auf den ersten blick sehen können. richtig. ohne alles=autoerkennung. :python ist die manuelle Auswahl aus den Optionen. ja, das schon. aber muss der doppelpunkt sein? wäre es für den user nicht schöner, wenn ´´´code python und ´´´code:python und ´´´python gleichwertig sind? nee, dann erziehst du den user ja nie zur "richtigen" syntax. Optionen anbieten ist immer Fehler-Vektor für Verwirrung. So lange die Syntax selbst-sprechend und konsistent ist, bevorzuge ich ganz klar Einheitlichkeit. Ich würde sogar den Markdown-Standard ohne _ und weitere Optionen bevorzugen, aber da kämpfen wir gegen Windmühlen. Bei den Datenstrukturen (CSV z.B.) können wir dafür nachgiebiger sein. Da versuchen wir den Parser möglichst schlau zu machen, dass er Exporte aus diversen Programmen hilfreich interpretiert, auch wenn die nicht immer der reinen Lehre entsprechen. der vorteil, die syntax so zu modellieren, liegt in der internen konsistenz. und darin, dass du nicht alle teile der syntax lernen musst (z.B. kannst du auch auf Referenz oder Kommentierungen deiner Plugins verzichten) sondern nur die, mit denen du auch arbeitest. und der erste lern-schritt ist: oh, wenn ich ´´´schreibe kann ich sektionen für meine Folien einsetzen oh, wenn ich ´´´um den Namen eines Plugins ergänze, kann ich besondere Sektionen einfügen, die meinen dort enthaltenen Text automatisch umwandeln oh, wenn ich den Namen eines Plugins um :Option1 ergänze, kann ich bestimmen, wie mein Text umgewandelt werden soll und so weiter ja ich sehe was du meinst. wenn ich eine eigene syntax von neu schreiben würde würd ichs auch so machen. aber wir verwenden ja markdown und wollten uns so eng an den standard halten wie möglich. wenn du meinst, dass es das hier wert ist die github-syntax zu verlassen mach ich das. ich sehe das zwar anders, aber will mich nicht daran aufhängen. ist halt die frage, ob wir mehr user haben, die markdown noch garnicht kennen (und die sich über diese variante quasi freuen) oder mehr user, die sich ärgern, dass sie ihren md-code noch nachträglich ändern müssen nachdem sie ihn per copy-paste in die slidenote eingefügt haben. die neue syntax ist halt nicht kompatibel zu github und muss bei jedem copy-paste zwischen github und slidenote angepasst werden (in beide richtungen). das wollte ich vermeiden, damit die user ihre geschriebenen sachen direkt bei beidem verwenden können. OK der usecase copy-paste ist ein Argument, was mich wirklich zum Grübeln bringt. Abwägung ist tatsächlich die zwischen Verschiedenen Nutzergruppen und wie man denen entgegen kommt. Können wir das nicht beim Import lösen (gerne in späterem Release) dass der Parser so schlau ist zu fragen, ob du github-markdown verwendest und dann die Syntax für dich automatisch anpasst? gaenseklein commented 5 years ago OK der usecase copy-paste ist ein Argument, was mich wirklich zum Grübeln bringt. Abwägung ist tatsächlich die zwischen Verschiedenen Nutzergruppen und wie man denen entgegen kommt. Können wir das nicht beim Import lösen (gerne in späterem Release) dass der Parser so schlau ist zu fragen, ob du github-markdown verwendest und dann die Syntax für dich automatisch anpasst? import meinst du copy-paste? oder import als md-datei? ich würd das nicht machen wollen, weil du dann genauso umgekehrt vorgehen müsstest beim abspeichern als .md-datei um github-kompatibel zu sein und per copy-paste ist es garnicht möglich umgekehrt - technisch nicht, aber auch nicht inhaltlich, weil du ja schwer erkennen kannst ob der text nach dem kopieren aus der slidenote in github eingefügt werden soll. per copy-paste einfügen ists ebenfalls schwierig zu erkennen. hat der user jetzt nen codeblock von github kopiert und in die slidenote eingefügt oder ein layout-block aus ner anderen oder sogar der gleichen slidenote? ist nicht zu unterscheiden fürs programm und daher würdest du raten müssen. das hat die gefahr des "was-zum-teufel-machst-du-da?" fehler, welche autokorrekturen (nichts anderes wäre das ja) leider mit sich bringen. daher lieber schlicht halten ohne autokorrektur und an der github-syntax bleiben. dann kannst du den usern sagen "we use the md-syntax from github with slidenote enhancements". wir weichen momentan nur in den tables ab, wobei wir selbst da relativ kompatibel sind - die tabelle muss für slidenote nur in ´´´table tag gepackt werden. (und tabellen sind eh fürn arsch und absolut neunziger) durch die wahl von ´´´datatag anstelle von ||datatag|| sind wir sogar kompatibel im kopieren zu github - es wird halt als code in github dargestellt und nicht interpretiert. das ist imho das beste, was wir da rausschlagen können und eine gute wahl und hatte ich vorher garnicht bedacht. user, die sich noch nicht in der syntax auskennen werden ja durch das insert-menü etc. an unsere syntax herangeführt und haben es daher ebenfalls einfach. daher glaube ich nicht, dass wir es denen "einfacher" machen müssen. daher denke ich nach wie vor: lieber ´´´ als code interpretieren als default und an github bleiben. in der user-erziehung (also wie die buttons gemacht werden) können wir ja den default-case weglassen. data-tags sind jetzt durch section-tags ausgetauscht, section heißt jetzt layout. sollte jetzt wieder funktionioeren. wenn ich das richtig sehe, ist in diesem issue nur noch offen, ob ´´´ alleinstehend, also als default, als code oder als layout-tag interpretiert werden soll, sowie wie die header-struktur aussehen soll bei mehreren variablen. jochmann commented 5 years ago gute Überlegungen. Ich würde als feature-request für die road map vielleicht festhalten, dass wir eventuell ein "experten-Menü" vorhalten, in dem wir auch die Option anbieten "convert all / selected text into github-flavored markdown" im experten-Menü könnten wir dann auch unsere Defaults zum ändern frei geben. Also auch die Vorgabe, dass ´`´als code zum Default wird. Unser standard sollte aber sein, dass layout-block (quasi unsemantische section) der default ist. wenn du semantische sections haben willst, zeichnest du sie aus. Am 19.12.2018 um 17:33 schrieb gaenseklein notifications@github.com: OK der usecase copy-paste ist ein Argument, was mich wirklich zum Grübeln bringt. Abwägung ist tatsächlich die zwischen Verschiedenen Nutzergruppen und wie man denen entgegen kommt. Können wir das nicht beim Import lösen (gerne in späterem Release) dass der Parser so schlau ist zu fragen, ob du github-markdown verwendest und dann die Syntax für dich automatisch anpasst? import meinst du copy-paste? oder import als md-datei? ich würd das nicht machen wollen, weil du dann genauso umgekehrt vorgehen müsstest beim abspeichern als .md-datei um github-kompatibel zu sein und per copy-paste ist es garnicht möglich umgekehrt - technisch nicht, aber auch nicht inhaltlich, weil du ja schwer erkennen kannst ob der text nach dem kopieren aus der slidenote in github eingefügt werden soll. per copy-paste einfügen ists ebenfalls schwierig zu erkennen. hat der user jetzt nen codeblock von github kopiert und in die slidenote eingefügt oder ein layout-block aus ner anderen oder sogar der gleichen slidenote? ist nicht zu unterscheiden fürs programm und daher würdest du raten müssen. das hat die gefahr des "was-zum-teufel-machst-du-da?" fehler, welche autokorrekturen (nichts anderes wäre das ja) leider mit sich bringen. daher lieber schlicht halten ohne autokorrektur und an der github-syntax bleiben. dann kannst du den usern sagen "we use the md-syntax from github with slidenote enhancements". wir weichen momentan nur in den tables ab, wobei wir selbst da relativ kompatibel sind - die tabelle muss für slidenote nur in ´´´table tag gepackt werden. (und tabellen sind eh fürn arsch und absolut neunziger) durch die wahl von ´´´datatag anstelle von ||datatag|| sind wir sogar kompatibel im kopieren zu github - es wird halt als code in github dargestellt und nicht interpretiert. das ist imho das beste, was wir da rausschlagen können und eine gute wahl und hatte ich vorher garnicht bedacht. user, die sich noch nicht in der syntax auskennen werden ja durch das insert-menü etc. an unsere syntax herangeführt und haben es daher ebenfalls einfach. daher glaube ich nicht, dass wir es denen "einfacher" machen müssen. daher denke ich nach wie vor: lieber ´´´ als code interpretieren als default und an github bleiben. in der user-erziehung (also wie die buttons gemacht werden) können wir ja den default-case weglassen. data-tags sind jetzt durch section-tags ausgetauscht, section heißt jetzt layout. sollte jetzt wieder funktionioeren. wenn ich das richtig sehe, ist in diesem issue nur noch offen, ob ´´´ alleinstehend, also als default, als code oder als layout-tag interpretiert werden soll, sowie wie die header-struktur aussehen soll bei mehreren variablen. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gaenseklein/slidenotes/issues/55#issuecomment-448659268, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6hBGIGEn4637EQ_MRJ_4JEDFKtpN6yks5u6mpNgaJpZM4Y8kFO. gaenseklein commented 5 years ago habs jetzt so implementiert, dass der default eine section ist (bzw. inzwischen ja in layout umbenannt). Das ganze kann im Menü umgestellt werden um wieder github konform zu werden. Github-User werden sich das dann einfach so einmal einstellen (option wird ja gespeichert), allen anderen ists ja eh egal und nutzen ´´´ synonym für ´´´layout. Ein "convert all / selected text into github-flavored markdown" soll dann in zukunft aus ´´´code einfach ´´´ machen? und die tabellen ebenfalls umformen/neu schreiben? in die roadmap kann das rein, aber wäre bei mir prioritätenmäßig ganz unten aufgrund der beschriebenen problematik. es ist nicht wirklich zielführend für den user. wenn der user aber githubuser ist und deswegen möglichst github kompatibel sein will wäre es einfacher für ihn einmal in den optionen umzustellen auf github-code. jochmann commented 5 years ago stark. rest heben wir uns für später auf, wie du schriebst. ich vermute, dass es außer bei den tabellen noch andere abweichungen geben könnte, aber da können wir uns gedanken machen, wenn die wichtigen dinge erledigt sind Am 11.02.2019 um 05:52 schrieb gaenseklein notifications@github.com: habs jetzt so implementiert, dass der default eine section ist (bzw. inzwischen ja in layout umbenannt). Das ganze kann im Menü umgestellt werden um wieder github konform zu werden. Github-User werden sich das dann einfach so einmal einstellen (option wird ja gespeichert), allen anderen ists ja eh egal und nutzen ´´´ synonym für ´´´layout. Ein "convert all / selected text into github-flavored markdown" soll dann in zukunft aus ´´´code einfach ´´´ machen? und die tabellen ebenfalls umformen/neu schreiben? in die roadmap kann das rein, aber wäre bei mir prioritätenmäßig ganz unten aufgrund der beschriebenen problematik. es ist nicht wirklich zielführend für den user. wenn der user aber githubuser ist und deswegen möglichst github kompatibel sein will wäre es einfacher für ihn einmal in den optionen umzustellen auf github-code. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gaenseklein/slidenotes/issues/55#issuecomment-462219371, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6hBCNoIKhfmhkwxZ_a6z_4X2oidvYiks5vMPb5gaJpZM4Y8kFO. gaenseklein commented 5 years ago der übersicht halber schließe ich dann dieses issue - oder habe ich was übersehen, was noch getan werden muss? jochmann commented 5 years ago close Am 12.02.2019 um 01:23 schrieb gaenseklein notifications@github.com: der übersicht halber schließe ich dann dieses issue - oder habe ich was übersehen, was noch getan werden muss? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gaenseklein/slidenotes/issues/55#issuecomment-462552719, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6hBBRfaiAlnPhQoxqrF8nkWBSgBvrMks5vMgmcgaJpZM4Y8kFO. © Githubissues. Githubissues is a development platform for aggregating issues.

gaenseklein / slidenotes

Änderung von datensyntax #55