Fix E1312 when quitting a window #875
Conversation
The idea is taken from README.md of MattLombana/dotfiles Fixes preservim#851
|
I've added a couple more changes to this PR to address a couple other areas of concern. It should now handle vim-9 with the newer handling, but pre-vim-9 will still behave as the old method. I've tested the following scenaios autoclose_netrw=0 test casesautoclose_netrw=0, single file, single windowIn this scenario, open a single file in a single window. Then with Tagbar open and NERDTree open, hit the
autoclose_netrw=0, single file, multi-windowOpen a single file, split the window, then open Tagbar and NERDTree. Then hit
autoclose_netrw=0, multi-file, single-windowOpen multiple files in different buffers, but only a single window. Then open Tagbar and NERDTree. Then hit
autoclose_netrw=0, multi-file, single-window, one file edited but not writtenOpen multiple files in different buffers, but only a single window. Then open Tagbar and NERDTree. Next edit one of the files, but don't write it. Then hit
autoclose_netrw=1 test casesautoclose_netrw=1, single file, single windowIn this scenario, open a single file in a single window. Then with Tagbar open and NERDTree open, hit the
autoclose_netrw=1, single file, multi-windowOpen a single file, split the window, then open Tagbar and NERDTree. Then hit
autoclose_netrw=1, multi-file, single-windowOpen multiple files in different buffers, but only a single window. Then open Tagbar and NERDTree. Then hit
autoclose_netrw=1, single-file, single-window, file edited but not writtenOpen a single file. Then open Tagbar and NERDTree. Next edit the file, but don't write it. Then hit
SummaryThis is definitely better, however in the cases where VIM would normally prompt a warning about something (multiple buffers, unwritten changes, etc), we have a break in functionality where we no longer see the prompt and windows are closed leaving VIM in an odd state. I think we can build on this though and see if we can address these remaining items, maybe even fix the undesired behavior on vim-8.x as well. |
| try | ||
| try | ||
| quit | ||
| if has('patch-9.0.907') | ||
| call timer_start(50, {-> execute('q', 'silent!') }) |
There was a problem hiding this comment.
Why different wait time argument for the 3 timer_start call? I think maybe what matters is where the command is going to be invoked, and the wait time can be all 0.
There was a problem hiding this comment.
The call timer_start() will return immediately after the call is queued. But there can be different background threads that will actually execute the queued call. So the delay is in there to allow for the previously queued call time to execute and complete before starting the next one. It is kind of a soft serialization of the queued calls so they aren't trying to all execute at the same time.
What we want to avoid
The par section will execute in parallel, and we don't have control over the order in which the threads execute.
sequenceDiagram
participant main
create participant only_window as s:HandleOnlyWindow()
main->>only_window: call
create participant close as timer_start(0)
only_window-->>close: call timer_start(0)
create participant bdelete as timer_start(0)
only_window-->>bdelete: call timer_start(0)
create participant quit as timer_start(0)
only_window-->>quit: call timer_start(0)
destroy only_window
only_window->>main: return
par
note over bdelete: execute('noautocmd keepalt bdelete ' . tagbarwinnr)
and
note over close: s:CloseWindow()
and
note over quit: execute('q', 'silent!')
end
destroy close
close->>main: done
destroy bdelete
bdelete->>main: done
destroy quit
quit->>main: done
Adding delay in timer
In this instance, we add the delays to ensure there is time for the other tasks to complete in proper order.
sequenceDiagram
participant main
create participant only_window as s:HandleOnlyWindow()
main->>only_window: call
create participant close as timer_start(10)
only_window-->>close: call timer_start(10)
create participant bdelete as timer_start(20)
only_window-->>bdelete: call timer_start(20)
create participant quit as timer_start(50)
only_window-->>quit: call timer_start(50)
destroy only_window
only_window->>main: return
note over close: s:CloseWindow()
destroy close
close->>main: done
note over bdelete: execute('noautocmd keepalt bdelete ' . tagbarwinnr)
destroy bdelete
bdelete->>main: done
note over quit: execute('q', 'silent!')
destroy quit
quit->>main: done
The idea is taken from README.md of MattLombana/dotfiles
Fixes #851