Editor markdown-vorschau bleibt in kursiv, obwohl tag geschlossen ist

[jochmann]

auf Safari MacOS. Siehe screenshot

[gaenseklein]

hmm... kann ich nicht reproduzieren im chromium. bleibt das so, wenn du enter gedrückt hast? oder backspace oder ähnliches?

[jochmann]

backspace macht keinen unterschied, nach enter normalisiert sich die Anzeige und der Teil, der nicht innerhalb der Sternchen steht, wird wieder in regulärer Schrift angezeigt

On 15. Sep 2018, at 01:58, gaenseklein notifications@github.com wrote:

hmm... kann ich nicht reproduzieren im chromium. bleibt das so, wenn du enter gedrückt hast? oder backspace oder ähnliches?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gaenseklein/slidenotes/issues/40#issuecomment-421513213, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6hBHs_GAPTixnFxQMg_PwisstedwsZks5ubEKpgaJpZM4WpIP3.

[gaenseklein]

existiert der bug immer noch? ist ja inzwischen einiges passiert. ich denke, es war ein fehler, der zurückzuführen war auf fehlendes neu parsen. so zumindest reproduziert er das bei mir: es wird kursiv dargestellt, bis das parsing greift (nach inaktivität von ca. 300ms) und dann ändert es sich richtig. würde den bug dann schließen, wenn das sich bei dir genauso verhält.

[jochmann]

Ja, verhält sich bei mir auch so: auch nach geschlossenem Tag kursiv so lange, bis keine Eingabe erfolgt. dann wird alles nach dem geschlossenen Tag wieder regulär dargestellt.

Können wir das noch irgendwie erzwingen, dass schneller oder schlauer geparst wird? Wenn jemand schnell tippt, ist das schon irritierend, wenn die Schrift während des Tippens falsch ausgezeichnet dargestellt wird.

On 6. Jul 2019, at 04:55, gaenseklein notifications@github.com wrote:

existiert der bug immer noch? ist ja inzwischen einiges passiert. ich denke, es war ein fehler, der zurückzuführen war auf fehlendes neu parsen. so zumindest reproduziert er das bei mir: es wird kursiv dargestellt, bis das parsing greift (nach inaktivität von ca. 300ms) und dann ändert es sich richtig. würde den bug dann schließen, wenn das sich bei dir genauso verhält.

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

[gaenseklein]

müsste ich gucken, ist aber ein anderes problem. Das problem tritt auf, weil ich versuche, das schnell und schlau zu parsen bzw. eben extra nicht zu parsen, um keine verzögerung zu haben. Ich vermute tatsächlich, dass es die Cursorposition ist, die mir hier einen Strich durch meine Rechnung macht. das heißt: bei Abschluss des Tags steht der Cursor noch in dem Tag drinne, so dass folgende getippte Buchstaben ebenfalls in den Tag reingeschrieben werden. Beim Neu parsen korrigiert sich das. Das ganze findet in dem kritischsten Bereich statt den das Programm hat, nämlich dem schnellen Tippen. Und um da keine Verzögerung aufkommen zu lassen lasse ich ja gerade extra nicht parsen. Heißt: Um das zu beheben müsste ich warscheinlich die Cursorposition neu berechnen - dazu müsste ich aber neu parsen - und das bedeutet, dass es eine Verzögerung beim Tippen gibt. Das heißt so oder so wird es zu einem warscheinlichen "Bruch" im Tippgefühl kommen. Und da fand ich die bisherige Lösung eleganter. Nach einer kleinen Tipp-Pause korrigiert sich das ja und solange es keine Tipp-Pause gibt ist es imho wichtiger, dass die Buchstaben schnell auftauchen (des Tippgefühls wegen) als dass sie nicht kursiv, aber mit Verzögerung auftauchen.

[gaenseklein]

ich lass den bug nochmal offen, ich gucks mir nochmal an, ob ich vielleicht den cursor besser gesetzt kriege, so dass er bereits außerhalb des tags steht und das dann verschwindet. mit cursor meine ich, dass es im text ein tag gibt: <span id="carret"></span> und in dieses wird der text immer sofort reinkopiert, der neu getippt wird. dadurch ist es so schnell. erst wenn es ca. 300Ms keine Eingabe gab wird neu geparsed um eben ein "ruckeln" beim tippen zu vermeiden, da das extrem störend ist. momentan sieht es so aus, als ob der cursor links vom </i>-tag gesetzt ist und nicht rechts, wie es eigentlich sein müsste. daher müsste das eigentlich behebbar sein, wenn der cursor richtig gesetzt wurde. das passiert anscheinend auch nachträglich, also wenn der cursor so steht: *kursiv-tag*| weiterer text und losgetippt wird passiert das auch.

[gaenseklein]

war einfacher als gedacht... eine sort-funktion war falsch und hat nicht gearbeitet wie sie sollte, dadurch wurde der cursor falsch einsortiert. jetzt läufts wie gewünscht.