Fix help screen

[ghaerr]

Fixes help screen display issue(s) described in #2.

[ghaerr]

The last push allows for (partial) display of the teletype/MDA/CGA column on terminals with width less than 240. This enhancement allows for the same display on 240+ character wide displays but allows for seeing console output without having to decrease the displayed font size without having to take up the entire screen area, which I feel is a reasonable tradeoff for better usability of blink.

[jart]

Thanks for sending this, and welcome as a new contributor!

Could you please send me an email (to jtunney@gmail.com) where you say, "I intend to assign you the copyright to the changes I contribute to Blink and Cosmopolitan" and include a link to this PR in the email. Please send it from your real name via your primary email address. This is important because I need to own the code that goes in this repository, and I want to have it documented in email that you understand my wishes and that I'm respecting yours.

It's your responsibility to ensure that you're able to assign me copyright ownership. For example, (1) some employers make employees sign contracts that says the company owns everything you do. You can't give me something that doesn't belong to you. In that case, what I recommend is simply email your manager and tell them what you're doing. Make sure they feel comfortable with it. That's important because, once again, we need email records showing that we're respecting everyone's wishes.. Another example, (2) in some countries denizens are forbidden from assigning copyright altogether. If you live in such a place, then you can make your contributions public domain, using the language in either Unlicense or CC0.

[ghaerr]

Could you please send me an email (to jtunney@gmail.com) where you say, "I intend to assign you the copyright to the changes I contribute to Blink and Cosmopolitan" and include a link to this PR in the email

I sent you an email as above for Cosmopolitan a month or so ago, which you approved. Would you like me to (re)send again with Blink included? Please let me know, thanks!

[jart]

Yes please.

[ghaerr]

Hello @jart,

the kernel has a completely wrong idea of where the cursor is currently positioned in the actual terminal emulator, and as such, we need to emit a lot more \e[y;xH directives...

Just for kicks, I commented out the following line in PrintPanels() on my macOS system, using the standard Terminal for testing:

AppendFmt(&b, "\033[%d;%dH", y + 1, x + 1);  // bsd utf-8 :(

What I found is that the RDI ... and R8 ... lines are incorrectly displayed in the third column of my terminal display (macOS does have IUTF8 defined in termios.h). This goes a bit against your thought the bug is BSD only, or kernel related. I'm thinking that perhaps the issue is related to other things incompatible with some ANSI emulators (like for instance PrintPanels improperly displaying buffers with CR's included, which I fixed by removing them from the HELP message in this PR, rather than diving further into the problem).

If you'd like, we can look further into this issue, to determine the exact reason for the display problem. I'm guessing perhaps larger set of control characters or possibly UTF-8 sequences should trigger a possible panel cursor reposition, rather than the current solution.

Thank you!

[ghaerr]

And interestingly enough, with the above AppendFormat line removed, the cursor position bug only occurs on lines that are just to the right of a separate panel which has UTF-8 character(s) displayed:

Could there be an issue with the PrintPanels state machine, since the improper X,Y is only seen directly after a displayed UTF-8 character?

[ghaerr]

Hello @jart,

I've debugged the problem, and fixed it with the last push. It seems the requirement for the extra cursor position is not because of IUTF8 handling within the kernel, nor the terminal emulators that we possibly suspected. Instead, it appears that in PrintPanels, the wcwidth call is likely returning 0, and the following code used MAX(0, ...) instead of MAX(1, ...) in that case.

Changing the lines to

                      width = wcwidth(wc);
                      width = MAX(1, width);

fixes the problem, with no requirement for all the extra \Ey;xH cursor positions. Yay!

[EDIT: I'm still not really sure this is a wcwidth issue - it seems that wcwidth only returns -1 in the problem case, otherwise returns 1. Thus, while my fix solves the problem for now (and introduces a new issue if wc == L'\0', which matters little), it would appear that the tpdecode above may be assigning a -1 value to wc incorrectly on each last panel column when that character is not ASCII, perhaps due to further state machine problems within PrintPanels. Since I don't quite fully understand that state machine yet, I will leave that to you for further introspection].

[EDIT: Not tested on BSD, but confirmed fixed on macOS].

Thank you!

[jart]

Thanks for sending the email and doing the bug research. I think we're good to merge now!