3 ms·

Yes, because it could be available while looking at your actual config file (JSON document), and showing you info specific to the element you're looking at, ins

Yes, because it could be available while looking at your actual config file (JSON document), and showing you info specific to the element you're looking at, instead of on a separate page and requiring searching for a relevant element. Why would this be any harder to describe complex JSON documents? Optional arguments don't need to be described if they're not in your specific file – not by something like this anyways. That's what the regular documentation is for, and this could easily link to it too. Mutually exclusive arguments can easily be linked-to, or, rather, if your file contains one of those arguments then the contextual info can link to any other mutually exclusive arguments. Why couldn't the context info state that valid values include either a string or an object (of some type and that type linked to in the context info)? I'm confused about your confusion! It seems like this is a really handy way to show documentation specific to a selected portion of a JSON object for a given format.

SamBam 10y ago
OP described the tool as this: "It's an editor for those JSON file formats which shows contextual help as you edit the files." Is that what it's supposed to be? Because what I was saying was lacking was any contextual help that tells you what you could add, vs what's already there. If I were shown http://package.json.is http://package.json.is as "contextual help" to help me author my package.json file, I would have no idea that I could add "author" or "contributor" fields. This only gives documentation for the stuff that is already there. You could add every property to the original document, but that fails if you have mutually-exclusive properties, because the original document would not be valid. You could try to add every possible property to the top-level comment, but then the top-level comment needs to be practically as long as the original documentation. Documentation that is incomplete, and doesn't seem to have a reasonable way to make it complete, doesn't seem useful to me -- and in many ways seems worse than not having it, because the incompletion means I would never even realize I was missing useful documentation. I'd have to have the real documentation open on another page anyway, to make sure I'm not missing stuff. But again, maybe I'm missing the use-case.

SamBam 10y ago

OP described the tool as this: "It's an editor for those JSON file formats which shows contextual help as you edit the files." Is that what it's supposed to be? Because what I was saying was lacking was any contextual help that tells you what you could add, vs what's already there. If I were shown http://package.json.is http://package.json.is as "contextual help" to help me author my package.json file, I would have no idea that I could add "author" or "contributor" fields. This only gives documentation for the stuff that is already there. You could add every property to the original document, but that fails if you have mutually-exclusive properties, because the original document would not be valid. You could try to add every possible property to the top-level comment, but then the top-level comment needs to be practically as long as the original documentation. Documentation that is incomplete, and doesn't seem to have a reasonable way to make it complete, doesn't seem useful to me -- and in many ways seems worse than not having it, because the incompletion means I would never even realize I was missing useful documentation. I'd have to have the real documentation open on another page anyway, to make sure I'm not missing stuff. But again, maybe I'm missing the use-case.