You continue to argue about a tangential issue. I've asked multiple
times if you are a win32 api or curses programmer. You never answered.
You apparently are not. If not, what makes you think you have special
insights? And why do you continue to pursue tangential topics? My last
post, I said we were in agreement, giving you an out to stop wasting
time and space. But you won't let up. I'm sorry, you don't seem to have
much common sense in dealing with people.
>> Right, they agreed with me.
>
> They provided an example of how `wcon_setcolor` is implemented
> using Win32 API calls, including `SetConsoleTextAttribute`.
> Whether that's agreeing with you or not, I'd rather not guess.
I agree it's best not to guess. I would never guess about something that
I'm not knowledgeable about. In my previous post I explained about the
api calls in the library file.
>>> Anyway, try this. Run mintty and inside run `/usr/bin/mc | tee ~/foo`.
>> > In mc, enter a directory, open a dialog or whatever. Kill the mc
>>> process (for example using the Task manager). Close mintty and
>> > open a new one. Run `cat ~/foo`. The last state of mc's TUI should
>> > appear in the new mintty window.
>>
>> What did you expect? I think that makes my point perfectly. In the real
>> world, we don't direct mc output through a pipe! I'm sure you know the
>> difference, it's very basic. TUI Programs like mc are fundamentally
>> different from command line programs like grep, both in how they are
>> programmed and how they are used. Even given that you do not know how to
>> program in curses, where the difference is obvious at the source code
>> level, from a user point of view the difference is obvious.
>
> I'm not disputing that TUI and non-TUI programs are different.
If that is the case, can you please stop wasting time arguing about
mostly off-topic issues (that you don't seem to know much about)?
> I wastrying to provide evidence in reply to """I stand by my
> statement that "curses programs do not normally use
> stdin, stdout, or stderr", but am ready to be corrected and learn.""".
>
> I thought this exercise would convince you that the program (the
> curses part of it, to be precise) is not communicating with
> the terminalwindow via any other channels than std{in,out}.
I didn't need convincing. One would basically never use "stdin" or
"stdout" in writing curses code. Words matter. Unfortunately, you have a
loose way with words, eg "regular windows program".
> I was hoping to demonstrate that by showing that `cat`,
> not acurses program, can create the same terminal output
> as a curses program.
Well, now you've demonstrated it. Again, what did you expect? Again, in
the real world, we don't direct mc output through a pipe.
> Which part of the argument do you disagree with, if any?
I already explained. Read the previous post (included above).
--------------------
My original question was a practical question concerning best ways to
compile and run curses programs from within MSYS2. You were not helpful
in answering that question, I don't blame you, how could you know?
Someone else (Greg Jung) gave me quite helpful information, I appreciate
that. The issue is still mostly not resolved, but there was at least a
little progress.
It is unfortunate that you've launched into a mostly theoretical
discussion concerning win32 and curses programs. I think it's more
helpful to MSYS2 users to have practical information and directions. I
think this thread turned into a waste of time long ago (besides being
mostly off-topic). Again, refer to my previous post where I suggested we
are in agreement.
Daniel
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval
_______________________________________________
Msys2-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/msys2-users
