On Thu, Jul 24, 2008 at 4:16 PM, Micah Cowan <
address@hidden> 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
OWOFmVvTHGDk9PXhhbeEz8A=
=el6F
-----END PGP SIGNATURE-----
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. =)
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.