On Thu, Jul 24, 2008 at 4:16 PM, Micah Cowan <[EMAIL PROTECTED]> wrote:
> -----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. Very true, haskell was a bad example, but the point remains the same. > > > 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. Generally that might be true, but there are lambdas and the like as well as 'map' in perl and python. If the consensus is guile, that's fine, and you're absolutely right about it making sense for a gnu project, it's just that there are many people who are uncomfortable with, or even militantly opposed to, lisp based languages. > > > >> 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. :) Agreed. > > > >> 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. To clarify, I don't think emacs is necessarily bad at what it's meant for, but it's easy to fall into that trap when you can do anything in the program. For that matter it's easy to get into a pattern of adding more features instead of improving the existing ones, something of which many projects are guilty but it's best to avoid if possible. > > > 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 > [EMAIL PROTECTED] > http://lists.gnu.org/mailman/listinfo/screen-users > One way or another, I think any way this gets done will put the project ahead of where it is. For that matter I'm glad to see so much life back in this list. =) -- -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
