Consider different approach to multiline strings?

Hi there! I’m a big fan of nested text, but as I went through the docs I was surprised with your choice for multiline strings:

address:
    > 138 Almond Street  
    > Topeka, Kansas 20697

Perhaps you’d consider an alternative way to specify this? I find needing to add the > character on every line isn’t ideal especially long pieces of text or for html templates, etc!

My guess is you can use your indention rules pretty well to find the end of the string without a character on each line. I immediately was hoping for this syntax:

address:
    138 Almond Street  
    Topeka, Kansas 20697

But I think this is also clear:

address: >
    138 Almond Street  
    Topeka, Kansas 20697

Or even this if you prefer it as the first character

address: 
    > 138 Almond Street  
    Topeka, Kansas 20697

To my surprise YAML also supports all of these directly. Here’s a playground to look (they have perhaps too many options) : https://yaml-multiline.info

Additionally, here’s a couple examples that would improve the nested text significantly with this as an option:

website:
    product page template: >
        <h4>Product Info: {{name}}</h4>
        <ul>
              <li>Product: {{name}}</li>
              <li>Color: {{color}}</li>
              <li>Price: ${{price}}</li>
        </ul>

In the current syntax it would have to be this, which is quite hard to type and pretty confusing!

website:
    product page template: 
        > <h4>Product Info: {{name}}</h4>
        > <ul>
        >      <li>Product: {{name}}</li>
        >      <li>Color: {{color}}</li>
        >      <li>Price: ${{price}}</li>
        > </ul>

The other situation is larger embedded text (readme, documentation), and again a character on each line would be very hard to read:

screenplay:
   name: Groundhog Day
   contents: >
      INT. BREAKFAST ROOM 
      
      Phil enters the old library of the house and finds everything
      exactly as it was the day before. Mrs. Lancaster spots Phil as
      she comes out of the kitchen with the fresh pot of coffee.
      
	      MRS. LANCASTER
	      Did you sleep well, Mr. Connors?
      
	      PHIL
	      (completely confused)
	      Did I? I don't know--
      
	      MRS. LANCASTER
	      Would you like some coffee?
      
	      PHIL
	      Yes, thank you. I ' m feeling a
	      little strange.
      
	      MRS. LANCASTER
	      (as she pours)
	      I wonder what the weather's going
	      to be like for all the festivities.
      
	      PHIL
	      Did you ever have deja vu, Mrs. Lancaster?
      

As for parsing, obviously it’s more tricky because multi-line strings could contain a colon. The key, I think, is either to require the > character at the start (easiest), or to look at the first line. If it doesn’t contain a colon or start with a - then it’s a multi-line, and subsequent lines with the same indention are appended.

Thanks for considering. Very cool project!

[KenKundert]

Sorry I did not mean to close the issue when you had more to say.

I agree with you that it would be better to not have the leading > symbols on multi-line strings. I personally thought long and hard on how to accomplish that. If fact I probably spent at least 6 years on and off thinking about how to create a format like NestedText. Every attempt I made hit a dead end until the current approach occurred to me. I do believe it is possible to create such a format, but I was never comfortable with the trade-offs.

Regardless, this ship has sailed. NestedText is not clean as I had hoped, but as it is it is a nice advance over JSON and YAML. It has been released and others are building new versions in other languages. This is not the time to make fundamental changes to the base format. Instead we continue to develop NestedText as it is, and if someone takes inspiration from it and develops a new format that improves on it, much the way I took inspiration from YAML and improved on it, then so much the better.

[LewisGaul]

Personally I completely agree with NestedText’s approach, where each line type is identifiable without surrounding context. This makes it easier for parser implementations, but also makes it easier to visually parse IMO.