-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephane Chazelas wrote: > On Fri, Aug 08, 2008 at 02:18:02PM -0700, Micah Cowan wrote: > [...] >> I think the discussion I wished to have, was whether there was agreement >> that in all cases we would wish the mouse sequences to go to the filter, >> rather than the application. I would think that in many cases, one would >> wish the reverse (say if the application is vim, and the filter doesn't >> get mouse sequences). > > Sorry, > > I shouldn't have brought that thing about the mouse because it > is not at all about that, and it seemed to have confused > everybody.
<snip example using CPR, rather than mouse-tracking> I was aware that the issue wasn't specific to mouse-reporting. What I didn't realize is that the issue actually fails to apply at _all_ to mouse-reporting. Your talk about mouse support is possibly even more of a red herring than you knew. :) The concerns I brought up in my previous response still apply, whether mouse-tracking is concerned or not: should "screen-generated" responses be sent to the filtering process in all cases, or is that likely to confuse filters which weren't set up for it? The bit I wrote: > In order to be done right, it might be necessary for screen to determine > which tty the mouse-tracking sequence was sent on (app's or filter's). is equally applicable if you replace "mouse-tracking sequence" with "CPR sequence". However, what I did not realize is that mouse-tracking sequences are _already_ always sent to the filter, and not the application, with or without the patch you provided. I was assuming that it worked through the same mechanism that response to CPR use. However, after some digging around, I realize now that this is not at all the case: screen responds to CPR internally, and issues its response directly to the application. However, when screen sees mouse-tracking requests, it passes it on to the host terminal (that part I already knew), and then when it sees mouse-state reports, it leaves the report in-stream (if it's for the correct position), and simply adjusts the information. I had been thinking the information got swallowed up, and re-reported via Report() or similar. So, my concern whether screen-generated responses holds somewhat less weight as an impedement to your patch, since mouse-tracking sequences (which are also "responses" to application (or filter) requests), are _already_ always sent to the filter's input, leading to an inconsistency. However, the concern still remains, that if I apply your patch, it may be that filters that didn't send/don't expect a response to an application-sent CPR may be confused/broken. I'm thinking that it might be more robust if screen were to note which tty the CPR (or other request) came down (application or pseudo), and send the response back on the same one. For consistency, one could also consider having screen swallow up mouse-tracking responses, and reissue them down only the ttys on which requests had been seen. But that wouldn't be a general solution, since other term-specific query/responses couldn't be caught by Screen, and so would always end up at the filter end in any case. So, perhaps I should simply apply your patch to obtain a general _and_ consistent solution (if a potentially existing-filters-breaking one), and have done with it. ...which is why this is a discussion, and not a rant. Feedback, anyone? :) - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer. GNU Maintainer: wget, screen, teseq http://micah.cowan.name/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFInPh17M8hyUobTrERAur4AJ9NHfkXTwX6s0auWUqXYn/NzLYMxwCZAZVm IcxnILLLPAzZ4ja4QBhyF2w= =gkKt -----END PGP SIGNATURE----- _______________________________________________ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users
