:set list has no effect in a :terminal buffer

[joshtriplett]

• nvim --version:

NVIM v0.1.5-642-g2dd9f33
Build type: None
Compilation: /usr/lib/ccache/cc -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DDISABLE_LOG -Wconversion -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1  -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wvla -fstack-protector-strong -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -DHAVE_CONFIG_H -D_GNU_SOURCE -I/tmp/neovim/build/config -I/tmp/neovim/src -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/tmp/neovim/build/src/nvim/auto -I/tmp/neovim/build/include
Compiled by josh@x

Optional features included (+) or not (-): +acl   +iconv    +jemalloc +tui      
For differences from Vim, see :help vim-differences

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

• Vim behaves differently? N/A, vim doesn't have :terminal
• Operating system/version: Debian GNU/Linux, latest unstable
• Terminal name/version: gnome-terminal 3.20.2
• $TERM: xterm-256color

Actual behaviour

In a :terminal window, :set list has no effect; for instance, tab characters do not display the visible characters defined in listchars.

Expected behaviour

:set list works in a :terminal just as it does in any other vim buffer.

Steps to reproduce using nvim -u NORC

nvim -u NORC
:set listchars=tab:>-
:terminal
/usr/bin/printf "abc\tdef"
<C-\><C-n>
:set list

[ZyX-I]

There are no tab characters at all because they must be processed by libvterm and converted to spaces. Characters must be processed by libvterm because it must know tab width. Also tab width must not depend on &ts value because in terminal it is fixed and equal to 8.

[justinmk]

:setlocal list listchars+=space:x

shows x's where spaces appear, in :terminal. So 'list' works.

As @ZyX-I mentioned, :terminal can't control what data is received by the underlying terminal implementation, where layout is driven by a grid of characters, and some information about the source is lost.

This is just like when you select 'listchars+=tab:>' text in gnome-terminal or iTerm2, and your clipboard has literal > characters: gnome-terminal and iTerm2 can't know that the > is semantically a tab. They only see the final representation. Same with :terminal.

[joshtriplett]

A terminal is capable of knowing the difference between a tab and the corresponding number of spaces. gnome-terminal does, for instance. Try running the command:

printf 'this has\ta tab\nthis has        spaces\n'

in gnome-terminal, and then slowly selecting character-by-character using the mouse. Notice that the tab gets selected or unselected as a unit, while you can select the spaces one-by-one.

[justinmk]

@joshtriplett You're right, and that also works on iTerm2 and Terminal.app. Though not if tmux 1.8 handles it before it reaches the host terminal, AFAICT. What's the tmux behavior for you?

In the case of :terminal, "the terminal" is libvterm. AFAIK by the time the <tab> reaches nvim, it has been "rasterized" as a series of spaces. Perhaps @leonerd can correct me: is there a way for nvim to know if a series of cells corresponds to a tab character?

[leonerd]

Indeed. The handling of a horizontal tab character is done by the state layer in libvterm, and by the time it has reached the screen layer (the 2D grid of cells that nvim reads from) it has forgotten why the movement happened.