Pass plain text to the modifier closure where available #65
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.
Overview
It seems to me like it would be valuable to have the plain text provided as part of the
Modifier's closure. Currently the closure is passed the HTML generated by Ink (which is useful if one wants to append a prefix or suffix) and the original markdown (which is useful if one wants to perform a completely custom parsing I guess?).But you don't get the raw text content from the markdown. I can see this being useful in places where eg you want to generate really specific HTML or (as in my use case) where I want to generate a plain text version of the string to go along with the HTML version (for additional analysis like applying Hemmingway Editor style rules to the document).
Given I already have the original markdown I could always parse it again, but that feels like unnecessary work.
Testing steps
I ran
swift buildfrom the command line and confirmed the build built correctly using MacOS 11.2 (Big Sur). I also ranswift testand confirmed the tests pass.I amended the
testModifierInputtest to also check that the plain text was generated successfully.I have not tested on Linux.
Considerations
Firstly, the API has now been changed to return an optional String, as not all implementations of
HTMLConvertibleare implementations ofPlainTextConvertible. (Although in practise I think they all are currently, right?). This is simplified from an API point of view if we instead change theextensionto:extension HTMLConvertible where Self: Modifiable & PlainTextConvertible, but then you're coupling theModifiableandPlainTextConvertabileprotocols, which seems undesirable.This is also a breaking change as existing modifiers will need to be updated to include
plainText(or_) in the closure argument list.