YAML (*.yml or *.yaml) extension support

[am11]

YAML, recursive acronym for "YAML Ain't Markup Language" has a VS support via http://yaml.codeplex.com/, which is old and outdated.

It would be wonderful, if we have .yml (in addition to the depreciated *.yaml) extension support in VS via WE (or Side waffle?).

One of the advantages of YAML is that it organizes the way of building multi-lingual websites (like resource files in .NET). For example in Ruby on Rails we can create en.yml and fr.yml and put the corresponding key value pairs in both files for the text content embedded in layout and template pages.

en.yml

en:
    navigation:
        language-switch: "French"
        sign-in: "Sign In"
        tools: "Assess Your Health"

fr.yml

fr:
    navigation:
        language-switch: "English"
        sign-in: "Connexion"
        tools: "Évaluer votre santé"

And then we call it in template like:

<a href="/sign-in"><%=t "navigation.sign-in" %></a>

where t() is a translation function in Rails, which takes string as param, automatically search for the key in language file (based on the current locale) and returns corresponding value. Note in this example, we don't need to mention the YAML file name when calling the function. The translation class expects a predefined file name format en-us.yml or en.yml and then devise the values from it.

We can also populate the arrays and lists. For an instance:

In .NET we may populate List<String> from yml file. From the above example navigation key will populate "French", "Sign In" and "Assess your health" in a list.

Similarly, List<Tuple<String, String>> or List<KeyValuePair<String, String>> can be created for easy accessibility. To illustrate, the FillList() function of our (PropertyList class](https://github.com/madskristensen/CssSorter/blob/master/CssSorter/PropertyList.cs) would look like:

private static void FillList()
{
    try {
         // suppose CssProperties.yml has name of 
        Properties = Yaml.Load("CssProperties", "Properties.Names", typeof(String)).Split();
    }
    catch (SomeYamlException yamlException)
    {

    }
}

and in CssProperties.yml:

Properties:
    Names: "position top right bottom left z-index display" // so on..

..perhaps not a very convincing example, but it would definitely a welcoming feature by many folks out there. :-)

[SLaks]

You're asking for a number of discrete features.

Web Essentials could offer a YAML language service to provide syntax highlighting and error checking when editing YAML text files. (this is something I've thought about writing)
This would be especially useful for Jekyll projects; the HTMLX editor could have a new LanguageBlockHandler for front-matter sections. (@madskristensen, can you make the editor allow new LBHs via MEF imports?)

SideWaffle could offer a YAML template for creating new YAML files. This would is possible right now; you can submit a pull request with a template containing a sample YAML file.

Finally, you can get a C# YAML parsing library from NuGet right now; see https://www.nuget.org/packages/YamlDotNet.Core

[madskristensen]

So what should be implemented in WE for this to work? Currently, all unknown files (.yml etc.) will just open up in the best suited editor. In the YAML case it would be the plain text editor. So basic support is there. Are you talking about having syntax highlighting inside a YAML file?

[am11]

@madskrstensen, yes syntax highlighting (like comments starts with # and there is no concept of multi-line comments) and 2-space indentation awareness. Also, would it possible that pressing Shift + Enter increment the indentation by two spaces in next line, Ctrl + Enter decrease the indentation level and Enter retain the current indentation?

[SLaks]

Ctrl + Enter is already bound to Insert line above.

[am11]

@SLaks, thanks for all the insights. If we have syntax highlighting for YAML implemented via WE, does it mean it will comply with all its official specs?

OAN, I I was following your super markup branch. Is it close to get stable/mature enough to incorporate in Mad's master? The reason I am asking, currently you have incorporated couple of languages. I was wondering in future if someone want to extend language support, such as VB, Ruby, Python and the other languages sharing (somewhat) same syntax family, would the implementation be possible via syntax family interface? Or is there a condition that VS must be aware of that particular language syntax for intellisense?

[am11]

@SLaks. can we override Ctrl + Enter behavior for particular file type?

[SLaks]

That depends how well we write our syntax highlighting. It looks like YamlDotNet.Core has a syntax tree, which would help.

My Markdown branch is not yet stable. It has problems with destructive artifact changes & inline block highlighting, and it doesn't work properly with languages that the HTMLX editor does not already embed.

Visual Studio implements language services using ContentTypes (see here); my markdown service would automatically use any ContentType registered with the editor. You can create your own ContentTypes and write classifiers for them.

[SLaks]

Maybe, but that would be a very bad idea. Shortcut keys should be consistent across editors.

[am11]

@SLaks, agreed. How about Alt + Enter for decreasing indentation, Shift + Enter for increasing and Enter for no change?

[SLaks]

That would work. (Note that Alt + Shift + Enter is Full Screen)

[TedDriggs]

For the specific multilingual scenario, there are already RESW files, which can be used in ASP.NET MVC projects exactly like you defined for the YAML files up above. I agree with @SLaks about the importance of consistent shortcut keys across editors, and I'm not sure that these are widespread enough requirements to take up so many modifiers on the Enter key.

[madskristensen]

So is the feature request to colorize comments and enable the comment/uncomment commands?

[SLaks]

Note that there already is a classifier. https://github.com/aaubry/YamlDotNet/blob/master/YamlDotNetEditor/YamlDotNetEditor.cs

Error checking would also be nice.

[madskristensen]

Cool. It makes more sense to support the YamlDotNet project than to write our own for this