David Lichteblau <[email protected]> writes: > Quoting Tobias C. Rittweiler ([email protected]): > > I just had the idea that it might make sense if clbuild built its sbcl > > such that it includes rlwrap and automatically uses sb-aclrepl. > > > > How do people feel about this? > > I'm interested in usability improvements. > > My design choices would be sligthly different in the following respects: > > - I've recently published a portable fork of sb-aclrepl, called PREPL > (for "Portable REPL"). I'd prefer using this portable library over > an SBCL contrib. (The unportable bits are handled by a lower-level > library: conium, which is a feature-reduced fork of swank-backend > for use in hemlock and prepl). > > - Although rlwrap is a nice trick, there is also linedit, which > provides the same capabilities written in portable Lisp, which I > think is more interesting. > > - The SBCL built my 'clbuild compile-implementation sbcl' should be an > upstream SBCL. (The only non-upstream thing we do is to enable > threads, and I would argue that since upstream ships its *binaries* with > that feature and just hasn't enabled it in the sources, that a > reasonable deviation.) > > It might go a bit far to load extra ASDF systems. > > Since I don't want to override the normal repl in "clbuild lisp", I > have instead added a command "clbuild prepl". > > By default prepl is loaded at run time. Users who want it built into > their image for improved start up speed can dump a monster.core. > > Proposal: > > Perhaps it would be nice to enable linedit in "clbuild prepl" by > default? (Note that "clbuild prepl" also works on other Lisps, in > particular Clozure. We should see to it that the linedit feature is > either supported by those Lisps, or enabled only if running on SBCL).
Sounds good. In fact I might actually be tempted to use clbuild. :-) -T. _______________________________________________ clbuild-devel mailing list [email protected] http://common-lisp.net/cgi-bin/mailman/listinfo/clbuild-devel
