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 build
from the command line and confirmed the build built correctly using MacOS 11.2 (Big Sur). I also ranswift test
and confirmed the tests pass.I amended the
testModifierInput
test 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
HTMLConvertible
are 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 theextension
to:extension HTMLConvertible where Self: Modifiable & PlainTextConvertible
, but then you're coupling theModifiable
andPlainTextConvertabile
protocols, 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.