First appearance of ~t (Tilda T) in format string is not expanded properly

[YP]

When I type:
(format t "~3tXXX~%~3tYYY~%")

it prints (please pay attention to number of spaces in front of XXX and YYY):
 XXX
   YYY

it should print:
   XXX
   YYY

Additional info:
$ sbcl --version
SBCL 1.0.30

$ uname -a
Linux gis 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 18:40:08 UTC 2009 i686 GNU/Linux

[YP (yuriy-pasichnyk)]

BTW
1. the same bug exist in CMUCL also.
2. the issue appears only when outputting to a stream (when first argument to format is nil - everything works as it should).

[Alastair Bridgewater (alastair-bridgewater)]

I believe that you will find (sb-kernel:charpos) to return 2 in this case (the "* " prompt), and there is no intervening newline to reset the position. (format t "~%~3tXXX~%~36YYY~%") should print something more to your liking (though with an additional linefeed).

[Stas Boukarev (stassats)]

Then maybe ~& would be better (inserts a newline unless already at the
beginning of a line).

[YP (yuriy-pasichnyk)]

Yes, indeed (sb-kernel:charpos) returns 2.The question is - why?
I know how to work around the problem (with additional new line, but still),
so I reported the bug
not because it is blocking me, but purely as a help to make SBCL even
better.

On Tue, Oct 6, 2009 at 9:54 PM, Alastair Bridgewater <
<email address hidden>> wrote:

> I believe that you will find (sb-kernel:charpos) to return 2 in this
> case (the "* " prompt), and there is no intervening newline to reset the
> position. (format t "~%~3tXXX~%~36YYY~%") should print something more
> to your liking (though with an additional linefeed).
>
> --
> First appearance of ~t (Tilda T) in format string is not expanded properly
> https://bugs.launchpad.net/bugs/439286
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Steel Bank Common Lisp: New
>
> Bug description:
> When I type:
> (format t "~3tXXX~%~3tYYY~%")
>
> it prints (please pay attention to number of spaces in front of XXX and
> YYY):
> XXX
> YYY
>
> it should print:
> XXX
> YYY
>
> Additional info:
> $ sbcl --version
> SBCL 1.0.30
>
> $ uname -a
> Linux gis 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 18:40:08 UTC 2009
> i686 GNU/Linux
>

[Nikodemus Siivola (nikodemus)]

I think this can be considered an exemplar of

  https://bugs.launchpad.net/sbcl/+bug/309471

I'm not marking this a duplicate yet, however, as that seems to occasionally cause confusion as to where the bug disappeared. (But unless there are objections, I will do that in a week or so.)

[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.