IUP, menu layout tables: any suggestions for readability and improvement?

I've been using IUPLua in a project recently with multiple dialogs and different menu bars for each. So far, I have been iupx.menu (found here: www.tecgraf.puc-rio.br/iup/examples/Lua/misc/iupx.lua) and layout tables created for it in order to layout my menus, and I find the shorthand provided easier to write and think about. A typical example from my code:

local menu_template = {
"File",{
    "New",do_new,
    "Open",do_open,
    "-",nil,
    "Exit",do_close,
},
"Planet",{
    "New",planet_dialog,
    "Edit Current",edit_current_planet,
},
"Galaxy",{
    "New", galaxy_dialog,
    "Edit Current",edit_current_galaxy,
    "-",nil,
    "Hide/Show Galaxy Tab",default,
}
}

But this syntax *relies* on the fact that there are two pieces of information about every subitem on the menu: a title paired with one of

a) an function to run on selection,

b) a table of subitems, or

c) nil to indicate a separator.

If I wanted to include more options for each item, I'd have to write nils or default values for the items that don't need or have that option. The example that prompted me to write this was in the case that I would like one of the items to be inactive to begin with:

local menu_template = {
"File","active",{
"New","active",do_new,
"Open","active",do_open,

    "Save","inactive",do_save,
    "-","active",nil,
    "Exit","active",do_close,
},
}

That's not terrible, but think about a fourth or fifth argument. It quickly becomes almost as verbose as without the layout table!

local menu_template = {
"File","active","notoggle"{
"New","active","notoggle",do_new,
"Open","active","notoggle",do_open,

"Save","inactive","notoggle",do_save,

    "Legacy Format","active","toggle",switch_format,
    "-","active","notoggle",nil,
    "Exit","active","notoggle",do_close,
},
}

So I am trying to come up with a new template syntax that allows additional optional arguments but still saves some work by calling the appropriate IUP constructors for me. Here's what I've come up with so far.

local menu_template = {
{
    "File",
    {"New",do_new},
    {"Open",do_open},
    "-",
    {"Exit",do_close},

},
{
    "Planet",
    {"New",planet_dialog, active="NO"},
    {"Edit Current",edit_current_planet, active="NO"},
},
{
    "Galaxy",
    {"New", galaxy_dialog, active="NO"},
    {"Edit Current",edit_current_galaxy, active="NO"},
    "-",
    {"Hide/Show Galaxy Tab",default},
}
}

Each submenu and item has become a table. Separators have become simply a "-". The first piece of data in any submenu or item is the title, and then the type of the second piece of data determines whether it is a submenu or an item. Items have a function as their second piece, while submenus have a table. Submenus also have additional integer-keyed tables to represent additional subitems.

In the grand scheme of things, this is a rather unimportant minutia. All the same, I would appreciate any advice or suggestions on how to improve my approach, and especially if you think there's an entirely different and better approach more suited. I had considered writing some kind of a mini-language to be parsed by LPeg, as it would give me an excuse to finally learn it, but straight Lua is probably already the mini-language I need. Or so I think.

Happy Father's Day from the US! I have recently learned that us Yanks are a few months premature in our paternal adulation when compared to Brazil.

-Cameron Seebach