On Thu, Jul 24, 2008 at 2:07 PM, Micah Cowan <[EMAIL PROTECTED]> wrote:
> -----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. > While I'm relatively new here I thought I'd throw in my 2 cents on the matter. Having everything doable via scripting sounds good, but it should be a situation where something is only done in scripting if you want to replace the default so as to reduce the overhead for the people that just want to use the defaults. Or as Micah pointed out, things that currently are handled poorly, and would significantly benefit from scripting without adding too much overhead (string escapes etc.). As far as what language to use, I know lisp and guile and the like are classic choices, but might it be a good idea to make it a language people are likely to know outside of the context of scripting? I'm not saying it has to be, but something in the python/perl/ruby/haskell family might be a good idea if only because people know them well already. It's like the experience with vim, it has a primary scripting language, which is different from what most people know, which people used because it's what was there, but finally python support went in and several complex extensions came into existance which could not have otherwise. Just something to consider. (NOTE: I'm not a python user personally, just used as an example) > > 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.) All of this is pretty correct, except that the gnu emacs we know was lisp with a C core for a long time because redraw was impossible to write efficiently enough in lisp for some reason. As such, when the program entered that state, everything changed, and that's something that should probably be avoided. Either have it be all scripted, or have it be a C core which can be extended and modified from outside, but avoiding a situation where most of the program is one way and certain parts are another, that will just generate frustration and maintenance problems. A final word here, bloat=bad. I would really like to see scripting, but if it means an emacs-like distribution of 100+ MB of scripting files and the generation of a program which does everything well except what it was designed for, then the point has been missed. > - -- > 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----- > > > -- -N AKA:Tom Scogland I am enough of an artist to draw freely upon my imagination. Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world. -Albert Einstein
_______________________________________________ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users
