search

onivim / oni

Oni: Modern Modal Editing - powered by Neovim
https://www.onivim.io
MIT License
11.35k stars 299 forks source link

[NERDTree] "Press ? for help" appear in the wrong buffer #106

Closed Ilphrin closed 7 years ago

Ilphrin commented 7 years ago

Hi! First, let me thank you a lot for your awesome GUI, even if it is still in development/beta, it looks really cool (I tried first Nyaovim, and was a bit disappointed x) ).

Now, when I open neovim, I have automatically NERDTree opened, but there is a little graphic issue when using Oni: untitled

When I write on the buffer, it replaces these letters, so it really looks like a graphical issue as it is not in the buffer. I have updated to the latest npm package for oni, and for neovim and NERDTree too (By the way, I am on Linux Mint 18)

Here is my .vimrc if you need https://github.com/Ilphrin/.vim/blob/master/vimrc

bryphe commented 7 years ago

Hi @Ilphrin ! Thanks for the kind words!

Yes, this definitely looks like a rendering bug. I believe I hit this on Windows too on startup - it seems like the beginning of the first line is always problematic. It might be we're missing or not handling one of the neovim msgpack-RPC actions correctly.

Ilphrin commented 7 years ago

You're welcome! When i'll have time, i'll try to give some help on Oni, this really deserves more hands =D

BTW, when i run Ctrl+L it is refreshing the page and the glitch doesn't appear anymore, as my NERDTree is has a plugin to be launched in every tab and on startup, maybe it is because the browsers draws too soon the content? (Just suppositions, I don't know a thing about what's is happening!)

bryphe commented 7 years ago

Awesome, would be great to have the help! :)

I just checked out this issue... It looks like it was a bug that was caused by a couple of contributing factors: 1) On startup, we would tell Neovim that we had a fixed size screen (80 cols x 40 rows), and then we would always resize to the proper size based on the font afterwards 2) During resize, Neovim sends a CLEAR action via the msgpack-rpc API. For that action, the cursor position wasn't being reset - so after clearing, it would just start rendering the first line whereever the cursor had been previously. So that was the root problem, and easy to fix.

Should be addressed now by PR #115