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 _______________________________________________ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users