Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add option to configure path seperator #69

Closed
Grisgram opened this issue Jun 15, 2024 · 7 comments
Closed

Add option to configure path seperator #69

Grisgram opened this issue Jun 15, 2024 · 7 comments
Labels
enhancement New feature or request probably fixed? the issue/feature appears to be fixed/implemented, but there still may be issues

Comments

@Grisgram
Copy link

Hi,

I know, it is pretty standard to use the . as seperator for json paths (like strings.legal.copyright), however I also have systems which would prefer a / as path seperator, like strings/legal/copyright.

Could you add an option to set a character as the path seperator? Leave it as . as default, so nothing changes for the current default behavior

Thanks!

@molsonkiko
Copy link
Owner

What is the context in which you would prefer / as path separator? I may or may not be able to help you.

If you are referring to the query box (for example, using @.foo.bar to select the bar field of the foo field of the current JSON), that is completely impossible, as . is hardcoded for that purpose in the RemesPath syntax.

If you are asking for a fourth option for the Path to current position command, with a configurable path separator defined in the settings, I would be willing to implement that.

@Grisgram
Copy link
Author

Grisgram commented Jun 15, 2024

I have a tool that accesses these json files at runtime and this tool expects a slash-seperated path to finally find a value in the struct.
So, no, not the query-box.
Just what you put into the clipboard with the "path to clipboard" or the path to current option, that you mentioned (or both).

I just right-click a node
image

and then you generate something like "strings.legal.copyright" but for this tool i'd need "strings/legal/copyright" (either use the configurable seperator in the javascript style or add a menu option "custom style" which refers to the seperator set in the settings. either way is ok.
I am working with quite large files and a deep structure -- it's a bit awkward to always manually replace all dots with slashes after pasting the path into my source code.
The reason why i can not use the dot is, that these json files already use the dot in their keys
image
like this.
And they get generated by another system which I have no control over.

I hope I could explain :-)
Cheers!

@molsonkiko
Copy link
Owner

@Grisgram

Sorry I didn't work on your issue for a while; I'm still game to work on it if you're still interested.

The main reason I've been anxious about working on your issue is the question of what to do with array indices and keys that contain the separator. This is only a reasonable thing to add to my plugin if I can come up with a simple general-purpose algorithm; it is not really reasonable for me to fill JsonTools with reverse-engineered application logic from any other arbitrary software that some user happens to use.

What I was currently thinking was this:

if the key is an array index:
    format it as plaintext
if the key contains the separator OR a literal " character:
    format it as a JSON string (for example, "fo/o\"" would be formatted as "fo/o\"" if / was the separator)
else if the key is the string representation of an integer (like "1" or "503"):
    enclose it in quotes
else:
    format it as plaintext

So the path (key "fo/o", index 1, key "bar", key "2", key "ba"z") would be formatted as "fo/o"/1/bar/"2"/"ba\"z"

Would that implementation work?

@Grisgram
Copy link
Author

Hmmm, I am not sure, if you are thinking too complicated for all that matter ... why don't you have a problem with a dot, because that is way more a parsing problem when you create a path like "path.to.my.key". why is there no problem in "way.to.502.33" - this is way more difficult as it could be 502 and 33 or a float 502.33.

I still think, you did not understand really what my request is, i try again with a simple structure

{
  "hello" : "world",
  "hey" : {
    "dude": 42
  }
}

currently, if i click on "dude" and get the path, you generate "hey.dude". All I want is, that you generate "hey/dude".
Just replace the "." with a "/"
not more, not less, generate as you always did, just use a "/" (or the configurable character from the settings, if i want, a *, so you generate "hey*dude"

I do not really understand that complicated parsing, string-representation construct you showed me up there.
There is a point in your code where you add the "." ... Just replace this dot with a character from the config.

I hope, this explanation is easier to understand

thanks!
cheers :-)

@molsonkiko
Copy link
Owner

molsonkiko commented Jul 16, 2024

You're welcome to test out my most recent commit, which I believe addresses your issue. Follow the instructions here to download the GH artifact for the commit.

You can also read the documentation for the new path_separator setting here.

@molsonkiko molsonkiko added enhancement New feature or request probably fixed? the issue/feature appears to be fixed/implemented, but there still may be issues labels Jul 16, 2024
@Grisgram
Copy link
Author

You do a very good job here - well documented!
Thank you for your efforts!

@molsonkiko
Copy link
Owner

You do a very good job here - well documented!
Thank you for your efforts!

You're welcome! If you ever see an opportunity to improve the documentation, feel free to create an issue.

The fix to this issue is now in v8.1, which I will try to get listed in the Notepad++ Plugin List ASAP.

Once the next version of Notepad++ is released that lists that version of JsonTools, I will wait a little while and then close this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request probably fixed? the issue/feature appears to be fixed/implemented, but there still may be issues
Projects
None yet
Development

No branches or pull requests

2 participants