Ziplinks offset bug?

Not sure if this is the right place to file bugs. What is the recommended place?

First off, THANK YOU SO MUCH for ziplinks. They are awesome! I got so much work done today.

Now to the bug (in Version 8.6.0 (b448)):

In the text of a note, if I add “I like [[cats]]”, the cats is correctly linked. Now, before this text if I add a link to a child of a sibling, say, I add “I like [[animals/mouse]]”, then the previous link disappears.

This is an offsets problem, I think, as revealed by the color of the text. If the original message had been longer (I like [[cats]] and like them around), after the addition, we see the blueness move right: Where as “cats” was blue before the most recent addition, something latter now becomes blue, and clicking that text leads to the cats node. (I am color blind; this may well be purple instead of blue)

What does not trigger this bug: adding a link to a sibling before, or adding a link to any note after.

1 Like

Cannot reproduce.

This forum is not the best place for bug hunting.

You might want to send an example file with the issue, and screen shots, to mailto:support@eastgate.com for bug resolution.

1 Like

Thanks, Paul. I emailed them. Surprised you cannot reproduce, though. Maybe I was entering the ziplink by selecting from the options and you instead typed it out?

Before adding new ziplink

During adding (I start typing [[, select animal, select mouse)

After adding (link to cat is gone)

Best,
Abhijit

Yes, I followed your steps (again), and no, sorry, cannot reproduce. Maybe something on your machine that watches / manipulates / is triggered by text is interfering? TextExpander, Typinator, Alfred, etc. etc,

Reproducability is key - one of the first things that needs to be established is is the effect local - i.e. affecting one document or perhaps one user on one Mac.

As a user we can help. If it happens in the current document, close that and try again. Still there? Now start a new document and see if you can reprocess the effect. When you contact support, as recommended above that testing is very useful collateral information. Also remember to report the version/build number (see the app’s ‘About’ dialog) and the macOS version you are using. If a first-time report it may also be useful to say what type/vintage of Mac you are using: a low and MacBook and an iMac Pro may not react the same due to difference in performance.

You are right on colours. Links in note follow the colour convention of the early Web. Links are coloured mid-blue and, during the current session, visited links are coloured purple. In the new session, i.e. on re-opening the TBX, all links revert to blue until used.

Yes, I can reproduce the effect. Not reliably, but I can make it happen. I think starting a ziplink before an existing link is a factor.

Then again, this whole feature developed from ‘quick links’ and being able to create links as you type. Thus I suspect this happens at, and most testing was of, using a ziplink at the end of current $Text.

Here, I made the ‘cat’ link first, then added the ‘cow’ link to the left of it:

Untitled 2020-03-13 09-58-14

1 Like

I believe this only arises when (a) there are links after the zip link, (b) you’re using the popup menu, and © you’re building a path to a note in another container.

I expect we’ll have this resolved quickly, but it’s easy to work around.

1 Like

FWIW, in my case a/b apply but not c. However, all were root level notes which might muddy the waters with regard to C, as at root $Name == $Path.

I added a ZipLink (née QuickLink & WikiLink) in this note and the active link area shifted, as previously reported in December.

As noted up thread, this issue has already been reported and is under investigation.

Mark’s reply said he thought the bug involved path building. My post demonstrated this was not a requirement, and that the bug did not involve solely new code associated with ZipLinks.

Indeed, as did my previous post. I was only meaning to note that the the issue is known. I’m certain I’ve seen outbreaks of this occasionally in the past which suggests a regression error. I’m sure it will be fixed now it is reported, even if not today. :slight_smile:

I believe this is fixed in 8.6.2

1 Like

Thanks. This is working nicely so far in 8.6.2. Very Roam like, and very conducive to quick note taking/creation.

1 Like

Unfortunately, I’m still having this problem where when I add a ziplink to a note that comes before an existing link, the existing link shifts to different words.

I have 8.6.2. I’m not expecting an immediate fix but I wanted you to know I’m still having the problem given your March 17 comment that you thought it was fixed.

Thank so much for all you do to make this such a wonderful product!

I can’t reproduce this in the current backstage release.

FWIW, I can’t replicate the issue in v8.6.2b425, the current release. However, my test document was fairly small (limited time to play) and with uncomplicated $Text, so these may be contributory factors. IOW, bigger files and/or bigger/more complex text might play a part.