Explode and weblinks in source $Text

@eastgate I think I successfully attached a simple test case to my post above. In case I was not successful here it is again:

multiple-links-one-note.tbx (151.5 KB)

The test is simple and reproducible on my machine (running TB 9.6.1 and previous versions). I simply drag multiple links from the address bar of the browser into the text of the note, typing a return between them.

Some links in the note are live as I hoped and expected. Some are not. The live ones export and preview as expected. The others don’t. And their status seems to shift for reasons I don’t understand.

Here is why consistent detection would be useful for me: I had a project where I was tracking and analyzing common anti-US Chinese propaganda themes. I thought Tinderbox would be ideal for this. One note per theme, with links to several examples dragged into the text as that would make it a simple matter to export later with live links.

Then I ran into the behavior described above. I think it is easily reproduced.

Edit: After I posted this I noticed in a footnote by @mwra that his tests seem to confirm what I am seeing, in v9.6.1 but also previous versions.

1 Like

That’s odd.

I made a new document and a new, empty note.

I dragged the URL of this page from Safari into the text pane; I got a link.

I repeated it four times. At the end, I had the expected number of links. What am I doing differently.

@eastgate Not sure. That’s sounds exactly like what I think I did, typing a return in between. I haven’t been able to figure out why sometimes results are as expected but often are not as can be seen from the test tbx I posted (unless on your side that renders all links as expected).

On my machine, corroborating what I think @TomD observed, all links in notes exploded from a note with multiple active links in the text pane are lost (though I didn’t need to explode in my project so I hadn’t noticed that before).

I get the same, I used @sumnerg’s file but couldn’t re-create the result of every other drag not creating a link (I deliberately followed the demo in dragging the same link in case duplication was some edge case error (I don’t think that is so). There will be some other contextual subtlety about how the process occurs. In context I did note (see grab):

I the first two cases I dragged (in Safari app, under macOS 12.6.8) the location bar URL to Tinderbox $Text. In the next two I dragged the icon to the left of the URL which appears to result in the HTML <title> being used as anchor text to the note. I’m sure there are similar ambiguities when using webpage body copy rather then the page source URL as the drag source. Roll in different browsers and macOS version and doubtless unexpected hilarity ensues.

But this strays from the OP’s use case, which does reproducibly fail (to detect URLs via action code). There is no way to tell Tinderbox to (re-)detect explicit (pseudo-)URLs in $Text other than via manual, per-URL, edits after the Url. the most common edit is to type a Return and then backspace. This manual intervention triggers the URL detection/link adoption.

Oddly, if I use the starting demo as the original $Text, using the manual edit hack to adopt the URLs as web links before exploding, i.e so the start $Text is like this:

Then on explode only some notes (in most cases all except the first new note) retain the source web-links in the new note text.

The new problem, given the constantly variable results is figuring out where in the process links are (re-created). IOW, it’s not really testable by a user—other than to show inconsistencies—as we don’t know what trigger condition we are testing.

Circling back around, Explode does seem to retain RTF styling but now (consistently) Tinderbox or web links in the source text. However, I can’t find a source for the inconsistent result. SoI guess the question becomes. How does explode handle links in the source and how does it handle if at all valid URLs in the new note that are plain text in the source?

I’m probably not the only one who’s a bit confused. I wonder if we should split @sumnerg’s problem into a separate thread. although arising out of trying to workaround the OP’s problem, I think it is a different issue. To be clear, I’m not trying to spike one or the other, but I think they are discrete issues to resolve.

Sure, if that makes more sense. OP’s example has multiple links in the text pane of a single note, one live, others dead, so it seems related but may not be.

BTW, there does not seem to be an “every other” pattern. It just happened to be that way in the example I posted.

@eastgate @mwra Another test file showing inconsistency on my machine that seems to be related to having multiple links in the text pane of the same note.

In one note all links dragged in are active. In another, dragging the same way in from the browser address bar, one link is mysteriously dead.

When exploded (presumably a separate issue) no links are active in the exploded notes.

note-with-multiple-links-2.tbx (166.3 KB)

Ok, I tried “note-with-multiple-links-2.tbx|attachment” and also replicated the effect both copying a note from copy/pasting the source note to a new TBX and making a new note in that TBX and then copying the $Text of the source note and pasting-+match-style into the new note. Exploding each (with default settings had the same effect: explode-test-x1.tbx (373.9 KB)

But, the fact that every paragraph (with a link) is both:

  • the same text
  • the same link
    seems begging to be an edge case as it’s unlikely as a real-life, deliberately tested scenario.

To make a less contrived test case I drag-copied several URLs from my open browser, once using the raw URL once using the icon so as to make a link with non-URL syntax anchor text. I also in each case made 2 further copies. One with non-link text at the beginning of the paragraph and one with text at both beginning and end of the paragraph. The file is here: explode-test-x2.tbx (293.6 KB)

Of those 6 tests, 4 failed completely. In the other two, where the URL or link anchor formed the complete contents of the paragraph, the source web link survived in the new note except in the case of the first new note. Odd, but consistent with a pattern id seen in earlier tests and points to an unexpected dissimilarity of treatment of new note text.

Regardless, this test is disconnect with the problem in the original thread. In that case the source note $Text had web-links and ‘bare’ URLs. Regardless of the persistence of web links from the source the OP’s expectation that ‘bare’ URLs would automatically be both detected and adopted as web links in the new notes is a further twist.

I don’t think the above solves any of those problems but does add some further tests.

1 Like