-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom Scogland wrote: >> 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.).
Right. That's essentially what Emacs does: use C implementations where efficiency is important, but allow users to override with Lisp >> 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. I'm not sure I agree on "people know them well" for Haskell. Scheme /Lisp probably has a larger developer base than Haskell does. The only reasons I prefer Guile over those, is (1) it's much more straightforward to use complex constructs, such as loops, within an expression, and (2) GNU recommends it as first choice for scripting in GNU projects (it's a GNU project, so would be "eating our own dogfood"). What I mean about complex constructs in expressions, is that in many other languages, iterative constructs such as for-loops are statements, not expressions. So, for instance, setting "hardstatus" to an expression that dynamically generates a string by iterating over the window-list is straightforward. In some of other languages, it might be impossible. Perl could do it, probably with grep and map; Python could probably do something similar. It wouldn't be a problem in Haskell. I don't know about Ruby. But I suspect only in Guile and Haskell would it look like something other than a bit of a hack. >> 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) AFAICT, that's more an argument for using a full-featured language, than any particular language. Part of the philosophy that went into creating Guile was that by providing a powerful language, people could implement their favorite languages in Scheme, and so people could work in whichever language they like best. That sounds nice in theory, but as far as I know no one has actually implemented their favorite languages in Guile, probably because it wasn't worth the effort, so that's not much of a boon. :) >> 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. I disagree that Emacs doesn't excel at what it was designed for; but it obviously excels at many things that are entirely unrelated to editing, as well. I suspect we don't have to worry too much about that for Screen; but part of that may depend on how choosy we are about what we let into the Screen distribution. For my part, I don't currently see any reason why we would need to provide any Scheme code with Screen whatsoever, apart from probably a sample ~/.screenrc.scm, and perhaps other example scripts. Sure, a powerful programming language means that folks could write "Towers of Hanoi" or an email client within Screen; but that doesn't mean we have to include it. And anyway, why would they want to do that when they could just do it in Emacs? To be honest, implementing a Screen within Emacs makes almost as much sense as giving Screen Emacs-like scriptability; Screen has already duplicated quite a bit of Emacs' layout functionality and such, some of it not yet as well as Emacs itself does it. But I doubt anyone's interested in seeing that happen. :) - -- 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 iD8DBQFIiPEu7M8hyUobTrERAmTKAJ0fEk04Ir9HJCxpzBxH3JFAim+wiwCfd/vm OWOFmVvTHGDk9PXhhbeEz8A= =el6F -----END PGP SIGNATURE----- _______________________________________________ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users