Okay, this one is quite strange. First define this function:
(defun foo () (write (macroexpand-1 '(with-open-file (in "foo.txt") (read in))) :pretty t))
Then invoke it several times. What I observe is that the body of the let moves to the right each time I invoke FOO, as if the pretty-printing stream is somehow preserving some information about what column it is indenting to from call to call. I believe I had observed this behavior before when I was screwing around with pretty-printing logical blocks. This weird shifting only happens in the SLIME repl, the same function invoked from the *inferior-lisp* buffer works as expected. I've observed this in both OpenMCL and in Allegro on GNU/Linux.
-Peter
Peter Seibel peter@javamonkey.com writes:
Okay, this one is quite strange. First define this function:
(defun foo () (write (macroexpand-1 '(with-open-file (in "foo.txt") (read in))) :pretty t))
Then invoke it several times. What I observe is that the body of the let moves to the right each time I invoke FOO, as if the pretty-printing stream is somehow preserving some information about what column it is indenting to from call to call. I believe I had observed this behavior before when I was screwing around with pretty-printing logical blocks. This weird shifting only happens in the SLIME repl, the same function invoked from the *inferior-lisp* buffer works as expected. I've observed this in both OpenMCL and in Allegro on GNU/Linux.
Yes the stream preserves the column. The reason you don't see this behavior in the *inferior-lisp* is that Lisp prints the prompt with a newline character and this resets the column. SLIME inserts the prompt at the Emacs side without printing any newline to the stream.
I will try to find a way to reset the column.
Helmut.
-
Helmut Eller -
Peter Seibel