Feature request - Get JSONPath based on cursor location in text mode

[laurensV]

Would love to have the ability to get the current JSONPath based on the cursor location in text mode, but I don't think with the current features/events this is possible at the moment. Is this something that can be achieved or is this too hard in text mode?

[josdejong]

That would be very nice indeed, thanks for sharing your idea.

I'm not sure how complex this will be to implement, we probably need a JSON parser which can translate the current caret position into the nested path of the JSON document (and the other way around).

Anyone interested in figuring this out? Help would be welcome.

[AlexRMU]

You can use a json parser that will create an ast, then walk the ast and find the last node whose location contains the cursor location, then get the node path.
https://github.com/mischnic/json-sourcemap
https://github.com/MrVauxs/json-source-map
https://github.com/JohannesOehm/json-parse-ast
https://github.com/vtrushin/json-to-ast
https://github.com/KnisterPeter/jsonast
https://github.com/rse/json-asty

[AlexRMU]

The text may contain an error that prevents you from getting the path.

You can't get the cursor location right now.

[AlexRMU]

This editor focuses on editing json as structured data rather than text - it's easier and more efficient. Formatting is not saved, there is not much functionality related to the text, the ast is not created or used, etc. Consider that a text mode is just an utility, it cannot be greatly improved without compromising other modes.

[josdejong]

Thinking about it, the editor already uses json-source-map to figure point to parse errors and validation warnings, so that can be of use.

This editor focuses on editing json as structured data rather than text - it's easier and more efficient. Formatting is not saved, there is not much functionality related to the text, the ast is not created or used, etc. Consider that a text mode is just an utility, it cannot be greatly improved without compromising other modes.

That's simply not true. Formatting is saved, and text mode definitely is not just a utility. There already is an AST used like I explain above. What feature do you have in mind that would "compromise other modes" to implement or improve? Can you be concrete?

[AlexRMU]

Formatting is not saved - I mean, if you change the formatting in text mode (add spaces) and then change it in another mode, then this formatting will not be saved (spaces will disappear) because the json value is saved, not the ast of the text.

[AlexRMU]

I imagine it like this:

• text editor
  • changes in the form of text patches
  • stores only the source text
• structured data editor
  • changes in the form of json patches
  • stores the json value and possibly the source text
  • does not work with invalid json
• mixed editor
  • there is a text mode and a tree mode
  • changes in the form of text patches or json patches
  • stores the source text, json value and the ast (theoretically, you can do with one ast, because you can get both the value and the source text from it)
  • due to ast, there is a fix and json5

The mixed editor is more complex and requires more resources to work with, but it has more functionality.
As I understand it, you want to make a mixed editor.
However, let's say someone wants to use only the tree mode. He doesn't need a text editor, ast, etc., but he won't be able to completely disable everything unnecessary. He will have to accept it, compromise.

[josdejong]

Formatting is not saved - I mean, if you change the formatting in text mode (add spaces) and then change it in another mode, then this formatting will not be saved (spaces will disappear) because the json value is saved, not the ast of the text.

Ah, yes, that is true. The formatting will also be changed in text mode as soon as you apply an action like sorting or transforming.

You're right that working from an AST would allow for more features like supporting JSON dialects such as json5 (with comments and stuff). The focus of svelte-jsoneditor however is on JSON data and not on configuration. It focuses on operating on your
JSON data, like sorting and transforming it. Maintaining the exact whitespacing is not that important when working on data, except to have it formatted in a readable way. When working on a configuration file on the other hand, maintaining the formatting is very important. But that is not the focus of the editor.

Making all operations working from an AST that maintains all text formatting would be complex indeed. It would make the performance worse, and you would be limited to smaller JSON documents to prevent the AST from running out of memory. It would be nice, but I think the downsides are not worth it: svelte-jsoneditor aims to be fast and support large documents. Also, I think people are just fine with the data being reformatted after a sorting or transforming or opening the data in tree mode: in the past 14 years, nobody has asked about this yet, you're the first :).

However, let's say someone wants to use only the tree mode. He doesn't need a text editor, ast, etc., but he won't be able to completely disable everything unnecessary. He will have to accept it, compromise.

That is correct, in svelte-jsoneditor it is not possible to only use tree mode. You always need an escape to display JSON as text, to handle input containing invalid JSON. That can happen for example when pasting something in tree mode. So, the editor is indeed an "mixed editor", though the details slightly differ from your your listing (like how/where an AST is used).

[josdejong]

I've made a start with this in #521