console enhancements: mouse events

[Thomas Wolff]

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, towo@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