Skip to content
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

A version of Terminal.renderIO that checks ANSI support? #88

Open
sjakobi opened this issue Oct 21, 2019 · 4 comments
Open

A version of Terminal.renderIO that checks ANSI support? #88

sjakobi opened this issue Oct 21, 2019 · 4 comments

Comments

@sjakobi
Copy link
Collaborator

sjakobi commented Oct 21, 2019

This is a common pattern in dhall:

do
supportsANSI <- System.Console.ANSI.hSupportsANSI System.IO.stdout

Pretty.Terminal.renderIO
    System.IO.stdout
    (if supportsANSI
        then docStream
        else (Pretty.unAnnotateS docStream))

Could prettyprinter-ansi-terminal export a version of renderIO so I could write something like this instead?

Pretty.Terminal.renderIOCheck System.IO.stdout docStream
@quchen
Copy link
Owner

quchen commented Oct 25, 2019

In a way it could, but I think there are too many easily implemented combinations for rendering already – renderIO, putDoc, hPutDoc, … – they all combine small basic functions for convenience.

However, the combinations are neither exhaustive, nor are the existing ones very memorable. I’d rather like to remove some of these functions one day, and have users implement their own versions. Is there a reason you need this in the library, and don’t want to simply add this to Dhall’s source?

@sjakobi
Copy link
Collaborator Author

sjakobi commented Oct 25, 2019

However, the combinations are neither exhaustive, nor are the existing ones very memorable. I’d rather like to remove some of these functions one day, and have users implement their own versions.

As a user, I appreciate libraries that provide useful combinations, even if they aren't very memorable. If I know which library to look at, I can find them. The value of such utilities is that I don't have to define them myself, I don't have to find a place to put them, and I don't have to maintain them.

Is there a reason you need this in the library, and don’t want to simply add this to Dhall’s source?

"need" is a bit much, it's more of a desire or a wish. :)

@bgamari
Copy link

bgamari commented Mar 6, 2021

For what it's worth, I have also needed such a function.

As a user, I appreciate libraries that provide useful combinations, even if they aren't very memorable.

I would strongly second this, especially when the useful combination allows me to avoid adding yet another build dependency to my .cabal file.

@sjakobi
Copy link
Collaborator Author

sjakobi commented Jun 27, 2021

If we can find a good name for this function, I'd be in favor of adding it. Name suggestions / PRs welcome! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants