@turbotimon Try to stay below the 80 character limit CONTRIBUTING.markdown recommends. One reason for this is to ease reading git's diff views. Either set up your text editor to display an indicator, request automatic hard line breaks, or fold the file.

For the former and presuming Windows as operating system available to you, Notepad++ allows you to set one or multiple vertical marks. Go Settings -> Preferences -> Margins/Border/Edge -> Vertical edge settings (centre of the widget). In case you have access to vim (an editor more prominent in Unix/Linux, but cross-platform (e.g., gvim) add set colorcolumn=80 to your .vimrc configuration file to the same effect.

A Linux shell (e.g., the Git Bash by tortoise git in Windows) can equally help you to provide the edit post factum:

• run fold -s input.file > temp to break lines longer than 80 characters. Instead of a cutting words which pass across this threshold, the optional -s identifies the latest white space prior to this limit to do so.
• next, run sed 's/ \+$//' temp > out to write an out file without trailing white spaces the first step usually creates. If it passes the visual check, it can overwrite your submission.

A single blank line (after the first bullet list, line 16) is enough, too.

@nbehrnd Sorry, I somewhat assumed that's only for code section in the markdown and my reference was json.html.markdown where the lines are also longer.

Already fixed it and hope its ok now, everything else let me know! (Line 75 is still 1 char longer than 80, but can't fix that)

@turbotimon It is true, the 80 characters limit is somewhat arbitrary, but to help the layout once the markdown files are rendered, too. To prevent the need to scroll horizontally (e.g., current day's rendering about ReST). For milder cases (like here), by the browser's set up to use locally installed fonts / to optionally overrule the suggestions sent by a web site, a single character needn't be the camel's straw. It depends. The hint to markdownlint is an indicator that there tools around to help.

Speaking of such, lines 29, 47, 62, 83 appear like sub sections instead of being such (i.e., first defined by function, and their appearance a consequence). A leading ## as header of level 2 instead of enclosing them by ** (similar to the file about markdown itself, source, rendering) might match your intent.*

Regarding the contents: to me, the submission is a useful read more likely to fit into "Data Structures", than "Languages". I welcome it equally notes briefly tab separated files used for instance in the "chemistry spreadsheets" of e.g., Datawarrior.

* Though there are a few different approaches to GitHub's Markdown, I keep a copy of Kofler's reference about Pandoc's flavor. But there are so many markdown implementations around.

Hi @nbehrnd

Sorry for the silence, had a lot other things going on.

... lines 29, 47, 62, 83 appear like sub sections

Agree, I changed that

.. more likely to fit into "Data Structures"

Agree, that language is maybe not the best fit, not sure if Data Structure is, but i changed it. IMAHO it would fit more into a new section "File format" and/or "Data exchange format" (which would also fit better json, yaml and so on.).

to me, the submission is a useful read

Thanks. I really like this site and I use it whenever I can. My main motivation for adding this is, that I also teach and often link to this page for a short and concise explanation of data exchange formats like json, yaml and csv. But I always missed the last one:)

@turbotimon To me, content and format look good.

@verhovsky, @vendethiel Frequently, I saw you to triage and merge PRs to the project. May you have a look on this one, please? Can you comment on @turbotimon's idea to file this contribution (altogether with the markdown files about json and yaml) into a new section "file format" or "data exchange format"?