Re: Mouse-support with "exec" filters

[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).

Hi Micah,

I don't agree with that. If I filter the input to vim, I don't
see why I would expect part of the input not to go through the
filter.

But I'm talking here only of filters that filters the input,
that is what is otherwise being sent to the applications (what
applications read from their slave, or what they would have read
in the absence of a filter).

That includes characters sent upon a key press (or return) or
mouse button press or motion if the application requested mouse
tracking, screen -X stuff, responses to "report" sequences and
so on.

By trying to be clever and guess and select which of those a
filter author might be interested in, I fear that we lose in
clarity and flexibility.

It should be up to the filter to select what it is interested
in: anyway, if it filters the input to a curses like
application, it has to know how to cope with character sequences
sent upon <Left>, <Home>, <F*> keys and so on. The <kMouse> key
is just another character sequence, you may consider for
instance that there's a key for every character cell on the
window.

Every time I try to use filters, I have to scratch my head for a
while as it's quite complex. Having *all* the input go through
filters that have "." as the first character is the fd
specification looks like the most sensible thing to do to me and
what a user would expect.

It allows filters to do stuff on all the sorts of input. If you
leave one sort of input out, that means less flexibility, as
that's one thing a filter can't do anything on anymore, or you
have to provide with an alternative way for them to do it and
that would add complexity.

> 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).
> 
> OTOH, a case might be made that none of this applies when the filter
> spec has "." as the first character. I'm not confident enough in my
> knowledge/experience with filters to make such a judgment, which is why
> I wanted to discuss it. :)

I'm not too sure about what you mean with "which tty the
mouse-tracking sequence was sent on" in the context of
mouse-tracking.

Do you mean the sequence that enables mouse tracking, or the
sequence sent by the terminal when a mouse button is pressed
when mouse-tracking in enabled?

For the escape sequences sent by the terminal upon a button
press, it's like any other key press IMO. The sequence should go
to the window that has focus, and if there's a filter on input
for that window, it should go to the filter instead.

Like if you do :exec ... vim
That vim should overwrite what is currently running, and mouse
should work.

At the moment, mouse is working. What is not working is if vim
sends some "report" queries, it doesn't see the answer.

Actually, you can observe that vim takes some time to start up
and my guess is because it times out waiting for the answer to
some "query terminal type" sequence.

Best regards,
Stéphane