On Fri, 2009-03-27 at 22:00 -0400, Sadrul Habib Chowdhury wrote: > * Rui Guo had this to say on [27 Mar 2009, 12:03:20 +0800]: > > Hi Sadrul, > > > > I've thought a bit more about the idea of screen scripting support. > > > > The current use cases demonstrated fall into two catalogs:Event > > triggered handlers and user triggered actions. In both cases, we need to > > provide a interface to let them query the status of screen and execute > > actions on screen. The only difference would be the latter need a > > triggering interface for the user to use. In summary, we need to define > > a more complete set of events and possibly the interface too. There are > > four kinds of object to manipulate with, in addition to the root object > > screen, however they only provide limited functionalities. > > > > In addition to the above, I would like to show another kinds of use > > case. Not sure whether you will like it. > > > > Screen some times is called as a window manager. However, for historic > > reasons, the program running within screen does not interfere with > > screen. They even not aware of the existence of screen. If they would, > > some possibilities will show up. Imagining having a separate output > > buffer for shell commands executed in vim, that may be possible if we > > provide an robust interface for them. However, it's not likely for the > > program itself to interface with screen, since they will have to run > > outside screen. And this is where I think scripting can be taken into > > account. It can act as a middleman for the two. > > I too have been thinking about allowing applications to interact with > screen. There are two ideas I have thought of thus far: > > * Use some signalling system > When we switch to a window, we can send a signal to the application > running inside it. So, for example, if I am running finch inside > screen, then if it's not showing in any active window, then I would > want an incoming message to trigger a bell. However, if the > finch-window is in focus, I don't want the bell to go off. This is > currently not possible to do from within the application (finch). > However, if we make screen send a signal to the application (finch) > whenever I switch to/away from the finch-window, then finch can keep > track of it, and do things accordingly. Once we have some better > scripting support, this will be achievable.
I think there is some wording issue in my previous mail. The core idea is to let the application coordinate with screen. It doesn't matter which part initiate the communication. Your example here is still an use case of handling event. But this demonstrate the advantage of this idea very well. We may also do it in a reversed way: finch queries whether it is in foreground window when it received an incoming message. However, both ways need cooperation between applications and screen. Screen either need to trigger events upon window switching or provide a query interface. finch need to either response the event notification or query the window status. As I said before, it's less likely for an application to query the status of screen on it's own. But if it opens an interface to the environment, the screen scripting can take advantage of it. That's why I think your way is better here. However, I think there is some situations where it's better to let the application to seize the initiative. For example, the application may decide whether it needs a dedicated region/window to perform a task, as my vim example and your mutt example in the following paragraph. In such cases, screen should open a query/operational interface and keep ready for serving requests. Again, I think it's less likely for the application to do itself. But if it opens an interface to the environment, the scripting can take care of it. Since we are talking about adding scripting support to screen, the screen scripts have interface to screen. We may write a script that act as a server through socket or some globally available interface. And in application such as vim that is highly configurable by user, it's likely that one can extend the application to take advantage of it. And once we have such a interface, applications will be more likely to use it as time go by. Implement such a server within screen is an alternative. But since this is not a essential function, I think it's better to let it go into the scripting part, right? > > * Multiple screen windows for an application > This is very interesting, but I don't even know if it would be possible > to implement in a reasonable manner. The idea is exactly how it sounds: > we allow an application to span accross more than one Screen window. To > given an example with 'mutt', consider this: I am writing a reply to a > thread, but it's a rather long reply, and I would like to know when a > new response comes up while I am writing the reply. Currently, you > need to save the reply, go back to the list, postpone, check mail, read > new mail, come back and edit the response etc. Instead, if we let mutt > open the editor in a different screen window, then this gets much > simplified: while I am writing the reply, if a new mail comes in, then > it will trigger the alert in its screen-window, and I can leave the > reply as it is, switch to window listing the new mail, read it, switch > back to the window where I was writing the reply and edit accordingly. > This, clearly, is a much more complicated task to do than to just have > scripting support. And, more importantly, the applications will need to > be modified to take advantage of this feature (when run inside screen). > > > However, this scheme complicates things a little. Here, the script, on > > behalf of the client application, is no longer a slave to screen. They > > may need to run in background and communicate with screen when > > necessary. This requires the script and the screen can run > > asynchronously. > > > > What do you think about this idea? Currently, the command switch -X can > > be used to send command to a running screen session. The use case I > > showed here is only a more powerful scheme of this. > > > > Looking forward to your reply. > > > > ps: Should I send a copy of this to screen-dev? > > Always a very good idea! > > > Regards, > > Rui > > Cheers, > Sadrul Regards, Rui
