-
Notifications
You must be signed in to change notification settings - Fork 50
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
flow mapping enhancement, omitting the currently required space after colon #267
Comments
It might be uncommon, but having a mapping with urls as keys might be a use case, e.g. I believe your suggested change is very parser-unfriendly, and I personally don't want to implement it. The parser has to go back and reparse the whole string. edit: What about |
Maybe (but I'm probably not aware of further consequences), it would help to parse like this?
Trying with https://codebeautify.org/yaml-parser-online gives me: |
@UnePierre |
@UnePierre what does your suggestion have to do with @revintec 's suggestion? |
"Invalid" is also fine and understandable. If one-liners are necessary, flow-style with curly brackets can be used. (I sent a suggestion for improvement to codebeautifier.org linking back here.) |
If you think, investigating the other possible cases isn't worth: never mind. |
I sometimes want very compact lines, without any blank/space, because blank/space mess with line wrap and/or have special treatment in shells and may not be that noticeable(from screenshot or whatever, we can't see if there is a blank/space or not). I use them like this parama: xxx
paramb: yyy
defaults:
- {a:b,c:d}
- {e:f,g:h}
- ... I've written some parser/laxer before, it should be parser friendly/fairly easy to implement, just parse differently in FLOW_KEY context should be fine. I've done a POC here(manually tested, not sure it's fully spec compliant reference implementation as mentioned here(https://yaml.org#JavaScript
|
Please don't post screenshots of text. You wrote:
so I thought you were explicitly talking about the case when there is an empty value. But your suggestion is to not require a space after a colon in flow mappings in general. Of course this is not complicated. No proof needed. You mentioned a use case for it. I mentioned a use case for colons in the keys. You have a use case, I have a use case. Currently you have to add a space after the colon. With your suggestion, keys with colons would need quotes. |
Currently |
No, I just don't get how your suggestion does have anything to do with @revintec 's suggestion, like I said. |
sorry if there is any misunderstanding I think you're right mentioning that
I think removing the requirement of having a blank/space after the colon would make the language more compact and easier to use, I could be wrong |
The original intent was to make the key value separator always be JSON allows for 12 of 15 parsers get these exactly right. There are many YAML syntax issues we are looking to address in YAML 1.3 but this (colon+ws) is pretty solid. |
currently
{a:b}
parses to{"a:b":null}
this
key -> null
mapping should be an uncommon caseinstead I propose pasring
{a:b}
to{"a":"b"}
from here https://yaml.org/spec/1.2.2/#742-flow-mappings it states that
I think
a:b
should still parse to"a:b"
, but{a:b}
should have no ambiguity here, to{"a":"b"}
also,
{a:b:c}
should be parsed to{"a":"b:c"}
instead of{"a:b":"c"}
(may be only apply this inside
FLOW-KEY
context?The text was updated successfully, but these errors were encountered: