Definitely looks like the right token for multiline strings!

One thing I'm catching on is that it seems like a really strange mistake for @jneen to have made. I checked the git blame and the rule was apparently added with the original commit:

It's possible that it was an oversight and yet—I don't know—it's difficult to imagine an oversight like that happening completely unintentionally.

Based on the location of the rule, I wonder if it was meant to be a catch-all for some other type of value and is sort of unintentionally capturing multiline strings. @ashmaroli Can you think of any values for which Name::Constant would be the correct token here and that would have the wrong token if it's changed to Str?

Can you think of any values for which Name::Constant would be the correct token here

I think object tags and booleans would be best suited for this name. However, I think there are more bugs in this lexer. For example, unclosed single quote has no effect and num literals are highlighted as strings..etc.:

bool_true: true
true: "true"
bool_false: false
false: 'false'
number: 123456
str_number: '123456'
email_regex: !ruby/regexp '/^([\w.%+-]+)@([\w-]+\.)+([\w]{2,})$/i'

@ashmaroli I guess what I was getting at with my question was more whether the change in this PR would affect the existing behaviour of the lexer. It sounds like:

1. it does by causing certain values that were being tokenised as Constants to be tokenised as Strings; but
2. these instances were all errors because they weren't actually strings (such as the number literals).

Does this mean that in the same way that you fixed the number literals in #1239, we should have separate PRs to address the other bugs?

This PR does affect existing behavior. Like you've mentioned, tokens incorrectly rendered as Constants will now be Strings. To my knowledge, YAML doesn't have constants per se. Just tags.

From the visual test, all tags, booleans and null are highlighted properly. Therefore IMO, we should just wait for our users to report anything amiss once this gets shipped.

@ashmaroli Yeah, doesn't look like Constant is one of YAML's types so I'm guessing it was just an unintentional mistake. I'll merge this in.