`displaysize` is not inherited from `tty` in`IOContext(io, tty)`

[c42f]

For example in my terminal locally:

julia> displaysize(stdout)
(46, 167)

julia> displaysize(IOContext(IOBuffer(), stdout))
(24, 80)

This has flow-on effects like the context argument to sprint not being used for the display size and seems inconsistent with the :displaysize key being inherited from an IOContext.

On the other hand, it's not obvious to me how to fix this. If we always called displaysize on the context when creating the IOContext, we'd hit uv_tty_get_winsize which in turn hits an ioctl syscall on unix. That seems like a nasty pessimization. Another idea is to stash the context IO somewhere so we can call displaysize lazily.

[rohanxyzg]

Hey,
I would like to work on this issue.
Thanks!

[c42f]

Sure, however I think it's not entirely clear what the best solution here is.

One approach may be implement Base.unwrapcontext(io::Base.TTY) to call displaysize eagerly and save the result. The downside of this is that display size is a dynamic property (anyone can resize the remote terminal at any time), and also a potentially high-latency IO operation. So this would make IOContext construction from TTY a lot more expensive than it is now.

Another approach would be to stash the context as a key in the IOContext and update displaysize(::IOContext) to fall back to that underlying context lazily if necessary. This solves the above two issues, but means IOContext would carry an extra context key around always which seems less than ideal.

How about a hybrid approach — implement Base.unwrapcontext(tty::Base.TTY) to stash the tty as the :displaysize key in the returned ImmutableDict, which displaysize() can then use dynamically. The rule would be something like: if get(io, :displaysize) is itself an IO, call displaysize() again on that. Otherwise return the value directly. This avoids the performance hit of calling displaysize() eagerly, but doesn't bloat up the IOContext by default.

[c42f]

The following has a pleasing symmetry:

displaysize(io::IOContext) = haskey(io, :displaysize) ? displaysize(io[:displaysize]) : displaysize(io.io)

For that to work you'd also need

displaysize(x) = x  # Non-breaking, but perhaps also a bit weird
# or maybe
displaysize(x::Dims) = x  # Possibly mildly breaking, if someone somewhere has been setting :displaysize to non-Dims like things

[vtjnash]

This was (very mildly) intentional, in that I expected it to be very unlikely that the displaysize of the TTY has any relevance to the width available to an arbitrary sub-expression (which has follow-on effects of considering this only to be useful for text/plain MIME, and not regular recursive show). That said, the approach of making the displaysize key itself the IO object seems quite reasonable.

[c42f]

The motivating use case here is to add a few IOContext properties on top of a TTY (eg, :limit) and pass that new IOContext through to some function as the provided IO. But then that function gets the wrong displaysize().

[vtjnash]

It shouldn't prevent that?

julia> displaysize(IOContext(stdout, :limit => true))
(51, 200)

But from reviewing the code users, it looks like there's one dead call to it in show_ir, so I'll clean that up #38615. The others seem to indeed be generally interactive uses (Profile, REPL docs, Pkg, Markdown).

[c42f]

That's not the problem though. The issue is that properties are inherited from context in IOContext(io, context), except for displaysize, which "might be" inherited, depending on whether it's an explicit :displaysize key (inerited), or implicitly available from some syscall involving context (not inherited).

[JeffBezanson]

I think the current behavior is not so bad --- it seems better to require being explicit about inheriting something so state-dependent (on e.g. the size of my terminal window).