Console buffer does not redraw (OpenConsole bug?)

[johnd0e]

Far Manager version

3.0.6183.0

OS version

10.0.19045.3324

Other software

OpenConsole.exe v1.14.1432.0 or newer.

And these macros

-- Buffer: scroll with plain keys when Panels are hidden
local function inUserScreen()
  return not APanel.Visible or Area.Desktop
end

Macro {
  area="Shell"; key="Up";
  condition=inUserScreen;
  action=function()
    Far.Window_Scroll(-1)
  end;
}
Macro {
  area="Shell"; key="Down";
  condition=inUserScreen;
  action=function()
    Far.Window_Scroll(1)
  end;
}
Macro {
  area="Shell"; key="PgUp";
  condition=inUserScreen;
  action=function()
    Far.Window_Scroll(-Far.Height)
  end;
}
Macro {
  area="Shell"; key="PgDn";
  condition=inUserScreen;
  action=function()
    Far.Window_Scroll(Far.Height)
  end;
}

Steps to reproduce

0. Download some fresh Windows Terminal release, and extract single OpenConsole.exe.
1. Launch OpenConsole.exe far.exe with single macro file installed.
2. Make sure that console buffer is big, and fill the buffer with something like dir /s.
3. Hide panels with Ctrl-O and play with Up and Down, just to make sure that all works as expected - buffer scrolling is ok.
4. Now try PgUp / PgDn - and observe the bug: the buffer content is not refreshed after scrolling.
5. Press e.g. F10 and observe that buffer gets at last refreshed.

Expected behavior

• v1.14.1432.0 - the first "bad" version
• v1.13.11431.0 - the last "good" version

And even v1.13.11431.0 performs worse than conhost.exe.

• conhost reacts on PgUp immediately
• OpenConsole v1.13.11431.0: reacts after small delay (though I did not try to track it down to earlier versions)

P.S.
It would be interesting to try it with conhost.exe in Windows 11 as well, but I have no one.
@yegor-mialyk?

Actual behavior

Apparently this is bug in Windows Terminal code, so why I report it here?

• To confirm that it is reproducible
• And because i do not have enough competence to explain the bug without mentioning Far Manager, Lua macros, etc.
  I hope @drkns can help me with this.
• And it also possible to find some workaround, to force redraw console.

[yegor-mialyk]

Here are my findings on Windows 11 x64 [10.0.22631.2265], Far Manager x64 [3.0.6183] under conhost.exe (1) and OpenConsole.exe (2) from Windows Terminal Preview [1.18.1462.0]

(1) So under conhost the Up/Down keys work great and the screen refreshes fast, as for PgUp/PgDn keys, they do work as well but the screen refresh is delayed. I put a break point in console::SetWindowRect() method [console.cpp, line: 724] and found that SetConsoleWindowInfo() returns immediately but the screen is not refreshed until some time (maybe a refresh is done in a different thread).
An interesting finding is that if I press Alt+F9 (full screen) PgUp/PgDn keys start working smoothly and as fast as Up/Down.

(2) As for OpenConsole it looks like the behaviour the same as yours: Up/Down keys work great, PgUp/PgDn - no screen refresh. BUT, if I press Alt+F9 (full screen) PgUp/PgDn keys start working smoothly.

So I think both problems 'delay in refresh under conhost' and 'no refresh under OpenConsole' need to be forwarded to MS.

[alabuzhev]

microsoft/terminal#15932

[johnd0e]

Thank you!

@yegor-mialyk

An interesting finding is that if I press Alt+F9 (full screen) PgUp/PgDn keys start working smoothly and as fast as Up/Down.

Cannot confirm for my system.

@alabuzhev

Is it possible to force-redraw console programmatically in some way?
(Like I mentioned earlier, pressing F10 helps)

[alabuzhev]

Is it possible to force-redraw console programmatically in some way?

Not directly, but I guess writing something or moving the cursor around will do the trick.
Another option is to scroll in chunks < window height.

[HamRusTal]

scroll in chunks < window height

Imagine a really long scroll (M lines). Rather than do it in many small chunks (K lines each), will it work to make one (M-K)-line scroll (no refresh due to the MS bug) followed by a small K-line scroll that would hopefully cause the required final redraw?

[yegor-mialyk]

followed by a small K-line scroll that would hopefully cause the required final redraw?

It does not work for me under OpenConsole, after the screen stops refreshing (e.g. PgUp), single 1-line scrolls (Up/Down) do not help.

[johnd0e]

moving the cursor around will do the trick.

Indeed, and I was able to implement this as workaround for my macros.
The only issue left - is Far's own Esc handling: if Far is not currently fully contained in buffer window, then it scrolls window to proper position. The problem is that console content is not updating.

It's impossible to fix with macro, because Far does not call macros in this case.

So I ask you to implement the fix in code: on Esc not only scroll console buffer to Far's position, but also set cursor's position, to force console content update.

[johnd0e]

So I ask you to implement the fix in code: on Esc not only scroll console buffer to Far's position, but also set cursor's position, to force console content update.

@alabuzhev ?

[alabuzhev]

Why? It already works as expected when you press Esc.

[johnd0e]

Why? It already works as expected when you press Esc.

Because it does not.
E.g. if I scroll more than 1 screen up and press Esc - nothing happens.

[alabuzhev]

What do you expect to happen?

[johnd0e]

I expect that console window scrolls to fit Far UI.
That is normally happening when I'm using old conhost.

(Alternatively, I would be happy if just my Esc macro be called, but that does not happen either)

[alabuzhev]

I expect that console window scrolls to fit Far UI

Just to confirm, I'm doing this:

• add your macros.
• press CtrlO to turn the panels off.
• press Up three times. The buffer scrolls back 3 lines and is properly redrawn.
• press PgUp three times. Nothing happens.
• press Esc once. The buffer is all the way down again and is properly redrawn, UI (clock, keybar) is visible.

Are you saying the last step in this particular sequence doesn't work for you?

[johnd0e]

Exactly, the last step doesn't work.

Though I'm not sure about whole scenario, because I have improved my macros (by your advice), and now there is no problem with PgUp.

Anyway I meant clean Far without any macro.
To reproduce you can scroll it up with scrollbar.
Then press Esc.

• with conhost: buffer scrolls back to Far.
• with openconsole: nothing happens.

[alabuzhev]

Esc does work for me for some reason, but, as I mentioned elsewhere, bugs are not necessarily deterministic, so it's not that surprising after all.

The WT issue I created has been added to v1.19 milestone, so they might fix it relatively soon, which would be great.
Let's wait and see, if they fix it - awesome, otherwise we can add a workaround.

[alabuzhev]

Although ok, let's try.
I hope it won't break any old workarounds for other Win10 bugs.

[johnd0e]

Esc does work for me for some reason

After testing one more time I have found that Esc doesn't work when I use SetConsoleCursorPosition in my macro.
But with 6192 it is ok, thank you.

The only minor cosmetic thing: after Esc cursor is set in leftmost bottom position, while it would be rather expected in command line.

[alabuzhev]

after Esc cursor is set in leftmost bottom position

Currently "Esc" implemented as

1. move the cursor to the very last row
2. if it was in the UI area, move it back

because moving the window programmatically is full of bugs, while moving the cursor (and the window along with it) is still more or less reliable.

Since you moved the cursor outside of the UI area before pressing Esc, part 2 does not happen.
The code that does this conceptually has no information about command line and where the cursor is virtually expected to be.

[johnd0e]

Is really part 2 necessary?
What use case does it serve?

[alabuzhev]

Cleaning up after yourself is always a good idea.

[johnd0e]

The code that does this conceptually has no information about command line and where the cursor is virtually expected to be.

I suppose it is not so trivial to find out supposed cursor position, right? Dialog, Editor, Command line...

Ok, I can probably live with it. Let's hope MS will fix it soon.

[alabuzhev]

Let's hope MS will fix it soon

They did. You can find a fixed OpenConsole in WT nightly builds.