pretty printer and prompt

[Nikodemus Siivola]

  Using the pretty-printer from the command prompt gives funny
  results, apparently because the pretty-printer doesn't know
  about user's command input, including the user's carriage return
  that the user, and therefore the pretty-printer thinks that
  the new output block should start indented 2 or more characters
  rightward of the correct location.

[kr (kr-u)]

this bug report is a bit vague, lacking a concrete example. but at least there are some examples in the duplicate of this bug.

as far as i understand, the 2 character difference is due to the prompt that was printed, which is by default "* "

[kr (kr-u)]

i'll post the following both for bugs #439286 and #309471 , so
hopefully somebody will see it. i don't understand yet what the
implications are regarding duplicated bugs on launchpad.

i ran across this too, while investigating some other pretty-printing
bug having to do with indentation, which i will report at some other
point, later. even after my attempted fix, the first line looked
horribly confused, because of this bug here.

reply to YP:
> Yes, indeed (sb-kernel:charpos) returns 2.The question is - why?

after investigating this for a while (not having previously ever
looked at the stream implementation stuff), i concluded that this
basically reflects the change of the stream done by printing the
prompt in the toplevel repl. the default function bound by
SB-INT:*REPL-PROMPT-FUN* prints "* " , which is 2 characters.

there is a slot called output-column in the low-level fd-stream
structure that somehow gets updated during printing, and which
(sb-kernel:charpos) reads in some rather indirect way.

my proposed fix is to simply reset that slot to 0, after the prompt
was printed. maybe a bit of a hack, but it seems to work quite well.

here is the reported test case with my fix (i changed my sbcl version to 1.3.1.1) :

===========
This is SBCL 1.3.1.1, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (format t "~3tXXX~%~3tYYY~%")
   XXX
   YYY
NIL
*
===========

as one can see, a new side-effect of my fix is that there is no
extraneous newline being printed anymore, before the results are
printed. i think i prefer this in any event. it is also more similar
to franz allegro acl-9, which doesn't have the extra linefeed.

i'll attach a patch against sbcl-1.3.1 . with this, it rebuilds fine
and there does not seem to be any real change in the tests that are
run.

so, hopefully, now bugs #439286 and #309471 can be resolved.