- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add read/write specialisation for IOContext{AnnIO} #53715
Merged
+25
−0
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Loading status checks…
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 Jameson wasn't happy with it, with concerns that it could be tricked by IOContext{Any}). # 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.
commit 9fdb4dbfc49114dc8773ec92c3ceaaaa9a42be49
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change | ||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
@@ -500,6 +500,24 @@ function write(dest::AnnotatedIOBuffer, src::AnnotatedIOBuffer) | |||||||||||||||||||||||||||||||||||||||||||||||||||
nb | ||||||||||||||||||||||||||||||||||||||||||||||||||||
end | ||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
# So that read/writes with `IOContext` (and any similar `AbstractPipe` wrappers) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
# work as expected. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
function write(io::AbstractPipe, s::Union{AnnotatedString, SubString{<:AnnotatedString}}) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
if pipe_writer(io) isa AnnotatedIOBuffer | ||||||||||||||||||||||||||||||||||||||||||||||||||||
write(pipe_writer(io), s) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
else | ||||||||||||||||||||||||||||||||||||||||||||||||||||
invoke(write, Tuple{IO, typeof(s)}, io, s) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
end::Int | ||||||||||||||||||||||||||||||||||||||||||||||||||||
end | ||||||||||||||||||||||||||||||||||||||||||||||||||||
# Can't be part of the `Union` above because it introduces method ambiguities | ||||||||||||||||||||||||||||||||||||||||||||||||||||
function write(io::AbstractPipe, c::AnnotatedChar) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
if pipe_writer(io) isa AnnotatedIOBuffer | ||||||||||||||||||||||||||||||||||||||||||||||||||||
write(pipe_writer(io), c) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
else | ||||||||||||||||||||||||||||||||||||||||||||||||||||
invoke(write, Tuple{IO, typeof(c)}, io, c) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
end::Int | ||||||||||||||||||||||||||||||||||||||||||||||||||||
end | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Comment on lines
+505
to
+519
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The following is a 100% optional suggestion that is ultimately a matter of taste As you are most likely aware, you could avoid the code duplication by using
Suggested change
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
""" | ||||||||||||||||||||||||||||||||||||||||||||||||||||
_clear_annotations_in_region!(annotations::Vector{Tuple{UnitRange{Int}, Pair{Symbol, Any}}}, span::UnitRange{Int}) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still trying to wrap my brain around this:
unsafe_write(io::AbstractPipe, ...)
for simply redispatches tounsafe_write(pipe_writer(io)::IO, ...)
write(io, ...)
methods in the end go throughunsafe_write(io, ...)
write(pipe_writer(io), s)
seems pointlesswrite
methods ... such as yourwrite(io::AnnotatedIOBuffer, astr::Union{AnnotatedString, SubString{<:AnnotatedString}})
method...And now we have a problem if
AbstractPipe
type, such asIOContext
, wraps anAnnotatedIOBuffer
: instead of dispatching fromwrite(io, ...)
tounsafe_write(io, ...)
you need it to go throughpipe_writer(io)
so that the annotations can be handled by that.What if there is a sandwich of three AbstractPipe types, say an IOContext outermost, then some other AbstractPipe type, then the
AnnotatedIOBuffer
-- it wouldn't work out then either, right?This then makes me wonder: why not "simply" something like
I bet you considered this and ruled it out for some reason, but I didn't see it in the PR discussion.
None of this is meant as fundamental objection to this PR, but I feel at least this comment should be a bit more elaborate (which, if you happen to agree with this POV, could certainly wait for a future PR -- I don't mind to hold this one up). I'd love to be helpful and suggest something, but for that I'd first have to really understand it, hence my questions :-).