Move to Pretty Printer Proper #474
Conversation
HuwCampbell
force-pushed
the
topic/0.18.0
branch
2 times, most recently
from
cb70cc6
to
085602e
Compare
|
As you have some specific constraints for this library regarding the |
| , transformers >= 0.2 && < 0.7 | ||
| , transformers-compat >= 0.3 && < 0.8 | ||
| , ansi-wl-pprint >= 0.6.8 && < 0.7 | ||
| , prettyprinter >= 1.7 && < 1.8 | ||
| , prettyprinter-ansi-terminal >= 1.1 && < 1.2 |
There was a problem hiding this comment.
prettyprinter-ansi-terminal is problematic for my use cases, because it depends on text unconditionally.
Needless to say that my use cases are quite extreme and exotic. You are doing an excellent job in this PR.
Sorry, I don't remember, does optparse-applicative use any ANSI capabilities like colors or bold/italic?
There was a problem hiding this comment.
Not directly. I didn't want to add an annotation type parameter to Parser, so went with one which is capable enough (and which would still support what downstream users might have in their doc strings).
So for your use-case we could make a later release where this import is behind a flag.
There was a problem hiding this comment.
This suggests that ideally ParserInfo a should be additionally parameterized by ann from Doc ann, but it's probably too much of a breakage for a stable package.
Sorry, I don't have much time to delve into it right now, so I suggest you go ahead as is, and I'll try to figure out workarounds for my use case later. Thanks for remembering about my concerns, it's a pleasure to deal with you.
This also adds in the changelog for 0.17.1 which is not strictly a parent of this commit, but it's close enough and will be release in time order.
This is a proposed 0.18 release with the Prettyprinter support proper.
We will probably need to drop some older GHC versions for this, but
they're really old now.