From brod|e@g@@|@m @end|ng |rom y@hoo@com  Sun May 10 17:13:07 2020
From: brod|e@g@@|@m @end|ng |rom y@hoo@com (brodie gaslam)
Date: Sun, 10 May 2020 15:13:07 +0000 (UTC)
Subject: [Rd] Minor Infelicity in Printing of Objects Nested in Lists
References: <952966889.973899.1589123587774.ref@mail.yahoo.com>
Message-ID: <952966889.973899.1589123587774@mail.yahoo.com>

Currently S3 objects nested in generic vectors cause the tag buffer to be reset.? This feels sub-optimal for those objects that don't have a print method:

> list(a=list(b='hello'))
$a
$a$b???????????????? ### <<<< notice "$a$b"
[1] "hello"


> list(a=structure(list(b='hello'), class='world'))
$a
$b?????????????????? ### <<<< notice "$b", not "$a$b"
[1] "hello"

attr(,"class")
[1] "world"

This happens because the default print method resets the tag buffer anytime it's called[1], whether by a custom print method, or by internal C code as part of the recursion into objects in `printValueRec`[2].

One possible way to "fix" this is to make it the responsibility of `printValueRec` to reset the tag buffer on exit from the top level, but that would mean always having an active context to catch errors instead of just for win32 as is the case now.? Additionally, print method authors may themselves intentionally rely on `print.default` for some parts their output, in which case it may be desirable to reset the tag buffer.

Obviously not a big deal.? In my use case it can make it difficult to identify what part of a complex object caused a difference in a diff with a few neighboring context lines.? Just mentioning it in case there is interest in doing something about it.? If so I'll be happy to create a bugzilla ticket and assist with patches/testing.

Best,

B.

[1]: https://github.com/wch/r-source/blob/tags/R-4-0-0/src/main/print.c#L309
[2]: https://github.com/wch/r-source/blob/tags/R-4-0-0/src/main/print.c#L570



[Rd] Minor Infelicity in Printing of Objects Nested in Lists
brodie gaslam