Neovim TUI will be broken when used inside DevPod container

[AnhQuanTrl]

What happened?
When using Neovim as described in Quickstart Neovim page, Neovim will behave weirdly with broken scrolling with split buffers. I have created an issue to the neovim team: Issue. It seems that this issue is exclusive to DevPod due to the way it uses ProxyCommand when ssh-ing to the DevPod container.
Things that I and the people inside the neovim issue have tried:

• Set TERM variable inside the container to xterm or alacritty or xterm-256color and install the appropriate terminal info -> This does not solve the issue.
• Try using docker container exec -it containername bash directly -> This worked.
• Try running tmux inside the container before using neovim -> Weirdly this worked?!

What did you expect to happen instead?
Neovim should behave normally inside devpod ssh just like when used directly inside container's shell.

How can we reproduce the bug? (as minimally and precisely as possible)

1. Create a minimal devcontainer.json that contains an ubuntu container.
2. Install neovim inside the container, either directly or by using devcontainer features.
3. Try using neovim and open multiple buffers. Scrolling on one buffer will break the other buffers.

Local Environment:

• DevPod Version: 0.5.18
• Operating System: Mac and Linux
• ARCH of the OS: AMD64 and ARM64

DevPod Provider:

• Local/remote provider: docker

Anything else we need to know?

[pascalbreuninger]

Hey @AnhQuanTrl, thanks for reporting the issue! I can reproduce it on my side as well and will take a look at it 👍

[alanfzf]

Wow this issue was driving me mad, glad i found your report @AnhQuanTrl , i would like to share some workarounds i found these past few weeks:

As of now we know this bug occurs when we try to use a $TERM which has true color support, but there's some exceptions.

1. Foot and wayland

If by any chance you are running wayland, and use the foot terminal, the neovim TUI is not SO broken, you will get some rendering issues, here and there, but its doable. You can ejoy true color support on neovim trough ssh, BUT you still need to lunch tmux session with the following config:

set-option -ga terminal-overrides ",foot:RGB"

Note

In my experience you don't actually need to run tmux inside the container, you can run it on your host machine and the effect will be the same.

2. Headless neovim instance
   Other work around which i don't really like is running a headless neovim instance in the container, you can achieve this trough adding a bash script in your container and configuring you devcontainer.json like this:

#!/bin/bash
# this sleep is required, if you want nvim to take into account your dotfiles as they get cloned after the postStartCommand
sleep 40

while true; do
    nvim --headless --listen 0.0.0.0:6666
    exit_code=$?

    # If the exit code is non-zero, break the loop
    if [ $exit_code -ne 0 ]; then
        echo "SSH command exited with a non-zero status: $exit_code"
        break
    fi

    sleep 1
done

{
  "name": "DevPods",
  "dockerComposeFile": ["../../docker-compose.yml"],
  "service": "laravel",
  "postStartCommand": "nohup bash -c \"/opt/scripts/entry-nvim.sh > /opt/scripts/entry-nvim.log 2>&1 &\""
}

finally you connect with the following command:

nvim --server localhost:6666 --remote-ui

Note

For this to work you also need to forward the 6666 port.

In conclusion too complicated and not really worth it.

3. Devcontainer cli
   The most "realiable" solution sigh, we can mimic some of the devpod behavior with the devcontainer cli, but you still need to manage the installation of your dotfiles, and for ssh you need a user with a password to access the container. But hey! at least no TUI rendering issues.

simple example of the devcontainer.json file

{
  "name": "DevPods",
  "dockerComposeFile": ["../../docker-compose.yml"],
  "service": "laravel",
  "workspaceFolder": "/var/www/marco-regulatorio",
  "features": {
    "ghcr.io/alanfzf/features/bat:1.0.2": {},
    "ghcr.io/alanfzf/features/neovim:1.0.1": {},
    "ghcr.io/alanfzf/features/zoxide:latest": {},
    "ghcr.io/devcontainers-contrib/features/fd:latest": {},
    "ghcr.io/devcontainers-contrib/features/fzf:latest": {},
    "ghcr.io/devcontainers-contrib/features/ripgrep:latest": {},
    "ghcr.io/devcontainers-contrib/features/starship:latest": {},
    "ghcr.io/georgofenbeck/features/lazygit-linuxbinary:latest": {},
    "ghcr.io/devcontainers/features/github-cli:latest": {},
    "ghcr.io/devcontainers/features/sshd:1": {},
    "ghcr.io/devcontainers/features/common-utils:2": {
        "installZsh": true,
        "configureZshAsDefaultShell": true
    },
    "ghcr.io/social-anthrax/eza-devcontainer/eza:latest": {}
  }
}

As you can see we use the feature "ghcr.io/devcontainers/features/sshd:1": {}, to handle or mimic the devpod behavior.

Then you need to expose the 2222 port and use the following ssh config to connect:

Host remote 
  AddKeysToAgent yes
  ForwardAgent yes
  HostName localhost
  User YourUserHere
  Port 2222
  StrictHostKeyChecking no
  UserKnownHostsFile /dev/null
  GlobalKnownHostsFile /dev/null

As you can see this is also has a lot of overhead as well, but at least a little more doable, if any one finds another solution please post it :)!

On a final note, it would be really Cool, if this issue could be pinned to alert other neovim users, so they don't end up on the same rabbit hole i fell into hahaha.

[chango-goat]

Hi @bkneis, i see you mentioned that #1275 fixes this. Is it possible to give an overview of how it has been fixed? Just want to see if i can get it working locally, while waiting for the pull request to be merged