Make the status buffer a standalone instance

[ten3roberts]

Wild idea: making the status buffer an owned object, rather than the current global state intertwined singleton it is now.

The API would remain mostly the same, as we would simply store a global of the current instance, rather than multiple global variables.

The advantage of having it this way is that we can pass the instance around to the popups without intrusively require("neogit.status") and reaching in from within the popups. This would fix the issues @gegoune were having as you would now have to provide the instance (or create one) rather than crossing your fingers and hoping the correct global state exists and is in a proper state for what you are trying to do.

This would also clear up our public API tons, as well as enable a programmatic usage of Neogit by having the exposed API. For example for opening popups opening or committing. These would be methods of, or functions taking a Status object, and would further allow you to use the full extents of our library without opening and displaying Neogit status buffer, as you could simply create a Status object in Lua and just forego displaying or opening it. I.e; headless operation without missing some part of global state and panicking on attempt to access nil value "current"

[ten3roberts]

Related: #639

[gegoune]

That would be amazing. I did ask about programmatic access long time ago. Would love to be able to call api to commit file and push to remote. Big 👍 from me. Thanks for reviving Neogit!

[ten3roberts]

Great what I have in mind for the end usage is something along the lines of

local status = require"neogit.status".create()

status:commit( { msg = "Some small innocuous fixes" })

And yes, feel free to re-ask for features, as there is quite the backlog of issues from before my time as a maintainer that are out of date or no longer relevant. I am going through them in the meantime, but I may miss things, so feel free to re-open or close issues to make them relevant.

[gegoune]

It's still open actually #73. Don't mind what the api would look like above looks alright, but doesn't creating status go against decoupling from it that you described in your post here?