[syslinux] Arrow key feature request

[Gene Cumm]

On Sat, Sep 13, 2014 at 11:34 AM, Ady <ady-sf at hotmail.com> wrote:
>
>> On Thu, Sep 11, 2014 at 4:09 PM, Ady <ady-sf at hotmail.com> wrote:
>>
>> >> Since keystrokes were brought up, this seems like a reasonable time to
>> >> make the following seemingly simple-to-implement feature request:
>> >>
>> >> Navigating a multi-level menu structure seems to require use of
>> >> UP/DOWN/ENTER/ESC. It would be easier to quickly search/navigate if it
>> >> could be done with fingers stationed on the arrow keys so that the eyes
>> >> can stay focused on the screen.
>> >>
>> >> Current (disliked-by-me) behavior:
>> >>    LEFT ARROW: Jump to top menu entry (same as HOME and PAGE UP)
>> >>    RIGHT ARROW: Jump to bottom menu entry (same as END and PAGE DOWN)
>> >
>> >
>> > A minor correction. In a boot menu, [Home] and [End] move to the
>> > respective first and last items. In a "short" (less than one screen)
>> > menu, the [Page Up] and [Page Down] keys seem to obtain the same
>> > result. But in a "larger" menu,  the [Page Up] and [Page Down] keys
>> > will move the selection one page up/down, respectively.
>> >
>> >
>> >> Preferred (requested) behavior:
>> >>    LEFT ARROW: Return to previous menu (same as ESC on a submenu)
>> >>    RIGHT ARROW: Enter submenu (or no action if not on a submenu entry)
>>
>> > Considering that there is no "new" proposed action, breaking the
>> > current behavior would be questionable for users that are already
>> > taking advantage of it.
>>
>> > I am not against changing behaviors (sometimes, it is worth), but
>> > IMHO breaking a current behavior has to bring a very _clear_ gain,
>> > while such change should be as less traumatic as possible for current
>> > users.
>>
>> In my opinion, this would be better addressed with a conditional
>> directive than an outright change in current behavior.  Since it only
>> affects (vesa)menu.c32, it should begin with "MENU ", perhaps "MENU
>> ARROWKEY" (perhaps someone will think of another alternate behavior in
>> the future).  It should also accept 1 optional parameter to turn it on
>> or off.  When not present, it should turn the new behavior on.
>>
>> --
>> -Gene
>
>
> What exactly do you mean with "When not present, it should turn the
> new behavior on"?

When the _parameter_ is not present.

-- 
-Gene