windows: Unexpected "beep" on window resize

[avih]

Steps to reproduce:

Run less main.c and resize/maximize/restore the window (cmd.exe window or windows terminal).

Expected behavior: the content is re-rendered to fit the new window size, and nothing more.

Actual result: the content is re-rendered correctly, but additionally there's a "ding" sound - like when reaching the top/bottom of the content.

Sometimes there's also a ding when less starts - before any resize happened.

Can you reproduce it?

I've debugged it a bit, and the issue seems to be (at least in "master") that tbuf[0] here contains the byte value -3:

less/command.c

Lines 1542 to 1553 in 14e997e

	/*
	* Don't use cmd_char if we're starting fresh
	* at the beginning of a command, because we
	* don't want to echo the command until we know
	* it is a multichar command. We also don't
	* want erase_char/kill_char to be treated
	* as line editing characters.
	*/
	char tbuf[2];
	tbuf[0] = c;
	tbuf[1] = '\0';
	action = fcmd_decode(tbuf, &extra);

and action ends up as 100, which is A_INVALID, and this ends up at the default of the command switch - which does lbell.

I didn't try to analyze where this -3 value come from.

This did not always happen. I've bisected it, and the first bad commit is b3f04c3, which is between v688 and v689.

This seems to be part of the "on resize: re-render the content for the new size" changes, and indeed most earlier commits do not re-render correctly on resize.

However, few commit before it, e.g. the prior commit 6e29456 does re-render correctly on resize - and without the beep.

[avih]

I didn't try to analyze where this -3 value come from.

-3 seems to be #define READ_AGAIN (-3), so maybe a result of win32_enqueue(READ_AGAIN); which is not dequeued correctly?

[gwsw]

Fixed in 4d4583c.

[gwsw]

BTW you may notice that resizing the window doesn't work if you are in F mode on Windows (and has never worked). This is fixed in the post700 branch but the fix is too risky to include in the current beta.

[avih]

Fixed in 4d4583c.

Confirmed no more beeps on resize. Thanks.

BTW you may notice that resizing the window doesn't work if you are in F mode on Windows (and has never worked). This is fixed in the post700 branch but the fix is too risky to include in the current beta.

I'm not using F mode so I have not noticed it, but I'll try to check it out at some stage (maybe after it's merged into master).

Agreed that the READ_AGAIN fix does belong in master.

By the way, it looks like that this -3 value enters the KB input queue, is that true? Is it also the case on other platforms (non-windows)?

If it does enter the KB queue, is there any chance where this or other special values clash with actual key presses which also translate to the same values?

I think -3 specifically (253) will not clash with UTF-8 bytes, but what about other special values, if any? is the queue always UTF8?

[gwsw]

Well, there are a couple of queues. There is a Windows-specific queue win32_queue. All Windows input passes through that queue. It stores individual UTF-8 bytes, not full Unicode chars, and it stores each byte as a signed int, so a queued READ_AGAIN can't be confused with a real char, regardless of the char's value, since a real char will always be 0-255, not negative.

There is also a platform-independent queue ungot, which is used for ungetting a peeked char and things like that. Not all input goes through that queue, and it only receives actual chars, not error codes like READ_AGAIN.

[avih]

It stores individual UTF-8 bytes, not full Unicode chars, and it stores each byte as a signed int, so a queued READ_AGAIN can't be confused with a real char, regardless of the char's value, since a real char will always be 0-255, not negative.

Right, so assuming no bugs (like this one), there should not be any clashes. Thanks.

There is also a platform-independent queue ungot, which is used for ungetting a peeked char and things like that. Not all input goes through that queue, and it only receives actual chars, not error codes like READ_AGAIN.

Right. Good to know.

Thanks.