Wikilinks not made for names that begin with @ – could this be changed?

Very similar to a recent question, I’m trying to find a way to use wikilinks when the name of the destination document (or its alias) contains a leading @ character. In my case, I’m attempting to add aliases to the PDFs of academic papers, such that the alias is of the form @name2021something. But in my tests, DEVONthink 3.7.2 does not make wikilinks for names/aliases that begin with @. It seems that other leading characters also prevent wikilinks from being made, including +, _, and # (although that last one I can understand might be problematic). This limitation does not seem to be documented in the DEVONthink manual or the MMD syntax documents. It brings the following related questions:

  1. Is there a reason for this behavior? Is there something that relies on wikilinks having only certain leading characters in order to be recognized?
  2. Could the limitation be relaxed for leading @ characters?

I’m basically in the same situation as @lyndondrake who asked that question for the same reasons: being able to type [@something] in my notes would be a massively convenient way to link notes, while simultaneously making the Markdown source compatible with the citation-processing features of a popular external Markdown processor (pandoc). And it seems like it would not require anything special in DEVONthink except for allowing @something as a name recognized in wikilinks.

(Heck, I would not even mind typing double square brackets, i.e., [[@something]], if that’s what it took, and post-processing the resulting files, but currently even that syntax doesn’t work.)

Currently the Names & Aliases option requires alphanumeric characters at the beginning.

That works fine using the latest internal build, therefore if it shouldn’t work yet then it will soon.

1 Like

I am genuinely excited by this possibility and look forward to the next release!

I realized this morning that I’m unclear about some things:

  1. Does the upcoming change mean that single brackets will no longer prevent automatic wikilinking (thereby also resolving @lyndondrake’s request), or will only double square brackets work?
  2. Will this also work if there is additional text inside the brackets, such as [see @Foo2021something, p. 23] and [@Foo2021something; @Bar2021other]? Or will it only be for the limited case of (e.g.) [@Foo2021something]?
  3. Is any of this affected by whether the document alias has @ in it? I.e., is the expectation that the alias is Foo2021something, or must it be @Foo2021something?

Double-square brackets will be still required and the complete text inside the brackets must match the name or alias of an item.

Is there any chance that this might be altered, at least optionally, to accept Pandoc citations? No worries if it’s not going to be added - it would be helpful for me to know though in terms of where I build up my note base. At the moment I’m fully in DT, but the citation links are pretty critical to me and so it’s not pressure to add this to DT as I realise it’s a bit of an obscure feature, more just a steer for me as to where to go on this

There’s always a chance (depending on feedback) but there are no such plans yet.

I did some more exploration on this front. The MultiMarkdown syntax used by DEVONthink defines a meaning for plain [something] typed in a Markdown document. This is explained in the MMD user’s guide – here’s the example used:

In order to create valid [HTML], you need properly
coded syntax that can be cumbersome for
"non-programmers" to write. Sometimes, you just want
to easily make certain words **bold**, and certain
words *italicized* without having to remember the
syntax. Additionally, for example, creating lists:

* should be easy
* should not involve programming

[HTML]: http://en.wikipedia.org/wiki/HTML

This is just speculation on my part, but I think the reason that automatic wiki linking to names & aliases don’t work for a bare [something] (which is what would be needed to make [@anything] work to reference another document) is that the parser in DEVONthink is designed to support the MMD meaning of [something]. Obviously I don’t know the details of DEVONthink’s implementation – so this is just some annoying second-guessing on my part – but perhaps the parser switches from looking for external documents to looking in the current document for the target reference when it encounters a bare [something]. In any case, the need to support this MMD functionality would explain why DEVONthink doesn’t link to another document upon encountering [something] or even [@something].

Just speculating, but supporting [@something] seems like it would require one of the following:

  1. Extend the syntax such that [something] is defined to link to another document if no definition for [something] is found in the current document and something exists as the name or alias of something elsewhere (and automatic wiki links are enabled).
  2. Switch behaviors if the next character after [ is not alphanumeric, and assume that the destination is outside the current document. This is made difficult by the fact that MMD already defines meanings for [#something], [^something], and [%something]. But, one can imagine defining [@something] to have the definition "link to an external document whose name or alias is something".
    3. Define a (new) syntax for @something that works anywhere in a document (not just inside square brackets), to mean "link to an external document whose name or alias is something". In this context, it is worth noting that @something does not have a definition in Gruber’s Markdown or in MMD (as far as I can see), so at first blush it seems like this would not collide with other Markdown syntaxes. Still, it would probably be a good idea to put some limitations on this, such as that the @ must not be preceded by an alphanumeric character, to avoid triggering in cases like someone@gmail.com, and of course it would only make sense for MashedWords names or aliases and not for names/aliases having multiple words.

IMHO option #3 has the most potential. It has some similarity to syntaxes in (e.g.) online forums like this one, where @person is a way to link to a person’s handle in a discussion. In addition, it would solve another problem for people trying to do Pandoc-style citation syntax, which is that the syntax actually defines more than just [@something]. Indeed, I often cite more than one reference at a time, and would find myself wanting to type [@Someone2001; @Another1989] as well as the unbracketed form in contexts such as in their 1990 book, @Someone1990 wrote blah blah blah. If DEVONthink supported @something as the linking syntax, then all of these other forms would work, and at the same time, for people who never heard of Pandoc or used citations, having the option to type @something as a way to make a link might seem kind of natural.

Still, option #3 would require changing the single bracket MMD interpretation to be overriden if the text inside the square brackets could be interpreted as a @something style link to another document. (Otherwise, we’re back at the problem that [@something] doesn’t work.) This may or may not be easy to do, depending on when in the software pipline the interpretation of @something had to be done. If it came after the MMD parser did its work, then it might not be too bad to implement.

Well, duh, I just noticed #3 is not different from what DEVONthink already does: if something exists and you type @something, it links the something part already.

So, never mind. The problem really just boils down to the way single brackets turn off wiki linking, which is what @lyndondrake wrote about in the first place.

Haha! That’s quite a bit of self-redaction :wink:

I think part of the situation is adding support for pandoc syntax, something we don’t explicitly do as it’s yet another variation of Markdown, not part of MMD. And you are astute in the observations about MMD’s existing link uses (which are very useful in their own right, for sure!)

Yes, that’s the frustrating bit for me - it’s so close to what I’m after, and yet so far :slight_smile:

But, it’s the best variation of Markdown around :slight_smile:

1 Like

Well, that’s certainly subjective. :wink:

1 Like