Session Resume to restore grid buffer

[christianparpart]

trafficstars

on terminal exit we could store the grid buffer contents and if this session is to be resumed the grid buffer (including scrollback) could be restored.

we should remember & restore:

• grid buffer (including scrollback)
• path to config file
• active profile

it should be possible to disable this session-restore feature via config file setting (per profile or global?)

[Utkarsh-khambra]

Hi @christianparpart I am thinking of working on it. But I am not sure in which format should data be dumped in the file. What do you suggest.

[christianparpart]

Hey @Utkarsh-khambra.

That sounds like amazing.

The following structs/classes are of interest:

• [ ] Cell (single grid cell, also have a look at CellExtra).
• [ ] TriviallyStyledLineBuffer (this struct most likely will get its name changed to (suggestions welcome).
• [ ] Line<Cell> (holds line flags plus line buffer, which is either a vector<Cell> or a TriviallyStyledLineBuffer from above)
• [ ] Grid<Cell> (internally holding a ring<> over Line<Cell>)

the serialized state should bestored in $XDG_STATE_HOME/contour/session (e.g. ~/.local/state/contour/session - the sub-dir session because this sub-dir is also used for other state dumps. See crispy::App::localStateDir() in src/crispy/App.cpp.

Thanks for reminding me that I should document more APIs.

Mind, that I just (past 24 hours) have been merging a PR that was far exceeding the initial purpose (sorry) but it contains a major structural change related to grid line buffer management.

Naively, a grid line is just a vector<Cell>, and it still is by default for full support of all VT sequences. But mind the general case of the primary grid buffer where you occasionally have one or two lines for the command prompt (non-trivially VT sequences used to construct those lines) and then a couple of until thousands++ of lines of (what I call it...) "trivial" text.

trivial text is defined as text that is written to stdout without any SGR (graphics attributes) change in between and without(!) any VT sequences changing the contents of that line after creation. Those lines are called "trivial" therefore and can be held in a special data structure TriviallyStyledLineBuffer where no memcpy or any other special manipulation is needed to construct the such a line in the grid.

For the actual serialization/de-serialization, I think it doesn't have to be rocket science, in fact, the grid can be serialized back into a conforming sequence of text plus VT sequences and control codes and simply writing to a fresh terminal instance will then restore the old state therefore.

I think we can reuse some existing facility here even (VTWriter, which is currently used for creating text/VT screenshots when dumping the internal state (OSC 888 ST). I can polish the latter API and move it into the public ASAP.

[christianparpart]

p.s.: I just remembered after having hit Submit that Qt itself comes with a session manager, so we should reallize use this (I have no experience with that yet, I admit). so we don't need to use the above mentioned XDG dir but read from / write to what Qt provides us as source location. This will be probably more platform independant.

[christianparpart]

@Utkarsh-khambra is there anything else unclear? Can I help you in any case on that?

I can also join IRC if you tell me how to find you. Or any other IM-protocol.

[Utkarsh-khambra]

Sorry I didn't replied to you earlier. As you suggested I used VTWriter, to dump lines in a file. Currently I am trying to parse those lines back to Line<Cell>. I was thinking if there is any function to convert VTSequencs -> Line<Cell> or I should write one.

I am already in discord. I'll just log back in.

[christianparpart]

@Utkarsh-khambra create a draft-PR so I can early-review and give early feedback.

You don't need to reconstruct the Line's yourself. just write to the terminal, e.g. via Terminal.writeToScreen(string_view)

[christianparpart]

NB: #650 contains a fix to Terminal::writeToScreen() that should make it work for you too. I'll be merging it tonight.

[whisperity]

Okay, so how would this work? Contour reloads the "image" from disk and restores the buffer, but spawns a new shell underneath from scratch (i.e. default config set in the profile, spawned in ~, etc?).

How would this feature interact with running multiple terminals? Would the save be per-profile for global for the user?

Let's suppose

1. I start master profile and use for editing
2. I start another master profile, same config, but use that for building. Would I get the contents of the edit terminal, or an empty one?
3. I close the terminals in this order
4. I start a new terminal from the same profile. Will I get back the buffer of 1) or 2)?
5. I start another terminal. Now because 4) has consumed the save... so I should get a brand new shell?

"Terminal exit" means the closing of every shell, right? Or only during shutdown, like KDE's system restore? What happens in case of multiple contour binaries are running, and are to be respawned?

I found in KDE where I can disable respawning the contour binary, but it would be worthwhile to have this configurable from within Contour itself...