Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add specialised AnnotatedString pipe read/writes
Ensure that when an AnnotatedIOBuffer is wrapped in an IOContext (or similar AnnotatedPipe-based construct), that writes of annotated strings/chars and reading out an AnnotatedString is unimpeded by the IOContext wrapping. Without these specialisations, the generic pipe_reader/pipe_writer fallbacks will directly access the underlying IOBuffer and annotations will be lost. There are a number of scenarios in which one might want to combine an AnnotatedIOBuffer and IOContext (for example setting the compact property). Losing annotations in such scenarios is highly undesirable. It is of particular note that this can arise in situations where you can't unwrap the IOContext as needed, for example when passing IO to a function you do not control (which is currently extremely hard to work around). Getting this right is a little difficult, and a few approaches have been tried. Initially, I added IOContext{AnnotatedIOBuffer} specialisations to show.jl, but arguably it's a bit of a code smell to specialise in this way (and Jamerson wasn't happy with it). # So that read/writes with `IOContext` (and any similar `AbstractPipe` wrappers) # work as expected. write(io::IOContext{AnnotatedIOBuffer}, s::Union{AnnotatedString, SubString{<:AnnotatedString}}) = write(io.io, s) write(io::AnnotatedIOBuffer, c::AnnotatedChar) = write(io.io, c) Then I tried making it so that IOContext writes dispatched on the wrapped IO type, but of course that broke cases like IOContext{IOBuffer} with :color=>true. # So that read/writes with `IOContext` (and any similar `AbstractPipe` wrappers) # work as expected. write(io::AbstractPipe, s::Union{AnnotatedString, SubString{<:AnnotatedString}}) = write(pipe_writer(io), s) write(io::AbstractPipe, c::AnnotatedChar) = write(pipe_writer(io), c) Finally, we have the current AbstractPipe + Annotated type specialisation, which IOContext is just an instance of. To avoid behaving too broadly, we need to confirm that the underlying IO is actually an AnnotatedIOBuffer. I'm still not happy with this, only idea I've had other than implementing IOContext{AnnotatedIOBuffer} methods that actually seems viable, and I've had trouble soliciting help from other people brainstorming here. If somebody can implement something cleaner here in the future, I'd be thrilled.
- Loading branch information