Feature request: `bypassBlockCode` option

[jktrn]

Hello!

I was wondering if it were possible to add an option similar to bypassInlineCode, which skips inline code highlighting, but instead with <pre>-based code. This is for the (somewhat niche) use case when a user wishes to only utilize the inline syntax highlighting feature of rehype-pretty-code, but doesn't want their preferred <pre> code block parser to be overwritten by rehype-pretty-code.

[kelvindecosta]

Hey @jktrn, did you figure out a workaround for this?

I'm interested in setting this up alongside expressive-code.

[jktrn]

Hi @kelvindecosta I haven't found anything for this yet. Let me know if you find anything or if @o-az is interested in implementing this, although it seems this project has been unmaintained for a bit now.

[kelvindecosta]

Hey again @jktrn, I have found an unconventional way to achieve this.

If you're using pnpm or bun, you can use their patch functionality, letting you customize the contents of the node_modules/rehype-pretty-code package.

I only recently learned about this feature and it is a good workaround for the time being.

• Run pnpm patch rehype-pretty-code. In this case, pnpm instructs you to edit the files in a certain directory
• You can patch out the isBlockCode function to always return false instead. This should instruct the plugin to not process any block code elements.
• pnpm patch-commit <path/to/files> will then create a nice patches folder with the right changes.

This is a decent solution but can break if the patch can no longer be applied after, say, a version bump.

I've personally decided not to go with this approach since I can "live with" no syntax highlighting for the inline code elements.

Still, it is possible.

PS: Nice website! I hope a CTF expert like you can appreciate this rather hacky solution.

[jktrn]

@kelvindecosta,

Nice approach. I think in general the bypassBlockCode approach is hacky anyways since we're combining two separate code block implementations. I also wouldn't do any patches for now until we get word from the maintainer on whether this is planned.

If you haven't already, check out expressive-code/expressive-code#250. expressive-code is already interested in implementing inline code support, but it would be a bit nuanced to add since it has to:

• allow existing plugins to continue working normally with block-level code (without breaking changes),
• enable new plugins to explicitly declare support for inline code,
• and provide ways for plugins to distinguish between inline and block-level code processing.

[kelvindecosta]

Okay this is a bit insane, I didn't notice that you had commented on that issue too!
Thanks for sharing!