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
indentation in pretty-printed strings #24
Comments
I agree that for short strings, ( 1
, ( 2
, Here is some custom show output
that has newlines
in it
, 3
)
) looks better than ( 1
, ( 2
, Here is some show output
that has newlines
in it
, 3
)
) However, for longer strings (for instance, strings that are over 120 characters and will wrap on a monitor), I'm not yet convinced that indenting after new lines will necessarily produce the easiest-to-read output. Unfortunately, I don't have time to fix this, and no one else has posted about it, so if you want to attempt the solution described in your comment, please feel free. I would be able to review any PRs. Please be warned that the code for doing the output is not very good. Ideally, it would use something like a state monad for keeping track of the output state (like done in hindent). Right now it is basically being done by hand. |
Glad to read that you are open to a PR. I will look into if I can implement this. I have a hunch that it will be simpler to do so than you imagine, e.g. no state tracking will be required. As for longer lines: That's an interesting question that I hadn't considered. I've mainly ran into this with shorter lines that have newlines in them so far. Here are a few ideas that came to me how we could tackle those too:
And whichever we choose from this, while having a sensible default, it may be For a start I think it makes sense to implement nr. 1 as that seems to be the simplest. |
I think this case will have to be modified. However I don't know how easy it will be to figure out how much to indent each subsequent line. I agree that your 1. is probably the easiest to implement, and the easiest to understand for the end user. |
Yes, since then I've found that case as well, attempting to modify it currently. I'm also writing a new doctest for this, running it with |
Some progress so far: Wizek@4a26a538f6 Currently failing with ### Failure in src/Text/Pretty/Simple.hs:209: expression `pPrintOpt cfg (1, (2, "foo\nbar\nbaz"), 3)'
expected: ( 1
, ( 2
, "foo
bar
baz"
, 3
)
)
but got: ( 1
,
( 2
, "foo
bar
baz"
)
, 3
)
Examples: 52 Tried: 52 Errors: 0 Failures: 1 I have a suspicion that this is due to |
### Failure in src/Text/Pretty/Simple.hs:209: expression `pPrintOpt cfg (1, (2, "foo\nbar\nbaz"), 3)'
expected: ( 1
, ( 2
, "foo
bar
baz"
, 3
)
)
but got: ( 1
,
( 2
, "foo
bar
baz"
)
, 3
)
Examples: 52 Tried: 52 Errors: 0 Failures: 1
Nevermind, it was just some mistaken assumption on my part how the current rendering looked. I've pushed some new commits which I believe might just implement this feature entirely; sending a PR shortly. |
I think you should be able to call doctest directly (instead of letting |
Current output:
Desired output:
Can be reproduced by e.g.
Implementing this may be as simple as
What do you say, @cdepillabout?
p.s. I love your library.
p.p.s I've just noticed that even strings with newlines seem to cause the same issue:
pPrint (1, (2, "foo\nbar\nbaz", 3))
. My proposed solution above would solve this case as well.p.p.p.s In case you agree with my 'prognosis' and proposed 'treatment', would you prefer implementing the fix or would you like if I submitted a pull request?
The text was updated successfully, but these errors were encountered: