-
-
Notifications
You must be signed in to change notification settings - Fork 29
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
Use 'prettyprinter' library #67
Conversation
@@ -14,6 +14,4 @@ module Text.Pretty.Simple.Internal | |||
import Text.Pretty.Simple.Internal.Color as X | |||
import Text.Pretty.Simple.Internal.ExprParser as X | |||
import Text.Pretty.Simple.Internal.Expr as X | |||
import Text.Pretty.Simple.Internal.ExprToOutput as X | |||
import Text.Pretty.Simple.Internal.Output as X |
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.
Two modules have gone, as we now render straight from Expr
.
The remaining OutputPrinter
should perhaps be renamed ExprPrinter
, since the old Output
type that was being printed there no longer even exists.
@@ -39,15 +37,15 @@ import System.Console.ANSI | |||
-- | |||
-- If you don't want to use a color for one of the options, use 'colorNull'. | |||
data ColorOptions = ColorOptions | |||
{ colorQuote :: Builder | |||
{ colorQuote :: AnsiStyle |
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.
Colours are now expressed with AnsiStyle. This should actually be easier for users to work with, but is obviously a breaking change.
-- suitable for passing to any /prettyprinter/ backend. | ||
-- Used by 'Simple.pString' etc. | ||
layoutString :: OutputOptions -> String -> SimpleDocStream AnsiStyle | ||
layoutString opts = exprsToDocStream opts . expressionParse |
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.
This is potentially very useful, and should perhaps actually be exported from a non-Internal module somewhere.
It makes things like coloured HTML output much easier.
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.
It makes things like coloured HTML output much easier.
Well, it would, except that AnsiStyle
is opaque, and so it wouldn't be possible to define a conversion from it.
Not sure how best to resolve this. Perhaps have our own abstract Colour type?
@sjakobi Would you want to review this as well? |
As it happens, I just mentioned it to him on Reddit about two minutes ago. |
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.
Sorry, no proper review yet. I've had a brief look at the code and found it quite dense. Not sure how to make it more digestible though, maybe add type annotations and haddocks?
Or are you looking only for feedback on something particular at this stage?
Thanks @sjakobi. I was mostly just looking for feedback on the bits I've commented on here for now. I appreciate the full code isn't too easy to follow. I should probably separate more of And I'll try to match the old output fully, while keeping in mind how the rules on spacing could be made configurable. |
I've finally found the time to revisit this, but
I don't think I've changed anything relevant since this worked two weeks ago (I haven't changed anything within @cdepillabout @sjakobi Have you ever seen this sort of failure? |
@georgefst Sorry, no idea regarding that failure. I mostly use |
This should now be a lot simpler and more readable. Changes:
87984b2 and related changes introduce some conflicts, but it looks fairly straightforward to solve. Finally, the commit history is a little messy. I strongly recommend this be squashed. |
@georgefst Could you rebase this on the current |
Also, simplify the implementation considerably
Done, but there's one test failure. It looks like pretty-simple was previously trimming trailing newlines from string literals, which this PR doesn't do. Is there a particular reason for doing that, or shall I just change the expected test result? |
@georgefst I actually don't really remember, but let me take a look at it when I review this PR. (Sorry, I've been quite busy these last few weeks. It might take me another week or two til I have enough time to look through this.) |
No worries at all! The work I actually needed this for required a further change anyway, so I'm happily using my own fork for that (though I will open a further PR once this is merged). |
Oh, and don't worry too much about trying to support all sorts of older GHCs. I can always fix this up if I feel like it, but I don't want you to have to spend too much time on this. It is probably unlikely anyone absolutely needs new versions of pretty-simple on like GHC-8.2, GHC-8.0, GHC-7.10, etc! |
Yeah, it's not something I'd want to sink much time into, but it was an easy enough fix in this case (once I'd remembered the syntax...). Looks like all the failures now are from that one test. |
@georgefst Okay, sounds good. So I guess you're ready for me to review this and possibly merge it in? |
I haven't yet had a chance to look at the issue with the extra indentation at the start of muti-line strings and 'other's (corresponding to the two modified test outputs). But apart from that, yes. It's possible it could still do with more comments, but there are now at least haddocks on everything top-level. |
Well now there are. PS. is it possible to tell the CI to ignore that sort of change? Just seems like such a waste of energy |
Okay, sounds good. I'll try to get to a review of this in a week or two or so.
I think if you have commit rights here on github, it should be possible to stop CI, but unfortunately I didn't see this fast enough to be able to get to it. |
More compact output for multiline strings. Expected output changed to reflect that trailing newlines aren't stripped.
It's a stated goal of
Oh, okay. Then what's the purpose of having that variant if you can't take advantage of the laziness? Even something like |
Anyway, we can fix this here with an actually-lazy As it happens, it's virtually a one-liner with quchen/prettyprinter#164, so perhaps I should reopen that... |
Oh, interesting! I wasn't aware of that.
I think it's just an exposed implementation detail that can be used when you don't need a strict If you think that this is something that should be addressed, please do open an issue on the |
src/Text/Pretty/Simple.hs
Outdated
|
||
-- | Straightforward modification of 'Data.Text.Prettyprint.Doc.Render.Terminal' | ||
-- , in order to make it actually lazy | ||
renderLazy :: SimpleDocStream AnsiStyle -> TL.Text |
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.
I'd ideally like to upstream this to prettyprinter
, rather than keep it here...
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.
Hey, I haven't forgotten about this, I just haven't really been able to find time for it within the past week or so! Hopefully I'll get a chance to take a good look at this in the next two weeks. |
@cdepillabout No worries, it's probably worth waiting for quchen/prettyprinter#176 anyway. I still need to fix up some minor things with that PR, and I'm also waiting to see if the |
|
Allows us to remove laziness workaround.
Future-proofing
CI has failed on |
@georgefst Thanks for doing so much work on this! Sorry for taking so long to get to the review. I think this is a big improvement for the output printing, and I agree that with the nice refactoring you have here, a bunch of other PRs will be much easier to implement. Do you want me to release this on Hackage as pretty-simple-4.0.0.0? Or pretty-simple-3.4.0.0? This is the biggest change made to pretty-simple in a long time, so I'm leaning towards 4.0.0.0. |
Well it's a big change, but it's mostly an internal one. Personally I'd wait until some of the features and fixes which can make use of this change are implemented, seeing as these will bring more breaking changes, albeit not big ones. I intend to submit PRs for the ones I care about in the next few days. |
This is a big change, and definitely isn't ready to go in as-is, but it's ready for feedback.
All tests should pass right now, but only because I changed some of the expected outputs...
This closes #25 as obsolete, and should make #43, #56 and #66 easier to implement. Indeed I'm going to go off and implement #66 on a separate branch now, seeing as that's what led me to do all this in the first place...