[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [screen-devel] Scripting Support for Screen

From: Trent W. Buck
Subject: Re: [screen-devel] Scripting Support for Screen
Date: Fri, 25 Jul 2008 11:22:09 +1000
User-agent: Mutt/1.5.18 (2008-05-17)

On Thu, Jul 24, 2008 at 02:16:30PM -0700, Micah Cowan wrote:
> I'm not sure I agree on "people know them well" for Haskell. Scheme
> /Lisp probably has a larger developer base than Haskell does.

Last time I looked, on Freenode, #haskell has around double the number
of people that #scheme has.  While I think more people know *of*
Scheme and Lisp and understand the basics, my impression is that there
is a lot more people actively writing Haskell every day than there are
people actively writing Scheme every day.

However, I wouldn't recommend Haskell as an extension language for an
existing C-based application -- Haskell isn't designed for that role.
(cf. Lua was designed for *exactly* that role.)

> 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").

How many *active* projects use guile as an extension language, and
aren't trying to get rid of it?  How large is the guile user community
(people writing code and libraries in guile)?  How active is the guile
developer community (people improving guile itself)?

My impression is that *nobody* likes Guile.  At all.  Over the years,
I've met *one* guile user who actively advocated it, and about twelve
months ago he learned CL and admitted that he liked that much better.

>>> 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.

$ printf '%s\t%s\n' `grep-aptavail -sInstalled-Size,Package -S --regex ^emacs22 
| cut -d: -f 2`
412     emacs22-bin-common
4032    emacs22-common-non-dfsg
7120    emacs22-nox
7548    emacs22
7548    emacs22-gtk
13264   emacs22-el
51780   emacs22-common

emacs22, emacs22-nox and emacs22-gtk are alternative front-ends, so
the smaller two can be ignored in the count.  The emacs22-el package
is not used (since emacs22-common contains the byte-compiled
versions), so it can also be ignored.  Arguably most of emacs22-common
should also be ignored, since it mostly constitutes applications that
are written on top of Emacs and aren't needed by Emacs itself.  Even
if you count it, that's a total of (+ 412 4032 7548 51780) ==> 64MB,
not "100+ MB".

There's no real reason emacs22-common couldn't be split up into the
"core" files needed to run Emacs itself, plus a separate package for
applications.  This isn't done because in general, nobody really cares
about wasting 50MB of disk space.

> 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. :)

ElScreen is an Emacs window session manager modeled after GNU screen
by NaotoMorishima,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]