Suggesting new contents.lr file format

I think this can be implemented without a breaking change. Current format is always terminated with three dashes:

body: 

Multi-line
text content
---
title: single-line content
---
emptyAttr:
---
boolean1: yes
---

I do think this is a lot of boiler plate code espcially if most attributes are single-line. My suggestion would result it the following:

body:

Multi-line
text content
---
title: single-line content
emptyAttr:
boolean1: yes

There are three scenarios. If the line (after the colon) contains:

1. any non-whitespace → it is considered single-line and terminated by \n and/or \r
2. only whitespace and the following line is also whitespace → it is considered a multi-line attribute and terminated by ---
3. only whitespace and the following line is not whitespace → the attribute is considered empty

This parsing is almost completely compatible with the current file format. In the 1. and 3. case, after a single-line attribute we simply ignore the three dashes in the following line. Case 2 hasn’t changed and is processed till the three dashes. So we could use the same parser for both, v1 and v2 content format.

However, there is one case where it might indeed break. I havent tested these, but I think they are perfectly valid as of now:

tag1: multi-line
starting after tag
---
tag2: 
multi-line
starting in the following line
---

So, in case someone has edited the content file manually and removed the double newline it would break parser v2. Luckily the UI produces the double newline already, so for almost all projects this should be fine.

We could even recover from a parsing error. In this scenario the parser would assume a new attribute on the 2nd line. If we don’t detect an attribute name (v2) or --- (v1) in the next line, then there must be something wrong with the format. So we show the faulty file to the user.

Of course there are edge cases that won’t be detected, like:

blogTitle:
Wednesday: Workshop
---

(the parser would assume Wednesday is an attribute and won’t complain)

[davidism]

Counterpoint to yours: I find the current format easy to read/parse with human eyes. Every field is guaranteed to be separated by --- and be a simple key: value. It requires zero extra parsing, as a human or with Lektor.

That said, there’s an issue opened about allowing a project to use a different parser: #751. If that gets through you could write a lektor-non-separated-config package to provide a different parser.

[relikd]

Reading through #541 and the suggestion of including files, we could even enforce single-line attributes. Each attribute that is multi-line (html, markdown, text) will automatically be outsourced into its counterpart file. Without the need of escaping --- on user input. The parser would be even simpler than it is now. One line, one attribute, split by the first colon.

As for the outsourced file, it does not need to be named anywhere. The name could be inferred by the attribute key and model description, e.g., body.md. Enabling syntax highlighting and what not. For flows they could be enumerated, flow-type.1.body.md, etc.

Thats of course only possible with a breaking change, or with the minimum required version as suggested.