In the attributes view there is an Evaluate option for the Container attribute. I’ve noticed that characters such as comma (,) colon (:)… truncate the parent note when it’s evaluated. Is there a listing of characters that are not allowed? Should they be avoided / replaced for the paths to always work correctly?
What sort of problematic strings are you evaluating?
When you evaluate an expression, Tinderbox treats that expression as it would in a Tinderbox command. For example:
2+2
will evaluate to “4”. If you have a string, it should be enclosed in single or double quotes; Tinderbox will do its best to do what you want regardless, but operators like “+”, period, and comma embedded in strings will likely produce syntax errors.
Thank you for your clarification.
I haven’t yet sufficiently advanced in my Tinderbox practice to start doing string evaluations, but I wonder if I’m running into a similar problem:
When I select text in a note and use the key sequence ⇧⌘L (Park Link); start typing into the search box; and then navigate through the search results using the up and down keys: the “Link” button grays out and is not clickable if I navigate to or select a note name that contains both an open parenthesis character and a close parenthesis character.
Notes with titles that contain only open parenthesis characters are selectable, as are titles that only contain close parenthesis characters, but note titles that contain both are not selectable in the Park Link modal, whether or not they are correctly paired (i.e. open parentheses and close parentheses are ordered and paired in a way that forms a valid abstract tree).
Without delving into the particulars of string evaluation in Tinderbox, are there other special characters which will—singly or in combination—make note titles unavailable in the Park Link modal? Or have I fundamentally misunderstood what’s at issue?
This known-and-as-yet-undocumented issue with path parsing. Tinderbox will let you use pretty much anything in a note title ($Name than thus $Path) but here I’ve listed some characters that may cause unexpected/undocumented internal breakage if used in note $name values:
it is advisable to avoid the following characters when titling notes: forward or backward slashes, opening/closing parentheses, colon, semi-colon. Note: this list is not exhaustive.
I think straight double quotes (unless used in pairs) may be problematic. Also, there is no escape mechanism for these characters, i.e. an ‘escaped’ $Path function.
The problem here is that the parentheses are ambiguous. For example
. (x)
is a note named (x). But
child(nextSibling)
is the note that is the first child of the sibling of this note.
Similarly
. /animals/bats
is a note about bats in a container named animals. If you meant the note named “/animals/bats” you’re out of luck.
Thank you, Mark, I appreciate both the clarification and the list of special characters.
To check my understanding: there is no relevant string parsing occurring when I enter a title for a note; instead, what is happening to me is that when I enter a string into the search field of the Park Link modal, that string is interpreted as a path. However, the completions that are offered have unescaped special characters in them, and therefore—when parsed as a path—do not resolve to note titles in my project for the purposes of the Park Link modal.
Further, based on your statement that there is no way to escape special characters in paths, it sounds like the underlying issue is that there are note titles which are unresolvable by the current path mechanism.
If all that is the case, I will do as it sounds the community has done, and avoid using the characters you list in note titles.
Thank you again, Mark.
Sure, I understand. Like you, I’m just a user and—No—there is as yet no safe work-around for this known but non-fully-documented issue.
FWIW, I have suggested )off-forum) that there be some read-only attribute or action that checks for a safe $Path or $Name. But, I sense the problem is that if that were easily testable there would likely be escape wrappers for ‘bad’ names. Meh. Anyway, I share your pain.