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