search

rhysd / git-messenger.vim

Vim and Neovim plugin to reveal the commit messages under the cursor
MIT License
1.35k stars 32 forks source link

Preview was closed immediately as soon as it was opened on Vim 8 #16

Closed voldikss closed 5 years ago

voldikss commented 5 years ago

Vim version

VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Apr 10 2018 21:31:58)
including patch: 1-1453

This plugin works perfect on Neovim. but on Vim 8, the preview window will crash on the moment it is created if I set updatetime to 100.

Is this a bug of Vim? Do we have a solution for the problem?

voldikss commented 5 years ago

In addition, if the cursor is on the top line of the page, this issue will not occur anymore.

rhysd commented 5 years ago

It seems that this plugin does not work on Vim8 correctly. I did not notice that because tests are run only for Neovim for now.

On my laptop, updatetime seems not related. First :GitMessenger does not open window, but second try opens window as intended.

rhysd commented 5 years ago

It seems that this is a problem of behavior of job feature on Vim8. I'll try to make a workaround.

voldikss commented 5 years ago

Wow, it's astonishing. I ever thought it was a preview-windows problem or Vim itself...

rhysd commented 5 years ago

Could you check 8e71f4d fixes this issue? At least on my laptop, it seems to have gone.

voldikss commented 5 years ago

Yes! The problem was solved. Now this plugin works normally on Vim 8. It's awesome!

Hmmm, cloud you tell me in brief that how did you found that cause? Since the plugin has this code

autocmd CursorMoved,CursorMovedI,InsertEnter <buffer> call <SID>on_cursor_moved()

I ever thought the cursor's movement event caused that issue, but it didn't moved, which made me puzzled. How did you directly found that the ringleader is "job's channel hadn't been closed after callback function was called"

Thanks.

rhysd commented 5 years ago

I also thought that a cursor move would cause this issue. However, I noticed that window was actually not opened while the issue. I found it by dumping trace data by giving -V8log.txt to vim command. It is a good point to start debugging since many events are logged in the file to know what happens.

Then I added some debug prints to out_cb, err_cb and exit_cb and found that there was a situation that I did not expect. When exit_cb is called, I thought stdout and stderr channels were closed, but actually there were some cases where channels were still open. So I added a workaround to wait for the channels being closed with blocking polling loop.