#1

I’ve just discovered Obsidian. Am very, very impressed by how such a simple interface solves so many pain points I’ve had with text notes.

However!

Use case or problem

Obsidian defines prismjs code blocks using backticks followed by the language, e.g., ```js

The prismjs spec requires prefixing with language- or lang-, e.g., ```language-js

This means that code blocks inserted via Obsidian are not compatible if the text file is opened in any other apps using prismjs (in my case DEVONthink), and vice versa.

Proposed solution

Allow Obsidian to recognise code blocks in a manner consistent with the prismjs spec, i.e., with the language- or lang- prefix.

2 Likes
Use different underlying syntax highlighting library
Bash or shell command syntax highlighting
#2

Use case or problem

The current syntax highlighting for the markdown previews uses “prismjs” and this highlighting isn’t applied to the code blocks in editing mode. There are many requests for this. To fill the void there is a plugin to achieve this but it is based on “codemirror”. This results in some weird usage:

  • They don’t come with matching themes
  • They use different tokenizers and results in different HTML, so you have to write your themes twice
  • Both prismjs and codemirror are highlighters built for web and they don’t have the best tokenization. Text editors use the textmate tokenizer which results in waaaay better syntax highlighting. It supports theme customization prismjs and codemirror can’t even come close to.

Proposed solution

  1. Switch all code highlighting to GitHub - shikijs/shiki: A beautiful Syntax Highlighter. - It uses TextMate grammar to tokenize strings, and colors the tokens with VS Code themes.
  2. Enable syntax highlighting in editor mode using shiki
  3. Expose a syntaxTheme configuration option that can use any vscode theme, portentially expose two options: lightSyntaxTheme and darkSyntaxTheme

Current workaround (optional)

Use the community plugin for editor syntax highlighting + write two similar (but not matching) themes for both underlying syntax highlighters

Related feature requests (optional)

3 Likes
#3

Having written a plugin now I see that switching to shiki would be quite hard. all current plugins are tied to codemirror so changing to shiki (an by extension monaco) would probably be a huge lift.

Instead the solve for this could be just switching the preview pane from using prism to highlighting with codemirror. We miss out on the better textmate tokenization, but will at least have matching themes when switching between the editor and preview

1 Like
#4

I merged the two threads for and against using primjs, as both options can’t be implemented. I’m tempted to merge this with the syntax highlighting thread as well.

1 Like