Based on the quotes in the last email, this conversation seems to be going
on in two separate places. I don't know where the second place is, but this
is confusing. Please consolidate.
As for the specific issue of running mc directly from the windows command
prompt, my findings on a Windows 7 machine are that mc, presumably through
ncurses, sizes itself to the window buffer width rather than the actual
width, to the actual window height, and does not get window resize
notifications. What this means is that if I size my command prompt window
to it's maximum width, mc looks fine. There are still at least a couple of
issues, specifically that changing the height of the window does not in
itself prompt a redraw of the screen (although pressing a key after the
resize fixes this). Also pressing and holding an arrow key only moves down
one line. running mc directly from the mintty/bash prompt works fine.
Now for the general issue discussed in this thread.
@Daniel, I would like to point out that you not understanding an
explanation is not a sign of the explainer's lack of understanding himself.
It could also be a sign of either a bad explanation, language/communication
issue, or in rare cases your own misunderstanding.
That said, I admit that I don't fully understand the issue, but here is my
attempt at explaining what I think I understand:
First off, terminology. I am only including relevant terms, not all
possible variants of every term:
* User interface (UI)
The part of a program that gets input and sends output.
* console/text terminal
A character input/output device. It sends character input and receives
character output. It may interpret certain character sequences as special
commands. A historic (and important. we will come to this later) example is
the VT-100. All interaction with console apps happens via a console (real
or emulated).
* Graphical terminal (not a common name)
The screen/mouse/keyboard/joystick/touchpad/touchscreen type devices we are
all used to today.
* Program
There are 3 types of programs, categorized by their UI and terminal use.
1) A "regular" app. Has a stream-based UI. This is what you get when you
compile the standard "Hello, world!" C program. It has 3 abstract I/O
(character-)streams (stdin, stdout, stderr) allocated to it by the OS upon
starting. These streams are usually emulated/mapped by the OS over the
console's character stream, and may be buffered (depending on the
implementation) by the OS and/or the terminal and/or the library. The
streams may be redirected, such as by pipes or redirecting to a file. Often
the input stream is buffered and only sent to the app at a newline or EOF,
so the app has no control over the text entry phase. To correct input you
would typically have to erase (backspace) as needed and re-enter input.
Examples are ls, mv and pacman.
2) A GUI app. This type gets no I/O streams allocated by default (it can
open streams using OS APIs if needed) and it's I/O is not character based
(graphic output, usually to a window, and multiple types of input, such as
pointer and keyboard). It uses a graphical terminal rather than a text
terminal. Examples are firefox, office or media player.
3) A console based non-stream app. These types of programs use a text-based
console, but rely on directly communicating with the console rather than
via abstract streams. This of course means that they are dependent on each
console's particular capabilities and supported features. 2 classic
subtypes of this are the line editing type and the TUI type. The former
mostly uses it's direct console connection to manage it's own buffering of
input/output and to move the cursor around. This can be used for various
REPL apps, as well as things like gdb, sqlite and many others. Often done
with readline, linenoise or similar library. The TUI type usually use a
*curses library, and they rely much more heavily on console-specific
things, such as size, colors, special keys, etc. Examples are vim, mc, etc.
* console emulator/virtual terminal
This is a GUI app that emulates the console input by translating input from
the GUI input method (keyboard or other) into console character stream, and
the console output to a graphical output in a window. It will
generate/parse the special commands/escape sequences as needed. Many
(most?) terminal apps simulate some form of the VT-100 terminal. A notable
exception is the Win32 console, that dos not simulate the VT-100 escape
sequences. I don't know if it even emulates any actual terminal, or just
does its own. Examples are xterm, gterm, Win32 console, mintty.
* shell
This is a console app (usually type #3 line editing, but can be type #1, or
any type of #3 too). It parses its input to figure out what other app you
want to run, and runs it via the OS. Examples are bash, zsh or Windows cmd.
For the rest of this text, console, terminal and console/terminal emulator
are interchangeable.
Now for the explanation of what is going on.
GUI apps are tied to an api, which usually ties them to an OS, unless using
an abstraction level for the api (Qt, wxWidgets, wine, etc.)
"regular" apps usually work just fine in any console, since they work with
abstract streams, which are basically supplied by both Windows and Posix
OSs with any console.
The problems start with type #3 apps. The more they rely on some special
console capabilities, specifically VT-100, the more likely they are to
break in Win32 console, and vice-verse.
winpty attempts to run the app passed to it in a hidden Win32 console and
translate the input/output from mintty (VT-100) to Win32 command and back.
This is my understanding. Please someone who understands this better
correct me as needed.
Baruch
--
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Msys2-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/msys2-users
