Implement composer

[wenzhengjiang]

This is quite large PR containing below major changes:

1. Appending composer system prompt for copilot-plus mode.
2. Rendering composer markdown blocks by adding a note path title and the apply button.
3. Implement apply function by calling the composer apply endpoint and creating the Apply view.

[logancyang]

Awesome job 🔥 Congrats! 🎉

Some quick observations:

• The full path, details and the buttons in this top section look pretty big overall, might be better to make them smaller?
  

• After clicking "Apply", there's a noticeable lag before the diff view is opened. It's fine to have a lag but it would be a nice UX improvement to add a spinner on the Apply button so that it doesn't look like nothing is happening for a second after clicking it.

• When there's nothing accepted, I click "Apply Accepted Changes" it just closes the diff view without anything changed. This is reasonable function-wise but a bit awkward on the UX side - user might think it's "Apply All" or they didn't realize they didn't accept anything. Is it better to have an "Apply all / or accepted changes", if nothing is accepted explicitly, it just acts like "Apply all"; if anything accepted, it applies those. Open to other ideas.

• When there's only one diff block with Accept / Reject, is it better to make the block-level Accept / Reject act like the global ones and close the diff view? It seems unnecessary to click the top ones again for a single block.

WDYT? @wenzhengjiang

[zeroliu]

• user might think it's "Apply All" or they didn't realize they didn't accept anything. Is it better to have an "Apply all / or accepted changes", if nothing is accepted explicitly, it just acts like "Apply all"; if anything accepted, it applies those. Open to other ideas.

I was thinking the exact same thing when I first saw the demo. The UX of accepting diff has been pretty standardized. The same pattern has been used not only for the latest AI editing, but also has been like that since the git diff experience. I would highly recommend us to mimic a similar experience.

[wenzhengjiang]

Thanks for the good UX feedbacks!

• For the top section, I also plan to remove the status bar. I feel like it's not adding much value.
• For the top apply button, let me rename the "Apply Accepted Changes" button to "Apply changes"? And it will apply accepted or unselected changes.

When there's only one diff block with Accept / Reject, is it better to make the block-level Accept / Reject act like the global ones and close the diff view? It seems unnecessary to click the top ones again for a single block.

Or they could just click the top ones since there is only one block? Not sure we want to change the behavior of the buttons for this specific case.

[wenzhengjiang]

@logancyang @zeroliu I think I have addressed all your concerns. I'm pretty new to web frontend, so I could be still missing something...

Currently I'm using the default variant for accept/apply buttons and secondary variant for reject buttons. They look like below:

Open to making the green and red changes if you think they’re worth it.