Markdown and store image

Good points. That made me realize that I’m probably not really expressing well what I’m after. Indeed I should not tell the md crowd or devs what to do for the sake of just md. As a standalone tool, say the quick and dirty notes you mention, I can take it or leave it. And hence, for outside DT, my go-to quick and dirty note tool is Apple Notes. It could be Draft. You name it.

But once a format is adopted within a larger system, then format choices will go away. Let me try to illustrate that:

Jupyter devs chose md as their rich-text format. Great, especially with embedded LaTeX math, it’s very handy. But my use case to make powerful Jupyter documents for my research makes good (i.e. painlessly easy to use) image usage (and also tables) a must. Other than Mathematica there is no other tool out there that would do the job. So all those “tons of formats that can handle images just fine” become irrelevant. I’m chained to md because of Jupyter.

Now, in DT, the use of md docs is not mandatory, but it is compelling. An editable document format is particularly useful in DT when it is

  1. indexable
  2. viewable within DT (ideally natively, but at least with a preview mechanism)
  3. editable within DT (for fast workflow)

(text, rtf, rtfd, formatted notes, md) fullfil all 3, whereas Pages and Word fulfill (1), (2) partly, but not (3). Md is in my view the best of the first group, and so, for a DT user, it assumes the de facto role of the most capable, most future-proof (cf. rtf) internal document creator/editor/viewer. And that’s why many people clamour for certain features in it. At that point, the history and philosophy behind it take a back seat. People notice that it’s a cool format, and so close to doing what they want or need. And then they notice that in mmd, a lot of features do eventually show up, so it’s not that devs are very principled either. That at least partially excuses why people suggest features.

The introduction of image assets in DT md, either by dragging a file in or by pasting an image, was a game changer to me. I still would not mind at all the ability to scale the image, but I understand that that’s beyond DT, without breaking md compatibility (unless they spearhead another mmd flavour).

And I was then particular excited to find that I can collect all my image assets in one, x-item-referenced, location, which makes for my use case (and only mine!) the use entirely foolproof. I hindsight, I should have just pointed out the ability to put a slash in front of the asset folder name to make the location absolute. I should have abstained from remarking on the (factual) non-universality of the group-based location, which has its own advantages, as was pointed out.

2 Likes

Thank you very much for this thorough assessment. Although I’m not happy with it, it describes the situation quite accurately.

Also, I learned a lot about Jupyter notebooks –thanks for that, too!

As to „scalable“ images: why not use CSS for that? But you’ve opened a new thread for that,
so I’ll head over there.

When I move the markdown document, I got this error in the log:

“Smart Rule: Couldn’t find the moved record’s old "Assets" group”

The image in the markdown document is not moved. The markdown document now has a broken link, image not displayed.

Under Preferences Files > Markdown, I have Set the location to /MyMDImages

In the script, I have also change the property theImageDestinationLocation : “/MyMDImages”

Is there anything else I need to change?

Just an update of my observation. It seems the problem is that the image is not an x-devonthink-item link due to my md file is at the root of the DB.

More details here:

Indeed. @pete31 pointed that out. I would not have run into this problem as I never put documents at the root level. From @cgrunenberg 's explanation, this effect is hardwired into DT and we cannot influence it.

I am curious why md file at root level cannot create x-devonthink-item linked image? I have many md files at root level with x-devonthink-item link. I manually import the image. Copy the item link and Paste the item link.

It is not a question of whether it can be done. It’s a judgement call by the devs when to choose one or the other. As @cgrunenberg explained above:

Currently the used link depends on the location of the image and the document - if possible a relative link is preferred as that’s more compatible to other apps.

There are advantages to regular paths/links: They can be interpreted straightforwardly by other apps. So for example, if I want to use Typora as an external md-editor, it will not be able to make sense of the x-items. Any technique that relies on x-item links must be understood to only work within DT.

1 Like

Ok. It makes sense to make it more portable, more usage for other external app to use relative path.

I thought that has already been covered if you use a name, such as Asset, without the \. You will get a relative path.

For those who wants x-item, you have to use \. That will generate x-item link, except at the root level. So, question is why exclude md file at root level?

For one, this is a DT design decision, so I can’t really answer authoritatively. Having said that, I think the decision made by DT is not “absolute vs. relative path”, but rather “is the resource in a subfolder or not”. Documents put at the root level are special in the sense that any other document (other than those that are also at the root level) will by definition be in a subfolder (even if by more than one level).

We might add a preference to choose the desired behaviour if there should be a common need for it.

1 Like

Will appreciate if it can be added as a preference. Thanks.

I just found out that this search condition is not working. The Content: ![ will find match all resulted all Markdown file. In fact, I find using just Content: x-devonthink-item:// also does not match the correct Markdown file.

How should we redefine the search condition?

The query is actually invalid as matches (EN) or stimmt überein mit (DE) conditions use the alphanumeric search index.

What about just simply Content: x devonthink item? Somehow, it still cannot find the file.

But this search (x devonthink item) works in Inspector search.

DEVONthink doesn’t index the raw source without enabling the hidden preference IndexRawMarkdownSource.

1 Like

I have enabled the hidden preference. The search work on all newly created Markdown file after the enabling of the hidden preference. Those old Markdown file created before the enabling seems not indexed. How can I force a re-index for those old Markdown file?

Rebuild the database, see menu File > Rebuild Database.

From help:

Rebuild Database: Completely rebuilds the database by exporting all items to a temporary folder in the file system, creating an empty database, and reimporting all items. This removes any structural problems. Depending on the size of your database, this can take from a few seconds to several hours. This option is typically only used in a troubleshooting situation.

Thanks. It works.

1 Like

Thanks for making this in 3.8.6. Now, all my images, copy&paste, drag&drop, are all in x-item link, even for Markdown file at root level.

For the Import images to group, would it be possible, in future, for us to select which database, which group/folder/level?
Screenshot 2022-09-30 at 8.41.02 AM

As the images are all Item Link, it is no longer important that they reside in the same database as the Markdown document. In fact, I have created a separate database just to house all the images, at root level.

2 Likes

I support this as well. I have quite a few HTML files in different databases that link to images in a single database. The only reason I am considering Markdown is the inability to edit HTML on DT2G. I would really like a simple mechanism that allows this.

Thank you.

Michael