Copying HTML-formatted output

[Eugeny]

Please consider adding an API to copy terminal contents as a HTML string.

[Tyriar]

@Eugeny does switching to the DOM renderer and copying the inner HTML of Terminal.element work?

[Eugeny]

It should, but with the webgl renderer coming up, it might make sense to have a frontend-independent API for that. What do you think?

[jerch]

I stumbled over this myself the other day when I tried to copy over a terminal page into a rich text editor (libreoffice). I kinda expected it to preserve the text attributes and the font (at least as monospaced), but it stripped all for any renderer. Maybe we need something like an optional rich text copy renderer?

[Tyriar]

When we added this to VS Code the feature really annoyed me and many other users, the reason being it replaced ctrl+c and almost always personally I was non-formatted text. While the copy action does copy both text, it will always paste the rich text one into editors that support it.

Downstream issue: microsoft/vscode#20813

[PerBothner]

@Tyriar: "While the copy action does copy both text, it will always paste the rich text one into editors that support it."

When I've pasted into LibreOffice, in the past it has asked me if I wanted rich test. When I tried right now, it didn't - perhaps it remembers my previous choice and pasted rich text.

DomTerm has a separate "CopyAsHtml" option, which creates html, but with the text/plain MIME type. That allows pasting the actual HTML - but it doesn't support easily pasting rich text.
One could have 3 separate actions "Copy (plain text)" (only text/plain), "Copy (rich text)" (text/plain and text/html). "Copy as HTML" (only text/plain). That may be too many options.

[PerBothner]

To be able to detach a terminal session, you need to be able to save (serialize) the terminal state in some fashion, and then restore it later. DomTerm saves the output as HTML, slightly cleaned up, along with JSON for other state. On a later attach, it re-creates the DOM (using innerHtml), followed by some re-initialization.

It is not sure that that HTML is the best serialization format for xterm.js's output state, but it does have some advantages.

[Eugeny]

@PerBothner it's not about serialization, it's about getting the content with the formatting included

[PerBothner]

@Eugeny: "it's not about serialization, it's about getting the content with the formatting included"

Of course. My point is that being able convert part or the whole the output buffer to HTML, could also be useful for serialization, and it might be useful to keep use-case in mind.

[starpit]

fwiw, copying the innerHTML from the DomRenderer view does not work when the content is taller than the viewport.

[XiaocongDong]

Is there any way to get all of the content of the terminal as a plain text?

[jerch]

@XiaocongDong Plain text is already possible via API with term.buffer.getLine(0).translateToString(true) (grabs first line in buffer right trimmed). For all lines iterate up to term.buffer.length.

[XiaocongDong]

@XiaocongDong Plain text is already possible via API with term.buffer.getLine(0).translateToString(true) (grabs first line in buffer right trimmed). For all lines iterate up to term.buffer.length.

Thanks jerch, another question on this term.buffer. Does this buffer have a limit? What happen if this buffer goes too large. Will some of the lines be removed? Thanks.

[jerch]

@XiaocongDong The line buffer is a circular buffer with a max size of scrollback + rows. Writes that require new lines beyond that limit recycle top lines (FIFO) and re-append them at the bottom with the new content. This circular behavior is important to know, as it leads to a "moving index" once that limit is hit (from content perspective).

[XiaocongDong]

Thanks @jerch , that just answers my question.

[Tyriar]

Current plan AFAIK is to enable supporting this eventually via an addon and the buffer API #2075

[Tyriar]

Opps, just duplicated this #3436

I don't think this meets the bar for a core feature and it aligns closely with what the serialize addon already does. Having the addon able to do this would enable embedders to route ctrl+c or a context menu to use it instead of regular copy.

[Eugeny]

In case anyone fancies extracting it into an addon, here's the code: https://github.com/Eugeny/tabby/blob/4f244a126c30181862ebd29bb41261394ad71bf9/tabby-terminal/src/frontends/xtermFrontend.ts#L335-L390

[jerch]

To some degree it does actually the same as the serialize addon, but for different output formats (and slightly different needs). While the serialize addon currently only supports "terminal escape sequence text format", imho it makes sense to transform the addon into a more general output format thingy, maybe also for HTML/Richtext formats. (We discussed that with the initial addon PR, but the idea back then was to keep the code slim and not bloat with hypothetical use cases.)

Further note, that all those serialize actions are in fact render actions, as they all would grab things a renderer has to push to the screen, but here instead into some data format. I am still a fan of the renderer API idea (wel thats mostly covered by the buffer API now, still I have to deal with several nasty private imports in the image addon for its image renderer). 😸

[Tyriar]

@Eugeny nice, btw I sent you an email

[Eugeny]

@Tyriar already answered, check your spam :)

[starpit]

fwiw, as part of Kui from the Kubernetes SIG-CLI, we have code that exports the xterm Buffer model to an XtermResponse model.

This includes squashing down contiguous cells with identical styling, and handling line wrapping.

[jerch]

@starpit Eww, your sameStyle function would have been a one-liner (2 uint32 mask & compare operations), if we would not try so hard to hide the internal buffer layout behind "convenience" (in fact creating inconvenience and a runtime penalty here) 😊

[starpit]

lol, yeah that was painful to write.

[Tyriar]

@jerch maybe we should just expose the raw fg/bg numbers and add some things to watch out for in the jsdoc

[jerch]

@Tyriar Yeah that would do. As long as the shape of fg/bg as a bit compound gets explained, ppl can use it. It has a small drawback though - if we ever reshape things internally, we'd have to provide those fields explicitly, prolly as getter. But thats not a biggy either.

[Tyriar]

Yeah one of the caveats I had in mind was compatibility across xterm.js versions is not guaranteed.

[Tyriar]

#3440