[syslinux] comments about 5.00pre10

[Ady]

> On Sat, 2012-11-17 at 21:09 +0000, Matt Fleming wrote:
> > > 7_ When using menu.c32, the boot prompt behaves as if MENU CLEAR is 
> > > always used. I previously reported this when testing menu.c32 to 
> > > pwd.c32, but the same happens with any other image or even with 
> > > [ESC].
> > 
> > OK, I'll look into this.
> 
> Looks like Peter was the one that changed this,
> 
> commit 6ab02b6682c0b693b3e4f9afcc2ab8775f804f0a
> Author: H. Peter Anvin <hpa at zytor.com>
> Date:   Tue Mar 27 14:39:46 2012 -0700
> 
>     menu: Make "menu clear" the default
>     
>     Make "menu clear" the default... it was sort of implicitly so at least
>     for vesamenu when using the old system, since we would end up zapping
>     the mode when any output happened, but that no longer is the case.
>     
>     Also move the cursor to the top of the screen.
>     
>     Signed-off-by: H. Peter Anvin <hpa at zytor.com>
> 
> Ady, unless you know of a reason where this isn't wanted, I'm inclined
> to just leave Peter's commit as-is.
> 
> -- 
> Matt Fleming, Intel Open Source Technology Center
> 
> 

As for reasons, let me mention several possibilities.

First, it is working recurrently in some cases. In my previous report 
I mentioned several situations where the first line of some result 
(like the DISPLAY files, F1-F12 for example) was not displayed. Or 
when the boot prompt seems to fail, it really wasn't. After showing 
some kind of "fail" message, you can still act on the boot prompt and 
it cleans the screen, but it is not doing it correctly.

In addition, now it is forced, not just for VESAMENU, but also for 
menu.c32 and maybe (I would have to review my tests) for no UI 
directive present too. It certainly makes "debugging" (in the sense 
of understanding what's wrong) unnecessarily more complex for the 
final user.

Moreover, we are talking about making useless an already-existent 
directive. I fail to see the advantage of changing this behavior. If 
someone wants this behavior, simply use the directive.

About adding an "off/on" situation for directives (as mentioned by 
Peter in another email of this same thread), I think that the same 
names of already-existent directives should be maintained. Adding NEW 
directives, like "MENU NO CLEAR" makes no sense to me. IMHO, the 
simplest way to maintain coherence between several different 
directives (with some additional advantages, like simpler 
documentation changes, that I could expand on if necessary) is to add 
"0 (zero) / 1 (one) / -1 (negative one) / [some other value] " to the 
current directive(s) when adequate.

For example, in 4.06 "MENU CLEAR" is not the default, so the 
equivalent non-default would be "MENU CLEAR 1" ("MENU CLEAR [1]"). In 
5.00pre10, "[MENU CLEAR [1]]" would be the default and "MENU CLEAR 0" 
would revert the behavior.

Finally, at least until other issues are resolved, I would suggest 
releasing the next 5.00-pre11 with that MENU CLEAR change reverted to 
what was the default before. Reverting that commit would let users 
test and compare to older behaviors, identifying what is REALLY not 
working as expected in 5.00-preXX. Once other problems are resolved 
and only if it is really necessary, the MENU CLEAR directive could be 
set back as default and test again, so to find out if it is really 
necessary or convenient, or has any advantage (which I fail to see), 
and if the expected behaviors are still maintained or if instead it 
introduces issues (which as of pre10, it does).

TIA,
Ady.