Crash on `call ddu#start({})` by `E523: Not allowed here` in some case

[lambdalisue]

Warning: I will close the issue without the minimal init.vim and the
reproduction instructions.

Problems summary

Invoking call ddu#start({}) crashes denops.vim itself by E523: Not allowed here when statusline/tabline call function that invokes RPC call on Vim and Neovim (or sleep on Neovim.)

It seems sbuffer is called in statusline/tabline update context because of RPC asynchronous call and it seems that's not allowed. So I guess this is more likely a bug on Vim/Neovim side but not sure...

I wonder if call ddu#start({}) wrap internal call with timer_start() to evacuate sbuffer from that context solves this issue or not.

Expected

Works properly

Environment Information

• ddu.vim version (SHA1): b52e60b

• denops.vim version (SHA1): 963a8a9

• gin.vim (SHA1): fe45b9e

  • NOTE: Workaround for this issue is already applied so you MUST use this SHA1 to reproduce the issue

• deno version(deno -V output): deno 1.20.3

• OS: macOS 12.3

• neovim/Vim :version output:

  • Neovim v0.7.0-dev+1373-g80d4d6b48
  • Neovim v0.6.2
  • Vim 8.2.4600

• :checkhealth or :CheckHealth result(neovim only):

Provide a minimal init.vim/vimrc with less than 50 lines (Required!)

if exists('+compatible') && &compatible
  set nocompatible
endif

" Disable Vim's native pack feature
set packpath=

" Clone https://github.com/lambdalisue/fern.vim in somewhere
" and specify that directory to the below
set runtimepath^=~/.config/nvim/pack/jetpack/src/denops.vim
set runtimepath^=~/.config/nvim/pack/jetpack/src/gin.vim
set runtimepath^=~/.config/nvim/pack/jetpack/src/ddu.vim
set runtimepath^=~/.config/nvim/pack/jetpack/src/ddu-ui-ff
set runtimepath^=~/.config/nvim/pack/jetpack/src/ddu-kind-file
set runtimepath^=~/.config/nvim/pack/jetpack/src/ddu-source-file_rec
set runtimepath^=~/.config/nvim/pack/jetpack/src/ddu-filter-matcher_substring

filetype plugin indent on
syntax on
"----------------------------------------------------------------

nnoremap ; :
nnoremap : ;

call ddu#custom#patch_global({
    \   'ui': 'ff',
    \   'sources': [{'name': 'file_rec', 'params': {}}],
    \   'sourceOptions': {
    \     '_': {
    \       'matchers': ['matcher_substring'],
    \     },
    \   },
    \   'kindOptions': {
    \     'file': {
    \       'defaultAction': 'open',
    \     },
    \   }
    \ })

set showtabline=2
" Crash with RPC calls in Vim or Neovim
set tabline=%{gin#component#worktree#name()}
" Or crash with sleep in Neovim (Vim won't)
" set tabline=%{Sleep()}
function! Sleep() abort
  sleep 10m
  return "Hello"
endfunction

"----------------------------------------------------------------
echomsg "Custom minimal vimrc has loaded"

How to reproduce the problem from neovim/Vim startup (Required!)

1. Invoke :call ddu#start({})

Screenshot (if possible)

[Shougo]

Well, I have not reproduced the error.

[Shougo]

I think gin.vim implementation is changed, the error is not occurred. Please test it again.

[lambdalisue]

That what I already mentioned 👍

[Shougo]

OK. I have reproduced. But it is bug of ddu.vim?
How to fix the problem??

[lambdalisue]

OK. I have reproduced. But it is bug of ddu.vim?
How to fix the problem??

I've no idea as well. That why I mentioned that its more likely a bug on Vim/Neovim side like:

It seems sbuffer is called in statusline/tabline update context because of RPC asynchronous call and it seems that's not allowed. So I guess this is more likely a bug on Vim/Neovim side but not sure...

This issue is mainly for users who faced similar issue to describe what's going on.
But I haven't faced similar issue on gin.vim even that gin.vim open buffers so maybe ddu has some code to cause this behavior? I don't know.

[Shougo]

But I haven't faced similar issue on gin.vim even that gin.vim open buffers so maybe ddu has some code to cause this behavior? I don't know.

Ddu has asyncronous update. It may be on statusline state?