Open christianparpart opened 1 year ago
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.
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. ;)
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.
OSC 512 ; NAME ST
OSC 512 ST
OSC 513 ; NAME ST
A requested region will be sent back to the application in chunks in the following form
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 withgrep
.Positive side effects
This could also be the basis for #836, #1010.