Disable xterm strings when WP is running?

[emendelson]

This is probably something that any experienced Linux user already knows, but I can't figure it out.

I run wpunix in the Windows Subsystem for Linux, in xterm. When I press a function key in wp, it sometimes types the corresponding string listed on this page:

https://gist.github.com/hlecuanda/3fd34c87e5d61eb7d18566b2b3eded0b

Is there any way to turn off these strings while wp is running?

Again, if this is painfully obvious, I apologize for wasting bandwidth.

[taviso]

When you press a function key it generates an escape sequence - literally an escape character (i.e. as if you pressed Esc) followed by a short string to identify the key.

The problem is it's difficult to determine if you're pressing Esc and then literally typing something weird like [18~, or if you pressed F1, because both of those generate identical input events. The only difference is that one usually delivers the whole sequence in one quick operation, and the other happens in distinct slow operations - so we guess based on how the events arrived.

Yes, this is not very elegant - we're stuck with some design decisions from the 70s 😂

People sometimes report bugs like this if they login over a very slow network, because it makes these big input events look like they're coming in slowly... but it's hard to believe WSLg is that slow, even if it's a bit slower than Linux.

When this happens does it look like WordPerfect thinks you're typing Esc then a random string? That would suggest WordPerfect is getting the correct sequence, but the timeout it's using to ensure it received the complete sequence needs to be increased.

If it doesn't look like that, then maybe WordPerfect just isn't seeing the Esc at all and it's getting lost somewhere? I think we might need strace logs of WordPerfect when it happens to see what it's getting, I guess that sounds like a WSLg bug, but if we know why maybe we can workaround, not sure...

[taviso]

I quickly read through the logic in wp, I think what it does is every time it receives input it checks if more input is available by calling select() with a zero timeout. If there isn't any more input available, it assumes it got the whole message.

In my opinion that is a pretty aggressive timeout - for comparison, I think vim uses 100 ms by default - so we could try raising it... 🤷‍♂️

[emendelson]

It does look as if WP is getting the correct sequence but the timeout needs to be increased. The string that appears always matches the one in that page of xterm function key strings. If you can increase the timeout, that would be terrific. (Would it be possible to let the user increase/decrease the timeout some day?)

[taviso]

Yes, can probably make it a variable - let me see if I can make you a test patch tonight just to see if it fixes the problem. If it does, maybe I can write it properly. Can you reproduce it reliably?

[emendelson]

Here's a reproducible example:

Start wp.
Press these keys, pausing briefly between them:
Esc
F7

What appears on screen is always:
[[[[[[[[18~

That should be eight open-square-brackets, followed by 18, then a tilde.

Here's another sequence:

Esc
F1

This produces 00000000P.

These aren't logical keystrokes but maybe they point to the problem?

I can test tonight (Eastern time) or tomorrow!

[taviso]

Hmm, so I think that might be correct... maybe this is a DOS vs UNIX thing?

You will know better than me, but I think in DOS, just Esc means "Repeat"? In UNIX it uses Esc,Esc instead.

So If you type Esc,F7 wp sees this:

EscEsc[18~

Which means repeat [ the last repeat count number of times, then type 18~.

Timeouts never trigger here, because there is no possible way to split this sequence into another valid input. A timeout is only ever used if there are multiple possible ways to interpret a sequence, and we need to decide which one is correct - but in this case there is only one valid interpretation.

The complicated explanation is that it traverses a binary tree to determine what escape sequence matches a known binding, and it only uses timeouts if it doesn't reach a leaf (i.e. a terminal node on the tree), if it does find a leaf then no timeout is necessary because the input was unambiguous.

[emendelson]

In DOS or Windows, Esc always means Cancel - except in the "Original Keyboard" layout in WPDOS 5.1, where it means Repeat and generates a prompt for the number of times to repeat the next key. Every sane user of WPDOS 5.1 switches to the Alternate Keyboard where Esc means cancel, as in everything else. - And I just saw that I can switch to the Alternate Keyboard in Unix WP, which I've just done, but I don't see any effect on the Esc key.

Will experiment with using the keyboard editor to make the Esc key perform Cancel and another key to open the menu, but probably not until tomorrow, unfortunately.

[emendelson]

I forgot to report back a few days ago; apologies. I tried to create a keyboard layout where the Esc key produced {Cancel} but that didn't seem to have any effect. I'd like to make WPunix fully usable in WSL, but will need to work on this more. Apologies again for not having anything useful to report.

[taviso]

Yeah, it's not going to be possible to rebind Esc unless we rewrite the key mapping code to make that work - I'm reluctant to do that because we will need timeouts to differentiate between EscEsc and Esc,Esc which I think existing users will find confusing.

You can rebind Esc,Esc easily though.

[emendelson]

Understood! I already tried rebinding Esc,Esc to Cancel but it didn't prevent odd strings from appearing in the text when I used various states of the function keys. I'll keep exploring...

[taviso]

Do you have a way to reproduce it? It could still be a timeout problem!

Maybe it's also possible that you're hitting Esc reflexively and accidentally starting a multi-key input? I suppose a solution to that could be to show an indicator on screen when that happens.

[emendelson]

Here are a few:

Esc then a brief pause, then Ctrl+F3 produces

[1;5R

Esc then a brief pause, then F9 produces

[20~

Esc then a brief pause, then F8 produces

[19~

I probably have a bad habit of pressing Esc when I shouldn't, but it's hard to outgrow it...

[taviso]

I think these are also working correctly, because Esc,F8 is not a valid shortcut, so it's being interpreted as {Repeat} and then some junk. (Note: Esc,Esc F8 is valid though)

I think there are two possible solutions...

1. An indicator appears when you press Esc so that you know you are starting a multi-key shortcut? The result won't change but maybe it will be less confusing when you see input you weren't expecting...?
2. Add a timeout so that after you press Esc and then wait, it resets? How brief a pause are we talking, does 100ms sound like it would work? This would have to be optional, because right now you can wait as long as you like, so anyone used to that behaviour will be confused instead!

[taviso]

Wait a minute - you can just bind Esc to {Cancel} in xterm!

I dunno, something like this?

XTerm*vt100.translations:   #override\n<Key>Escape:string("\033OP")\n

You will have to bind {Repeat} to something else, although maybe Alt+Esc will work, unless Windows reserves it?

Note: I have no idea if this will break anything, you might need to experiment! This will also affect any other application you run inside that terminal, if you do run other applications you will need to setup individual profiles, like xterm -name WordPerfect

[emendelson]

Yes! Adding that line to .Xresources and then running xrdb ~/.Xresources seems to have fixed this problem, though I only a few moments to test it. The fix works only with the Alternate Keyboard setting in Environment set to No.

I'll continue to experiment this and will report back. This may make WPunix fully usable in WSL. Thank you!

[taviso]

Just some notes if you want to experiment: \033OP means F1, I figured out the required value like this:

$ infocmp -1 | grep kf1=
        kf1=\EOP,

(\033 is just octal for escape, infocmp uses \E as a shorthand).

XTerm is very highly configurable, so it's probably possible to do anything you want.... but it might require some arcane terminal knowledge 😂

Maybe it makes more sense to bind it to {Repeat} (i.e. \033\033) and then bind {Repeat} to something else in wp, not sure.