Syntax highlighting documentation updates. #277
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Proposed for your consideration. Two things are addressed in here. First is a function to strip all hljs-* spans from existing code when editing with rhino. This allows CodeBlockLowlight to then properly re- parse the code blocks for highlighting. Without this, the spans do appear in the editor's highlighted code blocks, but some newlines are missing. The missing newlines will be when they are at the end of a line with only whitespace after them. Those newlines get lost in processing if these spans are not first stripped. Second is for DB storage, decoding the code content before we re- process it for storage. Without decoding first, some HTML entities will get double-encoded. I also changed the #highlightCodeblocks function to no longer track highlighting with a has-highlighted HTML attribute. In my testing this was leading to the JS sometimes skipping highlighting upon DB storage. I'm not sure why this tracking existed before, whether it was inadvertent double-execution of this function or if it related to not removing spans before reprocessing edited code, which we now do in #stripHljsSpans. I don't _think_ it's necessary, but I could find out I'm wrong. I adapted this documentation from our Pika.page code. Apologies for any typos/mistakes!
|
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
KonnorRogers
approved these changes
Apr 29, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Proposed for your consideration. Two things are addressed in here.
First is a function to strip all hljs-* spans from existing code when editing with rhino. This allows CodeBlockLowlight to then properly re- parse the code blocks for highlighting. Without this, the spans do appear in the editor's highlighted code blocks, but some newlines are missing. The missing newlines will be when they are at the end of a line with only whitespace after them. Those newlines get lost in processing if these spans are not first stripped.
Second is for DB storage, decoding the code content before we re- process it for storage. Without decoding first, some HTML entities will get double-encoded.
I also changed the #highlightCodeblocks function to no longer track highlighting with a has-highlighted HTML attribute. In my testing this was leading to the JS sometimes skipping highlighting upon DB storage. I'm not sure why this tracking existed before, whether it was inadvertent double-execution of this function or if it related to not removing spans before reprocessing edited code, which we now do in #stripHljsSpans. I don't think it's necessary, but I could find out I'm wrong.
I adapted this documentation from our Pika.page code. Apologies for any typos/mistakes!