-
Notifications
You must be signed in to change notification settings - Fork 202
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Console buffer does not redraw (OpenConsole bug?) #727
Comments
Here are my findings on Windows 11 x64 [10.0.22631.2265], Far Manager x64 [3.0.6183] under (1) So under (2) As for So I think both problems 'delay in refresh under |
Thank you!
Cannot confirm for my system. 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. |
Imagine a really long scroll ( |
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. |
Indeed, and I was able to implement this as workaround for my macros. 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. |
|
Why? It already works as expected when you press Esc. |
Because it does not. |
What do you expect to happen? |
I expect that console window scrolls to fit Far UI. (Alternatively, I would be happy if just my Esc macro be called, but that does not happen either) |
Just to confirm, I'm doing this:
Are you saying the last step in this particular sequence doesn't work for you? |
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.
|
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. |
Although ok, let's try. |
After testing one more time I have found that Esc doesn't work when I use The only minor cosmetic thing: after Esc cursor is set in leftmost bottom position, while it would be rather expected in command line. |
Currently "Esc" implemented as
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. |
Is really part 2 necessary? |
Cleaning up after yourself is always a good idea. |
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. |
They did. You can find a fixed OpenConsole in WT nightly builds. |
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
Steps to reproduce
OpenConsole.exe
.OpenConsole.exe far.exe
with single macro file installed.dir /s
.Expected behavior
And even
v1.13.11431.0
performs worse thanconhost.exe
.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?
I hope @drkns can help me with this.
The text was updated successfully, but these errors were encountered: