@clean for "real" JSON files

[Félix]

Just small remarks for using "real" JSON with Leo:

Background:

Some applications have settings or data stored in "fake" json files, which support line-comments (with "//"). This is an addition to the json standard, for commodity. Its not part of the official JSON  standard.

More serious software handle only real json files, without possibility of comments. Clever webdevs have been using json entries with a "//"  as the key to comment parts of their json. But it can get ugly with decorators as no duplicates are allowed in non-array objects. etc.

User case: 

Big json files, like the one that manages almost all aspects of a vscode extension, would gain a lot by being viewed as a structure, because the files get very long. 

In fact its quite rare that xml or json files are so small that they fit in the screen and the structure is visually apparent at a glance. such as this: 

"container": {

    "child1":"content1",

    "child2": {

           "grandChild1": 1234,

           "grandChild2": 5678,

    }

}

Its more like files with thousands of lines, and so, bracket pair color match, and other little helpers do not suffice to understand the structure without long minutes of exploring the long linear scroll of indented text.

Solution

So here comes Leo: Structure the json like a boss in an @clean node, with clear and obvious sections, organized to illustrate meaning or intent.

And to top it off, @clean won't break the json with comment decorators! 

So, in conclusion, Leo's pretty cool. 

--

Félix

  

[Edward K. Ream]

Hehe. Well said.

Edward

[Edward K. Ream]

On Thursday, July 16, 2020 at 7:51:47 PM UTC-5, Félix wrote:

> Just small remarks for using "real" JSON with Leo:

When I awoke this morning I understood several aspects of Leo and json that I never appreciated before. Most of what I am about to say is implicit in Félix's remarks, but I didn't fully understand them until now:

1. json does not support comments, so Leo really can not properly embed Leo sentinels in .json files.

In other words, you can' reliably use @file on .json files.

2. You can use @clean on .json files without any problem!

The @clean update algorithm (The Mulder/Ream algorithm) uses "pseudo sentinels" internally. The specific comment delimiter used doesn't matter, because only the algorithm uses the sentinel.  The comment delim never appears "outside" the algorithm.

3. The @button mark-changed script won't work well with .json files. It can't detect nodes that are candidates for being split.

The script uses parse-body to mark nodes that are candidates for being split. Alas, parse-body uses the importer for the language that is in effect, but there is no .json importer, and never can be such a thing. Boo hoo.

Edward

[Edward K. Ream]

On Friday, July 17, 2020 at 7:01:34 AM UTC-5, Edward K. Ream wrote:

3. The @button mark-changed script won't work well with .json files. It can't detect nodes that are candidates for being split.

The script uses parse-body to mark nodes that are candidates for being split. Alas, parse-body uses the importer for the language that is in effect, but there is no .json importer, and never can be such a thing. Boo hoo.

The great thing about writing is that it exposes assumptions.  One can imagine a .json importer.

It's probably not a great idea to assume that // is a valid comment delim, but it could be done in a pinch. Happily, it might work to use a "hidden" .json importer for parse-body. That is, a public json importer looks like a dubious idea, but a private json importer might work as a "hidden helper" for parse-body.

I don't plan to work on such an importer at present, but I'll consider it if you, Félix, think it would be useful.

Edward

[Edward K. Ream]

On Friday, July 17, 2020 at 7:13:57 AM UTC-5, Edward K. Ream wrote:

> ...a public json importer looks like a dubious idea, but a private json importer might work as a "hidden helper" for parse-body.

Alas not.

json syntax suggests no natural way to divide json into nodes. Only the user can know what would be useful.  As a result, parse-body does not seem possible, even in principle, for .json files.

Edward

[Félix]

> Only the user can know what would be useful.

totally ok for such a filetype where its just 'data' storage and definitions... dont bother with that

[Edward K. Ream]

On Fri, Jul 17, 2020 at 10:09 AM Félix <felix...@gmail.com> wrote:

> Only the user can know what would be useful.

totally ok for such a filetype where its just 'data' storage and definitions... dont bother with that

Glad you agree.

Edward