Skip to content
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

TVedit does not work from git-bash MINGW console #25

Closed
alexey-vostrikov opened this issue Oct 26, 2020 · 16 comments
Closed

TVedit does not work from git-bash MINGW console #25

alexey-vostrikov opened this issue Oct 26, 2020 · 16 comments

Comments

@alexey-vostrikov
Copy link

TVedit does not work from git-bash MINGW console
image

@magiblot
Copy link
Owner

Hi Alexey!

You are right. Turbo Vision uses the Win32 Console API, and the MINGW console has traditionally not supported it.

However, since Git for Windows 2.27.0, the Git Bash console has had support for Windows-native pseudo consoles. So I suggest you to check if you already have the latest version of Git Bash or if you need to enable this feature manually.

If that still doesn't work, all I could do would be to pop up a native console automatically. So you would be able to use Turbo Vision applications, but not directly from a MINGW console.

@magiblot
Copy link
Owner

Make sure to enable this option during setup:

Anotación 2020-10-26 175159

This is what I get:

Anotación 2020-10-26 175750

Unfortunately, mouse does not seem to be supported :(.

@alexey-vostrikov
Copy link
Author

alexey-vostrikov commented Oct 27, 2020

Can tvision detect winpty console and support it?
To make applications written using t vision work on any consoles.

@magiblot
Copy link
Owner

Can tvision detect winpty console and support it?

How can I do it?

@alexey-vostrikov
Copy link
Author

I am not a developer, but i think you could read something like https://stackoverflow.com/questions/48199794/winpty-and-git-bash

@alexey-vostrikov
Copy link
Author

msys2/MINGW-packages#2675
python3: Use is_cygpty() to detect a terminal

@magiblot
Copy link
Owner

Okay, thanks for investigating.

Turbo Vision prints the error you show in the image when the system calls needed to interact with the console fail. What the commit you shared seems to do is add a clause to an if statement so that Python doesn't refuse to interact with the terminal. So in the case of Turbo Vision, it would be useless to add a check like is_cygpty if the system calls for console interaction will fail anyway.

In theory, or at least as I understand it, winpty is exactly what is needed: a compatibility bridge between terminals using VT sequences and applications using the Win32 console API. Thus, I would expect Turbo Vision to work out of the box. But in practice, it doesn't work. I can't even get winpty cmd to work on Git Bash. So I guess I'll have to ask the winpty developers.

If none if this works, the only solution will be to implement terminal I/O with VT sequences. The most reasonable way would be to support Ncurses on Windows, since the code handling Ncurses interaction is already there. I can't promise I will implement this anytime soon. If you or anyone else wants to give it a try, I encourage you to contribute to the project.

Cheers.

@alexey-vostrikov
Copy link
Author

Thanks for your attention, i just looking for console text editor for using with git-bash in windows. So it seemed to me that tvedit or turbo are the best candidates.

@magiblot
Copy link
Owner

Okay. Thanks for your interest :)

@magiblot
Copy link
Owner

I tried spawning a native console instead of printing that error message and exiting, but it didn't work, I don't understand why.

So I tried the latest Git Bash on ConEmu and the application started just fine. However, there is an issue with input. I found a related ConEmu bug report and commented there: Maximus5/ConEmu#2065 (comment).

@magiblot
Copy link
Owner

magiblot commented Nov 1, 2020

After having talked with the author of ConEmu, I suggest you to create a Task that just invokes the bash shell directly, so that the native console host is used instead of mintty:

imatge

With this Turbo Vision should work out of the box:

imatge

@alexey-vostrikov
Copy link
Author

image

@alexey-vostrikov
Copy link
Author

but if i change dir to bin
it works

@magiblot
Copy link
Owner

magiblot commented Nov 2, 2020

Segmentation fault

I think this happens when startup doesn't fail but still is unable to get the console dimensions. This could have been fixed by a previous commit. Can you upgrade to the latest commit and recompile?

but if i change dir to bin it works

Do you mean this?

cd bin
./tvedit.exe

That's strange. Do all the demo applications crash?

magiblot added a commit that referenced this issue Jan 22, 2021
The current platform classes have many issues. One of them is that they interact with the terminal in the constructor. This makes it impossible for an strategy to "fail" so that we can fall back on another one, unless we use exceptions, which I'm not willing to use because I think they are not the best solution.

This commit changes several things: first, it fixes the "fail" issue for Win32ConsoleStrategy by hiding the constructor and having a public static 'create' function which returns nullptr on error. Second, it reduces the amount of state by splitting the member variables between Win32Input and Win32Display, so that these don't need a reference to Win32ConsoleStrategy. Third, it moves the handle ownership handling to StdioCtl, so that the global TermIO::consoleWrite can be unified. The console detection has also been improved and it is now more resilient and it finally supports spawning a new console when none is available (fixes #25).

There's still room for improvement. I look forward to having just PlatformStrategy as singleton instead of StdioCtl. StdioCtl functionality should be moved into PlatformStrategy, and TermIO functions would receive a pointer to PlatformStrategy instead of referring to the StdioCtl singleton. StdioCtl is currently the equivalent of passing parameters by global variables. Also, it can be seen clearly that the resource lifetime of StdioCtl on Windows is tied to Win32ConsoleStrategy's lifetime. This is why I believe they should both be part of the same object.
magiblot added a commit that referenced this issue Jan 22, 2021
The current platform classes have many issues. One of them is that they interact with the terminal in the constructor. This makes it impossible for an strategy to "fail" so that we can fall back on another one, unless we use exceptions, which I'm not willing to use because I think they are not the best solution.

This commit changes several things: first, it fixes the "fail" issue for Win32ConsoleStrategy by hiding the constructor and having a public static 'create' function which returns nullptr on error. Second, it reduces the amount of state by splitting the member variables between Win32Input and Win32Display, so that these don't need a reference to Win32ConsoleStrategy. Third, it moves the handle ownership handling to StdioCtl, so that the global TermIO::consoleWrite can be unified. The console detection has also been improved and it is now more resilient and it finally supports spawning a new console when none is available (fixes #25).

There's still room for improvement. I look forward to having just PlatformStrategy as singleton instead of StdioCtl. StdioCtl functionality should be moved into PlatformStrategy, and TermIO functions would receive a pointer to PlatformStrategy instead of referring to the StdioCtl singleton. StdioCtl is currently the equivalent of passing parameters by global variables. Also, it can be seen clearly that the resource lifetime of StdioCtl on Windows is tied to Win32ConsoleStrategy's lifetime. This is why I believe they should both be part of the same object.
@magiblot
Copy link
Owner

This now sort of works with a workaround. When ran in Git Bash without pseudoconsole support, the application will spawn a separate terminal and run in it. This may not be what you were expecting, but it works.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants