New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not yaml problems: spacing and scrolling #6

mk-pmb opened this Issue Jun 22, 2018 · 4 comments


None yet
3 participants
Copy link

mk-pmb commented Jun 22, 2018


about :

I agree that yaml doesn't help you much with the problems of large structures in documents, and it's unfortunate that there are so many specs that require using large documents with too few considerations of modularity. The modularity part seems to be one aspect in which yaml can actually help a bit, trading screen space for the effort of remembering anchor names.

However, I'd rather consider display problems a concern that should be addressed by an editor. If I understand your argument for tabs correctly, it boils down to: "My editor can configure how wide tabs are displayed, but not how wide spaces at start of line are displayed, thus the document should be adapted to fit my editor's feature set." I know, it's really hard to find the perfect editor, unless you code your own. ;-) Same for a missing (or lazily implemented) fold and/or "split horizontally" feature that lets you divide the scrollbar into an arbitrary number of document parts, so you can keep table headers (or container names and their indentation) at a fixed position while scrolling the below part of the document.

How far will my suggestion "your editor should do that" dissuade you from considering those a YAML problem?


This comment has been minimized.

Copy link

earonesty commented Jul 2, 2018

Saying "it should be the editor" is a common excuse for python and YAML syntax. I'll buy it for python ... but realistically, if I'm trying to configure something on a router via serial port... i may not always have the choice of editors. With config files, this is more often the case than not. Maybe not in your world... but in mine... I loathe "space sensitive" formats.


This comment has been minimized.

Copy link

mk-pmb commented Jul 3, 2018

I'm not sure I fully understand the "serial port" problem. I guess you mean you're limited to terminal access to a device where you can neither install a good editor, nor easily access the files with a remote editor via a network filesystem like sshfs? That's a quite special case, so I'd suggest to express the limitations more clearly, e.g.

"Lots of editors aren't really good for (large) YAML, so YAML shouldn't be used in environments where your choice of editor is very limited."

I'd totally agree with that, as it avoids conflating some device's specific problems with claims about YAML in general.


This comment has been minimized.

Copy link

Carpetsmoker commented Jul 9, 2018

I understand your point @mk-pmb, and I agree it does have some merit. But on the other hand YAML is explicitly designed to be "easily readable by humans" (it is listed as the top goal in the spec), so it seems to me that if you need specific editor/IDE tools/plugins to effectively deal with YAML, then something – somewhere – is not quite optimal.


This comment has been minimized.

Copy link

mk-pmb commented Jul 12, 2018

I think solving the context visibility problem for large bodies of information is outside of the scope of a language, and thus doesn't interfere with the goal of being easily readable. Consider a simple english translation of the bible. It's (hopefully) easy to understand each sentence, and its relation to the other sentences around it.
Even so, to explain the relation of some verse to another verse in another book, the authors would probably add a footnote rather than trying to implement it in the grammar of the language. I can't imagine even remotely how the latter option could be attempted at all.
More closely related would be the navigation problem: To which chapter of which book does this paragraph belong? Last time I read an offline book of those proportions, it had the chapter names on the top of the left page and the subchapter name on the top of the right page, and that hypothetical simple english bible would probably use a similar design rather than trying to incorporate navigation into the language.

On the other hand, we could interpret that page design as part of the representation "simple english with chapter names above each page". Obviously the format of "a book written in simple english" left the designers enough freedom to duplicate the navigation information in a place where it's clearly distiguishable from the core data.

In that light, YAML is more helpful than some other data formats. It supports out-of-band information for human readers in form of comments – a clear advantage (in our scenario) over some other languages. (The sad story of JSON comes to mind.)
YAML goes even further and provides anchors, so instead of just annotating parts of data, you can even present sections of data in an order that is easier to understand for a human, and at the same time guide a program to read them in another order that makes more sense for a machine. This shares some similarity with footnotes, although way more powerful.
Both measures are opt-in, but at least they're supported.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment