Conversation
Some addons write hex color tags with a doubled "#" prefix. Extended all three places that recognize <#rrggbb> to also accept <##rrggbb>: the live decoration engine (scanColorRuns), the color picker (DocumentColorProvider), and the static grammar fallback. The color picker also now preserves whichever of "#"/"##" the original tag used when a new color is picked, instead of always collapsing back to a single "#". Version bump: 1.0.4 -> 1.0.5.
scanColorRuns started each colored run at the tag's own position (match.index), so the literal tag characters (&c, <#5f0202>, etc.) got colored the same as the text that followed them - not just the text the tag is meant to style. This is invisible for a subtle legacy code, but very noticeable for hex tags with an extreme color: <#5f0202> (near-black dark red) made the 9-character tag markup itself nearly illegible against a dark theme, and <#fffb00> (near-white bright yellow) made it look like a glaring highlighted block - both reported as "colors are weird" from a real file. Real chat rendering never shows the tag as literal text either way (it's a control sequence consumed by the client), so only coloring what comes after it is both more correct and avoids this. Fixed by starting the run after the matched tag instead of at it.
…ects" This reverts commit 01ae7eb.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Summary
Two color-tag fixes:
<##rrggbb>support - some addons write hex color tags with a doubled#prefix. Extended all three places that recognize<#rrggbb>(the live decoration engine, the color picker, and the static grammar fallback) to also accept the doubled form. The color picker preserves whichever of#/##the original tag used when a new color is picked.Fixed "colors are weird" report -
scanColorRunscolored the tag's own literal characters (&c,<#5f0202>, etc.) the same as the text that followed, not just the text the tag actually styles. Barely noticeable for a subtle legacy code, but very visible for hex tags with an extreme color:<#5f0202>(near-black dark red) made the 9-character tag markup itself nearly illegible against a dark theme, and<#fffb00>(near-white bright yellow) made it look like a glaring highlighted block - reproduced directly from the reported file (anon.sk). Real chat rendering never shows the tag as literal text either way (it's a control sequence), so only coloring what comes after it is both more correct and fixes the look. Fixed by starting each colored run after the matched tag instead of at it.Version bump: 1.0.4 -> 1.0.5.
Test plan
npm run typechecknpm run build<#rrggbb>and<##rrggbb>detected correctly by the decoration engine and color picker#/##prefix<#5f0202>Ritual Table,<#fffb00>Ritual Craft) and confirmed the tag markup is no longer colored, only the following text&c&l...&r&7...cases still work correctly after the fix.vsix