feature request: code line numbering and highlighting

[jochmann]

siehe https://twitter.com/slides/status/1113415825766088705

[gaenseklein]

für code-blöcke? code-line-numbering sollte möglich sein, highlightning bestimmter zeilen braucht syntax-ergänzung für code-blöcke

[gaenseklein]

auch: soll das bis zum release stehen oder für später?

[jochmann]

Hier ist das eine Frage des Aufwandes, den ich nicht einschätzen kann. Ist kein absolutes Must-Have, aber wie die Reaktionen in dem Twitter-Thread ja ziemlich deutlich machen, ist das für unsere Kernzielgruppe zum Start (die Mac-lastigen Programmierer und Nerds) schon mega interessant.

Vielleicht nehmen wir erst mal nur das line-numbering und verschieben die syntax-Ergänzung auf später?

Ziel für einen Starttermin, wo das Produkt vorzeigbar sein soll, wäre August. In die Road Map passt nur, was immer du und Marie bis dahin schaffen.

On 16. May 2019, at 17:37, gaenseklein notifications@github.com wrote:

für code-blöcke? code-line-numbering sollte möglich sein, highlightning bestimmter zeilen braucht syntax-ergänzung für code-blöcke

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gaenseklein/slidenotes/issues/86?email_source=notifications&email_token=AAPKCBAAVKHNJWPXQ76W3SLPVV5SNA5CNFSM4HMBIVQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVSGOLI#issuecomment-493119277, or mute the thread https://github.com/notifications/unsubscribe-auth/AAPKCBHNTM76AK4P7HCQCN3PVV5SNANCNFSM4HMBIVQQ.

[gaenseklein]

Aufwand ist, sich ne ordentliche Syntax zu überlegen, der Rest ist relativ easy zu machen. Ich denke, wir sollten hier vielleicht zweigleisig fahren und evtl. überlegen, wie wir überhaupt mit Code umgehen wollen. Wir könnten bspw. sagen, der Code-Block wie er jetzt ist ist der Standard-Codeblock, aber wir können auch einen gestylten Code-Block einführen, quasi einen Advanced-Codeblock, der konfigurierbar ist ähnlich der Chart-Block-Syntax. Bspw.

´´´code:styled
language=javascript
startline=102
highlightstart=§€
highlightend=ۤ
highlightline=§§
---
function superduper(heititei){
    var superduper=1024;
§§ var result= domymagicfunction(superduper*heititei);    
    return result * §€(superduper/8)€§;
}
´´´

das ließe sich dann auch erweitern mit der anderen code-idee die du mal geschickt hattest, wo im code "gesprungen" bzw. gescrollt wird.

ich habe mal probeweise dem highlightning erstmal zeilennummerierung verpasst, sowie die ausgabe mit speciallines getestet. als specialline hab ich als syntax fest §§ am anfang der zeile gemacht, da ich keine programmiersprache kenne, die das als symbol benutzt. ich kann mich da aber auch irren. gleichzeitig muss das symbol ja auch international erreichbar sein auf der tastatur. auch da weiß ich nicht, ob das gegeben ist. und da sehe ich die hauptschwierigkeit, da was für die syntax zu finden. daher mein ansatz, dass die user das selbst entscheiden können. und über einen solchen gestylten codeblock können wir über die optionen auch möglichkeiten anbieten wie linenummern angeben, welche hervorgehoben werden sollen. bspw: highlightlines = 1,3,55,78 usw. insgesamt ist es übersichtlicher und erweiterbarer. alles in die headerline vom codeblock zu packen ist zwar theoretisch möglich. bspw: ´´´code:javascript:highlightlines=1,3,55,78:linestart=102 aber da werden wir schnell an grenzen des übersichtlich schreibbaren stoßen, daher denke ich eher ein gestylter codeblock wäre da doch sinnvoller.

[jochmann]

Hey,

wenn das einfach geht, die Syntax anzupassen würde ich vielleicht später das wortgenaue Highlighting als Markdown-Befehl aufnehmen, statt das in den meta-daten-header zu packen. Für jetzt würde ich Highlighting auf Zeilen beschränken.

vielleicht lieber nur das Argument:

line-numbering=on (default ist on, kann man also weglassen und eventuell in den globalen Einstellungen an- und ausschalten) line-highlight=34, 35, 38 (code-Zeilen werden manuell als array eingegeben)

Highlighting und Numerierung kann dann ganz trivial über CSS-counter angesteuert werden. Jede Zeile kommt in einen Wrapper, vor den wrapper kommt der CSS-Counter, ausgewählte Linien bekommen gesondertes CSS per äquivalentem counter zugewiesen.

Zum Verständnis: War "styled" das Argument, was die Farbauszeichnung für den Code auslöst? Startline heißt was?

Danke!

On 26. May 2019, at 05:46, gaenseklein notifications@github.com wrote:

Aufwand ist, sich ne ordentliche Syntax zu überlegen, der Rest ist relativ easy zu machen. Ich denke, wir sollten hier vielleicht zweigleisig fahren und evtl. überlegen, wie wir überhaupt mit Code umgehen wollen. Wir könnten bspw. sagen, der Code-Block wie er jetzt ist ist der Standard-Codeblock, aber wir können auch einen gestylten Code-Block einführen, quasi einen Advanced-Codeblock, der konfigurierbar ist ähnlich der Chart-Block-Syntax. Bspw.

´´´code:styled language=javascript startline=102 highlightstart=§€ highlightend=€§ highlightline=§§

function superduper(heititei){ var superduper=1024; §§ var result= domymagicfunction(superduperheititei);
return result §€(superduper/8)€§; } ´´´ das ließe sich dann auch erweitern mit der anderen code-idee die du mal geschickt hattest, wo im code "gesprungen" bzw. gescrollt wird.

ich habe mal probeweise dem highlightning erstmal zeilennummerierung verpasst, sowie die ausgabe mit speciallines getestet. als specialline hab ich als syntax fest §§ am anfang der zeile gemacht, da ich keine programmiersprache kenne, die das als symbol benutzt. ich kann mich da aber auch irren. gleichzeitig muss das symbol ja auch international erreichbar sein auf der tastatur. auch da weiß ich nicht, ob das gegeben ist. und da sehe ich die hauptschwierigkeit, da was für die syntax zu finden. daher mein ansatz, dass die user das selbst entscheiden können. und über einen solchen gestylten codeblock können wir über die optionen auch möglichkeiten anbieten wie linenummern angeben, welche hervorgehoben werden sollen. bspw: highlightlines = 1,3,55,78 usw. insgesamt ist es übersichtlicher und erweiterbarer. alles in die headerline vom codeblock zu packen ist zwar theoretisch möglich. bspw: ´´´code:javascript:highlightlines=1,3,55,78:linestart=102 aber da werden wir schnell an grenzen des übersichtlich schreibbaren stoßen, daher denke ich eher ein gestylter codeblock wäre da doch sinnvoller.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gaenseklein/slidenotes/issues/86?email_source=notifications&email_token=AAPKCBADZAE35JAD6WE6PRLPXIBXDA5CNFSM4HMBIVQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWH5PKA#issuecomment-495966120, or mute the thread https://github.com/notifications/unsubscribe-auth/AAPKCBHMASHWYUKXUQQ6WOTPXIBXDANCNFSM4HMBIVQQ.

[gaenseklein]

Zum Verständnis: War "styled" das Argument, was die Farbauszeichnung für den Code auslöst? Startline heißt was?

styled war das Argument, was auslöst, dass es einen header im codeblock gibt (mit dem ende-trenner ---) in welchem dann genauere sachen eingestellt werden können wie oben beschrieben. ansonsten ist der inhalt vom codeblock ja als "code" aufgefasst - sprich, er wird nicht interpretiert sondern so wie er ist noch mit syntax-highlightning versehen dargestellt. das wort kann auch gerne geändert werden, ist mir wumpe (z.b. options). ich finds nur schicker, als dafür einen extra block aufzumachen wie bspw. ´´´highlightedcode oder ähnliches.
startline ist die nummer der ersten line deines codes (das fehlt bei slides.com bspw.). also wenn ich aus meinem code eine bestimmte funktion heraushole, dann ist die ja nicht in zeile 1-ende, sondern bspw. von zeile 436 bis 488. der code ist jetzt in eine ordered list gepackt (oder eben nicht, wenn keine zeilennummerierung aktiviert werden soll) und die fängt dann bei startline an. default ist 1. da brauch ich mir kein eigenes css für zu überlegen, das bringt html schon mit ;)

wenn das einfach geht, die Syntax anzupassen würde ich vielleicht später das wortgenaue Highlighting als Markdown-Befehl aufnehmen, statt das in den meta-daten-header zu packen. Für jetzt würde ich Highlighting auf Zeilen beschränken.

das ist ja außerhalb unseres sonstigen markdowns, da es innerhalb des codeblocks ist (das wird von uns nicht geparsed). das heißt, da kannst du frei neu erfinden was das zeug hält. das problem ist halt, dafür symbole zu finden, die du mit jeder programmiersprache umsetzen kannst. und da wirds halt holprig, denn diese symbole sind dann meist nicht auf internationalen tastaturen erreichbar, sondern nur in speziellen. bspw. das €-symbol. wenn du grad nicht verstehst was ich meine, schau dir den wunsch und den "lösungsvorschlag" von dem user daher die idee, dass die user das "zur not" auch selbst ändern können. glaub mir, viele werden dafür dankbar sein und ich denke, dass wir damit auch zeigen, dass wir auf dev's gut ausgerichtet sind weil wir deren nöte kennen.
ansonsten ist das nicht schwer, einzelne zeilen highlighten hab ich bereits umgesetzt probehalber und funktioniert super mit §§ am anfang der zeile. einzelne wörter highlighten sollte genauso gehen.

line-numbering=on (default ist on, kann man also weglassen und eventuell in den globalen Einstellungen an- und ausschalten)

klar, kann default gemacht werden und klar, kann auch global eingestellt werden. aber wenn wir eh einen header reinpacken kann es auch pro codeblock eingestellt werden. auch hier gilt wie bei den charts: header-optionen sind immer optional.

line-highlight=34, 35, 38 (code-Zeilen werden manuell als array eingegeben)

ja, das hatte ich ja geschrieben, das ist eine form, wie definiert werden kann welche line genommen werden soll. ich würd die sogar erweitern auf: line-highlight = 34, 38-40, 44 das ist menschenfreundlicher zu schreiben und genauso parsebar. aber da du die zeilen im editor nicht siehst und sich die zeilen ja ändern können wenn du noch was einfügst o.ä. ist es einfacher, mit einem start-symbol am anfang der zeile als über eine solche zeile.

[jochmann]

On 27. May 2019, at 01:59, gaenseklein notifications@github.com wrote:

Zum Verständnis: War "styled" das Argument, was die Farbauszeichnung für den Code auslöst? Startline heißt was?

styled war das Argument, was auslöst, dass es einen header im codeblock gibt (mit dem ende-trenner ---) in welchem dann genauere sachen eingestellt werden können wie oben beschrieben. ansonsten ist der inhalt vom codeblock ja als "code" aufgefasst - sprich, er wird nicht interpretiert sondern so wie er ist noch mit syntax-highlightning versehen dargestellt. das wort kann auch gerne geändert werden, ist mir wumpe (z.b. options). ich finds nur schicker, als dafür einen extra block aufzumachen wie bspw. ´´´highlightedcode oder ähnliches.

verstehe. ich glaube, es wäre einfacher, wenn wir die "YAML-Header-Block"-Konvention aus einem anderen Markdown-Projekt übernehmen und den Block mit "---" als Optionalen Block abgrenzen. https://pandoc.org/MANUAL.html#extension-yaml_metadata_block https://pandoc.org/MANUAL.html#extension-yaml_metadata_block Also

---
counter-start=30
---
print: "hello world";
asdf...

startline ist die nummer der ersten line deines codes (das fehlt bei slides.com bspw.). also wenn ich aus meinem code eine bestimmte funktion heraushole, dann ist die ja nicht in zeile 1-ende, sondern bspw. von zeile 436 bis 488.

ah, OK - das setzt natürlich voraus, dass es relevant ist, auf echten Code zu referieren. Kann durchaus Sinn machen. Default ist also, dass bei 1 losgezählt wird und man kann es als Option manuell ändern. der code ist jetzt in eine ordered list gepackt (oder eben nicht, wenn keine zeilennummerierung aktiviert werden soll) und die fängt dann bei startline an. default ist 1. da brauch ich mir kein eigenes css für zu überlegen, das bringt html schon mit ;)

Hier würde ich dringend CSS nehmen, genau für diese Fälle ist es ja da? Eine ordered list ist doch ein semantisches Element, unser semantisches Element ist aber ein code-block. Im Endeffekt lasse ich mich durchaus überzeugen, sofern die Funktionalität identisch ist - was passiert z.B., wenn screen-reader den Code vorlesen, macht es einen Unterschied? wenn das einfach geht, die Syntax anzupassen würde ich vielleicht später das wortgenaue Highlighting als Markdown-Befehl aufnehmen, statt das in den meta-daten-header zu packen. Für jetzt würde ich Highlighting auf Zeilen beschränken.

das ist ja außerhalb unseres sonstigen markdowns, da es innerhalb des codeblocks ist (das wird von uns nicht geparsed). das heißt, da kannst du frei neu erfinden was das zeug hält.

hervorragend, siehe YAML-Standard oben. das problem ist halt, dafür symbole zu finden, die du mit jeder programmiersprache umsetzen kannst. und da wirds halt holprig, denn diese symbole sind dann meist nicht auf internationalen tastaturen erreichbar, sondern nur in speziellen. bspw. das €-symbol. wenn du grad nicht verstehst was ich meine, schau dir den wunsch und den "lösungsvorschlag" von dem user daher die idee, dass die user das "zur not" auch selbst ändern können. glaub mir, viele werden dafür dankbar sein und ich denke, dass wir damit auch zeigen, dass wir auf dev's gut ausgerichtet sind weil wir deren nöte kennen.

gute Sache, wenn wir dank Parser frei sind, würde ich im Code mit einer Kombination von Symbolen arbeiten. z.B. <## foo ##> (aber die können wir ja später noch ändern. Nimm, was dir am plausibelsten aus deiner Erfahrung mit Programmiersprachen erscheint) ansonsten ist das nicht schwer, einzelne zeilen highlighten hab ich bereits umgesetzt probehalber und funktioniert super mit §§ am anfang der zeile. einzelne wörter highlighten sollte genauso gehen.

line-numbering=on (default ist on, kann man also weglassen und eventuell in den globalen Einstellungen an- und ausschalten)

klar, kann default gemacht werden und klar, kann auch global eingestellt werden. aber wenn wir eh einen header reinpacken kann es auch pro codeblock eingestellt werden. auch hier gilt wie bei den charts: header-optionen sind immer optional.

line-highlight=34, 35, 38 (code-Zeilen werden manuell als array eingegeben)

ja, das hatte ich ja geschrieben, das ist eine form, wie definiert werden kann welche line genommen werden soll. ich würd die sogar erweitern auf: line-highlight = 34, 38-40, 44 das ist menschenfreundlicher zu schreiben und genauso parsebar. aber da du die zeilen im editor nicht siehst und sich die zeilen ja ändern können wenn du noch was einfügst o.ä. ist es einfacher, mit einem start-symbol am anfang der zeile als über eine solche zeile.

auf jeden Fall besser das im Code-Block zu machen, als im metadaten-Block. je mehr wir auf den verzichten können, weil die Standard-Einstellungen die meisten Fälle abdecken, desto besser — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gaenseklein/slidenotes/issues/86?email_source=notifications&email_token=AAPKCBBPH3DNCYBL6WVO4ELPXMP5JA5CNFSM4HMBIVQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWIP43I#issuecomment-496041581, or mute the thread https://github.com/notifications/unsubscribe-auth/AAPKCBGWPOI4UCUUVRZCHCLPXMP5JANCNFSM4HMBIVQQ.

[gaenseklein]

verstehe. ich glaube, es wäre einfacher, wenn wir die "YAML-Header-Block"-Konvention aus einem anderen Markdown-Projekt übernehmen und den Block mit "---" als Optionalen Block abgrenzen

das halte ich für keine gute idee. der inhalt vom code-block wird in der regel nicht geparsed danach, da da code drinne ist. das heißt auch --- ist ein valider code, der als code dargestellt wird. daher lieber den header nutzen, der ist außerhalb des codes und wird geparsed. daher kann danach entschieden werden, ob der code geparsed werden soll nach metadatenblock oder nicht. daher entweder code:config, code:styled oder ähnliches oder einen komplett eigenen block für gestylten code, bspw: ´´´extendedcode.

Hier würde ich dringend CSS nehmen, genau für diese Fälle ist es ja da? Eine ordered list ist doch ein semantisches Element, unser semantisches Element ist aber ein code-block. Im Endeffekt lasse ich mich durchaus überzeugen, sofern die Funktionalität identisch ist - was passiert z.B., wenn screen-reader den Code vorlesen, macht es einen Unterschied?

ok, darum hab ich mich nicht gekümmert. für mich war es das passende html-element für die aufgabe (stelle nummerierte zeilen dar). ein codeblock ist ja semantisch eigentlich ein mit pre-wrapper ausgestattetes element, wo auch enter und tab etc. dargestellt werden. so lasse ich das auch, wenn ich keine zeilennummerierung habe. aber bisher änder ich das, indem ich die zeilen in ein listen-element packe. ich kann auch dabei bleiben und einfach nach jedem enter ein neues span-element setzen, welches die zeilennummerierung beinhaltet. das kommt dem näher. kann aber auch sein, dass es gerade für den screenreader besser ist wie es jetzt ist. und es steht immer noch innerhalb eines <code>-blocks

gute Sache, wenn wir dank Parser frei sind, würde ich im Code mit einer Kombination von Symbolen arbeiten. z.B. <## foo ##> (aber die können wir ja später noch ändern. Nimm, was dir am plausibelsten aus deiner Erfahrung mit Programmiersprachen erscheint)

ja, an solche kombinationen hab ich auch schon gedacht. das problem mit kombinationen ist, dass du irgendwann immer auf jemanden triffst, der genau diese kombination in seinem code verwendet ;) deswegen. gutes, durchdachtes default, was auch okay aussieht (das von dir vorgeschlagene für innerhalb des codes markieren sieht doch schon nicht schlecht aus - für zeilen würd ich tatsächlich §§ nehmen) und dann optional verändern lassen durch die user. das ist denke ich die beste lösung.

[jochmann]

On 28. May 2019, at 07:13, gaenseklein notifications@github.com wrote:

verstehe. ich glaube, es wäre einfacher, wenn wir die "YAML-Header-Block"-Konvention aus einem anderen Markdown-Projekt übernehmen und den Block mit "---" als Optionalen Block abgrenzen

das halte ich für keine gute idee. der inhalt vom code-block wird in der regel nicht geparsed danach, da da code drinne ist. das heißt auch --- ist ein valider code, der als code dargestellt wird. daher lieber den header nutzen, der ist außerhalb des codes und wird geparsed. daher kann danach entschieden werden, ob der code geparsed werden soll nach metadatenblock oder nicht. daher entweder code:config, code:styled oder ähnliches oder einen komplett eigenen block für gestylten code, bspw: ´´´extendedcode.

Das macht irgendwie alles Probleme und die Leute müssen Ausnahmen vom Umgang mit den übrigen Blöcken lernen. Eigentlich wäre es am elegantesten, wenn wir ganz auf den header verzichten können. Vielleicht schaffen wir es, alle Auszeichnungen entweder im Text selbst (Zeilenanfang und Inline) oder als Variable in den codeblock-befehl einzupflegen?

``code:highlighted:counterstart='23 (default ist jeweils "off)

foo (hello world) <== bar ==>; <== wenn jemand eine ganze Zeile markieren will, dann muss er halt trotzdem schließen ==>

ich sehe gerade eher das Problem, was passiert, wenn wir inline-highlighting (im Beispiel oben bei "bar") auch als inline-element (<span>) zum Stylen im CSS abbilden, aber jemand über Zeilen hinweg ja verschiedene HTML-Blockelemente vermischt. Das müssen wir eigentlich vermeiden. Also Highlighting erst mal nur auf Zeilenbasis (dann muss auch nicht geschlossen werden)?
> Hier würde ich dringend CSS nehmen, genau für diese Fälle ist es ja da? Eine ordered list ist doch ein semantisches Element, unser semantisches Element ist aber ein code-block. Im Endeffekt lasse ich mich durchaus überzeugen, sofern die Funktionalität identisch ist - was passiert z.B., wenn screen-reader den Code vorlesen, macht es einen Unterschied?
> 
> ok, darum hab ich mich nicht gekümmert. für mich war es das passende html-element für die aufgabe (stelle nummerierte zeilen dar). ein codeblock ist ja semantisch eigentlich ein mit pre-wrapper ausgestattetes element, wo auch enter und tab etc. dargestellt werden. so lasse ich das auch, wenn ich keine zeilennummerierung habe. aber bisher änder ich das, indem ich die zeilen in ein listen-element packe. ich kann auch dabei bleiben und einfach nach jedem enter ein neues span-element setzen, welches die zeilennummerierung beinhaltet. das kommt dem näher. kann aber auch sein, dass es gerade für den screenreader besser ist wie es jetzt ist. und es steht immer noch innerhalb eines <code>-blocks
> 
> gute Sache, wenn wir dank Parser frei sind, würde ich im Code mit einer Kombination von Symbolen arbeiten. z.B. <## foo ##> (aber die können wir ja später noch ändern. Nimm, was dir am plausibelsten aus deiner Erfahrung mit Programmiersprachen erscheint)
> 
> ja, an solche kombinationen hab ich auch schon gedacht. das problem mit kombinationen ist, dass du irgendwann immer auf jemanden triffst, der genau diese kombination in seinem code verwendet ;)
> deswegen. gutes, durchdachtes default, was auch okay aussieht (das von dir vorgeschlagene für innerhalb des codes markieren sieht doch schon nicht schlecht aus - für zeilen würd ich tatsächlich §§ nehmen) und dann optional verändern lassen durch die user. das ist denke ich die beste lösung.
> 
> 
yo, noch schicker im Textbild fände ich <== foo ==> (wenn nur für Zeilenanfang: ==>)
selber Leute die zu parsenden Elemente wählen lassen ist ja krass mächtig. Cool.

[gaenseklein]

ich sehe gerade eher das Problem, was passiert, wenn wir inline-highlighting (im Beispiel oben bei "bar") auch als inline-element () zum Stylen im CSS abbilden, aber jemand über Zeilen hinweg ja verschiedene HTML-Blockelemente vermischt. Das müssen wir eigentlich vermeiden. Also Highlighting erst mal nur auf Zeilenbasis (dann muss auch nicht geschlossen werden)?

ah, ok, ja, guter einwand. zeilenbasis macht sinn. wenn nicht geschlossen ist wird ende der zeile genommen. oder - um verschachtelung zu vermeiden (bspw. <== foo <==bar ==> to==> ) nur ein zeichen für anfang und ende nehmen und wenn kein ende da ist, dann wird bis zum zeilenende gegangen.

yo, noch schicker im Textbild fände ich <== foo ==> (wenn nur für Zeilenanfang: ==>)

php hat das glaub ich wenn ich mich richtig erinnere. vor allem das ==>. sorry. deswegen kam ich ja auf das §§-zeichen.

selber Leute die zu parsenden Elemente wählen lassen ist ja krass mächtig. Cool.

ich finde das halt einfach durchdachter. weil so kannst du bspw. in deinem code auch schon elemente reinbringen, die das im code kennzeichnen und musst dann nur noch nach dem reinkopieren sagen: das sind die zeilen. bspw. in einem javascript-code:

´´´code:metablock
linemarker = /*highlight*/
---
function human_test(call){
  if(call && call.length > 100){
/*highlight*/    call.isHuman = this.analyzeCall(call);
  }
}
´´´

[gaenseklein]

Das macht irgendwie alles Probleme und die Leute müssen Ausnahmen vom Umgang mit den übrigen Blöcken lernen. Eigentlich wäre es am elegantesten, wenn wir ganz auf den header verzichten können.

Wie gesagt, das geht theoretisch ohne Probleme, aber praktisch ist das ätzend für die usability. und die sollte ja gesteigert werden. Ich orientiere mich ja bereits am Chart-Block, wo wir die selbe Metadaten-Struktur haben. Wir müssen dem Codeblock nur irgendwie beibringen, dass es einen Metadatenblock scannen muss. Und das geht am einfachsten in der Kopfzeile. Beispielsweise mit ´´´code:highlighted. Dann scannt er nach einem Metadatenblock. Oder ´´´code:options, oder ´´´code:extraoptions. Wenn wir uns da festgelegt haben hilft ja an der Stelle das Insert-Menü weiter, weil darüber ja genau sowas auf Knopfdruck eingefügt wird.

[jochmann]

On 1. Jun 2019, at 07:17, gaenseklein notifications@github.com wrote:

Das macht irgendwie alles Probleme und die Leute müssen Ausnahmen vom Umgang mit den übrigen Blöcken lernen. Eigentlich wäre es am elegantesten, wenn wir ganz auf den header verzichten können.

Wie gesagt, das geht theoretisch ohne Probleme, aber praktisch ist das ätzend für die usability. und die sollte ja gesteigert werden. Ich orientiere mich ja bereits am Chart-Block, wo wir die selbe Metadaten-Struktur haben. Wir müssen dem Codeblock nur irgendwie beibringen, dass es einen Metadatenblock scannen muss. Und das geht am einfachsten in der Kopfzeile. Beispielsweise mit ´´´code:highlighted. Dann scannt er nach einem Metadatenblock. Oder ´´´code:options, oder ´´´code:extraoptions. Wenn wir uns da festgelegt haben hilft ja an der Stelle das Insert-Menü weiter, weil darüber ja genau sowas auf Knopfdruck eingefügt wird.

OK. wird bei den Charts der Metadatenblock notwendigerweise immer eingefügt oder ist der auch optional? Wenn es optional ist, lass uns doch mit dem Argument :options den codeblock bei beiden einfügen.

[gaenseklein]

OK. wird bei den Charts der Metadatenblock notwendigerweise immer eingefügt oder ist der auch optional?

Der ist bei den Charts genauso optional. Wenn keine Metadaten (bzw. kein Metadatenblock) vorhanden sind werden Defaults benutzt.

Wenn es optional ist, lass uns doch mit dem Argument :options den codeblock bei beiden einfügen.

Bei den Charts ist das unnötig. Das Zeichen "\n---" kann im Chart-Block gescannt werden, da der Inhalt des Chartblocks ja eh interpretiert werden muss vom Chart-Plugin (und daraus eine Chart erstellt wird). Ein "\n---\n" taucht im Datenteil eines Chartblocks nicht auf bzw. wäre dort ungültig. Somit kann danach gescannt werden - und wenn "\n---\n" im Chartblock auftaucht wird alles davor als Metadatenblock aufgefasst, alles danach als Datenblock. Da macht das keine Probleme. Beim Code ist das was anderes. Code bedeutet ja eben, dass er nicht interpretiert werden soll (syntax-highlightning lassen wir mal aus, das ist was anderes weils ja nur den Code verschönert, nicht interpretiert). Das heißt, im Code selbst kann sehr wohl "\n---\n" auftauchen. Bspw. wenn wir in eine Präsentation ein Beispiel eines Markdown-Textes bringen wollen. Daher kann ich da nicht einfach nach scannen im Codeblock. Deswegen muss beim Codeblock die Anweisung, dass es einen Codeblock gibt außerhalb liegen. Ich denke, ´´´code:options ist da schon ein ganz guter Ansatz. Es kann auch dem User freigestellt werden, wie er das schreiben will. Also bspw. alles in die header-line packen geht theoretisch genausogut und es wäre auch kompatibel miteinander. Aber Einzeiler sehen doof aus und sind unübersichtlich. Ein Metadatenblock ist da schöner, übersichtlicher und leichter zu erweitern.

Wir können auch, um Standards zu nutzen auch wenn sie hier finde ich keinen Sinn machen, den YAML-Headerblock von oben nutzen. Allerdings abweichend zum dort beschriebenen Standard kann ein solcher Block nur in Datenblöcken/Sections auftauchen und dort auch nur im Kopf. Sprich die erste Zeile der Section muss ein "---" sein. Für Codeblöcke würde das bedeuten, dass wer die erste Zeile mit "---" beginnen lassen will (ohne dies als Metablock interpretiert haben zu wollen) dies nicht tun kann, sondern bspw. "--- " schreibt. Denn dann würde das Codeblock-Plugin in der ersten Zeile gucken und anhand derer entscheiden, ob es einen Metadatenblock gibt oder nicht. Das wäre zwar nicht sauber getrennt, würde aber gehen.

Am logischsten finde ich immer noch, einen metadatenblock im header kenntlich zu machen. Also ´´´code:options o.ä. und dann wird nach einem Metadatenblock gescannt, sonst nicht. Und da Codeblöcke nur von Leuten verwendet werden, die diese Problematik verstehen sollten wird das auch funktionieren ;)

[gaenseklein]

so sieht das im editor aus. eigentlich ganz cool, oder? habs noch aufgehübscht

[jochmann]

ja, sehr cool. alles, was wir im Textfeld selbst abbilden hilft uns, Platz für UI zu sparen.

kläre doch bitte mit Marie, welche Elemente des Interfaces alle zum Start der Betaphase dabei sein sollen. Das Ausklappmenü zum Beispiel hatte sie gedacht, soll noch nicht genommen werden, aber vermutlich hattest du mit "Kontextmenü" etwas anderes gemeint?

On 2. Jun 2019, at 08:57, gaenseklein notifications@github.com wrote:

https://user-images.githubusercontent.com/31316726/58757897-4f6e9c80-8514-11e9-8f07-16d01b21b82d.png so sieht das im editor aus. eigentlich ganz cool, oder? habs noch aufgehübscht

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gaenseklein/slidenotes/issues/86?email_source=notifications&email_token=AAPKCBBTILGKAPJLR7DPRLTPYNVMFA5CNFSM4HMBIVQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWXPI5I#issuecomment-498005109, or mute the thread https://github.com/notifications/unsubscribe-auth/AAPKCBGZ63PM3G6LGHMK6ITPYNVMFANCNFSM4HMBIVQQ.

[gaenseklein]

Hier würde ich dringend CSS nehmen, genau für diese Fälle ist es ja da? Eine ordered list ist doch ein semantisches Element, unser semantisches Element ist aber ein code-block. Im Endeffekt lasse ich mich durchaus überzeugen, sofern die Funktionalität identisch ist - was passiert z.B., wenn screen-reader den Code vorlesen, macht es einen Unterschied?

Laut meiner Recherche ist es für die Screenreader sogar von Vorteil, wenn der Code in einem Listenelement dargestellt wird: Dadurch kann der Screenreader dem User sagen, wieviele Zeilen Code kommen und liest sie auch dementsprechend vor. https://www.sitepoint.com/screen-reader-usability-tips - tip 3

[jochmann]

Super nachgehakt. Wie machen es, wie es für Screenreader besser ist.

On 8. Jun 2019, at 21:19, gaenseklein notifications@github.com wrote:

Hier würde ich dringend CSS nehmen, genau für diese Fälle ist es ja da? Eine ordered list ist doch ein semantisches Element, unser semantisches Element ist aber ein code-block. Im Endeffekt lasse ich mich durchaus überzeugen, sofern die Funktionalität identisch ist - was passiert z.B., wenn screen-reader den Code vorlesen, macht es einen Unterschied?

Laut meiner Recherche ist es für die Screenreader sogar von Vorteil, wenn der Code in einem Listenelement dargestellt wird: Dadurch kann der Screenreader dem User sagen, wieviele Zeilen Code kommen und liest sie auch dementsprechend vor. https://www.sitepoint.com/screen-reader-usability-tips https://www.sitepoint.com/screen-reader-usability-tips - tip 3

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gaenseklein/slidenotes/issues/86?email_source=notifications&email_token=AAPKCBEZZADKLJ7SLJCRPUDPZQA4NA5CNFSM4HMBIVQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXH3X6A#issuecomment-500153336, or mute the thread https://github.com/notifications/unsubscribe-auth/AAPKCBE4ZYZDXGZZ3DIKO5DPZQA4NANCNFSM4HMBIVQQ.

[gaenseklein]

alles umgesetzt