page
page copied to clipboard
Page keeps scrolling with journalctl
Hello,
I just installed latest git version of page
from AUR, it's truly fantastic, but I've noticed issue with journalctl
(I run it with PAGER=page journalctl
. I also tried to run page
with empty vimrc, like that
touch ~/min.vim
PAGER='page -c ~/min.vim' journalctl
but I could still observe the issue).
Problem is that nvim buffer starts scrolling on its own after few seconds. It cannot be stopped otherwise than exiting nvim, as far I can tell. Also page
seems to be eagerly loading whole output of the journalctl
, which can be costly. I couldn't find find switch to enable on-demand fetching more content akin to what less
is doing.
My installation:
[fenuks@fenuks fenuks]$ page --version
page 1.8.0
[fenuks@fenuks fenuks]$ nvim --version
NVIM v0.3.1
Build type: Release
LuaJIT 2.0.5
Compilation: /usr/bin/cc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -Wconversion -O2 -DNDEBUG -DMIN_LOG_LEVEL=3 -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fdiagnostics-color=auto -Wno-array-bounds -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -I/build/neovim/src/build/config -I/build/neovim/src/neovim-0.3.1/src -I/usr/include -I/build/neovim/src/build/src/nvim/auto -I/build/neovim/src/build/include
Compiled by builduser
Features: +acl +iconv +jemalloc +tui
See ":help feature-compile"
system vimrc file: "$VIM/sysinit.vim"
fall-back for $VIM: "/usr/share/nvim"
Run :checkhealth for more info
Hello, thank you for reporting this.
Page buffer start "scrolling" because journalctl
output is larger than 100000 lines which is limit for :term buffer and lines at the top just moved outside. Unfortunately, I cannot do anything with that (only request neovim developers to increase limit).
Option to read text on-demand would improve situation at least partially. Currently it's hard to figure out a proper implementation, but it definitely should be done
I see, that makes sense now.
Solution with increasing limit is more or less temporary, sooner or later someone might end with longer file. For instance, my journalctl
output starts from 21st September this year, so it is easy to imagine longer output, especially on server that runs 24h a day. It is possible to have infinite scrollback, for example KDE konsole terminal emulator have this feature (output as needed is saved in temporary file).
Reading on-demand could be a solution, but I understand that it is difficult to implement, given that nvim potentially should be few with new data in many, many cases (crossing boundaries of buffer, searching for string, etc.)
This issue prevents me from setting page as my system-wide pager, but it is nonetheless very useful for things like git aliases with custom output that vim don't know how to colourize. Thank you very much for this utility! :-)
Temporary solution is implemented in new version.
It's not very elegant, since requires querying for more text manually with :Page
command, and scrollback limit is not gone.
But at least it could prevent eager text loading and unwanted initial scrolling.
Thank you, -q
option works quite well, andpage
even displays information there is more content that can be loaded. :) With setting -q
limit to the 100 000, invocation of :Page
command causes window to scroll until next batch of data is loaded, but I suppose that's inevitable (remediation could be clearing terminal buffer if that's possible, and then loading new data, but that would only work reasonably when page
limit is the same as neovim terminal limit, in case of smaller ones that would cause unwanted effects).
Is -q 100000
works well for you? I've set it to 90000
, since long lines in :term buffer are splitted into two or more and it still causes scrolling sometimes.
But anyway, I really hope that neovim will provide option for unlimited scrollback which would resolve all of this sort of problems.
Yes, you are right. In case of journalctl most lines are thankfully within one line length limit.
I've seen your issue on neovim project, hopefully it will be resolved quickly. =)
Recent page version gained -z
option which will pagerize such large output into multiple buffers. It also could be paired with -q
for even better experience.