Improve disable/enable command flow

[oliviercreurer]

At the moment, there is both a UX issue and a nasty bug in the flow to enable (and re-enable) commands from the config page:

1. UX issue: When disabling an individual command, the entire command list is cleared and re-written. This is to prevent a full-blown crash in the case of the command sequence position landing on a no-longer-enabled command. Instead, it would be better to re-write the algorithm such that only disabled commands are replaced instead of the whole act table.
2. Bug: ☝️ The full-blown crash mentioned above.

---

Ideas:

• Assign each command (in the parent table) an ID that can be referenced + compared to when building and modifying the act table on the fly?

Solution (for now):

All commands (+ related properties) are stored in a parent table, commands:

commands = {}
commands[1] = {
   action = clk_min,
   is_enabled = true,
   label = "[",
   description = "Slowest clock speed"
   id = 1
} -- ... and so on -- there are 19 commands total

When a user loads the script, a session-specific table, user_commands, is created to store their command preferences:

function user_commands()
local config = {}
for i=1,#commands do
if commands[i].is_enabled == true then
table.insert(config, commands[i].id)
end
return config
end

When a user is on the config page, they can disable/enable any command. Doing so toggles its is_enabled value. Every time this action is taken, the user_commands() function is called to update the list of enabled commands.

Later, we can use user_commands (since it returns a custom table) to randomize only enabled commands:

function random(table)
  for i=1,5 do
    print(table[math.random(#table)])
  end
end

random(user_commands())