Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
fix: fix rendering glitches due to interaction with vim-dirvish
This isn't a bug in vim-dirvish, but there is something about the way it operates that triggers this undesired behavior in Command-T. The repro isn't 100% reliable but it almost is: 1. Create a tmux split in order to have a narrow window to test inside. 2. Open vim-dirvish with `nvim .`. 3. Split the buffer vertically to make it even thinner (strictly speaking, you don't have to do this, but it makes it more likely to reproduce). 4. Open Command-T; see that the match listing is acting as though it were scrolled to the right (ie. you can't see the text on the left, or you can only see the tail end of it). Now, what vim-dirvish is doing is having potentially very long absolute paths in its buffer that are very wide, and hiding the bit that corresponds to the current working directory using Vim's "conceal" feature. So, you only see relative paths (relative to the current working directory), but each line in the buffer may be much longer. So, given a `'textwidth'` of, say, 80, it's easily possibly for you to have lines longer than that, even if they don't look that long. This becomes more obvious if you set `'colorcolumn'` to "+0,+1" etc; you might have a path that looks like "README.md" in the visible spectrum, but the line is actually prefixed by something way longer, and you can see the colorcolumn columns not in column 80 (assuming `'textwidth'` is 80) like you would expect, but in something way farther to the left, like "column" 15 or 20. If you jump the cursor all the way to the start of the line (with `^`) then you see the colorcolumn highlighting move to the right, and Command-T works without the rendering glitch. If you jump to the end (with `$`), the colorcolumn highlighting moves back to the left and the bug returns. I tried various settings of `'sidescroll'` and `'sidescrolloff'` but the only way I could get the problem to go away was to turn `'wrap'` _on_, and then trim my lines to avoid the unwanted wrapping. Moving the cursor to column 0 with `nvim_win_set_cursor` does not solve this problem, even thought he docs say it will scroll the window if necessary (note: we were already doing this). I tried to repro this without vim-dirvish, and didn't succeed. For example I got a big Markdown file with long lines and tried various values of all the settings without reproducing the bug. I turned off various bells and whistles. I updated vim-dirvish. In the end, I don't have a smoking gun, but I have a correlation. It's a mystery how the state of the vim-dirvish window could/would affect an independent buffer (the match listing); that does feel like a bug, in Neovim most likely. But it seem so edge-casey and speculative that I don't think I can even formulate a bug report.
- Loading branch information