Corinna Vinschen schrieb:
On Nov 9 09:54, Christopher Faylor wrote:
On Mon, Nov 09, 2009 at 02:35:51PM +0100, Corinna Vinschen wrote:
On Nov 8 23:02, t...@towo.net wrote:
Corinna Vinschen schrieb:
Ooookey, if they aren't listed in terminfo anyway, I have no problems
to change them. But we should stick to following the Linux console, I
guess.
I agree. I'm surprised that we've had the function keys wrong all these
years.
* I intended to implement cursor position reports and noticed that
their request ESC[6n is already handled in the code; it does not work,
however, so I started to debug it:
This needs some more debugging, I guess.
Do you have an opinion about my theory that the wrong read-ahead buffer
is being filled here (stdout vs. stdin)? If so, I still have no clue
how to proceed; maybe you'd kindly give a hint how to access the stdin
buffer / stdin fhandler?
I have no opinion yet, since I don't know this part of the code good
enough. IIUC you think that the readahead buffer of the wrong
fhandle_console is filled, the one connected with stdout, not the one
connected with stdin, right?
I'm still struggling to understand what a "stdout read-ahead buffer"
might be. Could you point to the place in the code where you see the
problem?
As far as I understand it:
Application writes ESC [ 6 n to stdout which is connected to one
fhandler_console. Cygwin creates the reply and copies it into the
Yes, see fhandler_console::char_command, case 'n', small_sprintf, then
puts_readahead (buf);
readahead buffer of this very fhandler_console.
Yes, I traced ralen and raixput in fhandler_base::put_readahead (in
fhandler.cc) and could watch the buffer being filled with e.g. 7 bytes.
But that's not the
same fhandler_console which is connected to stdin, which is the
fhandler the application reads the reply from.
I also traced ralen and raixget in fhandler_base::get_readahead and saw
the buffer empty immediately after the filling with 7 bytes;
I had also traced other places where ralen could be reset, with no
occurrence logged between the two traces mentioned.
So the reply never
makes it to the application.
Thomas