search

gicentre / litvis

Literate Visualization: Theory, software and examples
https://www.gicentre.net/litvis
BSD 3-Clause "New" or "Revised" License
376 stars 26 forks source link

syntax highlighting in VSCode requires space between elm and open brace #50

Open jwoLondon opened 4 years ago

jwoLondon commented 4 years ago

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 { ?

kachkaev commented 4 years ago

Created https://github.com/remarkjs/remark/issues/528 and https://github.com/prettier/prettier/issues/9155 to see if we can fix this on the formatting front.

kachkaev commented 4 years ago

Hi Jo! WDYT of stopping the support of non-whitespace characters as the delimiter in litivs? See https://github.com/remarkjs/remark/issues/528#issuecomment-703297322.

Doing so will include the removal of my hack in Prettier https://github.com/prettier/prettier/pull/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.

jwoLondon commented 4 years ago

Yes, that makes sense, for the reasons discussed.