Sublime Forum

Bug in yaml syntax highlighting

#1

Hi,

If I type a simple YAML file such as:

x: 10
y: 20
z: 30

the “y” appears in bright red italics, because ‘Yes’ and ‘No’ are typed that way when they are dictionary values. However, here the ‘y’ appears as a key, and it doesn’t make sense to treat it the same way as when it’s a value.

I’m assuming this could be quickly fixed by editing the file responsible for YAML syntax highlighting. Which/where would that be?

0 Likes
#2

You should open up an issue here.

0 Likes
#3

you can use https://packagecontrol.io/packages/PackageResourceViewer to edit your local copy of the YAML.sublime-syntax file

0 Likes
#4

Not sure what it means, but there is even a test case in the YAML package to ensure all kinds of data types such as y: are matched as boolean. The test case uses true: false to test whether both are matched as boolean.

Looks like it happens by design but not by accident.

0 Likes
#5

Thanks. In the end the .sublime-syntax file was too complicated for me to figure out, but I could at least remove ‘y’ from the list of ‘boolean identifiers’, to remove the annoying behavior in this particular case.

0 Likes
#6

YAML dictionary keys don’t have to be strings I guess, so the behavior is indeed correct - quote them if you want them highlighted as strings :wink:

0 Likes
#7

Look for the following variable somewhere at line 162 and append the (?!\s*:). That’s it.

  _type_all: |-
    (?x:
        ({{_type_null}})
      | ({{_type_bool}})
      | ({{_type_int}})
      | ({{_type_float}})
      | ({{_type_timestamp}})
      | ({{_type_value}})
      | ({{_type_merge}})
     )
     (?!\s*:)   ; added to avoid y to be scoped as type if used as key.
0 Likes
#8

Might be true, but indeed looks odd to have boolean scoped keys.

0 Likes
#9

@deathaxe: I did what you said, but it seems to kill syntax highlighting in the values as well as keys…

@kingkeith: Yes but:

Update: After a bit of experimentation, I find that the keys ‘y’ are ‘Y’ not interpreted as booleans by the python yaml loader (PyYaml), whereas ‘Yes’, ‘yes’, ‘True’, ‘true’, ‘On’ and ‘on’ are interpreted as booleans. So a YAML file like:

True: If you say so
Yes: on Wednesdays
On: on Thursdays

will come out as a 1-entry dictionary, when parsed! ({ True: 'On Thursdays' })

Anyway, this PyYaml behavior at least somewhat justifies my hack of removing ‘y’ from the list of official boolean values… (but I wonder what the official docs say).

0 Likes
#10

YAML spec explicitly includes y and n (http://yaml.org/type/bool.html)

Which values does it break:

Works for

0 Likes
#11

For me, loading the original example that I gave using PyYaml gives the dictionary {'x': 10, 'y':20, 'z':30 }, with y treated the same as x, z. It doesn’t for you? :fearful:

0 Likes
#12

Pyyaml doesn’t strictly follow the 1.1 spec. In 1.2, the boolean aliases were removed but many implementations still only use the 1.1 spec.

As mentioned, according to the spec keys are interpreted the same as values, including implicit type resolving. If you want a string key, quote it or prepend it with !str (though that would still apply the constant highlighting).

Ideally everything would be using the 1.2 spec and I didn’t need to include the aliases, but unfortunately that’s not the case and I’d rather follow the spec than a single implementation.

1 Like
#13

The YAML syntax is an awesome peace of code. Incredibly shows how a syntax definition can be built using official specs with a clear structure.

1 Like