[syslinux] "go to the next higher menu" equivalent?

[Ady]

> 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.
> 
> 	-hpa
 
 

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 
that pseudo-code.

The above would be equivalent to:

 *** 
MENU BEGIN mytagname
MENU LABEL my_menu_label
INCLUDE submenu.cfg
MENU END
 *** 

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 [1] to patch the behavior as it is supposed to be, it had to 
be reverted back [2] 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".


[1] elflink branch, 2012NOV12, menu: Inherit parent menu title , 
 commit 6387f043f7f870e4f0b402dae0b921d99eb82c39 .

[2] elflink branch, 2012DEC04, Revert "menu: Inherit parent menu 
title" , 
 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 
further submenus.

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 
submenu.



Well, maybe some day :).

TIA,
Ady.