I know I can add the code manually - but is there a way to automate this with an agent or stamp or otherwise to either automatically or easily convert web URLs to working “a href” links in the HTML code?
The ‘smart link’ tech of the underlying Apple frameworks is transforming the link into an RTF link, but not a Tinderbox link. Initially the former were adopted as the latter—or I believe that was the plan—but tech issues cropped up and for the interim it has proved safer to not adopt RTF-only links as Tinderbox links†. I think an unintentional aspect of that is it isn’t immediately obvious looking at $Text as to which web links are/are not native web-links.
Part of your confusion here in in other threads seems to stem from approaching Tinderbox as if it is a Web/HTML editor (I’m not judging). Far from it, it is a hypertextual note tool that can—amongst many other non-web things-generate hypertext.
Preview is confusing some users. It isn’t intended as a ‘viewing’ space. Its genesis was for checking HTML render before exporting lots of pages (aTbRef’s TBX emits c.2k files on full export). From there some have used it as a viewer. But, one can’t judge a feature from mis-use. If you need a different functionality, I’d mail in your use case. The use case part is important so the developer knows (rather than has to guess) your assumptions.
I’d agree the RTF-vs-Tinderbox link issue is annoying but I don’t find it confusing. It works fine in docs I don’t export and in those I do I disable the Smart Links for the note before pasting.
†. Lest that seem a trivial point, Tinderbox stored links outside the source text as was done until the limitations of the early Web bent perceptions of hypertextual normality.
My use case is that I would like to regularly use Preview as a viewer because it adds functionality since I can enter on-the-fly raw HTML formatting in the Text tab. One example is the ability to embed a video and I am sure other examples will evolve such as formatted lists or tables or anything else that you can do with HTML.
Once I start putting raw HTML in the Text tab, however, it really is not usable for viewing, so that means Preview becomes my main viewer. That works fine - except we get back to my original question - since my work involves lots of web URLs within my notes, do I need to enter the a href code manually each time or is there some way to automate that?
Thanks, this is useful , but please understand this is not Tinderbox 's Tech Support. This is a user-to-user forum, and though admin/mod am a fellow user like you. I don’t work for Eastgate and live on a different continent. The etiquette of such forums is that the developer my post here but that doesn’t make it formal tech support.
If you want something in the app, please describe your need to the developer directly. If it’s not worth your time, it likely means its not that important. I say that reflecting on the same. Over time I’ve requested features, whilst in some cases I realised it’s not a good fit/ROI/for the dev and I should just use what’s provided (i.e. revisit my untested assumptions about how the app ‘should’ work).
Compared to most apps I use, Tinderbox is much broader in focus. That is pertinent here. Thus what I find obviously needed may be shared by few if any other users. What you or I think is ‘obvious’ or done by ‘everyone’ likely isn’t.
@rkaplan Some of my notes have lots of web URLs in $Text too, for different reasons.
I’ve discovered I can make a pasted link preview and export as a link if I select it, “right-click” and choose ‘Edit Link’ from the contextual menu, command-c to copy the link destination to the clipboard, then in the menu Note > Make Web Link … > Create Link.
(The keyboard shortcut control-option-command-L doesn’t work on my machine, possibly because that keyboard shortcut is already taken somewhere; I haven’t had time to check).
Not automated, but it’s probably quicker and easier than coding manually. (Beware, though, if you have multiple web links in the same note. Previously added links can sometimes “disappear”).
@eastgate. Indirectly reported, here, in a different context. It could be that not too many users have tried dragging multiple web links in from Safari into the same note to then turn them into Web Links so they will be live in Preview and also export.
My use case has been to collect web sources illustrating each of several dozen themes without ending up with hundreds of separate source notes.
Quite often, when I drag in a new link and then turn it into a Web Link as described above, one of the existing Web Links “higher” in the note deactivates and its link destination disappears. So far at most I have 3 or 4 links in a given note, but the plan was for several more.
On my machine (v. 8.92, Big Sur) there seems to be something a little funky with links in the “RTF layer.” I have assumed that is already being addressed.
OMM this is because the same combo is used by 1Password for the Lock’ command, and as 1Password normally loads at start—so before Tinderbox it takes the shortcut; first in session to register a given shortcut holds it for the rest of the session.
I can’t replicate this in v8.9.2. The $Text area content menu has no "Edit Link…"option. Indeed such a menu is not seen anywhere in Tinderbox as far as I can see. Could you post a screen grab of the context in which the menu you describe is appearing?
Links detected in RTF drag/drop or paste are created as ‘Smart URLs’. These links are not Tinderbox native web links! as previously explained in a previous post. They exist only in the $Text RTF layer, un-less manually re-created as native Tinderbox links.
@mrwa I can’t replicate this in v8.9.2. The $Text area content menu has no "Edit Link…"option. Indeed such a menu is not seen anywhere in Tinderbox as far as I can see.
If you haven’t spotted Edit Link then I’m not entirely sure you followed my described steps to replicate. Here’s what happens on my machine in 8.9.2.
Here’s the link after it’s dragged in. It’s clickable but, alas, as described elsewhere, it isn’t a native Tinderbox Web Link that will preview or export. I’m of course aware of that, or I wouldn’t be going through the steps I described.
So I turn it into a Web Link. With the (non-native “smart link” or whatever it’s called) selected, right-click (control-click) and choose Edit Link... in the contextual menu. It’s the second option shown here:
That’s a bit of work. I would much rather automatically have a true Web Link. But I can live with the manual workaround.
BUT, BUT… now drag in another link below this one and repeat the same steps with it. On my machine a new Web Link appears in the text. But (unfortunately) the one before it goes dead and the Link destination: text appears to be lost.
If I fix’ the aTbref’ link to be a Tinderbox web link then drag in another URL into $TEXT (Smart URLs enabled), the new item is —as expected—and RTF layer link.
So this proves problem isn’t just Tinderbox, as I should get the same outcome as you report. My hunch would be possible macOS version-related factors, given that I’m still on Mojave.
Does this problem happen in all you TBXs, or just one. If you have access to another Mac, does it also happen there?
Not what I get on 10.14.6 with v8.9.2 - so it might be an OS thing.
It might be an OS thing. But then again it very well may not be an OS thing. I can’t see exactly in the screenshot, but it does look as if you have more than the ‘smart link’ (or whatever it’s called) selected. Your selection seems to include an extra blank character to the right.
On my machine I only see Edit Link... in the contextual menu if the link itself is selected without any surrounding text. That may well be the same behavior on your older OS.
With an extra character selected as I think your screenshot indicates I see this:
If I fix’ the aTbref’ link to be a Tinderbox web link then drag in another URL into $TEXT (Smart URLs enabled), the new item is —as expected—and RTF layer link.
Yes, of course. A ‘smart link’, not a native Web Link. BUT… what happens when you ‘fix’ the second link to be a native Web Link? On my machine, it’s that ‘fix’ that deactivates the first link and apparently discards the Link Destination text. The deactivation was merely an inconvenience. But the apparent loss of the Link Destination led to loss of work; I had to find a number of sources all over again.
Yes, this is easily replicated in four or five different TBX I have tried it on, including new test documents. I don’t have access to another Mac here (I’m 12,400 kilometers from home), but I created a new user account and the behavior is the same there.
This “isn’t my first rodeo,” as we sometimes say in parts of the US. I am quite confident this is an issue that can be reproduced and is worth addressing. Maybe give me the benefit of the doubt.
Understood. I think there are two different issues here. Whatever I do in a link or with only the anchor selected, I don’t get an Edit menu option in the text pane context menu. I only have 10.14.6 OS Macs here so can’t check further.
Separately, I have a hunch that the ‘broken’ link may be a manifestation of an odd effect (fixed for the next version, I believe) where editing the $Text of a note shifts anchor texts from their original position. The link is still there but now underlines/colours different text, or in some cases pushes the anchor outside text. In the latter case, the now-missing link will show in the Browse Links dialog but with no anchor text although it is a a text link because the character offsets for the link anchor texts (in the plain text version of the Text) are now outside the available text. Sounds complex, but you’ll understand it if you see it.
The main problem is replication on more than one mac/user at present, which doesn’t mean your report is wrong, but we (or more accurate Eastgate) have to figure out what environment is necessary to consistently trigger the issue you see. Here, I spent at least an hour earlier today trying all sorts of ways to trigger the effect, without success. So at this point all we know is (a) there is a problem (b) it doesn’t affect all users, which make it herder to diagnose.
Are you on macOS 11.x?
As it is I can’t follow your instructions as I can’t edit, via the method you describe, as the the menu option is not present. Given your precise instructions, my Tinderbox testing experience and the time I’ve spent thus far, I think it unlikely that I’m not following your instructions. I can’t get the option in betas for the new version; that’s out of scope here except it is running on the same OS [sic].
Can anyone on macOS 11 replicate the problem above?
Thanks! Yes, I’m on Big Sur. It’s late here now but will look at Browse Links tomorrow to see if I can spot any clues there. Some sort of anchor “shifting” sounds in general like what I imagined might be happening. Another chance observation I passed on to @eastgate may or may not be relevant in this context. Dragging in and converting to Web Link before other Web Links that does not seem affect the others. The deactivation seems to occur only when a Web Link is created after another Web Link.
I couldn’t get any more clues from Browse Links. The deactivated link seems to be “just gone.”
Here’s a simpler way to replicate if you can’t see Edit Link... in the contextual menu (I was just using Edit Link... to copy the url to the clipboard without having to make a trip back to the web page):
Drag in a link.
Go back to the web page and copy the url.
Back in Tinderbox select the link.
Choose Note > Make Web Link...
Paste in the new url where indicated (if necessary)
Result: The second link is active and previews/exports, but the one above it is deactivated and, worse, the url of the link to the source is nowhere to be seen.
A workaround suggested by @eastgate is (as I understand it) to avoid dragging in links and instead copy and Edit > Paste and Match Style, then go back to the website, copy the url, and, once again back in Tinderbox, Note > Make Web Link..., paste in the url and Create Link. That seems to avoid losing data (the url in the link to the source). But I’m hoping that’s just a temporary solution. It’s not very user friendly.
In fact this is what I’ve already tried. But, repeating in macOS 10.14.6 (patched to the macOS11.3 concurrent OS patch), I end up with two Tinderbox web links.
I’m sorry if I’ve missed it somewhere but:
does the problem occur in all or only some docs on your system?
Does the problem happen with both pre-existing TBXs and newly created TBXs?
have you restarted the Tinderbox app since you spotted this problem? Sounds odd, but sometimes this clears the issue?
have you explicitly tested dragging from several discrete app contexts, e.g. different browsers/apps? FWIW, I’m using Safari here as my drag source (Chrome just kills my Mac due to its poor resource management). Also, I’m dragging from the location bar icon so as to get an RTF-only link with the source <title> as the anchor text of the link.
I’ve seen nothing yet that proves this isn’t OS dependent. I don’t say that to trivialise the issue but to get on with the diagnosis. We already know the problem, but it isn’t yet reproducible—based on information in this thread—except on your Mac. I don’t think it’s that localised (but I and others have encountered such (seemingly) locally scoped errors, normally due to an odd edge case of app/OS/data/user workstyle).
Could another user on Big Sur please take just a few minutes - all that’s needed, to try the actions @sumnerg has helpfully described in detail here. It would be very useful to be able to delicate the problem in more than one user’s
Here’s what happens on my machine in 8.9.2.
