Modular Statusbar

[Nomarian]

This allows plugins to be written that can edit vis.statusbar[left, right] thus not completely wiping the WIN_STATUS event function

Is this even a good idea? I wanted far back but now I don't know.

[Nomarian]

This closes issues #1311 and maybe ameliorates #1379

[rnpnr]

I feel like this is not as flexible as it could be and I generally don't like dynamic lists of functions when they can be avoided.

To summarize: the point we are trying to address is that if the user wants their own status bar adding a WIN_HIGHLIGHT function is a really poor way of doing it since we still need to run the default one.

I do feel like vis.statusbar is moving in the right direction, but maybe it should be window local. How about instead of vis.statusbar being a table it is instead just a function? Then in the default WIN_HIGHLIGHT event we just call that function directly (if it is not nil).

[Nomarian]

What this aims for is not replacing the WIN_STATUS function but making it modular, so plugins can add into the statusbar without replacing or rewriting the statusbar function, if each plugin used their own WIN_STATUS function, then it would be chaos, especially when they probably only want to display a simple status.

I'm not quite sure what you mean by WIN_HIGHLIGHT, I haven't messed with it here?

For per window status bars is easily doable with creating a win.statusbar on WIN_OPEN and then using that or vis.statusbar as a fallback (WIN_STATUS seems to run before WIN_OPEN)

if you want more power from the statusbar, I don't quite know what you mean... I can think of changing the behavior a bit so its more user friendly

maybe something like

statusbar.actions is a dictionary of functions, (win): string|nil
statusbar.left: string = "mode countorkeys filename" -- each item divided by spaces, is a function name contained in .actions (this means the actions dictionary cannot have keys with weird names /%a+/ only)

win.statusbar -> vis.statusbar -- metatable points to vis.statusbar, which is the global statusbar
if plugins decide to set a special win.statusbar.left they can, win.statusbar will have a metatable that is mt.__newindex = rawset, so plugins can completely modify it however they like. With this, plugins have complete control over both global statusbar display functions and per window display functions This also allows, because both left and right are strings, to use the set command for statusbar.left and statusbar.right, the user can modify the display of the statusbar window at any time.

In the case of @fischerling spell plugin, all that would need to happen is a

vis.statusbar.actions.spellcheck = function (win) return win.spellcheck and "spell=on" end
vis.statusbar.right = vis.statusbar.right .. " spellcheck"

or it would need an extra WIN_OPEN event that adds it to win.statusbar.left directly, but that seems like a bit of a headache.

if vis.statusbar is a function, as you suggest, then I can only think of it as both .statusbar.left and statusbar.right would have to be functions that returns strings, which WIN_STATUS picks up, it would not be very extensible, each plugin would have to take in the win.statusbar.left function, and replace it with their own, maybe if each item in the string that returns is divided by \0 and then the plugin replaces the function with its own, which would require gsub() and sub() on where they want to insert their status item, but now you can't undo a bad plugin injecting their statusbar, its not very configurable

It being a simple function certainly simplifies things though, I really don't like thinking of metatables, inheritance and trees but it seems a necessity here.