Increasing the Far3 window size creates panel artifacts in the console window

[yulian5]

Far Manager version

3.0.6249.0

OS version

Windows 7, 10, 11

Other software

No response

Steps to reproduce

Increase windows size, mostly width, by dragging by the corner or border, or increase width through Windows Properties->Layout->Windows Size->Width. Switch to Console window (Ctrl+O).

It maybe related to similar issues #765 and #257

Expected behavior

Clean Console window.

When having a few monitors with different resolutions (like laptop with external monitors) it's quite frequently requited to resize windows including Far3.

Actual behavior

Multiple artifacts from Panels drawing:

When dragging for the corner:

When using Properties->Layout->Windows Size->Width:

Problem exists with Legacy console too. Loos like Far 2.0 doesn't have that problem.

[Zeroes1]

this option removed?

[yulian5]

Hi @Zeroes1. No, option is checked, actually I see the problem regardless of this option, checked or not. Just increase the window size (reduce it first if it's too big from the beginning).

[alabuzhev]

Loos like Far 2.0 doesn't have that problem

Far 2 is a bug-free perfection. It is known.

Oh wai...

@yulian5 Zeroes's suggestion is correct.
When the option is checked, the host actively tries to break things, not much we can do about it.

[yulian5]

Hi @alabuzhev, that's interesting about Far2. I was not able reproduce that, tried just now. I mentioned about Far2 just in case that it may be new related changes in Far3 that you know. Not to prove that Far2 is better, Far2 is history now, I just have it on one of my computers.

not much we can do about it.

Far3 is drawing on the console canvas. It should be a way to fix that problem.

When the option is checked

When option is not checked there are also artifacts, just in less degree:

[yulian5]

Original post about resizing was correct. It happens not only while increasing the windows size but when decreasing as well:

[alabuzhev]

When option is not checked there are also artifacts, just in less degree

Conhost being conhost.
When it enlarges the window, it uses the colors of the rightmost column for the new cells.
Why? No idea.
I implemented a workaround for this years ago (by re-filling those areas with the default color manually), and it even worked back in Windows 7 or so. In 10 MS reworked the host a lot and broke a lot as well, so I'm not surprised that it happens again.
However, this particular issue is potentially fixable.

not only while increasing the windows size but when decreasing as well

Your screenshot shows a graphical artefact outside of the screen buffer.
I'd be happy to fill that one too, but see above: it's outside of the screen buffer.

[w17]

Far2 is history now

Far3 5555 is history too.

[Zeroes1]

@yulian5 You try use Windows Terminal?

[yulian5]

Far3 5555 is history too.

@w17 Good joke. Why do you think so? Regarding this problem they're the same.

[yulian5]

You try use Windows Terminal?

@Zeroes1 What do you mean? I think the problem is integration Far3 with Conhost.

Originally I thought it's just a redrawing problem for empty space. But it looks more serious now. Let me add some screenshots.

[yulian5]

@alabuzhev mentioned:

I implemented a workaround for this years ago (by re-filling those areas with the default color manually), and it even worked back in Windows 7 or so.

Actually for Windows 7 it's the same problem (sorry for historic Far3 6116):

[Zeroes1]

Far can work with Windows Terminal without conhost under Win10/11/srv2022
try for example https://aka.ms/terminal-canary-zip-x64
it's portable build

[yulian5]

@alabuzhev said:

Conhost being conhost.
When it enlarges the window, it uses the colors of the rightmost column for the new cells.
Why? No idea.
I implemented a workaround for this years ago (by re-filling those areas with the default color manually),

It looks now that mentioned workaround erased most content of Conhost window inside Far. Please see the screnshots (latest Windows, latest Far3).

Running Conhost and Far3, the same size, print directory, reduce the width, then increase width to previous value. Conhost itself is doing fine, but Far3 console window is not.

[Zeroes1]

WT use GPU for render very usefull speed...

[yulian5]

Far can work with Windows Terminal without conhost under Win10/11/srv2022

@Zeroes1 How can I replace console in Far3?

[yulian5]

@alabuzhev Can this MS Conhost code help in that problem?

[Zeroes1]

for example try my settings?
unpack for example C:\UTILITY\Terminal
Microsoft.WindowsTerminalCanary_latest_x64.zip
unpack my settings.7z
to
\terminal\settings\
change settings.json
"commandline": "C:\Far4\Far.exe", to yours path
make link to desktop
run...

change font too

or make default profile himself :)
settings.zip

[alabuzhev]

It looks now that mentioned workaround erased most content of Conhost window inside Far.

It's unrelated. The erasure is by design.

Can this MS Conhost code help in that problem?

Depends. You've mentioned like 10 different issues here already. Some of them can (and should) be addressed in conhost, like reusing rightmost colors for new cells on resize and visual artefacts in the gap between the buffer and the window edges, some other are by (new) design and will likely be rejected.

[yulian5]

@Zeroes1 Thanks! I was able to run WT based on your instructions with your settings. But I see the same problem. Do I need to adjust something else? Can you check on your system? Just make Far3 smaller and increase the width with both panels on.

[yulian5]

@alabuzhev

It's unrelated. The erasure is by design.

Why is that? Conhost doesn't erase anything after resizing.

You've mentioned like 10 different issues here already.

Sorry. Discussion went wild. Can you just select one fixable issue for this ticket? I do not have enough Far3 knowledge to properly separate them. I didn't expect so many of them from resizing. But I'm going to create one more ticket for resizing issue which is separate for sure.

some other are by (new) design and will likely be rejected.

Why is that? Don't we all want to fix Far Manager problems?

[alabuzhev]

Why is that? Conhost doesn't erase anything after resizing.

"Wrap output on resize" assumes that all the output is static and stream-like.
When you resize with the option enabled, the host takes the text, reformats it to the new width and puts it back.
cmd.exe doesn't have any UI, commands like dir generate static stream-like text, so everything kinda works more or less as expected: the host does its thing, cmd.exe doesn't interfere, doesn't care, doesn't even notice.

Far isn't cmd.exe. It does have dynamic UI, represented as structured, table-like blocks of text. It doesn't make any sense to reparse it on resize, so the host makes things only worse, as can be seen on your very first screenshot. The output of dir, started from Far, is not a stream of text anymore, it's a text screenshot of it and basically a part of Far UI at this point. When the buffer is resized, that screenshot is trimmed to the new size as well, so everything that doesn't fit is lost forever.

Having said that, in theory we can skip that trimming and keep the captured output as is, hoping that it will be useful if the user enlarges the buffer again later. A rare scenario, but I won't mind if you create a new issue with a reference to this comment just in case.

Can you just select one fixable issue for this ticket?

#772 (comment) and #772 (comment) are actual (and likely entirely unrelated) conhost issues that should be relatively easy to fix.

Why is that?

Let's say these days MS is more interested in aligning with "other operating systems" in the command-line application space than in maintaining 100% backwards compatibility.

[Zeroes1]

@yulian5
ON this

problem still exist? I no have trouble, i change size by mouse.

[yulian5]

@alabuzhev, thanks for detailed info!

#772 (comment) and #772 (comment) are actual (and likely entirely unrelated) conhost issues that should be relatively easy to fix.

Sounds good to me! Anyway too many problems at once.

[yulian5]

@Zeroes1 I tried that. The same rendering problem. Strange that you cannot see it: Make Far window small with mouse, then make it big with both blue panels ON. Then turn OFF the panels (Ctrl+O) and check the console screen.

I'm not sure exactly what "Use Virtual Terminal for rendering" means. Just found one more small problem, F1 help for this screen doesn't describe it.

@Zeroes1 It looks like we have some misunderstanding about WT you mentioned before. I thought we're talking about replacing console inside Far instead of Conhost with something else not running Far from another console.

[Zeroes1]

@yulian5

ran:
far:config
search:
System.WindowMode
set to FALSE

re run FAR

better?

[yulian5]

@alabuzhev

Having said that, in theory we can skip that trimming and keep the captured output as is, hoping that it will be useful if the user enlarges the buffer again later. A rare scenario

At least that part is quite clear for me. But by default the text buffer is quite big like 3000 or 9000 lines. Changing width even to extreme small size still preserves quite a big buffer. Trimming lines doesn't feel right, especially when after enlarging they are filled with garbage. And user can copy that garbage as a text.

BTW Far2 has exactly the same trimming problem. But I still cannot reproduce other garbage in Far2, it always black console screen for me with trimmed text after resizing. Far2 doesn't honor height changes well.

@alabuzhev Far3 5555 has serious panels rendering problems after changing size with keyboard through Windows Alt menu. But I do not see that with the latest 6249. Are there some related rendering changes between those two versions?

[yulian5]

@Zeroes1

System.WindowMode
set to FALSE

Thanks! That much better in this regard. Always black console window without extra rendering garbage. Still trimmed text but that is already expected. But one additional problem now: Far3 doesn't honor reducing the height. When I shrink the height I have to scroll to see the bottom or the top.

[Zeroes1]

@yulian5 FYI: scroll output console in WT: Shift + scroll mouse

[yulian5]

@Zeroes1 OK. Thanks!

[AVBL]

I don't know if there is a connection with the discussion above, but I also want to add about resizing the FAR window. Original FAR window:

After starting fullscreen game with lower screen resolution:

After exiting game Windows restores desktop resolution, but FAR windows doesn't (see previous screenshot). I am trying to restore the contents of the window via double Alt-F9, without restarting the program, but...

[AVBL]

(For me, the above is a problem, but I can't say if there is some kind of bug in this or if it is purely an enhancement request).

[alabuzhev]

Are there some related rendering changes between those two versions?

It is possible that a change or two slipped in over the course of 4 years.

[yulian5]

@alabuzhev, thanks! Actually quite a stupid question from me, consider thousands commits. I didn't realize how fast time is passing! But this one 44a55b9 looks like a right one.

So @w17 is absolutely right and 5555 is a historic version. What a pity! I like number 5. Guess I have to wait till version 55555 to get an excellent version number. Do we even have enough bugs for that?

[yulian5]

@Zeroes1, thanks for information about running Far in WT. It's an only solution to run Far3 without ConHost I saw so far. And it's quite interesting development indeed.

I tried ConEmu but it looks like it still use conhost.exe. I found "extendedconsole.dll" in Far3 code, it looks like it was some attempt to integrate it.

[yulian5]

@alabuzhev explained:

Far isn't cmd.exe. It does have dynamic UI, represented as structured, table-like blocks of text. It doesn't make any sense to reparse it on resize, so the host makes things only worse, as can be seen on your very first screenshot. The output of dir, started from Far, is not a stream of text anymore, it's a text screenshot of it and basically a part of Far UI at this point. When the buffer is resized, that screenshot is trimmed to the new size as well, so everything that doesn't fit is lost forever.

Thanks! I was under wrong impression that Far a has separate console window as Far console emulation is very good (except resizing). I tried to check code but it's quite complicated with comments basically only for fixes. But it looks like the screen buffer is the same for UI and console output with console text in blocks and naturally it's a crazy complicated task to resize all that stuff correctly. But the excellent news is that UI itself is resizing almost always correctly (rebuild from the scratch?)! Only console output is messed up and only after resizing.

If I develop console app with user UI, the app will have separate buffers for UI (blocked based) and for console output (stream based, array of lines). Then we have mask of blocks indicating which areas are filled with UI and which areas are available for console output.

The app starts with empty screen buffer, builds UI and then scans console buffer lines (starting from cursor line), fills the empty blocks with text parts available for console output based on the UI mask and conditions (text wrap and screen buffer width).

Then, OK, let's resize the screen. Basically, we have no good choice but start from the empty screen buffer again and rebuild the UI. We do not have to resize console buffer, we actually do not have to do anything with it at all (except update it with new console output, if any). We again scan console buffer lines using our UI mask with empty blocks for console text output and conditions we have (wrap, width) and fill them with console text. Then everything should resized correctly (rebuilt actually).

[alabuzhev]

console output (stream based, array of lines)

Console output could be anything.
It could be one line, split to multiple lines due to wrapping (type some_poem.txt).
It could be an array of potentially wrappable lines (dir some_dir).
It could be an unwrappable block (type my_fancy_table_with_pseudographics.txt).
When we read it back after the app exits, we don't know and we can't know.
Treating it as an opaque static rectangle is the best we can do.

[yulian5]

@alabuzhev

You've mentioned like 10 different issues here already.

Treating it as an opaque static rectangle is the best we can do.

That doesn't work well and not fixed for 28 years. Does it still seem like the right approach?

[alabuzhev]

Does it still seem like the right approach?

It does if the alternatives are worse, which I think is the case.
But please don't take my word for granted, I could be wrong of course.

[yulian5]

@alabuzhev

It could be one line, split to multiple lines due to wrapping (type some_poem.txt).
It could be an array of potentially wrappable lines (dir some_dir).
It could be an unwrappable block (type my_fancy_table_with_pseudographics.txt).

I actually never worked with console apps except trivial cases. If you can get unwrapped lines from console output (most likely, yes), then all 3 mentioned cases are the same, just arrays of lines, and fit in the scheme I described. You can wrap and slice them to the blocks as needed.

I do not believe that there was a flaw in original Far design. At that time of small expensive memory, extra slow GPU and CPU speeds, primitive console, etc. that blocked design for console output was probably the best available option. Now we have a different situation and can afford a thousand extra buffers without any sacrificing. Just my opinion.

[MKadaner]

... console output (stream based, array of lines).

I am not sure I follow you. What exactly do you mean by "array of lines?" Console, at least on Windows systems, is a rectangular block of characters, 25 lines by 80 characters per line (ok, ok, these days it's more likely 9000 lines, 200 characters per line). Think of an electrical console typewriter (e.g., here and here). When a regular console application outputs stream of characters, they are printed one by one on the paper roll advancing printing position after each character by shifting the typewriter's carriage. When the printing position reaches the right edge of the paper roll, actually when the carriage traps the end-of-line lever, the carriage returns to the beginning of the line, and the paper roll is rotated by one line. All this happens automatically! The application also can control the carriage and roll movements. For example, to return the carriage to the beginning of the line, the application should output the Carriage Return character (ASCII 0D), and to feed the paper by one line, it should output, you guess it, Line Feed character (ASCII 0A).

What's important here is that after the character is transferred to the paper, the typewriter does not know why it has happened here. If a character is printed at the first (leftmost) position, neither the typewriter, nor the system have any idea of whether this character continues the word truncated at the end of the previous line or the application deliberately ended the previous line with the CR+LF sequence, or even if the application sent CR without LF thus causing the typewriter to print over the already printed character at the beginning of the line. What a mess!

Now, the console window, again, at least on Windows systems, is pretty much the imitation of the console typewriter. After the characters printed by a (regular console) application are set in the rectangular console buffer, neither the typewriter console, nor the system have any idea of... You've got it.

How does Conhost wrap the text when console window is resized? I bet nobody knows exactly, but it should be a job of advanced AI a bunch of guesswork. Something on the lines of, "if this line ends with a printable character, and the next line starts with a printable character, and it does not look like a command prompt, these two lines are more likely were spit out in a single breath and should be wrapped and rewrapped when the console window resizes." And, at the end of the day, Conhost does not do a great job anyway.

Unlike with the paper roll and the typewriter, with the console window we are blessed with the possibility to set a character in an arbitrary console buffer position (permanently overriding the unlucky previous resident of this position). So, Far draws its UI on top of whatever is in the buffer (carefully saving the original contents of the buffer to show it to you when you press Ctrl+Alt+Shift). Before launching an application, Far restores the buffer. The application adds more characters and exits. Far saves the buffer and draws its UI.

To do something nice with the contents of the buffer on resizing console window, Far basically has two options: (a) reproduce the dance performed by Conhost, and (b) before allowing the window to resize, restore the content of the buffer, somehow invoke Conhost to do its magic, then draw UI in the resized window. As you can guess, (a) is not an option because nobody knows exactly ... and ... does not do a great job anyway. My educated guess is that option (b) is impossible because to "invoke Conhost," Far would need to exit and then resurrect from the ashes like Phoenix when resizing is completed. I'll leave commenting on other possibilities to Alex, though.

[Zeroes1]

@yulian5

And of course you may encounter with another problems when working with FAR+WT vs FAR+ConHost:)

for example:
microsoft/terminal#15540

be ready...
I chose FAR+WT anyway :)

[yulian5]

@Zeroes1 Thanks! That is an interesting choice anyway, I didn't know before your information that Far may be run with alternative console. I do not using Far+WT now on regular basis, I think I need more testing and just to get used to it.

As for the topic of this issue, Far has the same console resizing problems either with ConHost or with WT, so I guess, logical conclusion that it's not their fault.

What other advantages do you know with combo Far+WT vs Far+ConHost?

[yulian5]

@MKadaner

Console, at least on Windows systems, is a rectangular block of characters

Now, the console window, again, at least on Windows systems, is pretty much the imitation of the console typewriter.

That is definitely wrong.

How does Conhost wrap the text when console window is resized? I bet nobody knows exactly

There is code for that MS Terminal, everybody can look.

And, at the end of the day, Conhost does not do a great job anyway.

Can you provide any proof of that? Does it have issues that fatally affect Far? Did you anyway mistaken it for the Far console emulation?

Windows console was quite powerful even when Far was created, just look closer at the Far UI, it's actually a miracle for a simple console typewriter. What do you think? And all this miracle is inside the Conhost which you are blaming.

As for mentioned problem so far I found only that ConHost itself doesn't resize output correctly in one case when the app prints on the same line multiple times (using '\r').

Blaming other development is not a good way to develop and fix issues. Some of them doing great job, some of them not so far for a lot of reasons. As for this resizing problems I see more blames than actual suggestions or development.

But @MKadaner in general I cannot reply to you more argumentatively, I'll learn this topic a little more and will return back to this.

From what I see, probably only @alabuzhev can fix that problem, as it arises from the original design and involves a lot of core changes. It's not a trivial fix, I guess. I can join to active development only about 2025. If it hasn't been fixed by then and nothing changes I'll work on it, it's a quite interesting task. I cannot say for sure currently what the solution may be.

And BTW during resizing Far screwed a lot of console output beyond its UI window, it should not do that, I guess. If you have buffer (not 9000 but much more than height of Far UI), perform dir /s command, check console output before and after resizing, most of the output after resizing either empty cells or reshuffled console output. I think, that is one more problem to list (and to fix eventually).

[bitraid]

Console, at least on Windows systems, is a rectangular block of characters

Now, the console window, again, at least on Windows systems, is pretty much the imitation of the console typewriter.

That is definitely wrong.

It is definitely correct. You can read about it (along with its evolution, some of its problems, the new ConPTY, and more) here: https://devblogs.microsoft.com/commandline/windows-command-line-backgrounder/

[yulian5]

@bitraid

It is definitely correct.

Yes, you're right. My bad. My GUI experience didn't help in that case.

As I mentioned:

I actually never worked with console apps except trivial cases.

in general I cannot reply to you more argumentatively, I'll learn this topic a little more and will return back to this.

But I do not believe that it's all ConHost and MS fault and it's not possible to fix.

[MKadaner]

There is code for that MS Terminal, everybody can look.

Of course, ConHost's source code does exist. Moreover, in Microsoft, they build it daily (or rather nightly). However, by no means it means that anybody knows how it works.

[Zeroes1]

@yulian5

What other advantages do you know with combo Far+WT vs Far+ConHost?

Tabs, cleartype, turbo speed of render, support unicode symbols, hotkeys (my favorite At-X - close current tab :), easy mouse selection area, scroll buffer, portable mode WT (easy my options on another computer), background picture...)
before use WT i use FAR under ConEmu 12 years...

[yulian5]

@Zeroes1

Thank you very much for the info! It's quite impressive. Do you have a portable Far3 for WT portable mode?
If I need more info or have questions, what is the best way to contact you?

[yulian5]

@alabuzhev

I started to look into Console API and Far 3 code, for sure it's very tricky to adjust console buffer size, my first impression is that width for console output buffer is less than width for Far UI console buffer but I didn't debug that yet.

What's about ConPTY? Maybe instead of fixing this problem and use "do not recommended to use" console API start migration to ConPTY? It will help to port Far3 to Linux (I hope it'll still happen one day).

[shmuz]

@yulian5
There are at least 2 Far2 Linux ports: far2l (popular enough) and far2m (less known).

[Zeroes1]

Do you have a portable Far3 for WT portable mode?

@yulian5 yep, i use far + wt portable
my e-mail: [email protected]

FAR portable:
Far.exe.ini
UseSystemProfiles=0
UserProfileDir=%FARHOME%\Profile
UserLocalProfileDir=%FARHOME%\Profile

WT portable:
canary build or relis/preview ZIP version download
inside dir need exist file: .portable
after this settings store at:
Terminal home dir\settings\

[yulian5]

There are at least 2 Far2 Linux ports: far2l (popular enough) and far2m (less known).

Hi @shmuz , yes, I tried far2l a few years ago. I didn't know about far2m. Thanks!

far2l(m) is using Wine, it's not a native port, I talked about. To port Far3 to Linux will be the titanic work.

I also tried Midnight Commander, Krusader, Double Commander.
I don't use any of them: the common problems are missing functionality, freezes or crashes, slow rendering.

Best results I had recently on Linux with Far3 under Wine on a few different distros but I also had a lot of problems with settings, colors, desktop shortcut link and dropped it. Linux shells or native file managers still look better for me.

Maybe I need to try far2l/far2m again. What are the main differences between them?

[yulian5]

Hi @alabuzhev,

Heavy rain all Saturday helps me to debug this problem. It looks like I found the root cause.

At least with small change in Far code it's possible to remove all visual artifacts. I used today's code from github to build Far. Here is result of multiple resizing with original github code:

Here is the same console with applied code change after much more heavy resizing:

The change is in file "far\savescr.cpp", line 180, to disable code after comment "// achtung, experimental":

SyncWithConsole = false;

179    }
180    SyncWithConsole = false;  // New code, disable conditioned code
181    // achtung, experimental
182    if (SyncWithConsole)
183    {

The issue is introduced a long time ago. I see nothing wrong with that code, except it may need some synchronization with other related code as Conhost is running in separate thread and resizing happens in a few overlapping steps usually.

But when this code read console buffer in lines 197 or 226

console.ReadOutput(Tmp, ReadRegion)

console output is already broken. Setting this flag SyncWithConsole to false, which is essentially (Global->Opt->WindowMode != 0), to disable code in lines 183-248 help to remove all visual artifacts with absolutely clean console output (except truncated lines, which we'll address separately).

[shmuz]

@yulian5
far2l and far2m contain some Wine code inside them but they do not have dependency on Wine - they do not run under Wine and they may be considered as native Linux/BSD/Mac applications.

far2m differs from far2l mainly by its macro-system (which is almost identical to that of Far3) and (while preserving the Far2 plugins API) it has some API extensions (mostly borrowed from Far3).

[alabuzhev]

The change is in file "far\savescr.cpp"

Thanks for having a look.
The idea of this code is to preserve the text in the shaded area as we make the window larger or smaller:

• when we make it larger, read existing data from the console buffer into the internal buffer to make it available later
• when we make it smaller, write excessive data from the internal buffer into the console buffer to make it visible to the user and to let the system manage it.

It did work more or less reliably back in the day. There were quite a few changes in conhost in the recent years and something might have stopped working at some point.

[yulian5]

@Zeroes1

yep, i use far + wt portable

Thanks for the info!

and @trexinc

Far installer has options to install it for the current user and for all users.
What do you think: Does it make sense to add option "Install in Portable Mode"?
It will be convenient.

[yulian5]

@shmuz

far2m differs from far2l mainly by its macro-system (which is almost identical to that of Far3) and (while preserving the Far2 plugins API) it has some API extensions (mostly borrowed from Far3).

Looks very interesting. Thanks! I'll check it out.

[HamRusTal]

Does it make sense to add option "Install in Portable Mode"?

This is strictly off-topic in this issue, especially in addition to its almost 60 comments already. Please create a new Discussion for this.