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

Configurable encoding #153

Merged
merged 2 commits into from Sep 17, 2018

Conversation

@chpatrick
Copy link
Contributor

commented Sep 6, 2018

By default, libyaml wraps strings at 80 characters with line breaks. This can make it cumbersome to edit long strings in yaml because you have to deal with the inserted newlines, and you can't use your editor's word wrap. Do you think it makes sense to disable this?

@snoyberg

This comment has been minimized.

Copy link
Owner

commented Sep 9, 2018

I'm not too excited about a cosmetic change like this that others may dislike, given that there's no objective way to measure which approach should be used.

@chpatrick

This comment has been minimized.

Copy link
Contributor Author

commented Sep 9, 2018

@snoyberg

This comment has been minimized.

Copy link
Owner

commented Sep 9, 2018

Yeah, I'd be in favor of that. We'd probably need a new set of APIs that alloy passing in an options value containing various options, such as described in #152. encodeWith and encodeFileWith seem like reasonable names. You interested in working on such a PR?

@chpatrick

This comment has been minimized.

Copy link
Contributor Author

commented Sep 9, 2018

@chpatrick chpatrick changed the title Don't wrap strings at 80 characters. Configurable encoding Sep 9, 2018

@chpatrick

This comment has been minimized.

Copy link
Contributor Author

commented Sep 9, 2018

I've added encodeWith and encodeFileWith, and also added an option to address #152. However, doesn't this conflict a bit with Data.Yaml.Pretty which also seems to be for customizable encoding?

src/Data/Yaml.hs Show resolved Hide resolved
@@ -66,6 +68,10 @@ module Data.Yaml
-- * Classes
, ToJSON (..)
, FromJSON (..)
-- * Custom encoding
, isSpecialString
, EncodeOptions(..)

This comment has been minimized.

Copy link
@snoyberg

snoyberg Sep 12, 2018

Owner

To avoid backwards incompatible changes in the future, I'd rather not expose the data constructors here. Instead, I'd like to see something like:

, EncodeOptions
, defaultEncodeOptions
, setEncodeOptionsStringStyle
import qualified Text.Libyaml as Y

data EncodeOptions = EncodeOptions
{ encodeOptionsStringStyle :: Text -> ( Tag, Style )

This comment has been minimized.

Copy link
@snoyberg

snoyberg Sep 12, 2018

Owner

For whatever identifier gets exported providing support for this, there should be a public comment explaining that missetting this can result in semantically-mismatched YAML documents due to #24. Also, please ensure that any exposed identifiers have a Haddock comment with a @since comment.

@snoyberg

This comment has been minimized.

Copy link
Owner

commented Sep 12, 2018

doesn't this conflict a bit with Data.Yaml.Pretty which also seems to be for customizable encoding?

Maybe, but it seems like everyone wants to use the Data.Yaml module.

@chpatrick chpatrick force-pushed the chpatrick:infinite-width branch from 580a489 to a99f50e Sep 12, 2018

@chpatrick

This comment has been minimized.

Copy link
Contributor Author

commented Sep 12, 2018

Please take another look.

@snoyberg
Copy link
Owner

left a comment

Looks good, just a few more minor comments.

ChangeLog.md Outdated Show resolved Hide resolved
src/Data/Yaml.hs Show resolved Hide resolved
src/Data/Yaml.hs Outdated Show resolved Hide resolved

@chpatrick chpatrick force-pushed the chpatrick:infinite-width branch from a99f50e to d81e37f Sep 13, 2018

@chpatrick chpatrick force-pushed the chpatrick:infinite-width branch from d81e37f to 9819ecb Sep 13, 2018

@chpatrick

This comment has been minimized.

Copy link
Contributor Author

commented Sep 17, 2018

Done.

@snoyberg
Copy link
Owner

left a comment

Looks great, thank you!

@snoyberg snoyberg merged commit c16c516 into snoyberg:master Sep 17, 2018

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.