:terminal scrolls if scrollback is full

[lf-]

• :ver:

NVIM v0.4.3
Build type: Release
LuaJIT 2.0.5
Compilation: /usr/bin/cc -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -O2 -DNDEBUG -DMIN_LOG_LEVEL=3 -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fdiagnostics-color=always -DINCLUDE_GE
NERATED_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.4.3/src -I/usr/include -I/build/neovim/src/build/src/nvim/auto -I/build/neovim/src/build/include
Compiled by builduser

Features: +acl +iconv +tui
See ":help feature-compile"

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/usr/share/nvim"

• vim -u DEFAULTS (version: 8.2) behaves differently?

Yes, vim pauses rendering new lines of input in its terminal buffers when you go into normal mode, but I assume this is because it has a very different implementation than Neovim.

• Operating system/version: Arch Linux
• Terminal name/version: mintty (wsltty)
• $TERM: xterm-256color

Steps to reproduce using nvim -u NORC

nvim -u NORC
:terminal
seq 100000
# then very quickly afterwards,
<C-\><C-n>
<C-b><C-b><C-b>

Actual behaviour

Cursor should stay on the same number.

Expected behaviour

The cursor is scrolled downwards as lines past 10000 are dropped.

[oblitum]

Other misbehavior I identified. When :term is first created, it's in normal mode, if then I create a :split to have the same new terminal buffer in two windows, and start to generate large enough output in the term through one of the windows, the other won't scroll. Meaning that new :term windows don't scroll content by default, unless you focus and enter insert mode in them at least once, then they'll always scroll on new content, even in normal mode.

[justinmk]

It's not really a bug, it's a side-effect of the fact that :terminal buffers in Nvim are real buffers, this means plugins can work with the contents at any time, using standard vim commands and functions... unlike Vim which has a separate API for terminal buffers. This makes it a bit tricky to "pause" the viewport if the buffer exceeds 'scrollback'.

But I agree it should not scroll if cursor isn't at end-of-buffer. We could switch to an "alternate" buffer with a copy of the "paused" scrollback (thus for scrollback=1000 the buffer would have 1000 lines).

[oblitum]

@justinmk any word on my previous comment? It's different behavior for normal, depending on whether the terminal buffer entered insert mode at least once or not, it just seems a bug, I can't see the reason for that.

[justinmk]

Not sure, but I :term text flow needs to be revisited in general. I have a plan just need time.

[oblitum]

@justinmk okay. For your information this is affecting some debugger interfaces where debugger/terminal windows are not scrolling because they're read-only and just receive output, they're never supposed to get into insert mode so that their scroll start to work.

[mortie]

I'm encountering the scrollback issues as well. It's pretty annoying. Would one solution be to just scroll up one line (and move the visual selection one line up) when a line is evicted from the scrollback buffer and the terminal is scrolled? Would be slightly hacky, but it should work, right?

[durka]

Is there a plan to fix this or a workaround?

[durka]

I guess one workaround is to just raise scrollback (or if you don't want to raise it, partially or fully clear it by setting it lower and then restoring to original value).