Multiline String Coloring

[benhamill]

It looks like strings are handled differently depending on whether they're quoted, vs literal, folded or unquoted. For example:

description: |
  foo
description: >
  foo
description: foo
description: "foo"
description: 'foo'

In this, the values in the last two keys will be one color and the values of the first 3 keys will be another.

I'm not sure what you can do about that middle (unquoted) one without targeting the description key specifically, but I think you can safely treat the | and > glyphs as introducing a string and bailing on other highlighting rules until indentation changes (or lessens? Not sure).

[benhamill]

Come to think of it, this might be the root cause of #3 (which I just created). As well as a few other oddities I spotted (like "on" being highlighted and colons playing weird in literal string descriptions).

[IN3D]

This one I'm not sure about, is this how RAML treats strings? I thought it was treated the same way that YAML treats strings. Are you aware of a part of the RAML spec that says different? I'm not aware of one, but it's very willing to admit I'm missing something.

[benhamill]

My understanding of the YAML spec is that literal and folded strings should be treated like double-quoted strings (except in how the hard newlines and leading whitespace are handled). However, I think this might be a problem with the default YAML highlighting that ships with vim? Have a look:

That's just a random YAML file that happens to have a really long literal string in it with colons and numbers and quotes. All the highlighting is wrong. If it's all white or all a color doesn't really matter to me, but having numbers and things that look like keys pop out is weird.

I noticed this in RAML files because the descriptions can often be kind of lengthy and are meant to contain Markdown.

Do you think this is the kind of thing to push upstream, somehow? And if so, where to? (I'm using neovim and maybe that means it needs to be pushed upstream to both places?) I guess possibly the first thing to try it just figuring out how to fix it as a new syntax file and then figure out how to get it into... whatever? I don't know. I haven't interacted much with vim or neovim mainline as projects at all.

[IN3D]

Your example makes a lot of sense, it's very hard to tell that's all supposed to be one block of text. In fact, I actually didn't realize it was in your example until I looked harder at it!

I know I describe this as a super-set of yaml, but the syntax file itself is actually a very trimmed down version of vim's own built in yaml syntax file I made; so an upstream fix wouldn't directly effect it.

That said, you example makes it clear this is very annoying, and can lead to some serious misreading. However, I'm not very sure how to handle it.

The first thought that pops in my head is it would be some sort of region based on indentation, but I imagine that it's a bit more complicated if the vim project itself hasn't implemented something. That's not to say it's not worth trying though.

[benhamill]

Yeah. Region sounds about right. You'd key on the leading > or | and then have expectations about the indentation level. I've never been able to get indentation-based stuff to work out in syntax stuff in vim (I have only tried once or twice)... and if the indentations increases, it's still part of the string. It's only when it decreases past the initial level.

I think this is the relevant YAML stuff: http://www.yaml.org/spec/1.2/spec.html#id2760844

I'll play with things and read docs and see if I can get it working at least a little.

[benhamill]

This plugin seems related, too... But it just seems to highlight the | or >, not make vim more aware of the bodies of the "block scalars" (I guess that's the technical term).

[benhamill]

So I opened my YAML file, but truncated off the file extension, so it didn't trigger the file type detection and started playing around with the :syntax command. Here's what hit the right spots:

hi def link yamlScalar yamlString
syntax region yamlScalar start=/\%(^\z(\s*\).*: >\)\@<=$/ end=/^\z1\S/me=e-1

So, the start pattern has a positive lookbehind that matched from start of line any amount of whitespace, then anything and a colon, space >. The whitespace is in an external grouping. Then it matches the end of the line.

The end pattern matches from start of line, the external grouping of whitespace from before and then a not-space character. Then the end of the match is moved back a character so that the first character in the next line, there, doesn't count as part of the region.

However, when I try to run this line inside the file with file type of YAML, it doesn't highlight anything. Still trying to sort out why, but I thought I'd drop the above in here in case it's useful.

Two known issues:

• It only supports > right now, but adding | support should be trivial.
• It won't work if it applies to a field that has the array marker (-) at the start. I figure we catch the simple case first and then we can figure that one out and any other edge cases.

[benhamill]

Also: I realize I'm working with YAML and that's slightly beside the scope of this repo, but I figure what works for YAML should also be able to work for RAML, right?

[benhamill]

Oh. Looks like the failure in a ft=yaml file was because of the plugin I linked before. Some kind of conflict with the yamlBlockScalarHeader from https://github.com/mrk21/yaml-vim/blob/master/after/syntax/yaml.vim.

I think that means that you could adapt the above into RAML pretty easily. Possibly also gate it to use Markdown highlighting, but I'm not sure. LMK if you want me to mess around with that stuff. I'm going to go chase YAML-related shit for a while and will only report back to you on that if you're interested.