newbie question: back history on the CMUCL listener

[h...@uol.com.br]

Hello-

Forgive my ignorance: simple question: in CMUCL I would like to know
what the keystroke for the back history is (in CLISP it's the up arrow) so that
I don't have to type the whole line again.
Thank you for your benevolent patience and may grace fall upon your heads :-)

HL

[Raymond Toy]

h...@uol.com.br wrote:

>
> Hello-
>
> Forgive my ignorance: simple question: in CMUCL I would like to know
> what the keystroke for the back history is (in CLISP it's the up arrow) so that
> I don't have to type the whole line again.

CMUCL doesn't have such a feature, so there's no keystroke to do what
Clisp does.

I always run CMUCL with XEmacs and ilisp.

Ray

[Dr. Edmund Weitz]

h...@uol.com.br writes:

There is no such thing. Most Lisp programmers prefer to use an IDE
that's based either on Emacs or on an Emacs-like editor (as with
vendor-supplied IDEs like the one from Xanalys). With CMUCL and many
other Lisp implementations you start your Lisp environment from
within Emacs and use ILISP for command history and other things. See
<http://sourceforge.net/projects/ilisp> for details.

Edi.

[Martin Cracauer]

h...@uol.com.br writes:

>Hello-

Besides the menioned ilisp, you can also turn any program into a
readline program by running it in emacs M-x shell-mode.

Also, CMUCl has its own emacs-like editor, Hemlock which is kinda
CMUCl's answer to Clisp readline integration :-)

Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <crac...@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/

[cbbr...@acm.org]

This isn't available as a built-in thing, but someone has implemented
such a thing as an "extension."

See:
<http://emu.res.cmu.edu/~mrd/line-reader/>
--
(reverse (concatenate 'string "ac.notelrac.teneerf@" "454aa"))
http://www.ntlug.org/~cbbrowne/spiritual.html
Roses are red
Violets are blue
Some poems rhyme
But this one doesn't.

[Thomas A. Russ]

cbbr...@acm.org writes:

> h...@uol.com.br writes:
> > Forgive my ignorance: simple question: in CMUCL I would like to
> >know what the keystroke for the back history is (in CLISP it's the up
> >arrow) so that I don't have to type the whole line again. Thank you
> >for your benevolent patience and may grace fall upon your heads :-)
>
> This isn't available as a built-in thing, but someone has implemented
> such a thing as an "extension."

Well, it may not be as flexible, but there is, in fact, a built-in thing
in Common Lisp:

+ ++ +++

are bound to the last, next-to last and input before that in the
listener.

This doesn't give you the full flexibility of history-based interfaces,
but at least it can sometimes save you some typing.

--
Thomas A. Russ, USC/Information Sciences Institute t...@isi.edu

[Thomas F. Burdick]

t...@sevak.isi.edu (Thomas A. Russ) writes:

> cbbr...@acm.org writes:
>
> > h...@uol.com.br writes:
> > > Forgive my ignorance: simple question: in CMUCL I would like to
> > >know what the keystroke for the back history is (in CLISP it's the up
> > >arrow) so that I don't have to type the whole line again. Thank you
> > >for your benevolent patience and may grace fall upon your heads :-)
> >
> > This isn't available as a built-in thing, but someone has implemented
> > such a thing as an "extension."
>
> Well, it may not be as flexible, but there is, in fact, a built-in thing
> in Common Lisp:
>
> + ++ +++
>
> are bound to the last, next-to last and input before that in the
> listener.

Huh. I use + all the time for situations like:

* (with-my-buggy-macro (foo (bar))
(baz))
;; something unexpected here
* (macroexpand +)

But I don't think I've ever done (eval +). Not that it wouldn't work.

> This doesn't give you the full flexibility of history-based interfaces,
> but at least it can sometimes save you some typing.

Sure it does, it just takes a little more typing/counting :)

* (loop for i from 1 to 10 do (format nil "~@R~%" i))
nil
* (setf (second (nth 8 +)) t)
t
* ++
(loop for i from 1 to 10 do (format t "~@R~%" i))
* (eval *)
I
II
III
IV
V
VI
VII
VIII
IX
X
nil

--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'

[Erik Naggum]

* t...@conquest.OCF.Berkeley.EDU (Thomas F. Burdick)

| Sure it does, it just takes a little more typing/counting :)
|
| * (loop for i from 1 to 10 do (format nil "~@R~%" i))
| nil
| * (setf (second (nth 8 +)) t)
| t
| * ++
| (loop for i from 1 to 10 do (format t "~@R~%" i))
| * (eval *)

I was about to suggest (eval (subst t nil +)), until it dawned on me that
subst works on trees. But any other substitution, and it should work. :)

///
--

[Kent M Pitman]

Erik Naggum <er...@naggum.net> writes:

or #.(subst t nil +)

Though I vaguely recall some "non-portability" (heh) in that some
implementations may bind +/*/etc. only around the EVAL of the REPL and
others may do it around the READ. ... Anyway #. and #.` are often very
handy in conjunction with +/*, etc.

In a debugger loop, if the EVAL will occur in a given stack context, an
explicit EVAL may not, so #. may be not only fun but necessary there.

[Thomas F. Burdick]

Kent M Pitman <pit...@world.std.com> writes:

> Erik Naggum <er...@naggum.net> writes:
>
> > * t...@conquest.OCF.Berkeley.EDU (Thomas F. Burdick)
> > | Sure it does, it just takes a little more typing/counting :)
> > |
> > | * (loop for i from 1 to 10 do (format nil "~@R~%" i))
> > | nil
> > | * (setf (second (nth 8 +)) t)
> > | t
> > | * ++
> > | (loop for i from 1 to 10 do (format t "~@R~%" i))
> > | * (eval *)
> >
> > I was about to suggest (eval (subst t nil +)), until it dawned on me that
> > subst works on trees. But any other substitution, and it should work. :)
>
> or #.(subst t nil +)

Heh, I think you missed Erik's point.

* (loop for i from 1 to 10 do (format nil "~@R~%" i))
nil

* (subst t nil +)
(loop for i from 1 to 10 do (format t "~@R~%" i . t) . t)

Oops, that's not very much like a CL expression.

> Though I vaguely recall some "non-portability" (heh) in that some
> implementations may bind +/*/etc. only around the EVAL of the REPL and
> others may do it around the READ. ... Anyway #. and #.` are often very
> handy in conjunction with +/*, etc.
>
> In a debugger loop, if the EVAL will occur in a given stack context, an
> explicit EVAL may not, so #. may be not only fun but necessary there.

Huh. In that case, I'd probably do something more like '#.(subst ...)
then #.*, because I always like to see whatever it is I'm about to
evaluate.