[syslinux] "go to the next higher menu" equivalent?
ady-sf at hotmail.com
Sat Mar 2 00:45:12 PST 2013
> On 02/28/2013 10:32 AM, Ady wrote:
> > You already answered that menu.c32 is GOTO, there is no history. So
> > there is no way to add what is currently missing. Or... maybe I am
> > misunderstanding what you meant with "missing" and "can be fixed" in
> > this case? Are you referring to submenus?
> Yes, I'm referring to submenus.
Well, I have a (long) wish list regarding several aspects of
Syslinux, including submenus. Some items in my wish list are _very_
low priority; so much that I am almost afraid of writing about them.
For example, would it be possible to add the equivalent functionality
of "MENU LABEL" to
"[MENU] INCLUDE submenu.cfg mytagname"?
I am thinking about something like:
"[MENU] INCLUDE submenu.cfg mytagname : my_menu_label"
where "my_menu_label" could contain "^" for hot keys, and could also
contain spaces. Of course "my_menu_label" corresponds to "mytagname".
The ":" (with or without spaces around it; you decide) used above is
just one possible separator between the tagname and its menu_label in
The above would be equivalent to:
MENU BEGIN mytagname
MENU LABEL my_menu_label
and also equivalent to "[MENU] INCLUDE submenu.cfg mytagname"
when "MENU LABEL my_menu_label" is the first line inside submenu.cfg.
There is one issue (which I don't consider so low priority myself,
but I know there are MUCH bigger challenges in queue) regarding
submenus that has been broken for so long that when Matt included a
commit  to patch the behavior as it is supposed to be, it had to
be reverted back  so to avoid "breaking" the INcorrect behavior
that had been effectively in place for so long. The current INcorrect
behavior is still useful (that's the reason for the reticence to
"break" it); yet "usefulness" doesn't always mean "correct".
 elflink branch, 2012NOV12, menu: Inherit parent menu title ,
commit 6387f043f7f870e4f0b402dae0b921d99eb82c39 .
 elflink branch, 2012DEC04, Revert "menu: Inherit parent menu
commit fb709d6483320244982e6fc8fda5425c5bcab62c .
To cope with this INcorrect behavior, I use workarounds, such as
using the TABMSG in place of the (sub)MENU TITLE (without timers).
So, since the current INcorrect behavior is kept, there are cases of
submenus where the parent menu title is still not inherited to its
submenus and no submenu title is displayed at all. I'll avoid here
repeating again my proposed behavior for the 2 relevant cases.
The (usefulness of the) current INcorrect behavior for (sub)MENU
TITLE is frequently used to show the "position" of the displayed
submenu in the menu structure. This is a consequence of a _missing_
feature, "MENU SUBTITLE[S]", in addition to the current menu title.
One possible solution would be to introduce a new directive (I'll
call it "MP" just for simplicity in this text).
Initially, MP should act similarly as MENU TITLE. When a submenu is
used and displayed, this MP would be inherited (as opposed to the
current INcorrect behavior of MENU TITLE).
If a particular submenu ("SM") uses "MENU LABEL" (or "tagname" as
fallback) for its entry in the parent menu, then the "almost
inherited" MP in the submenu would be the "position" of the submenu,
as in "MP/SM", similar to a "path".
I said "almost inherited" because if MP is used in the parent menu,
it already should mean that the submenus shall automatically use it
too except when MENU TITLE is explicitly used in the submenu
("inherited"), but with the additional "position" of SN appended. So
the MP for this submenu would be "parent_menu_title/SN".
In the main parent menu, if MP is used, it would also be taken as its
MENU TITLE. If both directives are present in a particular (sub)menu,
I suppose MENU TITLE should take priority in the displayed menu, but
the value and features of MP should be kept, so to be usable in
Advantages of adding MP:
_ The current INcorrect behavior of MENU TITLE is kept for those that
have already been taking advantage of it for a long time.
_ The behavior that was supposed to be expected from MENU TITLE
regarding submenus is partially achieved by MP.
_ A new feature is added to submenus: show its "position" in the
whole (sub)menu structure.
Optionally (and/or alternatively), MP could have its own "MENU
COLOR", "MENU MPROW" and "MENU MPENDROW" respective directives if
necessary. In such case, the priorities and fallback rules between MP
and MENU TITLE might need further revision over what I wrote above.
A new directive, "NMT", that would act the way MENU TITLE was
supposed to behave, is still a possible solution to the current
INcorrect behavior of MENU TITLE. If either MENU TITLE or NMT is
present in a submenu, NMT would respect it; and if neither, MENU
TITLE nor NMT, are present in the submenu, then NMT would be
inherited from the parent menu so to be used as MENU TITLE in such
Well, maybe some day :).
More information about the Syslinux