Just wanted to share some thoughts on wiki links and the fact that their color is almost indistinguishable from that of regular item links.
This may be a matter of personal preference, but isn’t the assumption that wiki links have very different meaning than item links? Typically it would be a matter of potentially relevant relations versus a “hard-coded” connection to some other database item.
Based on this use of wiki links, which I’m assuming is the most typical one, I think there is some validity to the argument that they should also be clearly visually distinguished.
Perhaps there could be a global preference in the settings to determine the color?
I wanted to follow up here to ask if this is something that might be considered.
Perhaps there could be a preference allowing users to specify the color of wiki links. Then everyone can choose as per their needs whether they would like them to be distinguished from regular item links or not.
Apparently nothing has changed more than one year later
While I understand the developer’s concern about overcrowded setting panes, which has been expressed many times in this forum, I also hold the belief that any application intended as an all-in-one solution of something (working with text documents in the case of DT) should offer more customization options whenever convenient.
So here’s my proposal: Add a special CSS class selector for WikiLinks when rendering markdown into HTML.
Currently all links in markdown are rendered into the simple format
<a href="some://link">some text</a>
It would be great if we can have DT automatically generate a CSS handle like
If the Wiki links do not contain x-devonthink-item or are somehow systematically different from item links, you could perhaps use an attribute selector in your CSS. I don’t use these links, so I don’t know what they look like in HTML.
That’s exactly the issue here. The DT manual explicitly states that WikiLinks are not item links. However there is apparently no difference in rendered markdown. For example,
[孔子](x-devonthink-item://014A48AC-83A5-42EE-9EDC-407DC3D43472) and [[孔子]] are both rendered as
In my use case, WikiLinks and item links do serve different purposes: the former for my notes, the latter for reference in a different database. Therefore it makes sense to separate both by color, which unfortunately is impossible if the links are indistinguishable.
For the time being, I resort to putting all reference links in footnotes, but it kind of defeats the purpose of markdown in the first place. That is, to write continuously without having to jump elsewhere just to format the text.
Yeah, I’ve seen that too in the meantime. And as both “types” of links end up being the same, you could use a class to mark your item links, i.e. (something)[x-devonthink-item://UUID class=“linkclass”]. That works just fine.
The purpose of a link is to bring the reader to another place (either in the same document or in another one). If they click on it, they’ll see the target document. If they don’t click on it, why is it important to know where this document resides?
And what about item links in the same database? Do they need another color, too?
I find it quite obvious that Wikilinks and item links are both rendered as the same. What else would a Wikilink be rendered too, given that it has to point to an object inside DT?
No offense but that is a quite simplistic view on the purpose of links.
DT is capable of creating WikiLinks automatically. These links serve as suggestions of potential connections as well as being actual portals. When I manually add item links, on the other hand, the connection is always clear and intentional.
In my workflow, WikiLinks are “internal” connections to my own thoughts, whereas item links are “external” connection to other’s work. Differencing colors makes it much easier to generate a mental picture about the standing of my idea inside a tiny part of the philosophical world.
As I have mentioned, it is stated in the DT manual that WikiLinks are not item links. The difference, per design principles, should be consistent across the document, which means they either appear differently or have the potential to do so.
In any way my proposal should not be difficult in terms of implementation or disrupt existing workflows; WikiLinks and item links would still look identical otherwise configured.
Some of us prefer keeping things simple. Some prefer working their way through things. CSS selectors are built by design to meet both needs
I can’t speak for the DT manual. But technically, a Wikilink must be rendered as an item link in HTML (talking about the href here, not the appearance). There’s no other way to make it behave like it should in the HTML. And using a class for item links in your MD makes it possible to discern the two.
You’re right that there are user-side HTML-in-Markdown workarounds. (Of course you can do anything with HTML ) What I’m requesting for, on the other hand, is an application-side, native solution that fulfills, among other things, another promise given in the official manual, as quoted below:
WikiLinks are specialized links
Which to me means it’s WikiLinks that deserve special CSS treatment, not generic links as is in your proposed workaround. So it would be desirable if a class is automatically added to WikiLinks by the markdown render engine, instead of being manually added to all other links by the user or their scripts.
The existence of workarounds does not negate the need for change. Which is why markup languages, Markdown included, and applications to process them exist and continuously evolve.
it is stated in the DT manual that WikiLinks are not item links
That is correct, regardless of the underlying implementation.
Item links are purposefully added links to specific items.
WikiLinks are dynamically generated and can appear or disappear with the changing of preferences. Their meaning is subjective.
WikiLinks in Markdown are not necessarily item links. A conversion to HTML would obviously have to produce valid HTML links. A ≠ necessarily B. While it definitely seems to be the case, @cgrunenberg would have the authoritative word on this.
While not creating true WikiLinks, @chrillek’s suggestion of applying a class to an item link isn’t too burdensome IMHO.
And it can be scripted, too.
As to “is a wikilink an item link or not”: It’s not in the MD. It is in the rendered HTML, though (and must be, since the link has to point somewhere, and that’s a DT document in this case).
Thanks for the suggestion, @chrillek . I already have a keyboard shortcut that adjust the link text upon pasting into DT. I can easily modify this shortcut to apply a class, if I so wishes. And a yet-to-be-created script could apply the change to all preceding MD notes.
From a “puritan” point of view, though, using HTML in MD for cosmetic purposes opens a pandora box. Should I also give logical indicators like because and therefore a different style (a script could do that)? Why not distinguish blocks of facts from opinions (a keyboard shortcut could do that)? And so on.
That was exactly my mindset when I was using Obsidian. It prevents you from getting your work done, as others have documented in this forum and beyond. The frustration of using Obsidian was even a major reason why I purchased DT!
For the time being, I’m committed not to introduce any HTML in my MD notes. This attitude might change in the future but certainly not now.
Just want to point out: The likes of Obsidian and Logseq gives one or more specific CSS class selector(s) for each one of their own feature / implementation of MD. Looks like a sensible approach to me.
DEVONthink is the best money I have ever spent. It’s a special feeling that DT itself is “growing” along with me the user
Dredging the sea floors is not a good solution to the battery shortage problem. Especially so when you know that there is something of importance in the deep sea that will be lost in the process.
HTML in MD is functionally the same thing: Do whatever is possible to get what you want, the environment be damned.
HTML has explicitly been allowed in MD from the beginning. Simply because MD was invented to make producing HTML easier, but not to replace it. You don’t have equivalents for section, main or aside in MD, for example. Or even detail/summary. And several MD dialects added dimensions to images – how else would one be able to size images, as you can’t target them individually with CSS?
As cute as your analogy seems to be, it doesn’t make any sense at all in this context.
That is not exactly true. Markdown was in fact invented to be easier for human readers/writers than HTML, as is documented in the Wikipedia page for MD. That means the MD environment, which by design is writing-oriented, is not the same as the free-for-all HTML environment.
A few popular implementations of markdown make popular the notion that a fair amount of HTML benefits aesthetic purposes. That is probably not originally envisioned in the founding principles of MD. And DT is certainly not one of those apps.
Sir, you keep saying that it’s possible. I’m insisting that it’s a less-than-desirable solution to the problem. Apparently we both make sense and none at the same time. On a side note, perhaps you can see the similarities between our engagement and the ever-going quarrels between capitalists and environmentalists, which only reinforces my analogy
)
