Markdown and store image

DEVONthink
19

@chrillek: I’m sure you’re right. I’m only vaguely familiar with the beginnings of Markdown. Wiki languages like PmWiki came along for a similar reason. The verboseness of html is in that sense very unfortunate. Same with TeX/LaTeX and Pascal. You can only deal with that many “begin{something}” (I write a lot of LaTeX). Nevermind, there are good reasons for doing it that way, so I won’t knock that (who am I to knock anything that Don Knuth has ever done).

Just as an example, PmWiki, which is also just a front end to rendering html, shows that it’s rather easy to go all the way. At the user level, it makes it entirely transparent whether something is a html element (strong/emphasize) or something coming through CSS. It just works. Now, while this has not been done to my knowledge, someone could write a PmWiki-markup standalone renderer for DT, Typora, etc., and it would function the same way as md, and it would be rather complete in its ability without having to resort to unbearably verbose html/css constructs inside your documents. I was under the impression that one basic tenet of these markup languages is that the un-rendered ascii text source is still human readable, which html and TeX are decidedly not. Markdown and PmWiki markup are, but Markdown with too many html constructs thrown in (like in my Jupyter notebooks) isn’t.

Inside DT and similar settings, md seems to have taken on a slightly different role, namely that of a portable, nimble format for (semi)rich documents, filling the remarkable void between plain text notes and full-fledged Word level stuff. For that purpose, it seems a bit underpowered, in my opinion, which no one has to take seriously :slight_smile: .

20

That’s one of the reasons I never got around to using (La)TeX – too much to type (that, and the penchant for american typographic conventions). Also, (La)TeX is kind of a hybrid language, since it deals with presentation and semantics at the same time.

Correct. HTML is readable (kind of), but it’s certainly not fun to do so. And, interestingly, Word, Pages etc. all use XML now under the hood – i.e. a human readable format (after you’ve unpacked the ZIP archive they use to hold everything together). Not that any human in their right mind would want to read that :crazy_face:

That is apparently the perception of many people. At least here – I haven’t seen the same kind of discussion in the context of Draft. In some enviroments, there seems to be a tendency to bend this format to perform something it was not meant to. Like the endless discussions about images: There are tons of formats that can handle embedded images just fine. MD is not one of them. It was not designed to be. In my mind, note taking is something quick and dirty (I’m not talking about the content here) – it’s a note, not a full fledged article. But it seems the borders between different forms of text are getting blurred.

1 Like
21

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
22

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.

23

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?

24

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:

25

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.

26

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.

27

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
28

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?

29

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).

30

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

1 Like
31

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

32

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?

33

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

34

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.

35

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

1 Like
36

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?

37

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.

38

Thanks. It works.

1 Like