[Openmcl-devel] Changing the REPL

[Gary Byers]

On Sun, 2 Dec 2007, Duane Ryan wrote:
> Still, one thing really annoys me: the repl. First of all, I'd like to
> change the prompt.

I checked in a change a little while ago that makes that a little easy
to do; it should propagate to CVS within the hour.


The basic idea is that CCL:*LISTENER-PROMPT-FORMAT* is defined:

(defparameter *listener-prompt-format* "~[?~:;~:*~d>~] ")

and used by the code that actually prints the REPL prompt:

;;; In CCL::PRINT-LISTENER-PROMPT:

    (format stream *listener-prompt-format* *break-level*)

where *BREAK-LEVEL* is 0 if not in a break loop and >0 otherwise.

*LISTENER-PROMPT-FORMAT* is expected to be a "format-control", 
which is either a format control string (like the initial value
above) or a function (possibly defined via FORMATTER) that
takes a stream and an &REST argument and returns the (possibly null)
unused tail of that &rest arg.  Since the only use of that format
control is that call in the call above and that call always passes
a single argument, a function that takes a single format parameter
and returns NIL would keep the FORMAT machinery happy:

? (defun standard-lpf (stream level)
   (if (zerop level)
     (format stream "? ")
     (format stream "~d> " level))
   ;; Either arm of the IF above will return NIL, but we might as
   ;; well be explicit about it.
   nil)
STANDARD-LPF
? (setq ccl:*listener-prompt-format* #'STANDARD-LPF)

is yet another way of getting the same (traditional) behavior. (Presumably,
it'd be more interesting to define a format control function that didn't
print the prompt the same old way ...)

As far as line editing goes: another interesting alternative might be
linedit (<http://common-lisp.net/project/linedit/>).  Someone sent me
patches several months ago that (among other things) provided non-standard
character name definitions that that code expected and we discussed
how it could be integrated into OpenMCL's REPL, but neither of us followed
up on this.

A general issue with things like this is that most people most of the
time run lisps under Emacs (possibly via SLIME), and built-in input
editing features like this tend not to interact well with the (usually
much more extensive) editing features that Emacs/SLIME provide.  There
are lots of ways around this (e.g., only turn the builtin stuff on
if not running under Emacs and/or use command-line arguments to enable/
disable it.)

I'd agree that it'd be nice to have saner input editing when running
in a vanilla shell environment (or as a detached background process,
or in some other cases.)  You may or may not like Emacs and/or SLIME,
but if (as a new user) you're not aware of them you might find them
useful.