Nerdtree: Slow scrolling with NERDTree open.

Created on 17 Nov 2014  路  11Comments  路  Source: preservim/nerdtree

I've noticed recently that scrolling in a buffer is noticeably slower with NERDTree toggled on than with NERDTree toggled off. I couldn't find any open issues that adressed this.

I tried running Vim with NERDTree as the only plugin, and the same occured.

Most helpful comment

Sorry to pick up this thread again and I agree with @mantiz. I think it actually has something to do with multiple panes (esp. vertical split). And this only occurs when using a large monitor and have the terminal (for me iterm2) spanning over the screen. The situation is worse significantly with tmux. It doesn't change too much between iterm2 vs terminal. (I'm using macvim in iterm2 in tmux to show the below screencast)

My only solution is to use gui macvim which seems to use a much better rendering than terminal macvim. However, I hope to went back everything in iterm2 again. Let me know if you have any solutions.

untitled

Ironically, I tried same setting except with gnu-screen instead of tmux. It became smooth again. Seems all evil was from tmux...

All 11 comments

Found this to also be the case. Kind of annoying; coming from IDE's (atom, sublime) I like to have my dir tree open.

I'm having similar symptoms. Opening a python file with ~200 lines and scrolling is very slow. I turned off all other plugins and isolated it to be nerd tree causing the issues.

Glad I discovered this issue. I've been trying to figure out what is bogging up my Vim rendering for a while now, and I realized it only happens when NERDTree is open. It seems to happen worst when scrolling through sections of long lines. That is, when there are a lot of total characters being rendered at once.

I'll admit, I probably shouldn't rely so much on having NERDTree open all the time, but it's really nice when I'm in a project with a lot of files in a lot of directories. At least now I'll remind myself to close it when I'm not actually using it.

Very annoying, agree.
I found that the problem exists when the buffer which is scrolled has a highlighted syntax. 'Cause I've tried to disable it and everything worked well.

Same here. But disabling syntax highlightning doesn't change a thing for me.
I have not tried to disable any other plugin since simply hiding the NERDTree makes scrolling flawless.

Nevermind, I think the problem is not specific to NERDTree, at least for me.
I tried to observe the behaviour a bit and finally found that vertically split windows are causing slow scrolling speed for me. Everything seems fine if two windows are split horizontally but if I change to vertically split windows (like it is also the case with NERDTree open) it gets laggy.
If I open just one file plus NERDTree and change the layout to horizontal split, the scrolling is also fast.

Sorry to pick up this thread again and I agree with @mantiz. I think it actually has something to do with multiple panes (esp. vertical split). And this only occurs when using a large monitor and have the terminal (for me iterm2) spanning over the screen. The situation is worse significantly with tmux. It doesn't change too much between iterm2 vs terminal. (I'm using macvim in iterm2 in tmux to show the below screencast)

My only solution is to use gui macvim which seems to use a much better rendering than terminal macvim. However, I hope to went back everything in iterm2 again. Let me know if you have any solutions.

untitled

Ironically, I tried same setting except with gnu-screen instead of tmux. It became smooth again. Seems all evil was from tmux...

Wow, I was getting annoyed by the slow scrolling and I also thought it was nerdtree at first. I can confirm it's tmux. I also found this: http://unix.stackexchange.com/questions/49414/tmux-output-is-slower-when-vertical-splits-exist-why

Yea, it start really slow especially after opening folder with a lot of items in it, and persists even after closing the folder. The workaround mentioned in the link above doesn't really help solve it. For now what we should we do to fix this? because netrw doesn't have this issue in tmux.

There's really nothing that can be done in NERDTree to fix this. As discovered above, there are a number of other factors at play here, from syntax highlighting (some languages are slower than others, especially on long lines of code) to vertical splits to tmux.

devicons was my culprit

Was this page helpful?
0 / 5 - 0 ratings