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

[Stephane Chazelas]

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.

A mouse event is exactly like a keyboard event, upon a keypress,
the tty sends a character or character sequence to screen.
Screen will generate a character for the window that currently
has the focus, and/or any filter that is configure to filter the
input. For a xterm-like mouse event it's the same thing, the tty
sends a character sequence to screen. screen might translate it
if there are split screen and send that to the current windows
and/or filter if the filter is configured to get the input.
That's what screen does already at the moment, it's all fine.

But my bug report was not at all about that.

There are some control sequences that you send to the terminal,
and the terminal /replies/ with another one.

One of them is the one to query the cursor (*not* mouse cursor)
position: Report Cursor Position (CPR): if your application
writes \e[6n to the slave side of its pty, xterm will reply with
the cursor position. It will write something like \e[4;1R to the
master side of the terminal, so that if the application reads
from the slave side, it will get those characters as if the user
had typed ESC [ 4 ; 1 R.

Just like xterm, screen supports that CPR sequence. The
difference with the pressing of a key or mouse button is that it
is initiated by an application talking to screen. And screen
makes up its response by itself. The host terminal is not
queried, screen might even be detached.

At the moment, the sequence that screen replies with (the cursor
(not mouse cursor, just text cursor) position like \e[4;1R) goes
to the application OK, but it doesn't go to a filter that is
configured to get the input (first character is "." as in exec
.!.), contrary to the mouse events. And I was saying it is not
right because they are inputs all the same, it's as if the user
had typed ESC [ 4 ; 1 R. So that's my bug report, nothing to do
with mouse.

Now, to explain why I brought the mouse thing up that confused
everybody: one example for which it would be useful to have the
filter see those /answers/ from screen is that it could allow
you to give mouse support to any application, for instance
"vi" (the good old vi, not vim which has support for mouse of
its own already) or GNU info. If you have a filter that
intercepts all the input (including the responses to the Report
Cursor Position), you can make that filter so that it intercepts
mouse events. That part works OK at the moment. Upon a click,
the filter is able to determine the position of the mouse
cursor because that's encoded in the character sequence that it
can read. Then that filter can issue a CPR to get the position
of the cursor. Unfortunately, at the moment, it cannot get the
answer because it is not sent to it, only to the application.
But if it could, it could have the information about both the
current cursor position and the position of the screen where the
user mouse-clicked so that it could for instance send the correct
sequence of <Ctrl-F> and <Ctrl-N> to tell "info" to move the
cursor localtion to where the user clicked.

I hope it clarifies it a bit.

Best regards,
Stéphane