Ability to scroll the REPL panel

[byorgey]

The user can scroll through their history using up/down, but perhaps it would be nice to allow scrolling the entire REPL itself, so they can actually look at what they did in context? I am not sure of the best way to do this (maybe with the mouse?).

[mateoatr]

What about Ctr+Shift+? I kind of expect it to work on terminals I use in Unix systems.

[byorgey]

Ah, good point. I often use Shift+PgUp/PgDown to scroll by pages. I guess Ctrl+Shift+Up/Down is sometimes used to scroll one line at a time? I have never used that and I didn't know about it until just now.

[xsebek]

After the refactoring of REPL history (in #253) is merged, this could be achieved by adding an offset to the latest line:

┌────────────────────────────────────────────────────┐
│ > "the 7th line entered"                           │
│ "the 7th line entered" : string                    │
│ > log "the 8th line entered"     // offset is 8    │
│ > log "current input, history is 42 lines long"    │
└────────────────────────────────────────────────────┘

Unless I am missing something this only requires adding Ctr+ Shift+ ?, the offset and generalizing getLatestREPLHistoryItems to respect the offset in drawREPL.

What do you think @byorgey, should I change it to ? 🙂

[byorgey]

A better way would probably be to render all of the REPL history into a scrollable Viewport and then let brick handle the scrolling. For example, see the way we handle the bottom-left info panel. This way the scroll amount doesn't depend on whether there are wrapped lines, multi-line inputs, etc.

It could get expensive to render the entire REPL history in memory when it gets large. We could have a (configurable?) limit to the amount you can scroll, just like most terminal apps.

[xsebek]

I do not see how it would be more expensive then what we do now, currently we have the whole history loaded in the memory so we could share it with brick. 😉

I am not sure if the Viewport is worth it - if we just keep a list of Widgets, then we can easily reuse those lines, for example to show history search results (#85) or keywords to select from with Tab completion (#207). While it would be nice to just let brick handle it, the power to do anything with the REPL is tempting too (for me at least, because I would not have to learn brick 😅 ).

As another though, if we add this history scrolling, then it would be nice to have a separating line above input with the " . . . " like in logger, so it would be obvious that the history is being scrolled.

[byorgey]

I do not see how it would be more expensive then what we do now, currently we have the whole history loaded in the memory so we could share it with brick.

Well, having brick render the entire history (and then only show a part of it) could be more expensive.

I am not sure if the Viewport is worth it - if we just keep a list of Widgets, then we can easily reuse those lines, for example to show history search results (#85) or keywords to select from with Tab completion (#207). While it would be nice to just let brick handle it, the power to do anything with the REPL is tempting too (for me at least, because I would not have to learn brick ).

You might be right, I don't know. We'll have to play with it.

As another though, if we add this history scrolling, then it would be nice to have a separating line above input with the " . . . " like in logger, so it would be obvious that the history is being scrolled.

Agreed. That is not hard to add.

[byorgey]

I also note that brick Viewports now support a scrollbar, which would fulfill the same purpose as the . . . line (probably better). I'd like to look into adding scrollbars in general.

[byorgey]

I think making a scrollable brick Viewport and adding a scrollbar (which we now have) is the way to go, with e.g. Shift-PgUp/Down to scroll. This video linked in another issue may be relevant as well: #629 (comment)

[xsebek]

@byorgey OK, I am convinced, let Viewports rule all! 👍

REPL is not as bad as messages, there will be fewer entries and they will not get appended while you scroll. But if we figure out how to do messages well, then REPL could also benefit from a slight speedup. 🙂