ConsoleTest in new Windows Terminal

[Chiliyago]

Hello,
I was able to execute the ConsoleTest application to see how it performed with the new Windows Terminal. It appears you are setting the terminal width prior to rendering the text which is not being honored by the new Windows Terminal. Because of that the text rendering does not line up properly and word wraps. Do you expect this library to work well in the new Windows Terminal? Can any tweaks be done to make it compatible? Classic command console seems to be fine.

Also, do you expect the library to perform well in a dotnet core / linux environment?

My goal is to add this library to a console application I am building which will run on dotnet core and non-windows machines. I have a lot of tables and formatting in my output and would very much like to use a library like this.

Thank you.

[Athari]

Samples

Checked the sources... The process list sample tries to set buffer and window width, but only in debug mode with an attached debugger and ignores if it throws (iirc, one of these throw on Linux). The table is width-independent, so in theory it should work. Unless the new terminal lies about the buffer width.

The console test sample uses lower level API, so I can see how it can fail to align at least some of the text. The rest relies on absolute sizes a lot, but uses high level API which reads current console buffer width before rendering, so that part should work correctly.

Please let me know what exactly works incorrectly. I expect the first part of ConsoleTest to be messy, but the rest should work fine.

Compatibility

Last time I checked, it worked fine on Linux. There were some incompatibilities in XAML, but I suspect most devs don't even use it, so they shouldn't see notice differences.

The biggest problem you may face is performance. Linux terminals rely on ANSI codes, but there's no way to use the character sequences directly using .NET API, so the library relies on standard API for colors and such. The same thing with Windows, but for slightly different reasons. There's a platform-specific low level API that provides access to console buffer for faster rendering, but the library relies on standard .NET API instead which causes a lot of WinAPI calls underneath. So if you don't use colors and want to produce huge walls of text, you may want to render to a text buffer and write the huge string to console in one go. If you target a specific Linux terminal, you can use ANSI renderer too, which would allow using the same approach while preserving colors (the reason I say it's limited to a specific terminal is because you'll have to manually provide ANSI codes which aren't cross-platform or even cross-terminal).

The library relies on standard .NET API, so has the same features and limitations regarding formatting. If there're major issues with formatting, you'd get the same by using standard .NET API, most likely (detection of ANSI codes in .NET is fragile in particular, last time I checked). If a platform happens to lie about console buffer width, you'll have the same problems with formatting and line wrapping when doing them manually.

Technical details

By default, Windows console wraps text automatically when reaching the last position in line. (Or .NET enforces that option, I don't remember precisely.) So if you print 80 spaces and "\n" in a console window having 80 character width, you get two line feeds. This is why the library doesn't produce line wrap characters, even though technically it would make sense and avoid some of the issues. There's a WinAPI function which changes that behavior, so if you want, you can experiment with customizing line wrapping behavior. I don't see much reason for this though.

Conclusion

The library completely relies on standard .NET API without any platform-specific calls, so in general it should be as cross-platform as it gets. I haven't tested the library on Linux heavily, but what I've tested worked fine.

[Chiliyago]

This video shows the output in the new Windows Terminal.

[Athari]

Hm... Something is wrong specifically with the ConsoleTest app. The ProcessManager app works fine at any window size.

[Chiliyago]

I always get unauthorized access error when running the ProcessManager. :(

[Athari]

Replaced setting with getting:

Console.WriteLine($"Console.BufferWidth = {Console.BufferWidth}");
Console.WriteLine($"Console.WindowWidth = {Console.WindowWidth}");

There's a problem with the Windows Terminal app. Sometimes it forgets to resize the buffer and .NET sees buffer and window width being 80 when they aren't. Opening a new tab and/or clearing with cls in some order eventually fixes this problem and the buffer starts resizing properly with window size.

Considering .NET (and below that, WinAPI function GetBufferInfo) return 80, there's nothing that can be done about that situation. This is clearly a bug in Windows Terminal. The "holes" in backgrounds are random, which makes me believe these are bugs in the Windows Terminal too. I also keep getting various visual glitches even without using my library.

If using this terminal is a priority, you can bypass this problem by formatting at Console.BufferWidth - 1 width and enforcing line wraps. (Text renderers support line wrap sequence natively through TextWriter.NewLine property. Console renderer ConsoleRenderTarget would require copy-pasting into your code to change line wrapping logic.) I'm not going to include these changes in the library as they're for bypassing bugs in another app and as such aren't useful in general.

I always get unauthorized access error when running the ProcessManager. :(

This is due to a relative path which the app doesn't make sure exists: File.Create("../Tmp/0.html"). You can create the tmp directory and it'll start working. The ConsoleTest isn't really meant as a proper sample, it's more like a quick way to test things during development.