Improve path matching

[Midblyte]

A few suggestions about the JSON syntax, to make the file path more dynamic.

• "Path" as a list of strings
  Sometimes, two (or more) equal entries were added when it was needed to match two (or more) different paths, even if the entries had the exactly same "help" and "movable" keys (e.g.: here the "help" key was repeated three times for .zhistory, .histfile and .zsh_history).
  This is a problem because it may be necessary to edit one message and at the same time forget to edit the others.
  Depending on the implementation, it could be necessary to edit every existing .json files to support the new syntax.

• "Path" as a regex
  Regex patterns allow to match even very different and complex strings.
  While I don't personally like the idea (slightly worse performance, uglier paths, more complexity, almost each .json should be fixed because the dot '.' is the match-all character while '\.' is the plain dot, increased risk of matching wrong files, etc...), maybe in certain cases it could be the most flexible way (think of optional alphanumerical suffixes; see following examples).

• "Path" including variables + fallback
  Currently, it is possible to use shell variables using the dollar sign followed by the variable name (e.g.: $USER).
  But this feature can be relied upon only for a very, very small subset of variables (e.g.: it's difficult to even get the hostname since $HOST is Zsh-specific, $HOSTNAME is Bash-specific, while shells like Dash don't even have it).
  A possible solution is to create a new key, for example "vars", like this:
  "vars": {"XDG_NINJA_HOSTNAME": ["HOSTNAME", "HOST"]}
  This is how it would work: it picks the first one if it exists, else the second, and so on. If none of them exist, the check on the path should be skipped completely.

• "Path" including command output + fallback
  Something like the previous paragraph, but for commands. For example:
  "cmds": {"XDG_NINJA_HOSTNAME": ["uname -n", "hostname"]}.
  If none of them has a returncode different from 0, the check on the path should be skipped completely.

Please note: I don't know if the added complexity is worth it. To be fair, except for the first suggestion, I doubt it.
But since in my case four files named .zcompdump-<hostname>-<version>.zwc, .zcompdump-<hostname>-<version>, .zcompdump-<user>-<version> and .zshrc.pre-oh-my-zsh-<datetime> existed in my home directory, I decided to give these ideas a try: there could be other dotfiles not yet added because of this lack of flexibilty. So I opened this issue.

---

Edit: @Ballasi in #271 is working on a solution which makes use of shell pattern matching. This solves the need to match slight variations of a file name, but it doesn't address the "Path" as a list of strings issue, which will need further development.

[Ballasi]

Putting my two cents here, but since these are all paths we are talking about, I think the easiest and most understandable way to do it would be with shell pattern matching as this is specifically tailored for this kind of use.

This would also be easy to implement as you would need to replace this line

xdg-ninja/xdg-ninja.sh

Line 130 in 5d5a66a

if [ -e "$FILE_PATH" ]; then

with a test for find $FILE_PATH, and you would use .zcompdump-*-*.zwc, ... which is super easier to understand compared to your "vars"/"cmds" idea and more flexible (i.e., for instance if you have a build date in your name, it's kind of impossible to "guess" it without a margin of error).

On top of that, it wouldn't require any change with the current files.

---

This wouldn't solve the "Path" as a list of strings issue you are talking about though, which seems much needed.

In shell, this is done in some sort of "list" which is just file paths separated by spaces (it's not exactly that, but that's how you'd implement it in JSON). This would work in theory but isn't the best idea as it is not adapted for JSON (imagine you have a path with spaces? you'd then need to use backslashes, yuck!).

I guess the best way to do it would just be to switch to JSON lists for the path attribute (which you'll probably need to rename to paths). They can be all updated quite swiftly with an in-place sed and the code can be updated accordingly.