Description
If some values are coming from user input, it is possible (however unlikely) that someone could input a literal string that start with @, %, or :. If this were to happen, jo would try to interpret those values as files to read and would fail to create JSON if the file doesn't exist (or create unintended JSON if the file does exist).
Currently, the only way to avoid this is to manually escape those characters with a \. But, if these values are coming from user input having to do any pre-processing and escaping on those values before passing them to jo kind defeats some of the great value of jo being able to make valid JSON without needing to manually escape things like double quotes within values.
To avoid this possible issue when values should be treated literally no matter what without anything needing to be manually escaped within the value, I'm thinking there could be a new coercion-style argument and/or a global arg to not interpret those special jo characters. I could see value in both a global option and a per value option depending on the scenario. I'm thinking something like -l (for "literal") could be good candidates for this kind of option.
Hopefully, this could be combined with existing coercion args so that something like jo -- -ls "key=${user_input_value}" could be done to always interpret user_input_value as a "literal string" without needing to escape any special characters in the string.
Thanks so much for considering this as well as for the amazingly useful jo!