rplugin: conditionally enable nested notifications

[bfredl]

for neovim/neovim#6544

[justinmk]

Instead of introducing "urgent" as a jargon, can we re-use the "deferred" vs "non-deferred" concept?

[bfredl]

@justinmk The only issue is that it makes deferred=True the default. In general bool options are False as default and True for the special case.

[justinmk]

In general bool options are False as default and True for the special case.

This rule really gets in the way. It is IMO much lower-priority than good names, consistency, and pretty much everything else.

[bfredl]

consistency, and pretty much everything else.

In this case consistency/everything else is that rplugin infrastructure (with @tarruda:s original restriction, or the neovim/neovim#6544 reimplementation) do implement an modified actor model where each rplugin only will handle one top-level request or notification at a time. (the modification is that nested requests are ok, but they can only be invoked because the rplugin itself did something that requires the request to be handled, to avoid dead-lock). On the other hand nvim is best described as a state machine of user input, and "deferred" /"undeferred" ("async" should never have been used for this) refers to what input states this event can be processed in, not whether the event is "nested" or not. It is therefore a different distinction and I see no point to use the same terminology.

"urgent" might not be optimal, but preferably it should be a word that positively describes how it deviates from the default (actor-like) model. Perhaps allow_nested, which indicates the relevant consequence (that it might be called nestedly inside a request handler)