Feature: Make current zellij scrollback accessible

[har7an]

Hi,

I think it would be very handy if the current panes scrollback buffer could be made accessible via some command (i.e. from within the pane). I could image this to be used in such a manner that you can call a command, call it zellij scrollback for now, and it outputs your whole scrollback content (i.e. like echo). This would allow the user to:

• search/grep/modify the content to their liking (i.e. search patterns with grep, paginate through some very long outputs)
• Import the text into their favorite editor, e.g. via :r!zellij scrollback in vim

This would probably require zellij to be made aware of which tab/pane it is called from, so it can find and output the correct scrollback buffer. Once that is done, maybe an argument such as --range would be handy to limit the amount of text from the scrollback that is echoed.

Any thoughts on this?

[raphCode]

Related:
#1446
#1403
#1353

I think we are working on dumping the content to a file already, would this fit your use-case?

[har7an]

Well it's a start, for sure. I assume that it will involve pressing some arcane keybinding to perform the dump, right? I think it's not as elegant as dumping to stdout, but it will work of course.

[raphCode]

When I think about it, I personally prefer your proposal over some keybindings. As an added benefit, we can dump it to file very easily from a shell and even in the current working directory. :)

[a-kenji]

Anything that is bound to a key, is one or more actions.
Actions will be able to be called from the cli by #1265.

[imsnif]

I really like this idea. I agree with @a-kenji that it should be implemented as an action, but I think there's a bit more context here (eg. knowing which is the focused pane) as well as being able to do this in a convenient way. In another issue (#1402) I suggested implementing a zc command which holds all of this context and will give us a friendly UX for this: zc dump-screen | grep "foo" - will know in which session/tab/pane I am, and will translate dump-screen to the DumpScreen action.
Looks like we've got some leg work before we can implement this, but I'm very much looking forward to this being possible.

[a-kenji]

but I think there's a bit more context here (eg. knowing which is the focused pane) as well as being able to do this in a convenient way.

The actions do know which is the focused pane.

I think adding something like zellij command is a good idea however,
I think this shouldn't be hardcoded.
But we can put some good default behaviours in there.

[imsnif]

The actions do know which is the focused pane.

I hear what you're saying, but I think in this case that won't necessarily be the correct behavior. Eg. If I do:

> sleep 1000 && zc dump-screen | grep foo

Then change focus, it will give me the scrollback of another pane, which is not what I want.

[har7an]

Then change focus, it will give me the scrollback of another pane, which is not what I want.

Interesting use case... Would environment variables suffice? I mean panes are numbered, and so are tabs (at least from my user perspective). zc dump-screen (or what ever we will call it) could read something like a __ZELLIJ_TAB_ID and __ZELLIJ_PANE_ID and then tell the zellij session to go fetch the scrollback of that specific buffer? We can't keep the user from meddling with these env vars, but then again the user could also shred their PATH and why do that?

I think the env vars could also be used in scripting. If I have a fixed layout, I could write myself an alias to grab the last 100 lines of scrollback from tab __ZELLIJ_TAB_ID=IDE, pane __ZELLIJ_PANE_ID=make or something like that: __ZCDS_TARGET=IDE,make zc dump-screen. Opinions?

[raphCode]

Can't we just try to use the tty special file? This should be uniquely identifying and is hard to mess with:
readlink /proc/self/fd/0
ls -Li /proc/self/fd/0
Any of these should do.

[imsnif]

We could, but I think a much more trivial implementation would be to provide context to the command. We already know what pane is focused in our internal state.

[raphCode]

Maybe I am misunderstanding, but the original problem was that a sleep 10; zellj command may act on the wrong pane?
For this I suggested that the zellij command process looks at its tty file, sends it over to the main zellij process which then can match the correct pane to the tty file.

[a-kenji]

@raphCode,
If #1502 is implemented, we don't need an extra file descriptor, the sending of the action can have a different focus, as the user itself. Because they are two different clients.

[imsnif]

@a-kenji wouldn't we still have the same problem there though with the sleep example? The specific client is focused elsewhere once this command happens.

Honestly, I was just thinking of doing something along the lines of providing environment variables with relevant context (eg. ZELLIJ_SESSION_NAME, ZELLIJ_TAB_INDEX, ZELLIJ_PANE_INDEX).

EDIT: and now reading up I see this is what @har7an suggested :)

[a-kenji]

Not necessarily, since they could be independent from each other.

That being said have something like ZELLIJ_TAB_INDEX would be much nicer, since that would be a more declarative approach.

[imsnif]

Not necessarily, since they could be independent from each other.

I don't understand what you mean here...