Spring RTS Engine

I'm going to implement a way for textActions from the actionHandlers to appear as autocomplete suggestions in Chonsole. Within Chonsole, I've already added functionality to insert/remove suggestions on the fly. What's left to do is:

(1) A way of retrieving the current textActions from the LuaUI actionHandler; options are to poll from widgetHandler.actionHandler, or give the actionHandler a way to modify Chonsoles suggestions directly. Neither is difficult, but which is best depends on future plans for the actionHandler.
(2) A way of retrieving the current textActions from the LuaRules actionHandler; I guess that it would be best to have the LuaRules actionHandler send updates to its actions tables (through a Script.LuaUI call) to the LuaUI actionHandler, which then maintains track of what the LuaRules one has in store.

So, I would like to know future plans (if any?) for the actionHandlers (LuaUI<->LuaRules? engine integration? etc). Aimed mostly at gajop/jK because I can see from the code that you've both planned/thought about this in the past.

If there is nothing planned, I'll simply implement it all myself In which case, thoughts on best design also welcome.

I've had no plans for implementing it in Lua or via the action handler, and generally this feature wasn't high on my TODO list, so you're welcome to do this without any worry of duplication happening from my side.

My original thinking was to do this in the engine, as it would make a lot of things work implicitly: Spring.GetUICommands, auto completion with the engine console, integration with Spring.SendCommands, /cheat detection, synced<->unsynced message passing and maybe even the ability to disable/override engine built-in commands.

Seems what's in basecontent is a bit of a mess; it contains two different versions of the actionHandler, one for LuaRules and one for LuaUI/LuaHandler/etc...

edit: And yet another different version is placed (on a clean install) into the Spring/LuaUI dir!??

At this point, I'm guessing there is no definition of "what is supposed to happen".

On reflection - I'm not going to touch this.

Basecontent & the packaged /spring/lua look like they have been left mid-migration between different handler versions; there are three different actionHandler versions and three different handler versions all packaged together. Afaics that has to be cleaned up first, and without any indication that the migration has been abandoned or might one day be finished, there is nothing I can reasonably do.

I might still implement a solution that relies on BARs custom handlers instead.