temporary paging mode

[muellerto]

Is your feature request related to a problem? Please describe. Sometimes I have many many files in a directory so that I need to use the pager. Then, after I checked the presence of some files or got their ELNs in the pager listing, I need an additional action: quit the pager because I can't use any commands while the pager is active. I can't then even select some files there. After leaving the pager I can run commands but I'm still in paging mode, the next upcoming listing will also be paged again. So I must also switch off this mode.

Describe the solution you'd like I would suggest to have a temporary paging mode, this means: do all ordinary paging but only for one cycle. When this paging cycle has been either ordinary completed or meanwhile aborted by q stop also the paging mode automatically. The temporary paging mode would require a separate command like pg (without parameters) or similar instead of pager on and pager off. I think this would be the typical way how I use the pager.

Yes, I saw the pager plugin on gg. This works almost as I would like it. I got it working even on my Windows machine. First I used bat as pager but the result was not colored and also not good in columns, less is much better in columns but also not colored. But I will probably use it. This plugin doesn't respect the view (long or short) the outer clifm instance currently has, it uses always the short view for the inner clifm.

Describe alternatives you've considered A much more elegant way would be to merge the vertical scrolling behavior the pager actually has into both the ordinary file views (long and short) to make them generally vertical scrollable whenever this is needed. OK, the cursor keys Up and Down would then collide with the prompt, different keys would be needed, you could use for instance PgUp and PgDn for this. This would then make the pager more or less obsolete. OK, this would be also a breaking change in the current philosophy. My temporary paging mode idea is much simpler and not breaking.

[muellerto]

I made now two simple aliases now, "pager long" and "pager short":

pl:    clifm --list-and-quit --no-clear-screen --no-bold --long | bat -p
ps:    clifm --list-and-quit --no-clear-screen --no-bold        | bat -p

This implements exactly my initial idea. In color! I'm a hero.

[muellerto]

Ha, a serious motivation for such a builtin temporary pager mode would be that this implementation would then immediately know all the settings defining the actual display, especially a file filter. The problem is that these external processes do not know anything about a filter or hidden files settings or sorting when these options differ from clifmrc. But they have massive impact on the ELNs.

[leo-arch]

Hi @muellerto.

I added a new option to the pg command: once, to run the pager only once. Since once is now the default parameter for this command, running just pg is like running pg once.

As to your pl/ps aliases, they work better than the gg plugin, showing both colors and columns (btw, using most instead of bat works as well). However, I do noticed that the number of columns in short mode is for some reason less than it should be when running ps.

[muellerto]

I added a new option to the pg command: once, to run the pager only once. Since once is now the default parameter for this command, running just pg is like running pg once.

Great! Your speed is breathtaking.

The advantage is that this implementation respects file filters, hidden file settings and sorting and keeps the ELNs still consistent. I will remove my aliases because of their dangerous problems with this (one wrong ELN used and an important file is deleted ...) After all this is a great improvement, really. I'm sure this pager once gets very popular. Thanks a lot.

There's still a minor thing: when pager once is aborted with q it still scrolls down until the end. I could imagine that people would scroll the pager view vertically to a concrete position and then press q just to keep this view exactly where it currently is. This would allow to use ELNs from there in the next command even if pager once is over. (This is something my aliases also didn't support at all.)

As to your pl/ps aliases, they work better than the gg plugin, showing both colors and columns (btw, using most instead of bat works as well). However, I do noticed that the number of columns in short mode is for some reason less than it should be when running ps.

Yes, I saw this too. The use of column is also not without similar problems in this aspect. I guess these inner processes have somehow a different imagination about the window size.

[muellerto]

BTW: There seems to be indeed no possibility to scroll upwards in Windows. Didn't check this on Linux until now. The relevant paragraph in the PDF file is:

Once in the pager, press the Down arrow key, Space or Enter to move downwards one line, or PageDown to move downwards an entire page. To go upwards, use the shortcuts provided by your terminal emulator, for example, Alt-PageUp or Alt-Up. Press ´c´, ´p´, or ´q´ keys to stop the pager, and ´h´ or ´?´ for help.

The keys c, p, q, ?, h do work, PgDn also. But then it gets complicated: PgUp behaves like PgDn and scrolls downwards. Alt-Up does nothing, Alt-PgUp is like PgDn. The help says:

?, h: help Down arrow, Enter, Space: Advance one line Page Down: Advance one page q: Stop pagging

An u would be good, if the Up arrow key is not possible, or the vi-keys j and k. Also Home and End.

[muellerto]

Found a workaround: when you want to scroll up in the pager you can press h h. This opens the help screen and closes it immediately. But after that the pager stands again on line 1 and is still working.

[leo-arch]

There's still a minor thing: when pager once is aborted with q it still scrolls down until the end.

Modified to stop listing after pressing q while paging.

There seems to be indeed no possibility to scroll upwards in Windows. Didn't check this on Linux until now

Upwards scrolling is just not implemented, simple because our pager does no buffering: it just prints line after line and stops when required. This is why this feature is relegated to whatever your terminal emulator has to offer (for example, mouse scrolling or some specific keybinding).

[leo-arch]

Found a workaround: when you want to scroll up in the pager you can press h h. This opens the help screen and closes it immediately.

According to my tests, the pager help screen is broken: after going back from the pager help, long file names are not trimmed down at all, which breaks columns (probably broken since a long time ago).

EDIT: Bug fixed.

[muellerto]

There's still a minor thing: when pager once is aborted with q it still scrolls down until the end.

Modified to stop listing after pressing q while paging.

Yeah. Best pager ever!

I still saw the following: When I have the pager showing files in the long view beginning on ELN 65 and I press q the display stays finally beginning on ELN 68. The first 3 lines are gone because on the bottom appears the prompt. Note: the size of this difference is not constant. It depends for instance on PrintSelFiles and MaxPrintSelFiles.

[leo-arch]

Yeah. Best pager ever!

Great! Btw, I reassigned c (standing for continue) to perform the old behavior: stop paging and list remaining files (unlike q, which stops paging without listing remaining files).

When I have the pager showing files in the long view beginning on ELN 65 and I press q the display stays finally beginning on ELN 68.

Well, I think this is rather the expected behavior. When you press q the pager stops exactly in the last listed file name, and then gives control to the prompt, which of course takes some space, hiding thus some files at the top of the list.

[muellerto]

When I have the pager showing files in the long view beginning on ELN 65 and I press q the display stays finally beginning on ELN 68.

Well, I think this is rather the expected behavior.

I pointed on this because my expectation was different :) Smells like an option, "PreferredRowInPager" with the values "first" or "last". But I see, it's no so easy. When the first row of the pager should really stay on it's place you have a lot to calculate on the bottom and you can then not just write forward at the end, you must then overwrite some rows.

BTW: There could also be another option: "PagerView" with the values "short" or "long" or "automatic" (which should be the default). This option could make the pager start always in the short or the long view, independent from the current file listing. Since the pager is a tool mostly used to find out ELNs for the next command it could be an advantage to see as many files as you can have on the screen. Mostly I have the long view in the listing, but I could imagine to become a friend of the short view in the pager.

[leo-arch]

PagerView: Done. Please give it a try. Options are PagerView (config file) and --pager-view (command line). Possible values: auto (default), long, and short.

PreferredRowInPager: At least for the time being, this won't be implemented. Why not? Prompt stuff (more generally, whatever is printed after the files list) is highly dynamic and even unpredictable. In order to know how much space all this will take, we need to calculate (the list is not exhaustive, but is enough to make my point):

1. Prompt lines. Though this depends on the prompt line (which is customizable) and the length of the current directory (which is dynamic), this can be calculated.
2. Extra stuff like selected files (if PrintSelfiles is set, which besides depends on the value of this option), disk-usage (if DiskUsage is set), DirhistMap, if set, and other program messages. All this might be calculated, but it's not that easy.
3. Prompt commands: this (same thing if the prompt line includes shell commands) is the real hurdle. In order to find out how many lines will a shell command take, we need to run it, redirect output, and count lines. The problem is not only that this is quite expensive, but that the output might totally change between the first run (when we count output lines) and the second (actual) run (nothing prevents the user indeed from generating random output -say, some variable-length ASCII art message- each time the command is executed).

Because of the above, we can have at most a half-working feature; but, as I see it, a half-working feature (even if working most of the time) is a broken feature, and a broken feature (and note that I'm not saying buggy, but broken by design) should not be implemented at all.

I still believe that the best way to handle this issue is using whatever mechanism is provided by your terminal emulator to scroll lines up.

[muellerto]

Thanks a lot for all the work with this PagerView option. Works good as far as I can see. Have it always short now.

The rows issue: I understand all that and can imagine how complicated it could get. And when you start to implement something you see even three more problems. Indeed the user can use a vertical scroll bar on the window to scroll up if this is needed. OK.

I close the case.