Re: [screen-devel] Scripting Support for Screen

[Micah Cowan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Johannes Weiner wrote:
> 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 :)

I agree with all of this.

I mentioned to Sadrul that I find Guile preferable (which would make
Screen decidedly Emacs-like); mainly because everything is an expression
(everything's a list), so you can use for-loops inside the dynamic value
for hardstatus, etc. As I've looked at our current String Escapes
support and the sorts of features people have been requesting in String
Escapes, it's becoming clear that the current state, and any additions
we make atop it, are an ugly hack that really wants to be full
expressive support. Rather than using %w and %W and adding flags to
change their behavior, and then being dissatisfied when we can't do what
we want (restrict to specific window flags, doing "odd/even" coloring of
window titles, add "blink" rendition to windows with the alert flag), we
should be looping over the windows and examining the attributes we want,
to generate the appropriate string.

Supplying "hooks" to screen as a C API would make it possible to tack on
any scripting lanuguage we choose, which is worth considering. However,
I'd like to see direct support for some scripting language within
screen; Guile looks like a good choice to me.

Your comments regarding "reducing C" are appropriate; though I'm not
sure I agree with it literally, as it might impede Screen's efficiency,
and adding as little crawl beyond the "real" terminal's processing time
is a worthwhile value. But having pretty much everything be
accomplishable via the scripting language seems desirable.

> Sort of like it's done with emacs (only that emacs was probably 
> written to this design from the beginning, I assume).

GNU Emacs was designed this way from the beginning. But this was based
on the community's past experience with Emacs; the original Emacs
was not built around a Lisp engine. Instead, it was based on a very
clunky language, that was sort of incrementally hacked to support the
various whims of its users. It was a similar situation to our String
Escapes, in that the original language lacked looping constructs (it
looks like it may have been roughly similar to the "ed" set of line
editing commands) until loops were hacked in (as the < and > commands).
It was the experience of the user community trying to hack
programming-like applications in a non-programmer-friendly language that
led to the conclusion that the best way to go was to make an
Emacs with a full-fledged programming language at its heart. Bernie
Greenberg's Emacs for Multics was the first Lisp-based Emacs (it was
written entirely in Lisp).

(http://www.gnu.org/gnu/rms-lisp.html was the primary reference I used
for this information.)

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer,
and GNU Wget Project Maintainer.
http://micah.cowan.name/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIiNL57M8hyUobTrERArJfAJ9Bc912lIxVfB1HGE8jtcDsCiI8jgCfZjyn
dIALgW9PktXYelZlfluLVgo=
=+PBO
-----END PGP SIGNATURE-----