[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [screen-devel] Scripting Support for Screen

From: Johannes Weiner
Subject: Re: [screen-devel] Scripting Support for Screen
Date: Thu, 24 Jul 2008 18:11:33 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)


Sadrul Habib Chowdhury <address@hidden> writes:

> Hi. I started working on a lua script loader for screen last night. I am
> quite happy with the progress so far. I would like to know what people
> think about this kind of work. I discussed about this briefly with Micah
> last night, and he also thought discussing this in the list would be
> useful.
> I will try to answer a few questions that might come up in advance:
> * Where is the patchset?
> - The current patchset is available at
> The patches are against
>   the development version of screen
>   (
> * What's the goal?
> - The goal right now is to allow executing some user-defined function
>   on specific events, e.g. when a window is closed, opened,
>   title/position changed, a display is detached etc. etc. easily, i.e.
>   without requiring a recompilation/reinstallation.
>   I started working on this mostly out of curiosity, to see where it
>   goes, and what cool things it might allow users to do. One use I have
>   in mind is to send some signal to the process in a window when it's not
>   visible in any of the displays, (and send another one when it becomes
>   visible for the first time). It doesn't make all that much sense to
>   implement such highly personalized features in screen itself.
>   I am sure people will find a lot of other interesting things to do.
> * Why Lua?
> - Because I like it!
>   To be perfectly honest, there was no compelling technical reason for me
>   to choose lua. I hadn't worked with lua bindings before, but I was told
>   it's much easier to work with than with some other scripting languages
>   (e.g. python!). I thought I would give it a try and find out.
> * Why not guile?
> - Because I haven't seen it before, and I wasn't aware of it until Micah
>   told me about it last night on IRC!
>   Note: with the patchset, it is possible to support multiple scripting
>   languages, either built-in at compile time (current), or dynamically
>   loaded on demand (not yet implemented, but possible semi-trivially.
>   [1] for details). So in theory, it will be possible to have none,
>   either or both lua and guile support. (and any other language someone
>   cares to write bindings for)

I once hacked something together that was based on guile but I ran into
problems with user input, IIRC.  I will try to look at the problem again
in the near future, hopefully.

I really like the idea.  Thanks for doing this!

By the way, Python is also embeddable :)

> * What about the bloat?
> - I would refer to the commit message at [1]

Screw the bloat, there are larger full-blown window managers around :-)

> * Is there a sample script?
> - Yes!
>   The 'fore_changed' function towards the end is the one that gets
>   executed when the foreground window for a display is changed. It prints
>   the list of windows (# and title), a message explaining the switch from
>   the previous window to the current one, and finally prints detailed
>   information about each display and its foreground window. The display
>   information includes the term, tty, user and the canvases.
> * What are the current triggers/hooks?
> - Right now, only changing the foreground window in a display will
>   trigger a function named 'fore_changed' in the lua script. I don't have
>   a complete list of hooks in mind yet. I plan on adding new hooks as the
>   need arises. Suggestions are very welcome!
> I would love to know if people have any opinions, suggestions etc. about
> this.

The trend I would like to see is not just extending screen with a
powerful language but reducing the C code where possible by this
language.  Sort of like it's done with emacs (only that emacs was
probably written to this design from the beginning, I assume).

Because the more you do in extension language, the more powerful
commands you can provide to the scripting interface.

And the more your configuration file becomes a program on its own,
written for the screen library :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]