Hello, The main reason for resetting the tagbuf in `print.default()` and other entry points to the print routine is that it is currently not reset on exit. Creating a context to reset it on exit to its last value might work. This should be done in the entry points rather than in print-value-rec though, since callers of the latter might write to the tagbuf.
Another solution to this problem is proposed with the first patch in https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17610. Maybe I should extract this patch into its own entry so the discussion can be separate from the other patches. The idea is to pass the tag buffer as argument to the `print()` generic so it can be passed again to `print.default()`. The added benefit is that print methods can then pass their own tagbuf, which should be useful for printing special list-like objects. The downside is that it is technically a breaking change for methods that pass their dots to other functions (there's a couple of occurrences of this in the base packages). However I think such usage is not recommended for print methods because `print()` is a recursive generic that dispatches on heterogeneous objects. For example the user might pass `digits = 2` to print a list of objects. The print methods should make sure they ignore any unknown arguments. Best, Lionel On 5/10/20, brodie gaslam via R-devel <r-devel@r-project.org> wrote: > 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 > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
