michaelb/sniprun

term window close after help window closed

zhengpd opened this issue · 4 comments

zhengpd commented

Describe the bug
Configured with display_options = { "TerminalWithCode" }.

Term window close after help window closed.

To Reproduce

  1. call Sniprun to open the ouput term window.
  2. :h vim and then close (q OR c-w c) the help window, the term window is also closed.

Expected behavior
Terminal output window should stay intact while closing the help window

Environment:

  • NVIM v0.9.0
  • macOS

I might investigate this bug later.

zhengpd commented

It's caused by vim.cmd("autocmd VimLeave,QuitPre,BufWinLeave ?* call Sniprun_close_term_on_leave()"). The autocmd runs on every window close.

Currently all buffer share the same output terminal buffer. I'm considering to create output terminal per buffer calling Sniprun, basic idea like:

  • document buffer has one-to-one relation with output terminal
  • VimLeave would stay as global autocmd, as we want output windows to be closed before vim quitting.
  • QuitPre, BufWinLeave would be buffer-local autocmd, which is bound to the document buffer. It's set-up on first run of Sniprun in current buffer. Whenever the doc buffer close, its output term would also close, but other doc buffers and output terms stay intact.

@michaelb Do you think this change is acceptable? I can create a PR.

michaelb commented

Hmmmm. Several terminals for sniprun output seems like a huge waste of space at first glance. Especially when you have splits, and on smaller (laptop) screens, I don't think more 'terminal' output buffers is a good solution.

However, I agree that sniprun's term buffer closes annoyingly often.

I'd favor a 'simpler' solution: a setting (possible enabled by default) would inhibit the BufWinLeave autocommand. A single output buffer would still be shared between all splits/buffers and should not close on one of them BufWinLeave'ing or help buffers closing.
Sniprun term buffer could still be closed with :q or :SnipClose

You're welcome to implement this change if you want to, but I'll probably do it anyway in a couple days if not since I convinced myself that it's a good idea

  • 👍1
zhengpd commented

@michaelb Yes multiple output windows could be less nice on small screens. Your solution should be good enough. I'm focusing something else and won't check on this soon.

michaelb commented

Will be included in 1.3.2 release through #231

  • 👍1