Re: console enhancements: mouse events

[Thomas Wolff <towo at towo dot net>]

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