You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Code block headers expressed as elm{l} and elm {l} (note the space in the second example) both work. In Atom syntax highlighting is applied to the block of code correctly, but in VSCode with the elm-tooling plugin (the one we recommend for litvis), only the second case with a space generates correct syntax colouring.
I assume the problem is with the elm-tooling plugin for VSCode, but could apply a Prettier type auto formatting to ensure a single space between the elm and { ?
The text was updated successfully, but these errors were encountered:
Hi Jo! WDYT of stopping the support of non-whitespace characters as the delimiter in litivs? See remarkjs/remark#528 (comment).
Doing so will include the removal of my hack in Prettier prettier/prettier#4783 as well as changing how mume separates the args from the language 'word'. This will make things in sync with how VSCode highlights the syntax.
I think that we initially got confused by what Atom was doing. If it only looked for spaces and tabs as word separators, we would do too. At the moment, it seems like we've ended up on a small island of not following the markdown specs.
Code block headers expressed as
elm{l}
andelm {l}
(note the space in the second example) both work. In Atom syntax highlighting is applied to the block of code correctly, but in VSCode with the elm-tooling plugin (the one we recommend for litvis), only the second case with a space generates correct syntax colouring.I assume the problem is with the elm-tooling plugin for VSCode, but could apply a Prettier type auto formatting to ensure a single space between the
elm
and{
?The text was updated successfully, but these errors were encountered: