[syslinux] RFC: Feature: MENU HIDDEN behaviour on ANY key

[Ady Ady]

I don't consider the use of multiple cfg files as "workaround" for this case, 
but I guess it is a subjective opinion. Whether multiple cfg files would 
introduce "more noise", IDK.

The following is just a potential basic example, with some (non-educated) 
assumptions. The point of the example is to show some basic combinations; if 
the assumptions are not relevant / applicable in your case, just use a 
different combination of directives / options.

### Initial syslinux.cfg Start ###

# Options for the SERIAL directive:
SERIAL port [baudrate [flowcontrol]]

# Potentially useful for SERIAL in some cases (YMMV):
CONSOLE 0
NOHALT 1


# Security?:
# Beware: these might be buggy (YMMV)
ALLOWOPTIONS 0
IMPLICIT 0
NOCOMPLETE 1

# Allow "escape keys"
# Are "escape keys" effective for SERIAL scenarios?
#  For this example, let's assume they are.
NOESCAPE 0
# Do not even prompt, unless some "escape key" is used;
PROMPT 0

TIMEOUT 50
TOTALTIMEOUT 50

# In this example,
# if "escape keys" were used
# then "on_timeout_label" is the fallback boot:
ONTIMEOUT on_timeout_label

# Would "ONERROR" be of any help too?


# Some "fancy" help :). It can be simplified, or not used at all.
SAY *****************************************************
SAY *** While booting, use                            ***
SAY ***  [Shift] [Alt] [Caps_Lock] or [Scroll_Lock].  ***
SAY ***                                               ***
SAY ***   Then                                        ***
SAY ***      Within the first 5 seconds,              ***
SAY ***      press "m" for boot menu,                 ***
SAY ***                                               ***
SAY *** Otherwise boot on_timeout_label in 5 seconds. ***
SAY *****************************************************
# Or [enter] to execute the default.


LABEL on_timeout_label
# The file "ontimeoutlabel.cfg"
# contains the "fallback" options;
# i.e. after TIMEOUT when no boot menu is triggered.
# The file could also contain MENU directives,
# so it could be "[MENU] INCLUDEd" in the boot menu too.
# This is frequently equivalent to the DEFAULT label too.
# If using "PROMPT 1", its content and goal could be different.
INCLUDE ontimeoutlabel.cfg


# In this example,
# if "escape keys" were used first
# then [enter] triggers "defaultlabel":

DEFAULT defaultlabel
# This can be different than ONTIMEOUT


LABEL defaultlabel
# For example,
# when using 'PROMPT 1',
#  [enter] could also trigger the boot menu;
#  OTOH, if the user doesn't press anything,
#   then run the ONTIMEOUT command after the 5 seconds.
# In such case, this entry is the same as the "m" label.
# One way of doing this is:
#  COM32 cmd.c32
#  APPEND m
#
# Since we are using 'PROMPT 0' in this example,
# this label is immediately executed by the DEFAULT command.
# Either use a separated cfg file:
#  INCLUDE defaultlabel.cfg
# or execute some kernel-like directive directly here:
LINUX mydefaultkernel
APPEND my default options go here
SYSAPPEND options go here

LABEL m
COM32 menu.c32
APPEND mymenu.cfg


### Initial syslinux.cfg End ###

The above cfg would normally boot the default label immediately, no prompt nor 
boot menu are shown.

If "escape keys" were used, then:

A_ show the SAY lines and, after 5 seconds, boot the on_timeout_label; or,

B_ pressing "m" within the first 5 seconds would trigger the boot menu; or,

C_ pressing [enter] would execute the default label.

Other options or editions are not allowed.

As said, the point is to show potential combinations of directives. If there is 
anything in that example that is not applicable to (or not desirable in) your 
case, I would suggest looking for different combinations. See the "Config" and 
"Menu" wiki pages, in addition to the "escape keys" wiki page already mentioned 
before.

I agree that having to add many 'MENU HIDDENKEY' directives could naturally be 
considered a workaround (not a solution) to the "ANY key" proposal. OTOH, I 
consider the usage of multiple cfg files as a solution, not just a workaround.

I am not against improving / expanding directives, while being very careful not 
to break backward compatibility. As for the default behavior of each 
directive... What one user considers "reasonable default behavior" could be the 
exact opposite for others (with a different "common" scenario). Inconsistent 
behavior is surely unwanted, and so it should be re-evaluated if that's the 
current situation. For all this, Syslinux's developer(s) would need to be much 
more active / involved.

Regards,
Ady.