Re: "exec .!" filters seeing responses to "query" escape sequences

[Micah Cowan]

-----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-----