[Fixed] Content got misaligned when drawing border

[laggardkernel]

Solved: It's caused by my buggy terminfo. The plugin works well.

---

• nvim --version: v0.4.4
• Operating system/version: macOS 10.14.6

Describe the bug

I've implemented z and v in my ranger for quick directory jumping, which basically passes some directory list to fzf and let you select one. Something is broken when let g:rnvimr_draw_border = 1 is enabled.

To Reproduce using nvim -u mini.vim

Let's get right to the point.

First enable let g:rnvimr_draw_border = 1. Secondly, open your ranger config, create a custom command in commands.py.

class test(Command):
    def execute(self):
        import subprocess

        command = "ls -al ~ | fzf --cycle --no-sort +m --tiebreak=index --layout=default --height=100"
        fzf = self.fm.execute_command(
            command, universal_newlines=True, stdout=subprocess.PIPE
        )
        stdout, stderr = fzf.communicate()
        # Just pop a window and do nothing

Trigger ranger within nvim with M-o, and you wanna type :test and press Enter. Then the fzf window pops up with the file, directory listed from your home directory by ls -al. Press ESC to quit the fzf window.

Now, we're back to ranger. Check the border of the floating window created in nvim. You're expected to find the right corner element ┘ is lost and printed to the next line!!! Not only that, use j, k to move the cursor in ranger, you'll find the content is misaligned.

---

I don't know if the following will help you. But better tell you what I've tried.

My first impression is switching to nnn.vim to have a test. nnn.vim doesn't support using ranger directly. But because it only uses nnn as a picker with command nnn -p, it could be easily achieved to switch to ranger --choosefiles by modifying the source code.

Anyway, I tried popping up ranger with a border with nnn.vim. It turns out there's no the above problem.

By checking its code, the border used in nnn.vim is drew with symbol characters manually. To be specific, the border calculation code is borrowed from fzf directly. https://github.com/mcchrish/nnn.vim/commit/6da76e936ecff13a06a4de8a99997db1e6c8a2c8

I haven't dig it deeper. Not sure if drawing border manually with symbol characters is related with the bug i'm reporting.

[kevinhwang91]

I have a hint to solve this issue. Thanks. The border of rnvimr drew by builtin curses in ranger instead of simulate border with nvim_open_win(). There was also an issue relate to it before.

https://github.com/kevinhwang91/rnvimr/issues/69

Did you try M-o again?

[laggardkernel]

Did you try M-o again?

If you mean if I tried to toggle ranger after content is misaligned, yes I did try to redisplay it with M-o. Only quitting ranger with :quit! fixes the problem.

[kevinhwang91]

I can reproduce this issue neither in ArchLinux nor in macOS. You'd try another terminal or make your shell environment clean.

[laggardkernel]

Apology for the issue reported. It's a bug of my terminfo xterm-256color.

After you tell me you can't reproduce it on your side. I re-checked thoroughly and located the cause. macOS uses an old ncurses 5.7, the xterm-256color within which doesn't have some font features like italic, strikethrough, undercurl. To get support for them, I chose to dump a new one from the brew installed ncurses 6.2, and compile it to be used for the system ncurses 5.7.

From what I heard, I only need to fix the color capability part to make this new terminfo work with the old ncurses 5.7. Obviously, from what I experience today, this is not the case.

Checking from eval os.environ.get("TERM"), ranger always choose this broken terminfo no matter what terminal I am using.

Sorry again for your time spent to help me found out the cause.