-
Notifications
You must be signed in to change notification settings - Fork 78
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
Conversation
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. |
Maybe it could be an option like in libyaml?
…On Sun, Sep 9, 2018, 07:20 Michael Snoyman ***@***.***> wrote:
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.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#153 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAy0z-oK1ucX3Ya1g0tXTRnpx8YJiFjDks5uZKUOgaJpZM4Wc9s5>
.
|
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. |
OK, I'll give it a shot.
…On Sun, Sep 9, 2018, 11:47 Michael Snoyman ***@***.***> wrote:
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 <#152>.
encodeWith and encodeFileWith seem like reasonable names. You interested
in working on such a PR?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#153 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAy0z-1ycjOxFqQxqTmrmaEibjNXp-N2ks5uZOO7gaJpZM4Wc9s5>
.
|
I've added |
src/Data/Yaml.hs
Outdated
@@ -66,6 +68,10 @@ module Data.Yaml | |||
-- * Classes | |||
, ToJSON (..) | |||
, FromJSON (..) | |||
-- * Custom encoding | |||
, isSpecialString | |||
, EncodeOptions(..) |
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.
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
src/Data/Yaml.hs
Outdated
import qualified Text.Libyaml as Y | ||
|
||
data EncodeOptions = EncodeOptions | ||
{ encodeOptionsStringStyle :: Text -> ( Tag, Style ) |
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.
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.
Maybe, but it seems like everyone wants to use the |
580a489
to
a99f50e
Compare
Please take another look. |
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.
Looks good, just a few more minor comments.
a99f50e
to
d81e37f
Compare
d81e37f
to
9819ecb
Compare
Done. |
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.
Looks great, thank you!
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?