Syntax highlighting gets messed up if $$ is in the middle of a line

[kendonB]

[jjallaire]

Sadly that's a known issue w/ our math highlighting (which is inherited from another extension).

[postylem]

Related: if you aren't careful to have a blank line before and after every display math block, then editing in visual mode will introduce this problem, where it doesn't exist.

For example, if you have the following, which has no issue with the highlighter:

and then you toggle in and out of visual mode (with Quarto: Edit in Visual Mode then Quarto: Edit in Source Mode), your file will now have the highlighting problem in any place where there wasn't a blank line in between the text and the start (or end) of the display math:

Given the known highlighter bug, maybe it would be good to make the Visual Mode not introduce these problems (by not putting any text on the same line as the double dollar signs?)

[jjallaire]

Oh, that's an excellent observation! Yes, we will definitely fix this in visual mode soon!

[jjallaire]

Taking a close look at this, I think the underlying problem is that visual doesn't have granular control over what markdown is written out. Rather, we give Pandoc the abstract representation of the document and it converts that to markdown. In this case, your original source by not having a blank line in between is actually asking to merge the display equation with the text above or below (because newline doesn't denote a block or line break in pandoc markdown). When the markdown is written back out Pandoc just collapses the math lines into the surrounding text.

So that's the source <=> visual behavior. For the highlighting behavior that is something we are getting from VS Code's markdown engine (and their rules aren't quite as sophisticated as what pandoc allows for).

So my advice here is to just include the newlines as appropriate in your source code.

[postylem]

I see, thank you for the detailed response! That's too bad, because sometimes I think you can't leave newlines around display equations: for instance, if you want a display equation in the middle of a paragraph:

Here is an example of a function I want to talk about mid-paragraph.  Let
$$
g(h) = \int_\mathcal{X} h(f(x)) \mathrm{d}x
$$
for some monotonically increasing function, $f$.

Putting newlines around the display math would make the text "for some..." start a new paragraph (like, in LaTeX / PDF with indented starts to paragraphs it would be indented), which wouldn't be desired.

[jjallaire]

Okay, that's a good motivating example! We'll definitely see if we can make that highlighting more robust in the future.

[HPDell]

Hi, may I suggest implementing the instant rendering mode in the way that Obsidian chooses? In that node-taking software, users type enter just to create a new line, not a new paragraph. By doing so, it is very easy for users to insert display equations like

Here is an example of a function I want to talk about mid-paragraph.  Let
$$
g(h) = \int_\mathcal{X} h(f(x)) \mathrm{d}x
$$
for some monotonically increasing function, $f$.

If users want to create a new paragraph, they simply type the enter twice, just like in the raw code mode. Alternatively, the editor can have different rendering behaviours when enter is typed one time or two times, for example, expanding space between the current line and the last paragraph for the latter case. That would be better.

Or, I would suggest allowing users to create a "raw" and "invisible" linebreak. Currently, when users type Shift+Enter, a backslash \ is append at the end of this line, to make the line break visual in the rendered document. However, there should be a way for users to create invisible linebreaks to better format their code. In this way, they can also type display equations that won't break a paragraph.