Lua scripting support

[ppebb]

Description

The ability to invoke arbitrary bash scripts for certain events is incredibly useful. However, certain shortcomings like latency and ease-of-use are present. I think allowing configuration to be done fully in lua (or another similarly powerful scripting language) would be very useful.

Proposed solution

Something akin to an init.lua could be loaded at launch, which would then register callbacks for events such as on_song_change, with the same variables being passed to those callbacks as the environment variables passed to existing bash scripts. The same functionality available over the remote protocol could be exposed as lua functions, such as modifying configuration and themes.

I believe this would be a better alternative to the current .ron configuration as well as something such as switching to toml (#255), as it would enable more complex setups to behave more gracefully and eliminate the awkward split between config and themes by allowing the user to manage it however they please.

I do not see this as being too difficult to accomplish (mayhaps I am overly optimistic), and I'd be more than happy to take a shot at implementing something like this myself.

[mierak]

Hi!

I have been playing with that thought for quite a while as well along other alternatives. I am all for integrating lua and deprecating the current config format, this would resolve several other annoyances I have with the current state of things too, just like you mentioned.

My concern here is mainly the design of such an integration because there are already quite a few things in play in rmpc: Hot reloading of config, several threads sharing things (luckily mainly through channels), the various hooks like on song change, now there is even the component system (that one would probably be obsolete if we had full lua, since you can just create variables), etc. And I think we need to give serious thought to the future and not block ourselves from other possible features.

TLDR: I am all for it, I just have concerns to not design this haphazardly.

[ppebb]

I believe hooks can be handled fairly reasonably by reusing the existing remote functionality; relevant functions should already be safe to be called asynchronously from Lua at any time. I don't believe this would restrict future development.

For configuration, there are two reasonable approaches I can think of:

1. Like the existing remote set config, just call some function with an entire config object. This would be the simpler option.
2. Something like neovim, where options are exposed as global variables you can just set (vim.bo, vim.o, etc). This would have the drawback of being distinct from the existing config structure, likely requiring additional effort to maintain if ron configuration is kept around.
   Personally I am more inclined toward the latter, but it may impede future development in ways I do not know of, so I would like to know your opinion.

There is also the consideration of whether or not Lua would entirely replace the existing ron configuration. Personally I would want to deprecate the old ron configuration (effort to maintain, high effort for feature parity if desired), but I am also aware of how annoying that would be for existing users. I wonder if some sort of automatic porting would be possible?

Would a draft PR be welcome for any of this? I do not mind putting in the work to get something functional up that can be iterated on into a proper state.

[mierak]

There is also the consideration of whether or not Lua would entirely replace the existing ron configuration.

I would like to completely get rid of it eventually, ron is a fine format but there are subtleties/bugs in its serde implementation which are unsolvable and I do not like. I also feel like rmpc has outgrown ron by now, it used to be a way simpler program when I decided on ron.

For configuration, there are two reasonable approaches I can think of:

I am fine with either but being able to reload only a part of config would be nice (I have wanted to do a remote command for that anyway, the rmpc remote set is set up to allow for this expansion).

There are few problems even with current implementation, whether or not they would block anything in the lua is a question though, I assume not, but I have no experience with rust+lua. For example the config is shared among multiple threads, but only on startup, ie. the thread handling connection to MPD gets address at the start and it will not change even after the config reloads. I do not know how the lua implementation would interact with this but I assume multiple rust threads will be a thing to handle.. or we could just continue ignoring it and keep the lua runtime on the event loop thread.
Then theme gets shared into cava's and album art's threads and these do need to get notified on change.

Then there are a few things in the current config file that need cleaning up/removing/renaming etc, some examples are renaming the artists option or maybe even better moving it to the Browser pane's config, that is not something that would block lua in any way but needs to happen with the implementation - I would do that or at the very least help with it.

And lastly, I would like to keep options open to maybe move the panes completely into lua eventually - I am not even sure that there would need to be any action taken for this to be possible in the initial implementation, but just to keep it in mind.

Would a draft PR be welcome for any of this?

Very much so, I would like to get involved as well!

[helixoid]

I think a better approach would be steel as I think this is what helix editor is going to implement for their plugin support.
This would be a better option for a rust project.

[ppebb]

Can you explain why it would be a better option? I'm personally inclined toward Lua just because I like it, and I've put some effort toward implementing it already (delayed due to midterms 💀).

Regarding the benefit for other users, I would argue Lua is easier for most people to write for configuration even without really knowing the language, which I doubt the same can be said for scheme. Lua would also allow users to leverage existing Lua libraries.

[helixoid]

It was just a suggestion, if you have already started implementing Lua then there is no reason to drop it.

[mierak]

I don't think helix using steel is an argument for scheme. I pretty much agree with @ppebb, it is a more widespread solution and I do not see any real downsides compared to scheme.

[v-Nyo]

implementing it already

Pls abort immediately and do Elisp instead. I am physically unable to write anything else

[ppebb]

Sorry for the large delay, I made this issue right before midterms and then finals for my summer courses, and I just moved for the beginning of my fall term for uni. I am very busy right now, but I will try to get to this in the next week. Just wanted to update so no one thinks I disappeared 😭.

[auralluring]

lua would be fantastic especially if it had the ability to do more custom ui. there are a couple of big things that i would love to be able to do with rmpc but wouldn't really make sense to be in the project itself, so having a way to properly add & augment behaviour would be great.

[ppebb]

Back again working on this. Sorry for the delay, didn't really have time this semester. On break for the next 3 weeks so I'll try and get a draft PR out within a few days. Will have something preliminary up since I'd want to discuss design decisions before fully fleshing anything out.