After first ui attach event, modifications to g:clipboard won't register

[yatli]

version: NVIM v0.5.0-828-g0a95549d6

If the ui attaches first (and nvim finds another provider, say tmux), later :checkhealth reports FVimClipboardProvider because it sees the current g:clipboard, but nvim actually isn't using it.

Can be worked around with:

1. Do not attach the UI until the initial let g:clipboard ... command returns; and:
2. Do not hard-code client channel in g:clipboard -- instead, capture the channel variable with a lambda. Say "+": lines, regs -> rpcrequest(g:fvim_channel, lines, regs). So later attached clients can modify the variable to redirect the clipboard.

[bfredl]

probably changes to g:clipboard should be detected after startup (using dictwatcher)

[erw7]

probably changes to g:clipboard should be detected after startup (using dictwatcher)

The dictwatcher only fires on assignment to a dictionary key. In order to do so, we need to implement a new autocommand or callback that fires on assignment to a variable.

In the meantime, I have added the following items to the FAQ.

https://github.com/neovim/neovim/wiki/FAQ#gclipboard-settings-are-not-used

[bfredl]

@erw7 g: is also a dictionary, so you can set a watcher on a global variable already.

[erw7]

I've added an example of using dictwatcher() to the FAQ. Should I add an implementation to autoload/provider/clipboard.vim that reloads with dictwatch()? IMO: Reloading with dictwatcher can cause performance problems, so it is better not to do it in autoload/provider/clipboard.vim.