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