When I use Markdown Tinderbox will not follow links to locations on my Mac. This fails in Preview whether I use the inbuilt Markdown Prototype or whether I use a stamp to add Pandoc or Markdown from Scrivener. All other Markdown effects and typing work satisfactorily as do external links to web pages.
The internal links can be structured using Hookmark or using the Copy URL that for example DEVONthink provides. I type such a link like this, for example: Using Poison in Ukraine’s Depleted Hope of Victory You need to click the edit pencil to see the typed link.
These same internal links work fine if I am not using Markdown but simply use a normal link.
From what I can see Tinderbox Preview opens links to external URls in situ, rather than going to the application and opening it there. My guess is that Preview can’t form the correct in situ structure for an internal link.
Has anyone seen this before and have a solution, please?
Hi, and welcome to the Tinderbox forum. Sorry you’re having an issue with links:
That’s easily checked by using the Text view’s Export pane which shows the HTML code being generated for export/preview use.
Does the link look correct in HTML terms? I suspect what you report is not intended, but there isn’t any documentations as to what should happen with pseudo-protocols. You report preview loads local/web HTML pages in the preview window, yet I assume the DEVONthink link is intended to open in DEVONthink and not a web browser. So, likely, preview can’t show the result of the link as it’s not an HTML page and fails silently, i.e. nothing happens.
Thus I don’t think this a bug so much as an error that ought to have a handler. This is probably one for Eastgate (@eastgate) as I suspect so coding is needed. The app would need to figure out the URL value is not a web page, and pass the URL to Finder for opening, which could—in this case—cause DEVONthink to open.
I think the loose end here is it was only in Tinderbox v9.5.0 (IIRC) that the app moved to using a full WebKit view for the preview window (for other causes). It is that latter that that enables the sort of thing you are doing, but it’s not predictable for what people will use the feature, so unbounded edges like this crop up occasionally.
Re Markdown, it’s important to note that whilst Tinderbox can optionally process Markdown, it isn’t a Markdown-based editor as in Marked or Obsidian, etc. The difference is subtle, but important. In an app like Obsidian you have to use Markdown to make the styled (HTML) text you see because there isn’t an alternative. Tinderbox doesn’t need that as you simple stlye the text and Tinderbox translates it for you. IOW, if you are using Markdown out of habit, rather than necessity (you need to export ‘.md’ files, then I’d suggest using normal Tinderbox text features and save the hassle of using Markdown.
HTH.
Thanks Mark. Yes the HTML structure of the link is correct. The plan is that the link opens in DEVONthink as you mention. I don’t need to write in Markdown though I enjoy using it, and I only reported it for the possible interest of others. I had already (recently) decided that I would not use Markdown of any sort in Tinderbox but I only decided that because internal links to DEVONthink is something I use quite a bit.
I rather think Eastgate (@eastgate) already has more than enough important issues to contend with.
Thanks again for a rapid and detailed reply. 
Thanks—that all makes sense, as does your rationale for reporting it, which is a help for those who might encounter it and not know what to do next.
I don’t wish to appear harsh about Markdown, it’s taken me a fair while to surface nuance between deliberate use of Markdown vs. its use as ‘native’ language of writing a note (as it is in many PKMs). Experience of the latter does cause confusion for some when faced with an app that is the former and not the latter, especially for those for whom Markdown is how they understand styled text & HTML. There’s no right/wrong there or a simple answer.
If you don’t use Markdown and use Tinderbox weblinks in $Text (or URL-type attributes in Displayed Attributes) then you can the DEVONthink links (and hooklinks, Bookends links, etc.) directly from the text view without having to mess around with going into preview to use links. Both internal links and weblinks in a notes $Text are ‘live’ in the normal text view. To see where links are in $text you can hold down the Cmd+Opt keys and all links will show an double-underline to indicate their presence. To see more info (for outbound links from the current note) see Browse Links.
Can you send me a sample file? I use markdown every day, all day. I can take a look at your settings.
Testing markdown.tbx (133.9 KB)
Hi Michael, thanks for taking an interest. Here is a small test file I have just set up. I hope the notes are self explanatory.
By the way, I enjoy your tutorials, very helpful.
Peter
Ok, I see your issue. The first two links work, they resolve in preview. I’ve noted however, that you can’t rt. mouse click and open link up in a new window. I wonder if this would be possible, e.g., right mouse click and open up in Chrome or Safari.
The Later two do not seem to open anything up. this is one for @eastgate to consider, i.e., is there a way to trigger an link form Preview to open an app on the computer.
<a href="https://www.yahoo.com">https://www.yahoo.com</a>
[https://www.yahoo.com](https://www.yahoo.com)
<a href="obsidian://open?vault=Obsidian%20temp%20file%20location&file=2023-04-28%20Frid">obsidian://open?vault=Obsidian%20temp%20file%20location&file=2023-04-28%20Frid</a>
[Markdown link to Obsidian note](obsidian://open?vault=Obsidian%20temp%20file%20location&file=2023-04-28%20Friday)
I have found, however, if you put the obsidian URL in a $URL attribute that is does open up.
Summary: we need to as @eastgate.
No, this is not a Tinderbox fault but is due to user error, in not configuring the page for export.
As suggested, a quick look at the HTML in the Export pane immediately shows an error in the code being previewed. The href value of the second link in the Tinderbox Markdown is incorrect:
%5Bobsidian://open?vault=Obsidian%20temp%20file%20location&file=2023-04-28%20Friday%5D(obsidian://open?vault=Obsidian%20temp%20file%20location&file=2023-04-28%20Friday)
It shows that Tinderbox is, as expected, encoding the second web link on the page. the Markdown post-processing is seeing the Markdown link code and making the already created web link into a nested link. Pick one method or the other.
If you want some of $Text text to be a Markdown-defined link it should not also be a Tinderbox link. Set $SmartLinks to false for the note,
Then, open Browse Links and delete the second web link:
The result is the second link looks like this:
Note the loss of the blue text indicating a Tinderbox web link. Now, the href value of the Markdown-processed link in the exported HTML of the second link (see the export pane):
obsidian://open?vault=Obsidian%20temp%20file%20location&file=2023-04-28%20Friday
Compare that with the value as taken at from your test doc at the start of this post.
Tinderbox’s $Text is not a Markdown-based editor, such as is popular in PKM apps like Obsidian and others. There, Markdown is what you write in. In Tinderbox you can use Markdown but you need to turn off other normal functions as Markdown is optional, non-standard, use. Tying to mix modes, as in your demo has results as seen. 
TL:DR Tinderbox != Obsidian. Assuming use of Markdown in Tinderbox works like in Markdown-centric apps will lead to errors.
I extensively tested turning on an off SmartLinks. I do not believe that the issue. The “blue” links appear, and the links are clickable, just nothing happens when you click them.
It is not as simple as turning $SmartLinks on or off after the fact. After turning them off for the note, you must also delete the unwanted weblinks and ascertain they are gone before trying Obsidian link. I can’t check opening the actual link as I don’t have Obsidian installed.
See note “Tinderbox Markdown 2” in this modified version of the demo: Testing markdown-ed.tbx (180.0 KB)
My understanding is the second link doesn’t work? If so please post the HTML code for that link as seen in export view. In this sort of scenario, always check the HTML code first otherwise Preview doesn’t show you that the error is bad code and not a feature error.
The fact the export pane uses WebKit to make the web view doesn’t mean it is a fully featured web browser. If the user wants full browser features, export the pages and open in a web browser. Indeed using preview to open follow links that you can open in Preview seems like making undue work (presumably because using Markdown is ‘easier’?).
Part of the problem is a starting from Markdown centric view and (wrongly) assuming that is how Tinderbox works when rendering text to HTML. If one is used to an app where the only way to make a link is using Markdown mark-up, I can see that might make one want to try and use Markdown links ‘just’ to make a a link you can more easily make in Tinderbox. Just because a crop of PKM/notation apps use the same implementation of Markdown use doesn’t mean it is the correct only way to use Markdown.
There are two separate issues here:
- trying to make Tinderbox function like Obsidian or other PKMs, rather that use the richer features built in to Tinderbox. This is not a Tinderbox problem but a user false assumption.
- actual to-HTML encoding issues, for instance through mixing Tinderbox links in $Text with Markdown link code.
There is no right/wrong here; people can use what they want but they need to read the Tinderbox docs. It is the case that Tinderbox’s web preview/encoding does not work the same way as Markdown-only apps like Obsidian and as users we need to use Markdown in Tinderbox in the manner it is implemented (making Tinderbox work like Obsidian would mean losing a lot of functionality just for the convenience of only using Markdown for text). People are confusing their expectation, from working in simpler apps than only have Markdown for markup and richer-featured apps that aren’t tied to Markdown only. The fact that the latter don’t work like the former is not a fault of Tinderbox but a misunderstanding by the user.
Testing earlier, I did trip over an oddity relating to the (unusual outside texting) scenario where $SmartLinks are off and the the note $Text contains _the same exact target URL in two web links. Deleting only one, the link reappears; this is incorrect and has already been reported to Eastgate. But, it isn’t the actual cause of the immediate problem in the demo file which is double-encoding links due to misconfiguration and the document.
I’ve updated my note on Markdown preview rendering to make clear two point arising here:
- Do not use Markdown link code with Tinderbox text link or web links in text. Either let Tinderbox use the default link-to-HTML generation of remove the Tinderbox and use only Markdown code.
- Using the Export pane and looking at the HTML code is the correct way to debug link issues. Just using precview tells you have a problem but not what or why?
@mwra your explanations make sense, but from a user’s perspective all of this is NOT very intuitive. The simple asks is (clearly not so simple to execute) is there a way to have TBX handoff links, e.g. “rt mouse click and open links in the default browser.” If this were easily implemented I think we’d have the best of all worlds, we’d be able to keep TBX pure and handoff complex functions to a “real” browser.
Thanks Mark. All is not as simple as you say it is. I agree there is an error, I do not agree it is the user’s fault. Perhaps that is simply my ignorance.
However I copied a URL link from Obsidian. I then pasted it into BBEdit. It looks like this:
obsidian://open?vault=Obsidian%20temp%20file%20location&file=Resources%2FPolitics%2FAustralia%2FRed%20Alert%20Australia%20is%20not%20ready%20for%20war%20with%20China
I then copied it into a tbx file and the HTML export looks like this:
obsidian://open?vault=Obsidian%20temp%20file%20location&file=Resources%2FPolitics%2FAustralia%2FRed%20Alert%20Australia%20is%20not%20ready%20for%20war%20with%20China">obsidian://open?vault=Obsidian%20temp%20file%20location&file=Resources%2FPolitics%2FAustralia%2FRed%20Alert%20Australia%20is%20not%20ready%20for%20war%20with%20China
(I’ve stripped off the href part of it.)
If i copy the whole piece of HTML code here it looks like this:
This leaves me with a few questions, The first is what is $SmartLinks? It looks to me that Tinderbox converts my simple copied set of characters into a more complex form. Once that happens if it happens to be a Markdown note the link does not work in Preview.
Does that mean that I can’t paste a link into a Tinderbox markdown file and have it work.? If so, why not.
But, intuition is highly subjective. We’re in the area of “I just want/expect…” based on incorrect assumptions. The issue I observe is those who work mainly/only in Markdown-centric apps (and also may have little/no understanding of HTML) simply assume that what they are used to is the norm and the ‘correct’ way of doing things.
Markdown-based apps seem to have an appeal to coders (looks like a code IDE!) and the same folk make apps, which is what the rest of us gets. A skilled coder may understand the interrelation of text+Markdown, style or semi-styled text based on Markdown (in some the Markdown markup is left visible but code enclosed text is styled. All very confusing for the ordinary person with no tech code background. It also contains an expectation as to two thinks are down, e.g. making links. None of this however is Tinderbox’s problem/fault.
‘Just’ making the Tinderbox text work as in an app like Obsidian isn’t trivial, even if it seems so to the person who only understand Markdown for mark-up; IOW, “it just needs to look work like Obsidian †” isn’t simple.
†. No unkindness to Obsidian here, lots of small PKM/annotation apps use a Markdown-centric text approach. I’d wager in part this is for ‘compatibility’ reasons (IOW jump from app A to app B) creating a false sense of a norm. Witness too the number of people using Markdown without realising is comes in many semi-compatible ‘flavours’ with different sub-sets of HTML feature. Markdown is not HTML but a set of inline hints for a small fraction HTML features that have to be parsed into HTML (the styled text peole think is ‘Markdown’ is actually HTML, with the HTML aspect hidden from the user.).
We’re down the rabbit hole is trying to think of Tinderbox as if it were a plain text Markdown-centric app. It isn’t! I can state it more plainly. Tinderbox working as designed. If the user has incorrect assumptions as to how things work.
If you paste text into $Text it places styled text into $Text. If you paste some text from a web page, for example, into $Text you get any fonts, bolding, links, etc. So, a weblink in the pasted text is received as a web link and Tinderbox recognises this as such and makes a Tinderbox web link. When you do default preview (or export) Tinderbox renders that link as the HTML web link. By adding Markdown around the link your add a link around the link. IOW the Markdown code is not needed as the HTML code (remember, Markdown is just a mark-up for HTML).
The Tinderbox attribute SmartLinks controls whether Tinderbox adopts links found in pasted text, or recognises URLs typed into $Text. It sounds like you want to turn off smart links in your documents to better mimic Obsidian’s text limitations.
Also, when pasting content, if you use the 'Paste & Match style" option (Cmd+Opt+Shift+V) then the text on the clipboard is pasted essentially as ‘plain text’, so no colours, fonts, links, etc.
You might also find it useful to think about pasting into $Text, using the normal Cmd+V paste, as being closer to TextEdit, Pages or MS Word than into BBEdit or a plain text editor.
This is the problem Markdown-styled-text cause. The user sees plain text, with Markdown mark-up in it and either sees the text styled in situ or a separate pane (depends on app). But the styled text is still HTML.
Plain-text-apps also tend to adopt, as a ‘norm’, creating hyperlinks only in the Web style, i.e. all links must be literally encoded in the text of the note. A further informal convention has arisen of using wiki-style mark-up (wiki is a form of website generator) that uses [anchor](url) to indicate what in proper HTML is <a href="url">anchor</a>(indeed, the links you see in the styled text of an Markdown is the HTML (not the Markdown. But this leaves people thinking that uses brackets if how (the only way?) to mark a link. Simply not true. However, it shows how casual assumption building on casual assumption can create a false perspective of what is correct (‘intuitive’).
In this context the Markdown-based app is the less textually powerful, so is not useful as the comparative norm. It is easier to think of normal text things a Markdown app can’t do, in order to understand the differences. But, lots of people most used to Markdown see it differently. I get why, but it causes a lot of confusion.
As I don’t work in one textual silo, find these false norms confusing, not least because for some what is most familiar is right, and anything different is wrong. But, it’s simply not that simple.
Well it’s getting late here (Perth, Australia) and I’m off to bed. However just to set the record straight, you seem to have started off with an assumption that you know a lot (probably true) and that I know close to nothing (definitely not true). Much of what you said in your last two replies is condescending to put it mildly. Such as telling me that paste and match style is different than paste. No kidding. As for telling me that intuition is subjective; my normal Aussi slang reply to that would be bulldust (at least more polite than the other eight letter word that also starts with bull).
Yes, I do know there are multiple forms of Markdown which is why I used three different forms of Markdown, the inbuilt Tinderbox variety, one from Pandoc and one from Scrivener while investigating my problem. Yes I do know that in the end Tinderbox “translates” markdown into HTML. No I am not down a rabbit hole.
My original point, if you bother to read it, was that Tinderbox will not call up an app on my computer to follow a link when in Preview but it will when in Text. And I wondered why.
The reason it seems is that Tinderbox handles a link in the form of an internal app URL differently to the way it handles a link in the more “traditional” style of a link to a webpage. It gets it right, more or less, in Text mode but it does not get it right in Markdown in Preview mode.
I have continued this conversation out of interest to explore what is happening. I have not continued it because I am enslaved to Obsidian nor because I do not know that Obsidian, Drafts, iA Writer and Tinderbox all handle Markdown differently.
Finally you might like to try using an internal URL on your computer to a document of some sort (with or without Hookmark) and see if Markdown in Tinderbox will open the app and then open the document. My “intuition” is that it will not. And that is what I have been talking about all the time.
My apologies if you read it that way—absolutely not my intent. I simply followed through the errors in the demo file as I found them which clearly led me to the wrong conclusions. that was what lead me to address intuition/norms/assumptions.
What derailed things was the test doc at the start of this had a Markdown encoding error caused by incorrect configuration of the note space. Unless that is resolved all else is moot, but I do think I’ve uncovered a bit more as to why pseudo-protocols URIs don’t work.
I’m not a programmer and just a Tinderbox user so why the WebKit view in the text pane doesn’t handle pseudo-protocols (or do open in new window), I’m not sure. But my understanding is that pseudo-protocols (for DEVONthink, Bookends, Hookmark, Obsidian, etc. are handled by the OS, not the web browser or, if they turn up in an HTML page, the browser looks to the OS (Finder, in fact) to try and resolve the link. That likely has some security implications so either can’t be done, or can but if so programmed with intent, IOW a new feature is needed (I think such has been already been asked for).
I had exactly the same thought—I used Bookends link—of using a pseudo-protocol URI (bookends://sonnysoftware.com/ref/books-2/45280). It works fine in from in $Text, not in Preview and it works if the HTML page is exported. But, the latter asks me to trust the Browser to open the target app (i.e. Bookends), there is a security angle. My hunch is the Preview window can’t (currently) ask the user the same security question so the link can’t be followed giving a silent fail. Opening a link on a new window, essentially means in the default browser, and I guess is a feature someone with the need will suggest.
I don’t think there is an easy fix for (accidentally) putting Markdown around a Tinderbox web link. There isn’t a setting to only suppress web link generation and so for both preview and/or export the HTML link has been generated before the Markdown parser sees the Markdown code and wraps this link in a further link (making it non-functional). I guess someone in the Markdown community could patch the Markdown parsers script so it doesn’t make a link if the offered UTL data is already a well-formed HTML link.
So two cross-cutting issues here:
- using Markdown with links needs the user to set up their doc accordingly. One insight from today is that whether via the Markdown prototype or some new ‘use Markdown for export setting’, ought to disable auto-detection of URLs via 'smart links ($SmartLinks) as that mixes badly with using explicit Markdown link mark-up. There’s no easy default, optimising for Markdown reduces utility for the general Tinderbox user. The smart links features was added so links in $Text works from text without having to use preview just to follow them. Today shows that one-size-doesn’t-fit-all in that regard, so setting up for Markdown-based export may take more care than might be desired.
- The Tinderbox preview pane doesn’t currently work like a fully fledged browser—and I think feature suggestions regarding that have already been made.
I’ve already made a number of small edits in aTbRef to address some of the new insights arising.
HTH