syntax-highlightning von codeblöcken bereits in texteditor

[gaenseklein]

wie der titel schon sagt - syntax-highlightning (mithilfe von hljs?) bereits im texteditor aktivieren

[gaenseklein]

@jochmann wird knifflig und höchstwarscheinlich auch ganz schön ressourcenintensiv. das könnte den editor arg ausbremsen. würd ich gerne nicht zum start haben. wir haben ja bereits ein syntax-highlightning und das ist md-code. jetzt noch für alle erdenklichen codearten syntax-highlightning einzubauen könnte das parsen vor eine echte herausforderung stellen.

[gaenseklein]

habs jetzt mal probeweise angemacht. scheint doch ganz okay zu gehen. müssen wir mal performance-tests machen. knifflig bleibts insofern, als das ich momentan einfach zeile für zeile neu interpretiere. dadurch ist das syntax-highlightning natürlich nicht so exakt wie sonst. sieht aber ganz okay aus auf den ersten blick...

[jochmann]

ist das nicht-trivial, das pro codeblock zu behandeln und mit einer fallback-liste von defaults zu arbeiten? für die performance würde ich das auch erst feuern, sobald der code-block geschlossen ist. weiß nicht, wie das plugin das mit der auto-erkennung macht. in zukunft wollen wir manuelle auszeichnung der sprache im codeblock ja auch erlauben durch ```code:haskell etc

On 1. Dec 2018, at 05:37, gaenseklein notifications@github.com wrote:

habs jetzt mal probeweise angemacht. scheint doch ganz okay zu gehen. müssen wir mal performance-tests machen. knifflig bleibts insofern, als das ich momentan einfach zeile für zeile neu interpretiere. dadurch ist das syntax-highlightning natürlich nicht so exakt wie sonst. sieht aber ganz okay aus auf den ersten blick...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gaenseklein/slidenotes/issues/52#issuecomment-443399067, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6hBB8N21jZhtf5lk5932JDtT3kuibfks5u0geRgaJpZM4Y0SSl.

[gaenseklein]

ist das nicht trivial, das pro codeblock zu behandeln

nein, weil es keinen codeblock gibt zu der zeit der erstellung. der wird erst für die präsentation erstellt. es gibt pro zeile einen span-tag. der wird einzeln interpretiert. wenn ich natürlich dank einer angabe weiß, welches codehighlightning verwendet werden soll kann ich immer das auf die zeile anwenden. aber sonst muss ich aus dem in einer variable liegenden datenblock erst ein neues html-element machen, das von hljs interpretieren lassen, daraus die zeilen ziehen und diese dann in die spans packen.

klingt banal, ist aber aufwand - der leider in einem kritischen moment des editierens passiert und so - wenn er zu langsam ist - das tippgefühl verschlechtert.

für die performance würde ich das auch erst feuern, sobald der code-block geschlossen ist.

so funktioniert der editor nicht, bzw. du verstehst die problematik anscheinend nicht. code-highlightning wird eh erst dann passieren, wenn der code-block geschlossen ist. erst da ist es ja als code ersichtlich. das ist nicht der punkt. aber das passiert ja nicht nur einmal dann wenn der codeblock geschlossen worden ist und dann nie wieder, sondern ständig. für die performance heißt das: jedesmal wenn neu geparsed wird wird erneut code-highlightning auf den code ausgeführt. oder um genau zu sein passiert folgendes:

user hat irgendwas getippt, bspw. enter, was den parse-prozess auslöst -> parse den text ein, d.h. besorge dir alle nötigen informationen aus dem vollständigen md-code und erstelle daraus eine map fürs rendern -> render aus der map einen hintergrund-html-code für die textarea -> wende hljs auf alle spans mit der klasse "code" vom hintergrund-html-code der textarea an beim user kommt das ergebnis an, bspw. eine neue zeile wird angezeigt

d.h. effektiv gibt es parsen->rendern->hljs quasi nach jedem tippen (zumindest wenn du bspw. löschst ist das momentan so). das darf insgesamt nicht länger als 100ms dauern sonst merkt der user ein "ruckeln". das parsen ist schon gut getrimmt, das rendern könnte noch mehr getrimmt werden (siehe #33 partielles rendern) aber war bisher als ok gesehen worden. und jetzt kommt halt noch code-highlightning hinzu. deswegen bin ich da so skeptisch, ob das wirklich sinn macht. also allgemein code-highlightning für die präsentation zu unterstützen klar. das ist ein muss. aber während der laufzeit, also beim tippen - ist das da nötig? du willst ja nicht darin programmieren, sondern eine präsentation machen. ob da die schickere optik performance-einbußen rechtfertigt ist halt die frage und meine priorität wäre performance. aber wenn die performance das hergibt siehts natürlich schicker aus schon beim tippen code-highlightning zu haben.

[gaenseklein]

apropos performance: neu hinzu kommt ja auch noch die sidearea - die muss ebenfalls gerendert werden, was auch nochmal performance frisst. also in den kritischen bereich kommt noch die sidebar-renderei hinzu. zur erinnerung: unter #31 hab ich benchmarks erstellt (vergleich neuer, alter parser). die werte vom neuen parser sind die momentan interessanten.

[jochmann]

OK, performance hat priorität. langfristig glaube ich, dass wir uns die rendering-logik für den parser noch mal ansehen sollten. vielleicht kannst du snapshots erstellen, die länger durchgeschleift werden und nur Änderungen an den snapshots (hash) prüfen, bevor jede zeile gerendert wird.

On 3. Dec 2018, at 02:44, gaenseklein notifications@github.com wrote:

ist das nicht trivial, das pro codeblock zu behandeln

nein, weil es keinen codeblock gibt zu der zeit der erstellung. der wird erst für die präsentation erstellt. es gibt pro zeile einen span-tag. der wird einzeln interpretiert. wenn ich natürlich dank einer angabe weiß, welches codehighlightning verwendet werden soll kann ich immer das auf die zeile anwenden. aber sonst muss ich aus dem in einer variable liegenden datenblock erst ein neues html-element machen, das von hljs interpretieren lassen, daraus die zeilen ziehen und diese dann in die spans packen.

klingt banal, ist aber aufwand - der leider in einem kritischen moment des editierens passiert und so - wenn er zu langsam ist - das tippgefühl verschlechtert.

für die performance würde ich das auch erst feuern, sobald der code-block geschlossen ist.

so funktioniert der editor nicht, bzw. du verstehst die problematik anscheinend nicht. code-highlightning wird eh erst dann passieren, wenn der code-block geschlossen ist. erst da ist es ja als code ersichtlich. das ist nicht der punkt. aber das passiert ja nicht nur einmal dann wenn der codeblock geschlossen worden ist und dann nie wieder, sondern ständig. für die performance heißt das: jedesmal wenn neu geparsed wird wird erneut code-highlightning auf den code ausgeführt. oder um genau zu sein passiert folgendes:

user hat irgendwas getippt, bspw. enter, was den parse-prozess auslöst -> parse den text ein, d.h. besorge dir alle nötigen informationen aus dem vollständigen md-code und erstelle daraus eine map fürs rendern -> render aus der map einen hintergrund-html-code für die textarea -> wende hljs auf alle spans mit der klasse "code" vom hintergrund-html-code der textarea an beim user kommt das ergebnis an, bspw. eine neue zeile wird angezeigt

d.h. effektiv gibt es parsen->rendern->hljs quasi nach jedem tippen (zumindest wenn du bspw. löschst ist das momentan so). das darf insgesamt nicht länger als 100ms dauern sonst merkt der user ein "ruckeln". das parsen ist schon gut getrimmt, das rendern könnte noch mehr getrimmt werden (siehe #33 https://github.com/gaenseklein/slidenotes/issues/33 partielles rendern) aber war bisher als ok gesehen worden. und jetzt kommt halt noch code-highlightning hinzu. deswegen bin ich da so skeptisch, ob das wirklich sinn macht. also allgemein code-highlightning für die präsentation zu unterstützen klar. das ist ein muss. aber während der laufzeit, also beim tippen - ist das da nötig? du willst ja nicht darin programmieren, sondern eine präsentation machen. ob da die schickere optik performance-einbußen rechtfertigt ist halt die frage und meine priorität wäre performance. aber wenn die performance das hergibt siehts natürlich schicker aus schon beim tippen code-highlightning zu haben.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gaenseklein/slidenotes/issues/52#issuecomment-443564478, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6hBMJT9ZJNag4pEw8H6drXIfUBlGybks5u1IH2gaJpZM4Y0SSl.

[gaenseklein]

zur performance vom rendern hatte ich mir bereits gedanken gemacht. ist n bischen tricky, aber sieh dir issue #33 an wenn es dich interessiert. das wäre mein ansatz um es zu machen. trivial ist das nicht, aber auch kein ding der unmöglichkeit und der ansatz wäre, so wenig wie möglich und so viel wie nötig neu zu rendern. die seiten bieten sich dafür als vergleichseinheit an, da sie unterschiedliche parse-ergebnisse begrenzen (es gibt keine elemente über pagebreaks hinausgehend). wenn ich es schaffe, dass immer nur eine seite gerendert wird im best case dann wird das ziemlich schnell.

[jochmann]

das mit den slides als basis zum hashen und prüfen ob neues rendern nötig ist, ist clever. kannst du der logik nicht noch die position der slides beibringen und so identische slides (beim copy and paste) voneinander unterscheiden?

On 5. Dec 2018, at 01:33, gaenseklein notifications@github.com wrote:

zur performance vom rendern hatte ich mir bereits gedanken gemacht. ist n bischen tricky, aber sieh dir issue #33 https://github.com/gaenseklein/slidenotes/issues/33 an wenn es dich interessiert. das wäre mein ansatz um es zu machen. trivial ist das nicht, aber auch kein ding der unmöglichkeit und der ansatz wäre, so wenig wie möglich und so viel wie nötig neu zu rendern. die seiten bieten sich dafür als vergleichseinheit an, da sie unterschiedliche parse-ergebnisse begrenzen (es gibt keine elemente über pagebreaks hinausgehend). wenn ich es schaffe, dass immer nur eine seite gerendert wird im best case dann wird das ziemlich schnell.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gaenseklein/slidenotes/issues/52#issuecomment-444312593, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6hBBr-jbNIAjs46yy6Vz9aZcMTmbIFks5u1xRSgaJpZM4Y0SSl.

[gaenseklein]

siehe issue #69 : highlightning im texteditor ist - sobald es was zu tun gibt - ein absoluter zeitfresser. entweder es wird irgendwie ähnlich zu partiellem rendern gehandhabt - d.h. alte ergebnisse werden nicht ernuet mit highlightning versehen - oder es muss raus. im proof-of-concept brauchte es tatsächlich 146Ms. Also alleine mehr, als die dem gesamten prozess zugestandenen 100Ms.

[jochmann]

schade, aber fürs erste auf jeden Fall zu teuer. Ich denke, dass wir das als feature-request festhalten sollten. Ich glaube, uns fallen noch elegantere Lösungen fürs Rendern ein, die dann auch das Highlighting gestatten. Das sollte dann auf jeden Fall auch möglichst "kompartmentalisiert" sein. Eventuell sogar als noch weitere Farb-Ebene über der Text-Ebene, die sich in größeren Zeitabständen rendert.

was mir auch noch einfällt: css rendert auf input quasi instantaneous (siehe ::hover etc). Wenn du Farbänderungen etc über css-variablen triggerst, statt über JavaScript, ist da vielleicht noch Massiv Potential vergraben? Dann muss eventuell noch weniger gerendert werden und bis auf die span-eben herunter kann das rendering auf einzelne Elemente beschränkt werden.

Am 25.12.2018 um 17:48 schrieb gaenseklein notifications@github.com:

siehe issue #69 https://github.com/gaenseklein/slidenotes/issues/69 : highlightning im texteditor ist - sobald es was zu tun gibt - ein absoluter zeitfresser. entweder es wird irgendwie ähnlich zu partiellem rendern gehandhabt - d.h. alte ergebnisse werden nicht ernuet mit highlightning versehen - oder es muss raus. im proof-of-concept brauchte es tatsächlich 146Ms. Also alleine mehr, als die dem gesamten prozess zugestandenen 100Ms.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gaenseklein/slidenotes/issues/52#issuecomment-449862609, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6hBLD3YB2A9OaR2YjYUZXb-3y2Loz9ks5u8lbQgaJpZM4Y0SSl.

[gaenseklein]

css rendert nicht instantaneous sondern braucht ebenso zeit wie javascript. das ganze ist sogar im selben prozess angesiedelt, so dass das eine auf das andere warten muss. den einzigen geschwindigkeitsvorteil den css gegenüber javascript hat ist, dass es bereits fest im browser implementiert ist, d.h. dort besser optimiert werden kann als javascript. aber für uns ist der unterschied dort marginal. ob du jetzt ein ::hover nimmst um die farbe zu ändern oder ein onmouseover - natürlich ist da css ein kleinen ticken schneller, weil es eben besser optimiert wurde. aber nicht merklich.

weniger rendern ist der knackpunkt um das ganze zu beschleunigen. siehe die geschwindigkeit vom sidebar-rendern. nur durch geschicktes partielles rendern habe ich dort wieder annehmbare zeiten hinbekommen. welche allerdings auch fehler hervorrufen kann.

[jochmann]

ja, da meinte ich ja, dass du über geschickte CSS-variablen viel präziser partiell rendern könntest. Womöglich.

Am 02.01.2019 um 18:23 schrieb gaenseklein notifications@github.com:

css rendert nicht instantaneous sondern braucht ebenso zeit wie javascript. das ganze ist sogar im selben prozess angesiedelt, so dass das eine auf das andere warten muss. den einzigen geschwindigkeitsvorteil den css gegenüber javascript hat ist, dass es bereits fest im browser implementiert ist, d.h. dort besser optimiert werden kann als javascript. aber für uns ist der unterschied dort marginal. ob du jetzt ein ::hover nimmst um die farbe zu ändern oder ein onmouseover - natürlich ist da css ein kleinen ticken schneller, weil es eben besser optimiert wurde. aber nicht merklich.

weniger rendern ist der knackpunkt um das ganze zu beschleunigen. siehe die geschwindigkeit vom sidebar-rendern. nur durch geschicktes partielles rendern habe ich dort wieder annehmbare zeiten hinbekommen. welche allerdings auch fehler hervorrufen kann.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gaenseklein/slidenotes/issues/52#issuecomment-450926947, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6hBK3565IRLfIgq-rzVipLLyhE0HUQks5u_Or8gaJpZM4Y0SSl.