Feature Request: optional splitting of view into scroll pane and static pane while scrolling

[tomaswindsor]

While scrolling, it is sometimes useful to see the current output (bottom of the view) at same time and even be able to type commands on prompt while seeing distant content in scrolled view without aborting the scrolling (e.g. to copy from long manual pages). In these situations it would help if (when enabled) scrolling would automatically split the view pane into two panes: static pane and scroll pane. Either with horizontal splitter (then static pane would be the bottom pane and scroll pane would be the upper pane) or vertically (then static pane would be the left pane and scroll pane would be the right pane). Scrolling would only take place in the scroll pane, static pane would always show the bottom lines of the view.

Proportion of the panes should be configurable e.g. by specifying the size of the static pane either in percents or in number of lines. Setting this to 0 or 0% would effectively disable this feature.

The splitter could be moved using drag'n'drop/keybindings as well. If typing on command prompt wouldn't abort scrolling in this mode (this could also be optional), there should be a button and keybinding to abort the scrolling (this abort scrolling command would be effectively same as move-scrollbar-to-bottom command).

The content of the scroll pane shouldn't move with additional content appearing in the terminal to allow user to read/copy the content without disruptions. (only the scrollbar would move in such case to reflect the change of position of the scroll pane in the whole scroll buffer).

[zadjii-msft]

I like this idea. It might require some extra technical difficulty - I'm not sure we can build a pair of TermControls that share a single Terminal instance, but it might be possible. The Terminal itself might need some re-working too - currently it only supports a single visible viewport, but there's not reason it couldn't have multiple.

I think the thing I'm having an extra hard time with is how we activate this split pane, and communicate it appropriately.

• Do we add a keybinding arg (Feature Request: Support arbitrary arguments for keybindings #1142) for splitting not with a particular profile, but instead as a view into the existing terminal?
• How do we identify that both these panes are the same terminal?
• What happens when you close the scrolling one or the static one - presumably the remaining one takes over as the primary?
• How does this interact with other panes? Is there anything special about this type of pane?

This might be better suited as an extension, though, with the Terminal changes we'd need to make, it'd probably require a lot of support internally.

[tomaswindsor]

• What happens when you close the scrolling one or the static one - presumably the remaining one takes over as the primary?

Closing of the scrolling pane will happen even automatically if you scroll to the bottom. So what happens when you close the scrolling pane (when you move the scrollbar to the bottom)? The scrolling pane will disappear and the static pane will be extended to occupy the entire area. If you close the static pane, it should perhaps remove both panes (as the scrolling pane can be seen as a sub-pane of the static one).

• How does this interact with other panes? Is there anything special about this type of pane?

It is special in a way that every scrolling pane will be tied with up to 1 static pane (0 if this feature is not used and then the normal pane simply becomes scrolling pane during scrolling as it is now).

[zadjii-msft]

This is very related to #644