Hey there! I'm interested in helping out with this, and I've gotten a very basic proof-of-concept version working locally: https://github.com/microsoft/terminal/compare/main...FuegoFro:windows_terminal:copy_with_control_sequences?expand=1

But before I keep working on it I wanted to check in on a few things:

• I see that this doesn't have the Help Wanted label, what does that mean regarding outside contributions?
• In the CONTRIBUTING.md it mentions that the Issue-Feature label indicates it likely requires a spec; does that hold true here, or does this seem like the kind of thing that could be worked out on a PR directly?
• Maybe this is just a different phrasing of the above, but what would be the best way to proceed here? Should I open an RFC/WIP PR for high-level feedback? Continue discussion here? Take a stab at a spec? Flesh out tests/docs/functionality on that branch?

I appreciate any and all guidance here! 🙏

(also as a side note, I just wanted to say how much I appreciate the docs and tooling here; I was able to go from "I've never worked with Windows-specific tooling" to "I have this up and running and can see the changes I've made" in a day, which is awesome 🎉)

Oh man, this is so cool! Thanks so much for working on it!

Absolutely -- we usually mark things "Help Wanted" if we think they'll be approachable for a community member. Getting down into the nitty-gritty of the text buffer usually isn't approachable.

In the time since you started working on that (maybe? I could be wrong!) @lhecker added a somewhat generic or genericizable function to TextBuffer that does the same thing. It's currently used for session save/restore. I wonder if y'all can converge!

I'm so glad you were able to get going¹ and I'm looking forward to your eventual PR 🙂

Ah amazing, thank you so much for the quick response!

That function is exactly what I wanted, so glad I can reuse it and not reimplement that all myself! 😅 Thanks for pointing me at it 😊

Given there wasn't mention of a spec in the above response, I've gone ahead and opened #17059 with an implementation that reuses the serialize function. Aside from a few questions I've left there, I think it should be ready for feedback!

If I may just offer some outside view on this.
First, I think allowing copy/paste with VT control sequences is a great idea, definitely something that should be supported in some way.
The goal of the clipboard is to provide as many formats as possible to enable as many copy/paste scenarios as possible.
The question really is only in which way...

VT being an in-band control in the text stream, copying it as CF_UNICODETEXT makes sense in several scenario, for example to copy formatted text to a script source file, or a code editor. We cannot expect all the editors to support a special clipboard format, so having the ability to copy them as CF_UNICODETEXT is required for those.
The problem is that there are also even more scenarios where we want to copy text without the control sequences, and the target application that doesn't know VT cannot provide a "paste as plain text" option since that precisely picks the CF_UNICODETEXT over a richer format. So copying with VT should be an option, not the default. We need CF_UNICODETEXT to contain plain text unless explicitly requested for all other apps to properly support "paste as plain text".
I think the default copy (right-click) should be text only, a modifier key (Shift, Ctrl, Alt) could be used to explicitly copy with the control sequences. Another solution could be for the right-click to always show a popup menu, which could also provide more discoverable options for paste, and maybe someday to insert special characters not easily accessible on the keyboard, or use a special item in the tab's menu.

Now on to the second solution, using a special ANSI/VT clipboard format. This would be a great solution for terminal-oriented apps that want to explicitly support these control sequences. I don't think this is an alternative to the CF_UNICODETEXT, the ANSI/VT format should always be copied. This means apps that can handle VT control sequences can always chose to process them regardless of how the text was copied from Terminal, and it also makes it explicit that that format contains VT, similarly to how RTF isn't an option but always copied alongside plain text.
Having that specific clipboard format always available when copying from Terminal would not make the "copy with VT in CF_UNICODETEXT" unnecessary, but would make it necessary only when the goal is to paste with the control sequences in a text editor or another app that isn't specifically terminal-oriented, making the extra operation to explicitly copy as "text with VT" less of a hassle as it would be required less often.

So to summarize, my ideal solution would be:

• Copying keeps plain-text (without VT) in CF_UNICODETEXT, alonside a "CF_UNICODEVT" format that contains the text+VT for apps explicitly requesting VT when available, just like it also copies as CF_RTF.
• A special "copy with VT" option to store the text+VT in both CF_UNICODETEXT and "CF_UNICODEVT" to enable copying it when needed to apps not designed for VT.

This makes the VT always available to apps that expect it, and enables advanced users/devs to copy with VT to apps that are not designed for it.

I would also add a CF_BITMAP version, containing a visual copy of the selection, making it much easier to do screenshot-like copy/paste in documentation about text-mode utilities. I'll be submitting an issue with that suggestion in more details.

On a related note, the Export text option should also allow the user to select plain text or VT text when saving the .txt file.

VT being an in-band control in the text stream, copying it as CF_UNICODETEXT makes sense in several scenario, for example to copy formatted text to a script source file, or a code editor.

The same can be said of HTML and RTF though. If we're going to support that for one format, we should support it for all of them.

@j4james I agree, and browsers have the Developer Tools to enable copy of HTML as CF_UNICODETEXT for advanced users, and always copy as a special HTML format for apps that look for it specifically because they can handle it. This makes the copy/paste experience between Edge and Word more advanced and convenient than plain text, and is exactly what I'm advocating for in Terminal.

Providing exports to HTML, RTF, and Bitmap from Terminal would make a lot of sense to improve the copy/paste scenarios with apps that do not handle VT.
And I don't think it would be very difficult to achieve, providing the font name, changing colors, and a few text attributes. It doesn't have to be perfect and map every single feature of VT, keeping the colors and some attributes would already be better than the plain text we currently have.
Having all those formats in the clipboard would make the life of users writing technical documents so much easier!