Render Markdown in task header

[cte]

Context

Implementation

Screenshots

before	after

How to Test

Get in Touch

---

Important

Render Markdown in task headers with support for mentions, code blocks, and Mermaid diagrams, including new mocks and refactored components.

• Behavior:
  • Render Markdown in task headers using MarkdownBlock in TaskHeader.tsx.
  • Supports mentions, code blocks, and Mermaid diagrams.
• Mocks:
  • Add mocks for mermaid, shiki, and unist-util-visit in src/__mocks__.
• Components:
  • Add MarkdownBlock in MarkdownBlock.tsx to render Markdown with optional plugins for mentions, code, and Mermaid.
  • Add MermaidBlock in MermaidBlock.tsx to render Mermaid diagrams.
  • Refactor CodeBlock in CodeBlock.tsx to support syntax highlighting and copy functionality.
• Styles:
  • Add styles for CodeBlock, MarkdownBlock, and MermaidBlock in respective .styles.ts files.
• Utilities:
  • Add rehype.tsx for custom Rehype plugins.
  • Add remark.ts for custom Remark plugins.
  • Add svgToPng.ts for converting SVG to PNG.

^{This description was created by for 35b7b73. You can customize this summary. It will automatically update as commits are pushed.}

[changeset-bot]

⚠️ No Changeset found

Latest commit: 35b7b73

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[ellipsis-dev]

The pull request introduces several changes across different areas, including:

• Refactoring and updating components to render markdown, code blocks, and mermaid diagrams.
• Adding new styled components and utilities for handling markdown and code rendering.
• Introducing new remark and rehype plugins for markdown processing.

While these changes are related to improving markdown rendering and UI components, it might be beneficial to split the pull request into smaller, more focused ones. This would allow for easier review and testing. Here are some suggestions for splitting:

1. UI Component Updates: Focus on changes related to updating the TaskHeader, CodeBlock, and MarkdownBlock components.
2. New Utilities and Plugins: Separate the introduction of new utilities like svgToPng and plugins in remark and rehype into another pull request.

This approach will help in isolating changes that can be reviewed and tested independently, ensuring a smoother integration process.

[sachasayan]

Okay, I have feelings about this one. What I'd really like Roo to do is spend a few tokens on a (hidden-to-user) one-sentence <summary> at every completion (and on first api response) and then make that the canonical heading, negating the need for code-formatting-in-header altogether.

It strikes me that perhaps the first full user message should appear in the chat stream — and that SHOULD be formatted.

Your thoughts, @cte ?

[cte]

Okay, I have feelings about this one. What I'd really like Roo to do is spend a few tokens on a (hidden-to-user) one-sentence <summary> at every completion (and on first api response) and then make that the canonical heading, negating the need for code-formatting-in-header altogether.

It strikes me that perhaps the first full user message should appear in the chat stream — and that SHOULD be formatted.

Your thoughts, @cte ?

Yeah, seems like a solid solution to me. Given the added complexity I probably won't have time to get to that soon. It's probably fine to punt on this though. I inject code snippets a lot from my editor so the current state of the task header looks less than ideal for a lot of my tasks.

[sachasayan]

@cte This is something I personally really want to prioritize, so I will try to get to it. If we can't make it work through the LLMs, I'll find another way to do it.

[cte]

We have an existing pattern for this kind of thing - check out the way "enhance prompt" works.

[dlab-anton]

@cte This is something I personally really want to prioritize, so I will try to get to it. If we can't make it work through the LLMs, I'll find another way to do it.

Interesting! I've thought about it too. I actually created this process for a RAG yesterday where it takes the first 50 words into a cheap model to create a project title. My biggest hesitation is costing users tokens. Also I have thought about the Roo summary system message being maybe not just a summary but nuanced to tell you what the goal was, or what was completed and pending (but again tokens $)

[sachasayan]

My biggest hesitation is costing users tokens.

At ~50 toks, it won't be much. We burn a lot more than that on other, more hidden things.

[mrubens]

There’s also a version where we ask the LLM to return a short task summary along with the first response. I have a branch for that somewhere.

[sachasayan]

There’s also a version where we ask the LLM to return a short task summary along with the first response. I have a branch for that somewhere.

Happy to work off of this if it's working / partially working and carry it to the finish line.