Hello and welcome! :) Thank you for this feature request!

This is currently not possible in Expressive Code, I'd need to add support in the plugin API and all built-in plugins for it so that they can distinguish between block-level code processing and inline code processing. In inline code, most rendering features like frames, line numbers, collapsible blocks etc. would not be possible because no block-level tags are allowed.

I'm honestly not very happy with the {:js} syntax, but if Shiki establishes this as a standard, I'd probably use the same syntax as well to avoid fragmentation in the syntax highlighting landscape.

That being said, I'm not sure yet how useful it actually is to highlight inline code. Do you have any real-world examples I could look at where inline highlighting is being used and looks helpful?

In inline code, most rendering features like frames, line numbers, collapsible blocks etc. would not be possible because no block-level tags are allowed.

I think that if you're at the point where you would need to add collapsible blocks, frames, or line numbers to an inline block it might as well be converted into a <pre>, so this should not be a problem!

I'm honestly not very happy with the {:js} syntax, but if Shiki establishes this as a standard, I'd probably use the same syntax as well to avoid fragmentation in the syntax highlighting landscape.

I unfortunately don't like it that much either, but it seems like this syntax (or variations of it) are an established thing already in a couple of examples I found:

• kramdown
• pandoc
• mayurankv/Obsidian-Code-Styler (which does its own thing with curly brackets, but also supports pandoc notation)

The main maintainer for Shiki had this discussion here and a couple of good points were made, including that nesting the curly brackets within the backticks themselves (`code{:js}`) is better than putting it outside `code`{:js} since the latter creates ambiguity within MDX files, and I believe the colon is there to help the parser discern between code snippets involving curly brackets. Some inline code parsers support VSCode token syntax like {:.entity.name.function} for arbitrary coloring based on a user-supplied VSCode theme's JSON.

That being said, I'm not sure yet how useful it actually is to highlight inline code. Do you have any real-world examples I could look at where inline highlighting is being used and looks helpful?

This feature itself is very, very uncommon--hence why supporting it would make documentation significantly more polished (especially in downstreams e.g. Starlight). These aren't considered "real-life examples" since they are documentation for already existing implementations of this feature (and or my own creations), but I hope you can see the appeal:

• From the rehype-pretty-code docs:
• From the mayurankv/Obsidian-Code-Styler docs:
• From my personal blogging template:
  
  

Inline syntax highlighting would be useful in these particular use cases, taken from the expressive-code docs itself:

The point of syntax highlighting itself is to help the human eye break up tokens into recognizable segments, which is especially true for longer segments e.g. the examples from the docs above. Hopefully this clears things up!

I found an example of this here https://rehype-pretty.pages.dev/.

I think it would probably be something people would want to be supported but default off? Not sure.

Also, I think personally that grey background only works when you don't have colour as that contrast doesn't look strong enough. So, there's things to think about I suppose.

Hi @hippotastic, is this in your pipeline/planned at all? I can attempt to take a look and send a PR if desired.

Hi @hippotastic, is this in your pipeline/planned at all? I can attempt to take a look and send a PR if desired.

Hi @jktrn, yes, basically every feature request I leave open is something I can imagine having in Expressive Code. I liked your idea and also gave your previous post outlining the idea in more detail a thumbs up. I just didn't get to it yet. :)

Thank you very much for offering to implement this! Before you attempt to do it, I'd like to come back to this point I mentioned in my first response:

I'd need to add support in the plugin API and all built-in plugins for it so that they can distinguish between block-level code processing and inline code processing. In inline code, most rendering features like frames, line numbers, collapsible blocks etc. would not be possible because no block-level tags are allowed.

In my opinion, getting this right in terms of the plugin API is the most crucial part of this feature request. We need to find a way to extend the existing plugin API so that plugins can somehow perform work on inline code as well, while making sure that all existing plugins (which are not aware of this new feature) don't get called on inline code while continuing to work as normal on regular code blocks.

You can take my existing plugins like frames, collapsible sections and line numbers as examples for your testing. Imagine that these were third-party code you cannot modify, and try to come up with an extension to the existing plugin API that adds inline code support without breaking these existing plugins. Without having to do any modifications to them, they should not get called on inline code, while your new version of @expressive-code/plugin-shiki should be able to declare somehow that it supports inline code. In its hooks, it also needs to have a way of recognizing if the code it's currently processing is inline code or a regular code block, in order to only process the special curly brace language suffix in inline code.

I'd be happy to discuss the API idea here first, but if you want to try something out first (or even already have an idea), feel free to risk it and and show a possible implementation in a PR right away. Either way, thanks again for your offer!

I've been looking to finding a solution for this as I agree it's a highly valuable feature.

Upon doing so, some initial testing shows that you can utilize expressive-code (for code blocks) alongside rehype-shiki or rehype-pretty-code (for inline code). The key is to ensure that expressive-code comes before the others in the list of rehype plugins.

The reason this appears to work is as follows:

1. EC will eliminate the language-* from the code block class names during its processing
2. EC will ignore any inline code blocks
3. Both rehype-shiki and rehype-pretty-code will ignore any code blocks where it cannot find a language-* class name

I have created a demo of using side-by-side, see example screenshots from the demo below.

There are a few drawbacks to this approach:

1. Depending on your EC theme, the theme used for inline blocks will be different
2. Even if your EC theme is a Shiki theme, you'll end up with multiple shiki highlighters. Both rehype-shiki and rehype-pretty-code support an option for providing a highlighter directly so if/when feat: add support for controlling bundle size #335 is merged, you would be able to utilize the same highlighter across both plugins you are using

Of course, having two code block processors isn't ideal and it would be preferrable to have one that handles both block code and inline code.

Along that line, I have submitted #336, would welcome any feedback/thoughts!

Demo Screenshots of using multiple plugins for inline code highlighting

Demo - Please be patient upon initial startup, may take a minute even after initial webpage displays.

Expressive Code Only

Expressive Code w/ Rehype-Shiki

Expressive Code w/ Rehype-Pretty-Code

@hippotastic Hi, there's a PR for this now! Any chance you can take a look?

Hello! We are moving feature requests and support questions to discussions and using issues only for bugs to help better track those going forward. See you in the Discussions tab!