You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a tool call , if mermaid ai , or any flowchart , decision tree and more can be rendered it would be better.
Vizual flows are better understandable for some query or in use cases where text highlights low value
I’d suggest starting with a narrow first step: render fenced mermaid blocks in Markdown file previews, as well as standalone .mmd and .mermaid files. A Render/Source toggle would keep the text accessible, with a source fallback when a diagram cannot be rendered. I wouldn’t try to detect Mermaid inside arbitrary .txt files yet.
Mermaid Tiny looks worth evaluating for this scope. It’s the official MIT-licensed build, roughly half the size of full Mermaid, and omits the sizeable ELK layout engine and features we don’t need for an initial version. We could pin and serve it locally so previews work offline, then load the script only when a diagram is present. Before committing to it, I’d check the actual compressed bundle impact and the licenses/notices of code bundled inside Tiny. Its unsupported diagram types should remain visible as source rather than failing silently.
why start with a narrow mermaid library when you can just implement it correctly? this should be easy to do correctly without complexity. a contribution may be accepted, but i've closed the existing one for quality.
putting effort to this means:
every standard feature a model would possibly think to emit
ive heard of great things about https://github.com/obsidianmd/pele. that would be where i start, and just do a lot of tuning so it feels good in Orx. forgot to add the contributor friendly label
I tried Pele against an isolated prototype: fenced Mermaid and standalone .mmd files render, with source fallback, and rendering can run in a terminable worker. Pele documents support for the Mermaid 12.1 built-in diagram types, though I have only tested a subset so far.
There are two behavior choices before this would meet the desired coverage. Pele leaves $$...$$ labels as TeX unless the app supplies a math renderer, so the prototype does not yet render those formulas. Also, Pele allows external image URLs by default; I disabled images and links in the prototype because diagrams can come from project files or agent output and rendering an image would make a network request. This protects the local-only behavior but omits a Mermaid feature.
Would an explicit user action to load external diagram images, with formulas rendered locally and links handled under the existing navigation policy, be an acceptable direction? I haven't submitted a PR or validated full feature coverage; the image behavior is a product/privacy decision rather than something the prototype should silently choose.
@dajiaohuang privacy first , local first is intended and one which can be rendered via llm , agent , harness . it can be like a tool which agents can use to render . external links are not expected a clean render for a) formula b) diagrams c) flowcharts d) UML diagrams must be cleanly visible in chat view and must persist.
More feedback can be provided from the maintainer ...
Activity
Rexarrior commentedon Sep 24, 2026
I’d suggest starting with a narrow first step: render fenced
mermaidblocks in Markdown file previews, as well as standalone.mmdand.mermaidfiles. A Render/Source toggle would keep the text accessible, with a source fallback when a diagram cannot be rendered. I wouldn’t try to detect Mermaid inside arbitrary.txtfiles yet.Mermaid Tiny looks worth evaluating for this scope. It’s the official MIT-licensed build, roughly half the size of full Mermaid, and omits the sizeable ELK layout engine and features we don’t need for an initial version. We could pin and serve it locally so previews work offline, then load the script only when a diagram is present. Before committing to it, I’d check the actual compressed bundle impact and the licenses/notices of code bundled inside Tiny. Its unsupported diagram types should remain visible as source rather than failing silently.
small-angel commentedon Oct 29, 2026
why start with a narrow mermaid library when you can just implement it correctly? this should be easy to do correctly without complexity. a contribution may be accepted, but i've closed the existing one for quality.
putting effort to this means:
Yash-2003P commentedon Oct 30, 2026
@paperclover Thanks , from a feedback . I too thought same . If you can work on it I would be happy.
small-angel commentedon Oct 30, 2026
ive heard of great things about https://github.com/obsidianmd/pele. that would be where i start, and just do a lot of tuning so it feels good in Orx. forgot to add the contributor friendly label
dajiaohuang commentedon Nov 4, 2026
I tried Pele against an isolated prototype: fenced Mermaid and standalone
.mmdfiles render, with source fallback, and rendering can run in a terminable worker. Pele documents support for the Mermaid 12.1 built-in diagram types, though I have only tested a subset so far.There are two behavior choices before this would meet the desired coverage. Pele leaves
$$...$$labels as TeX unless the app supplies a math renderer, so the prototype does not yet render those formulas. Also, Pele allows external image URLs by default; I disabled images and links in the prototype because diagrams can come from project files or agent output and rendering an image would make a network request. This protects the local-only behavior but omits a Mermaid feature.Would an explicit user action to load external diagram images, with formulas rendered locally and links handled under the existing navigation policy, be an acceptable direction? I haven't submitted a PR or validated full feature coverage; the image behavior is a product/privacy decision rather than something the prototype should silently choose.
Yash-2003P commentedon Nov 4, 2026
@dajiaohuang privacy first , local first is intended and one which can be rendered via llm , agent , harness . it can be like a tool which agents can use to render . external links are not expected a clean render for a) formula b) diagrams c) flowcharts d) UML diagrams must be cleanly visible in chat view and must persist.
More feedback can be provided from the maintainer ...
small-angel commentedon Nov 4, 2026
things which i believe are common sense choices:
(this applies to the entire app, if the behavior is not currently this we should make it this)
[-]Feature Request: Add mermaid ai , tool call for diagram , flowcharts[/-][+]Support mermaid diagrams[/+]