VT extension to grab text output by named regions (blocks)

[christianparpart]

There is the idea by Terminal.Click to access the last executed commands output by a special mouse movements of the upper command's output region into the command, which seems to then inject the name of a temporary file.

Proper VT-way solution

Introduce a way to mark and name regions, and give a way to access the last N regions by that name to access its textual contents.

VT sequence	description
OSC 512 ; NAME ST	start a named region
OSC 512 ST	finish current region
OSC 513 ; NAME ST	request a named region as plain text (no control codes inlined except LF)

A requested region will be sent back to the application in chunks in the following form

OSC 514 ; name=NAME ; data=TextChunk ST

The end of input will be denoted with an empty data reply.

p.s.: OSC numbers may potentially change in the future. I just picked (hopefully not conflicting) random numbers.

Feature Detection

My first thought and suggestion would be to make that discoverable either via DA1, or via a DEC mode. The DEC mode would maybe have the possible advantage of being runtime configurable.

Application uses

A potential future shell (integration) could use that to mark CLI output that way, and have the possibility to retrieve that output back by the given names. If the user (given the shell would implement it like that) would then type grep foobar $OUTPUT{1} where $OUTPUT{1} would reflect the most recent completed command, the shell could pre-fetch that content, put it into a temporary file, and replace $OUTPUT{1} with the appropriate temporary file, to make it work with grep.

Positive side effects

This could also be the basis for #836, #1010.

[j4james]

Have you considered implementing the FinalTerm OSC 133 sequences for marking up the command output? If you search for FTCS_PROMPT in the iTerm2 docs, there's a nice description of the main options. There are already quite a few terminals that support them to some extent, and I think there might even be a shell that generates those markers by default (or at least has an option for it).

And if your terminal has that information (knowing which parts of the buffer are the prompt, the command, and the command output), then I think you probably already have the ability to replicate a lot of that Terminal.Click functionality.

I'm not sure why you want a sequence to grab text from the buffer, though. I would have thought you'd be adding this functionality in the terminal itself, which already has access to the entire buffer? But if you are going to implement something like that, note that some people consider escape sequences that can read the buffer to be a security risk, so it may be a good idea to have an option to disable that.

[christianparpart]

Hey @j4james. Thanks for reminding me. I knew about FinalTerm's ideas and OSC 133 to some extent, and then forgot about it. It is kind of odd though, that I introduced CSI > M to mark a line, that the user can jump to via key bind (or in vi-like normal mode, to select text within two markers, e.g. by Vim (m for mark) or [m and ]m to jump to prev and next mark.
That however was implemented very very early, and I'm totally open to deprecate that VT seq in favor of something either more well used (OSC 133?) or more well designed (idea above?).

I have to check more in depth to see if FinalTerm's VT extensions suffice for what I am aiming for (it's not just mimmicking terminal.click's idea, but also to mimic what Warp is doing with their blocks (#1010) and #836.

I'm not sure why you want a sequence to grab text from the buffer, though.
I would have thought you'd be adding this functionality in the terminal itself, which already has access to the entire buffer?
I want the shell (/app) to be able to reference a text block for further processing (e.g. to be piped into grep, and for that, it sadly needs access to it in a way, that it would also work when NOT being exclusively locally connected, e.g. ssh)
The one idea that Terminal.Click has is attaching command output to the commands in the command history. I'm not 100% fan of that (I guess one must like it), but I may see that people might want to have that, and I think it's the shells job to maintain the history the way they like it, and if they want to associate that with the command's output, I think they'd need access to it through VT seq.

But if you are going to implement something like that, note that some people consider escape sequences that can read the buffer to be a security risk, so it may be a good idea to have an option to disable that.

We're already having some kind of permission wall for features that some users might consider questionable (font face/size change via VT seq). Those things in Contour always default to "ask" (the TE is opening a popup to ask the user if he/she wants that action to be taken). The user may then act on it, or simply have it configured to be permanently allowed/denied.

I personally feel pretty safe with giving the user a choice of protection (as well as freedom) here.

Whenever I'm going to start working on it, I'll most likely start triggering a small discussion round in case I feel like we should divert from FinalTerm or similar. I'll keep you posted. ;)