Improve page mode

[rschmitt]

Is your feature request related to a problem? Please describe.

Various commands like TYPE, LIST, and DIR support the P flag, which causes output to emitted through a basic pager (basically a more clone). There are two issues with the pager:

1. It only scrolls down one screen at a time; it cannot page up or scroll line-by-line, as modern pagers can. It might not be possible to get all of the lines I want to see together on a single screen, even if they would physically fit.
2. Quitting page mode via Q causes the first two lines of output to scroll off the screen when the BASIC interpreter prints its READY prompt. This can defeat the use of handy shortcuts like / and ↑ that work with DIR output.

Describe the solution you'd like

All of the following would be useful to me:

1. Support for paging up, as well as down (perhaps with the left and right cursor keys)
2. Support for scrolling line-by-line (probably with the up and down cursor keys)
3. One of the following:
   1. Support for scrolling up past the start of the document, in order to bring the lines I need closer to the bottom of the screen.
   2. Rendering each screen with a two-line gutter at the bottom, so that all output is preserved upon quit.

Describe alternatives you've considered

Line ranges (like LIST supports) would address several of my use cases, since they can be used like head, or to view an arbitrary range of lines when the line numbers are known. To get the most out of this, the pager would probably need to support displaying line numbers, and then we would have two types of line numbers: physical line numbers, and logical/explicit line numbers for BASIC programs. So a souped-up pager seems like the cleaner solution.

[dansanderson]

The 2-line gutter is a good idea and would be easy to do, so quitting the page display doesn't scroll off the top lines.

Unfortunately the Unix-style pager interface that would be nice to have would be difficult to implement. There is no buffer holding the output in these cases: it's just pausing the execution of the command when the print cursor reaches the bottom of the screen, then resumes streaming the output on keypress.

In case you haven't discovered it yet, F9 and F11 are mapped by default to Ctrl-P and Ctrl-V, which can scroll BASIC code listings up and down one line at a time. Very useful, though also very specific to BASIC and not something that can be generalized. It is implemented by scanning the screen for something that looks like a line number, then scanning to that point in the BASIC program memory and listing the next or previous line, every time you press the key.

[rschmitt]

The 2-line gutter is a good idea and would be easy to do, so quitting the page display doesn't scroll off the top lines.

I'd like to work on this if you can grant me access to the repo.

[dansanderson]

Nice! Added you. You can attach git diff patches to this ticket. (Github doesn't support repo-forks or cross-repo PRs for private repos, alas.) Should be easy to find and mess with, let me know if you have questions.

A minor alternative to a 2-line gutter is to use the full display, but then just move the cursor up by a couple of lines when quitting. Clearing those lines might also be useful for typing, though tbh it would be in bounds with Commodore style to leave them dirty so they remain mostly visible but corrupted by the READY prompt.

[rschmitt]

Github doesn't support repo-forks for private repos

That should actually be something that can be trivially enabled through permissions: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/about-permissions-and-visibility-of-forks#about-permissions-for-creating-forks

[dansanderson]

Yeah we probably just need someone in an admin role to check the box. I don't personally have permission to enable forks on the mega65-rom repo, so I haven't been able to test what Github does. "Private forks inherit the permissions structure of the upstream repository" is probably sufficient for our needs, though we'd also need to confirm that contributors can have a role that allows forks but doesn't allow other writes to the repo. It'd make sense if the "read" role could fork a new private repo with inherited permissions, but I'd want us to test it and make sure we're comfortable with the result.

Separately, we need to set up compulsory contributor sign-off with compatible project licensing terms. The ROM is not open source licensed, and we need to make licensing rights explicit for contributions. SteerCo is discussing this right now.