Fixes #2865. Unknown character sequence while resizing terminal.

[BDisp]

Fixes #2865 - On macOS Ansi escape sequences are send after the terminal resizing but they are corrupted. Thus is needed to restore them correctly. Also this fix includes some keys that aren't handled on macOS if a Wiindows numeric keyboard is used, like the Home, End, PgUp, PgDn, etc.... Another issue is that macOS doesn't rely on the curses lines_ptr and cols_ptr pointers to return the current size on resizing and now it's needed to use ioctl and resizeterm to get and set the current size. The better way to wait a Esc or an Ansi escape sequence, is use the nodelay method. I also added a new scenario to test the Terminal.Gui doesn't freeze while resizing.

Pull Request checklist:

• I've named my PR in the form of "Fixes #issue. Terse description."
• My code follows the style guidelines of Terminal.Gui - if you use Visual Studio, hit CTRL-K-D to automatically reformat your files before committing.
• My code follows the Terminal.Gui library design guidelines
• I ran dotnet test before commit
• I have made corresponding changes to the API documentation (using /// style comments)
• My changes generate no new warnings
• I have checked my code and corrected any poor grammar or misspellings
• I conducted basic QA to assure all features are working

[kacperpikacz]

When running on MacBook M2 the application crashes immediately.

When I revert changes inconsole_sharp_get_dims (out int lines, out int cols) the problem disappears and I see no more issues.

[BDisp]

Thanks. The problem is when I resize the terminal the app doesn't resize. It seem that some method is missing. Can you find what? Maybe ioctl or resizeterm.

[BDisp]

I added a definition for toggle the use of ioctl and now it's using the previous behavior. I now see that the issue on resizing isn't happening anymore. Maybe was other code that was causing the issue but I already fixed. Please confirm if it's allright now. Thanks.

[kacperpikacz]

I can't make it work with c#

using System.Runtime.InteropServices;

namespace Playground {
	class Program {
		[DllImport ("libc", SetLastError = true)]
		internal static extern int ioctl (int fd, ulong cmd, out winsize argp);

		public static ulong TIOCGWINSZ = 0x40087468;

                [StructLayout (LayoutKind.Sequential)]
		public struct winsize {
			public ushort ws_row;
			public ushort ws_col;
			public ushort ws_xpixel;
			public ushort ws_ypixel;
		}

		static void Main (string [] args)
		{
			var result = ioctl (1, TIOCGWINSZ, out winsize ws);

			Console.WriteLine (result);
			if (result == 0) {
				Console.WriteLine ($"Rows: {ws.ws_row}, Columns: {ws.ws_col}");

			} else {
				Console.WriteLine ($"Error code: {Marshal.GetLastWin32Error ()}");
			}

			Console.ReadKey ();
		}
	}
}

Untitled.mov

But C++ will always print correct size.

#include <iostream>
#include <sys/ioctl.h>
#include <unistd.h>

int main() {
    struct winsize w;
    if (ioctl(STDOUT_FILENO, TIOCGWINSZ, &w) == 0) {
        
        
        std::cout << STDOUT_FILENO << std::endl;
        std::cout << TIOCGWINSZ << std::endl;
        std::cout << "Terminal size: " << w.ws_row << " rows x " << w.ws_col << " columns" << std::endl;
    } else {
        std::cerr << "Failed to get terminal size." << std::endl;
        return 1;
    }

    return 0;
}

[kacperpikacz]

I added a definition for toggle the use of ioctl and now it's using the previous behavior. I now see that the issue on resizing isn't happening anymore. Maybe was other code that was causing the issue but I already fixed. Please confirm if it's allright now. Thanks.

Your last commit fixes the problem. No more issues.

[BDisp]

Try with this value TIOCGWINSZ = 0x5413 on c# please. Thanks.

Edit:
If that not works, please see what value TIOCGWINSZ has on C++ please.

[kacperpikacz]

Try with this value TIOCGWINSZ = 0x5413 on c# please. Thanks.

Edit: If that not works, please see what value TIOCGWINSZ has on C++ please.

Now ioctl returns -1, and win32error is 0.
C++ using 0x40087468

[BDisp]

Now ioctl returns -1, and win32error is 0.
C++ using 0x40087468

Do you know why you're having the error before?

[BDisp]

Now ioctl returns -1, and win32error is 0.

In this situation you still have used TIOCGWINSZ = 0x40087468 right?

[kacperpikacz]

Now ioctl returns -1, and win32error is 0.
C++ using 0x40087468

Do you know why you're having the error before?

Before 2411b8a ioctl was enabled but always return empty winsize and somehow it leaded to EntryPointNotFoundException.

The correct TIOCGWINSZ for my Mac M2 is 0x40087468 (c++ code print this value with correct terminal size)

[BDisp]

Now ioctl returns -1, and win32error is 0.
C++ using 0x40087468

Do you know why you're having the error before?

Before 2411b8a ioctl was enabled but always return empty winsize and somehow it leaded to EntryPointNotFoundException.

The correct TIOCGWINSZ for my Mac M2 is 0x4008746 (c++ code print this value with correct terminal size)

Now I'm confused. You said before C++ using 0x40087468 and now you are saying it return 0x4008746. Did you forgot to include the 8 at final?

[kacperpikacz]

@BDisp

[tig]

You may be smart enough, or have a good enough memory to remember what all these integers are, but I'm not.

Where do these codes come from? They're not ASCII codes. What are they?

I'm asking you to please make this code more readable and maintainable while you are in here.

We should always be making code we touch simpler and more readable, even if we understand it ourselves.

I have just spent 10 minutes trying to figure out where 108, 109, ...121 come from. No reader of the code should need to do that! And I still don't have a clue other than what the curses get_wch docs say: https://invisible-island.net/ncurses/man/curs_get_wch.3x.html (and that wasn't helpful).

[tig]

Found this:

https://stackoverflow.com/questions/3202629/where-can-i-find-a-list-of-mac-virtual-key-codes/16125341#16125341

Seems to imply shift is 56.

Anyway, I thought the whole point of ncurses was to map things up to the API.

I think there is some sort of termcap setting that will cause ncurses on the mac to surface these using the Curses.Key defines?

[tig]

As an example, this would be more readable if it were if (wch == (int)Key.Esc).