DT3 searching markdown footnotes fails

@cgrunenberg

Just noticed some extra strange behaviour. When I make a search targeting a text in the footnote, sometimes it does recognise it; other times it does not.

I’m attaching two screenshots that exemplify this. First I searched for Gibraltar and the term was found. Then I searched for Marinid (also in the same footnote text) and the term was NOT found.

Hopefully these examples will help on the issue.

We might add a hidden preference but you would have to rebuild the database afterwards.

That would be very helpful, Christian, thank you.

In the meantime, it would be helpful to have a full article on the implications of the changes, explaining exactly which elements of markdown files are no longer searchable, and whether this applies to all forms of search / smart groups / rules etc. E.g. At the moment, it’s not really clear what ‘rendered content’ means, and people are having to do their own testing. It would be helpful if there was a definitive statement.

Thanks.

3 Likes

Basically URLs of links/images (including the ones in the footnotes) and HTML tags. This effects all index based operations (search, see also, classify and concordance) and is actually intended to improve especially the results of these features and make them more consistent to RTF/HTML.

I seem to be able to search successfully for x-devonthink-item URLs, though. Regardless of the fact if they’re visible in the rendered file or not.

This might be possible if the files were indexed by older versions or if the link is part of the Markdown’s text.

It seems that it is also possible in other cases. In my Markdown file, I have this line:

[This is a DT-Link](x-devonthink-item://1E23F171-736F-4D63-9F91-376EA58CE131)

If I search for “x-devonthink-item”, I get this same file as one of the hits:

As you can see, the creation date is quite recent, and the last changed date even more recent (that’s when I added the DT link to the file).

Thanks.

But that doesn’t include Metadata, which are neither URLs nor HTML.

Is internal metadata searched for or not? There’s a suggestion up thread that it isn’t, but I seem to be able to do it fine. This is a search for journal entries on Fridays…

Is that because I haven’t (knowingly) rebuilt this database? Or is metadata in fact still searchable?

Secondly, as far as I can see URLs are picked up — a search for ‘https’ or ‘x-devonthink-item’ seems to work fine. (It’s the ‘seems’ which is worrying… are some being missed?)

Again, is this by design (you do search certain parts of links), or will this (helpful) behaviour go away if I rebuild the database?

So, I think we need a far more detailed explanation for the changes than a sentence or two in this forum.

At the moment, this is causing some people to query whether the searches they have made are accurate or not — rightly or wrongly. DT3 is built on the idea of robust searching — a change in that process needs to be fully and loudly documented, even if (especially if) the concerns are largely illusory. I’m sure you don’t take these decisions lightly, but the consequences and implications need to be explained properly.

Finally, please could we have a preference to turn back to the old behaviour soon?

Many thanks.

It should be. Otherwise try a rebuild or, if that doesn’t help, please post the source of the document.

Thanks, Christian.

So, as far as you’re concerned, Metadata is searchable and will remain so?

That’s a relief, but it only underlines my point — someone coming across this thread will be 26 posts in before they get that confirmed.

BTW: it seems to go against the idea in the Release notes and earlier in the thread that only rendered text is searched — or it uses a definition of rendered which some will not have expected (does ‘rendered’ mean shown on the screen or not).

It seems to me that at the least help files need an explicit note in both the markdown and Search sections listing the new restrictions (not just saying ‘rendered’ as that’s open to interpretation). Apologies if it’s there, but I couldn’t find anything.

An article in the regular feed would also be helpful — if you’ve been using markdown search successfully for years, it’s unlikely you’ll check the help.

Thanks!

2 Likes

At least there are no plans to change this right now.

Are you saying metadata should still be searchable?

I can’t search metadata since DEVONthink 3.5.1.

metadata: findMe

### Test

Text

I’m sorry, I shouldn’t handle too many things at the same time :slight_smile: But metadata is indeed currently not indexed like links.

No problem, you can be sure that I’ll point out that it is not searchable :wink:

Please make it searchable again, I really need this.

The next release will include a hidden preference.

3 Likes

THANK YOU CHRISTIAN!

:smile:

2 Likes

Hang on, now I’m really confused… The position seems to be changing and I can’t keep up.

Please can we have a definitive statement:

  1. Can we currently search markdown files for metadata: i.e. data at the beginning of a file with the form Keyword: Data. Yes or no?

  2. Are words within markdown links in the form [title](url) searchable or not? E.g. can we search for all items which contain say ‘https:’ or ‘x-devonthink-item’ within the (url) part of the link? Yes or not?

  3. If the answer to either is No, then why can I find examples of both where the search definitely works? Is it because my databases haven’t been rebuilt yet (I assume)? Will I lose this behaviour if I do rebuild them?

The problem is, forum threads really aren’t a good way of getting accurate information out about this sort of issue: that’s why it needs to be addressed in one place as a specific, definitive response to which people can be pointed.

Thanks again.

1 Like

No.

Only the title is indexed.

1 Like

As I said before: At least here x-devonthink-item URLs_are_ found. So they’re presumably indexed, too.

It’s possible that this was indexed by older versions. How does the source look like?

Cf DT3 searching markdown footnotes fails - #24 by chrillek

The MD source looks like this:

<style>
.class_open::before {
  content: '\25A1 ';
}
.class_closed::before {
  content: '\2713 ';
  color: green;
}
h2 {
color: #f00 !important;
}
</style>
## Headline

Normaler Text

> Blockquote eingerückt? Auch noch in der zweiten Zeile, die dafür allerdings lang genug sein muss, damit der Text umbrochen wird.

Normaler Text

[ ] task 1
[x] task 2

[This is a DT-Link](x-devonthink-item://1E23F171-736F-4D63-9F91-376EA58CE131)

And just for the record: This file is also found if I search for class_open, which is a part of the style element and as such certainly never “rendered” (in the sense of being even remotely visible). Not that I mind it being found, but this seems to further muddy the decision what is (not) found.