Hi,
highlighting syntax seems not correctly parsed on editing mode.
in editor it is highlighted but not after rendered.
thank you!
add:
- empty highlighting is highlighted on editor but not highlighted after rendering
- empty inline math is not highlighted on editor but correctly converted after rendering
Hey, I have notices that in the editor mode my text is highlighted, but in the view mode the highlighting is gone:
This is probably due to the leading space between the starting == and the **
- I would expect that that if the text is not highlighted in view mode, it shouldn’t be highlighted in the editor mode either?
Even though I get that it would be annoying during writing, if the highlight flickers on/off with each new word. I think this is kind of misleading and it took me some time to catch the error in the beginning.
Hi @Yannic, you’re totally right! There’s been an outstanding bug to fix this and we’ll see if we can clean this up in time for 3.1 
Finally fixed in Supernotes 3.1.2 
Just to note though, the second example in the OP (LaTeX parsing) is actually “correct”, in that what you have created is not actually inline LaTeX with no content, but rather the beginning of a LaTeX block with no content (and no closing tag). Our parser actually happily processes the rest of your card as LaTeX even without a closing $$, so we’ve left this behavior as is.
Highlights (==) and spoilers (!!) should be good to go now and properly align with their rendered counterparts.
1 Like
So cool. Thank you for the patch!
2 Likes
Highlights are not indicated in editor if the first == is preceded/the second == is followed by a punctuation or special character. It correctly rendered, though.
Yes, this was an oversight. We’ve actually already fixed this in the desktop builds of the app, so if you redownload it should work. Will be live for all platforms in 3.1.3.
1 Like