On Thu, Jul 24, 2008 at 2:07 PM, Micah Cowan <
address@hidden> 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-----
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.