fix(latex): render unbraced greek sub/sup symbols#475
fix(latex): render unbraced greek sub/sup symbols#475tianbaiting wants to merge 1 commit intoOXY2DEV:mainfrom
Conversation
aab16de to
32c619f
Compare
There was a problem hiding this comment.
Pull request overview
Fixes Markview’s LaTeX preview rendering so unbraced Greek subscript/superscript forms (e.g. _\alpha, ^\alpha) resolve through the existing subscript/superscript glyph maps, avoiding raw-TeX fallback in previews.
Changes:
- Normalize unbraced sub/sup symbol lookups in the LaTeX renderer so
_\alpha/^\alphamap toₐ/ᵅ. - Derive parser fake-preview allowlists from
markview.symbols.subscripts/markview.symbols.superscriptsto reduce parser/renderer drift. - Add regression examples covering unbraced and braced Greek sub/sup usage.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
test/latex.md |
Adds regression examples for unbraced/braced Greek sub/superscripts and a mixed expression. |
lua/markview/renderers/latex.lua |
Normalizes unbraced sub/sup keys (e.g. strips leading \) before glyph-map lookup. |
lua/markview/parsers/latex.lua |
Generates supported “fake preview” command allowlists directly from the glyph maps. |
Comments suppressed due to low confidence (2)
lua/markview/parsers/latex.lua:327
supported_symbolsis rebuilt (including iterating + sorting) on every subscript capture. Sincemarkview.symbols.subscriptsis effectively static, consider computing/caching the command list once at module scope (or memoizing per map) to avoid repeated work during parsing large documents.
---@param range markview.parsed.range
latex.subscript = function (_, TSNode, text, range)
lua/markview/parsers/latex.lua:366
supported_symbolsis rebuilt (including iterating + sorting) on every superscript capture. Sincemarkview.symbols.superscriptsis effectively static, consider computing/caching the command list once at module scope (or memoizing per map) to reduce repeated work during parsing.
---@param range markview.parsed.range
latex.superscript = function (_, TSNode, text, range)
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
@tianbaiting Sir, did you actually read what the original code did? The whole reason a I also don't understand why you bothered adding a new function to check for supported symbols. You could've simply removed the original piece of code and it should've been enough. |
|
You're right — I expanded the fix too far and changed the intended role of SUPPORTED_SYMBOLS. The real bug is narrower: for unbraced forms like _\alpha / ^\alpha, the renderer strips _ / ^ but still keeps the leading backslash, so it looks up "\alpha" instead of "alpha" in symbols.subscripts / symbols.superscripts. |
|
@tianbaiting I have added direct support for symbols inside subscript/superscript(for some reason it is parsed differently to normal symbols). It should now fix all edge cases. |
Fixing this by itself isn't enough btw(cause the function needs to register a style region which is used for symbol lookup). But the commit I made also carries additional changes to make it work correctly. |
|
Thanks for the fix! And thanks for the explanation about the style-region registration and symbol lookup — that helped me understand the rendering pipeline better. I also realized that more complex subscripts like \mu_{\text{pair}} probably can't be rendered cleanly with Unicode alone, since there isn't a full set of subscript glyphs for arbitrary text. |
Summary
_\alphaand^\alpharesolve through the existing subscript/superscript glyph maps_\deltaand_\thetastill render as symbols instead of raw TeXmarkview.symbols.entriesto keep parser and renderer behavior alignedtest/latex.mdReproduction
Before this change, plain
\alpharendered correctly, but unbraced forms such asq_\alphaandq^\alphastayed as raw TeX in Markview preview. The same issue affected other greek symbol commands in unbraced sub/sup form.Verification
ₐfor_\alpha,δfor_\delta, andθfor_\thetaᵅfor^\alpha,ᵟfor^\delta, andᶿfor^\theta_{\alpha}and^{\alpha}still render correctly