Lua/stdlib: behavior of global vs local "enable" (and other config)

[justinmk]

Problem

vim.diagnostic.enable(nil) and vim.lsp.inlay_hint.enable(nil) both actively override any buffer-local flags that were previously set by enable(..., {bufnr=...}.

That seems a bit "destructive". I tend to think that global enable() should act like a gate:

• if globally enabled, then defer to the buffer-local flag
• if globally disabled, don't check the buffer-local flag

IOW: buffer-local "enable" flag has precedence unless the feature is globally disabled.

Expected behavior

Need a clear pattern for all such modules to follow. This may have implications for other kinds of "config" besides mere "enablement".

The behavior of vim options (:help global-local, ignoring other kinds of option scopes) would imply that the global setting is only the "default", and any buffer-local setting should always override the global default.

[ofseed]

IMO the current behavior of enable is good enough, even if we provide something like vim.g.inlay_hint = true and vim.b.inlay_hint = false, we should keep the current behavior.

A summary of the current pattern:

Keep buffer-local states only when it is different from the global one. This means that after it is equalized, its state will change as the global state changes.

As I said in #28543 (comment):

The logic behind this design is that if it can be globally enable or locally enable, when the user selects local enable, we think the user's purpose is to distinguish the local state from the global state. I think this design is good for interaction,

It is the best choice that can be made under the following constraints:

...there is no way to remove "local variables" by using enable. Once the user manages a buffer's bufstate, it means that they must manage it all the time, there's no way to make them follow the globalstate.

And if we add more filters, like what #28521 tries to do, it should be hard to manage by global or buffer variables.