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.
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.
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 |
chpatrick
force-pushed
the
infinite-width
branch
from
580a489
to
a99f50e
Compare
|
Please take another look. |
chpatrick
force-pushed
the
infinite-width
branch
from
a99f50e
to
d81e37f
Compare
chpatrick
force-pushed
the
infinite-width
branch
from
d81e37f
to
9819ecb
Compare
|
Done. |
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?