Having not noticed that it is not advisable to include colons in the $Name of a note, I have several notes with them. This is leading to some strange behaviour. Consider this code in a stamp:
I had expected MyString to contain a few path names that were linked from this note. Each of the path names in fact begins with “/Prelude to a declaration of duties toward the human being OC V:2/112/” and what I find in MyString are concatenations of solely “/Prelude to a declaration of duties toward the human being OC V”. That is, the path is being truncated at the colon.
In my test situation this is the content of the aLink dictionary for the two linked notes, with the first one reformatted to show the keys in the dictionary:
source:/Prelude to a declaration of duties toward the human being OC V:2/112/112e;
dest:/Prelude to a declaration of duties toward the human being OC V:2/112/the domain;destination:/Prelude to a declaration of duties toward the human being OC V:2/112/the domain;
isFirst:true;
isLast:false;
type:*untitled;
class:;title:;
target:;url:;
comment:;
anchor:the domain;
source:/Prelude to a declaration of duties toward the human being OC V:2/112/112e;dest:/Prelude to a declaration of duties toward the human being OC V:2/112/note on location;destination:/Prelude to a declaration of duties toward the human being OC V:2/112/note on location;isFirst:false;isLast:true;type:*untitled;class:;title:;target:;url:;comment:;anchor:*;
I have tried various ways to cast the variable to a string in such a way so as to preserve the colon without success. If I do not want to change the $Name(s) of my notes, is there anything I can do to work around this?
Any chance you can post a sample file? From your description, I am finding it difficult to reproduce. Also, I don’t think the issue is the colon, but rather the “/” in the name. Froward slashed are used in designating paths. Please send the file and I’ll take a look. Or, try replacing the / with -.
aha! I was about to say, “there oughtn’t to be a problem with colons in path names!” But you’ve found one.
The issue only arises when using eachLink, and it arises because the argument to eachLink is a dictionary. And dictionaries think colons have special meaning.
I plan to clean this up in the next major release.
The slashes, on the other hand, are going to cause trouble — as Mark Anderson has already noted. That’s hard to avoid: if a note is named V:2/112, it’s hard to know that you don’t mean there note named “112” inside the container named V:2.
In fact, there are no slashes in the $Name of the notes in question. The $Name of the destination note is “the domain” and its parent’s $Name is “112” and its parent is the long one with the colon that is causing the problem. You can see that if you scroll to the left in the dump of the dictionary I gave.
Mark B has obviously spotted the problem which is that in a dictionary the colon is being used to separate dictionary-key from dictionary-element-content. So when I request the path that is stored in the dictionary, the dictionary parser stops at the colon because it thinks it has reached a new key instead of giving me the whole path (which I had wanted so I could grab an attribute from the note it designates).
Mark B, when you say next major release do you mean 9.4 or v10? I’m just weighing up whether to create a workaround.
It’ll be called “9.5” and should appear in the fall.
I write that with some trepidation, because the dictionary fix is just one of a bunch of tricky things I have planned, and right now I’m a bit stalled while trying to understand some rather complicated math that’s needed for a different project.
On reflection, I believe there is a possibility that I can patch this specific issue in a backstage release. That might be sooner.