[FEATURE]: Laxtex rendering in opencode web ui #24426

Activity

1. mbrotos

   added

   discussionUsed for feature requests, proposals, ideas, etc. Open discussionUsed for feature requests, proposals, ideas, etc. Open discussion

   on Apr 26, 2026
2. github-actions

   assigned

   nexxeln

   on Apr 26, 2026
3. github-actions

   added

   webRelates to opencode on web / desktopRelates to opencode on web / desktop

   on Apr 26, 2026
4. github-actions commented on Apr 26, 2026

   

   github-actionsBot

   on Apr 26, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • [FEATURE]: Latex/Mathjax rendering in opencode desktop client #6293: [FEATURE]: Latex/Mathjax rendering in opencode desktop client (closed)
   • [FEATURE]: LaTeX rendering in TUI #11655: [FEATURE]: LaTeX rendering in TUI (closed)
   • [Feature Request] Latex Rendering #2041: [Feature Request] Latex Rendering (closed)
5. mbrotos commented on Apr 26, 2026

   

   mbrotos

   on Apr 26, 2026

   Author

   More actions

   A few implementation details from local validation that may help scope this:

   Current behavior in opencode web:

   • The app already bundles KaTeX and uses marked-katex-extension for markdown rendering.
   • However, the renderer currently handles $...$ and $$...$$, but not \(...\) and \[...\].
   • In practice, models often emit the escaped LaTeX delimiters, so users see raw math like \(\rho\) and \[ ... \] instead of rendered equations.

   Concrete repro in opencode web:

   A quantum state \( \rho \) gives an observable expectation by
   
   \[
   \langle O \rangle = \mathrm{Tr}(O\rho)
   \]

   Observed result:

   • \( \rho \) and \[ ... \] render as plain text.

   Relevant code paths:

   • packages/ui/src/context/marked.tsx
     • already uses marked-katex-extension
   • packages/ui/src/styles/index.css
     • already imports katex/dist/katex.min.css

   So this looks less like “add a renderer from scratch” and more like “normalize/accept the standard escaped LaTeX delimiters before markdown parsing”.

   Minimal implementation direction:

   • Normalize \(...\) -> $...$
   • Normalize \[...\] -> $$...$$
   • Do that before markdown parsing, while skipping inline code / fenced code blocks so code samples are not mutated.

   One extra note: the public share page renderer is a separate code path from the main app UI, so if this gets fixed in opencode web, it is worth checking whether the share page should be kept in sync too.
6. thdxr

   removed

   discussionUsed for feature requests, proposals, ideas, etc. Open discussionUsed for feature requests, proposals, ideas, etc. Open discussion

   webRelates to opencode on web / desktopRelates to opencode on web / desktop

   on May 3, 2026
7. x-at-01 commented on Jun 7, 2026

   

   x-at-01

   on Jun 7, 2026

   More actions

   If you are looking to improve math rendering in opencode web and support standard escaped LaTeX delimiters like \( and \[ without leaking into inline code blocks, you can consider using browser-native MathML Core.

   Since all major modern browser engines (Blink, WebKit, Gecko) natively support MathML, compiling LaTeX to standard <math> tags delegates all layout work to the browser's native C++ engine, completely eliminating the need for client-side JS layout calculations and heavy CSS/font assets.

   I wrote @webc.site/math (GitHub: https://github.com/webc-site/math, Live Demo: https://math.webc.site) — the world's smallest and fastest TeX-to-MathML compiler:

   • Size: Only 3.58 KB Gzipped (zero dependencies).
   • Speed: ~329,000 ops/s.

   You can also use its plugin @webc.site/math-marked (or configure a custom marked extension) to parse TeX. To support \(...\) and \[...\] delimiters safely before parsing (while skipping inline/fenced code blocks), you can implement a custom tokenizer/lexer or pre-normalize them.

   A simple pre-normalization function that skips code blocks (using regex to split code blocks from plain text) might look like:

   const normalizeDelimiters = (markdown) => {
     // Regex to split by fenced code blocks (```)
     const parts = markdown.split(/(```[\\s\\S]*?```)/g);
     return parts.map((part, index) => {
       // If it's a code block, leave it untouched
       if (index % 2 === 1) return part;
       // Otherwise, normalize \( ... \) and \[ ... \] to $ ... $ and $$ ... $$
       return part
         .replace(/\\\[([\\s\\S]*?)\\\]/g, '$$$$$1$$$$')
         .replace(/\\\(([\\s\\S]*?)\\\)/g, '$$$1$$');
     }).join('');
   };

   Applying this normalization before passing the markdown text to marked will cleanly resolve the delimiter issue without mutating any actual code samples.
8. github-actions commented on Aug 7, 2026

   

   github-actionsBot

   on Aug 7, 2026 – with GitHub Actions

   Contributor

   More actions

   To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
9. github-actions

   closed this as not plannedon Aug 7, 2026