Search for Tags in Notes starting with "...-" using Search (not Notes) Tool

1Cor10 31

Hi everyone,

I have an hierarchical system for creating Tags with “-” being used to build the hierarchy. For example, one of the Tags is “Trust God-” I want to bring up all notes with Tags starting with “Trust God-” using the Search function in order to edit some of the Tags. [Note: There is a “-” at the end but not the beginning.]

I am not interested in using the Notes => Filters to do the above for 2 reasons:

1) With Notes, it shows only a few entries matching the Filter at a given time and have to hit “More” to see the full list (even then, only 100 is the max)

2) Once you pick one selection and then go into the Note to edit the Tag, you can’t get back to the starting point to edit other selections without multiple clicks. But with Search, the search results never go away. You keep clicking each of the search results one after another to go through the whole list. So many clicks avoided when using Search. Also with Search, it also groups the Search results by Notebook, which is also super helpful.

Any help would be super appreciated. Thank you.

Francis

@1Cor10 31 I am not sure what your question actually is. Can you elaborate please?

1Cor10 31

https://community.logos.com/discussion/comment/1370463#Comment_1370463

@Francis

Sorry for making the question more confusing than it needs to be. So let me start again.

I have many Tags starting with, say, Trust God. For example, possible Tags are Trust God-Defn-X, Trust God-Why-Y, Trust God-Consequence-Z etc. I would like to use Search function to get all the Notes containing these Tags.

If I were to write a computer program, I would ask it to grab all Tags where the first 10 characters are “Trust God-”. How would I accomplish this using Search function?

Please let me know if I am still being vague.

Thanks

Francis

Normally, a mytag: search in Docs using quotation marks will do just that. For instance, in the example below, the search "mytag:"Jesus, Deity" will find notes tagged with "Jesus, Deity of."

1Cor10 31

https://community.logos.com/discussion/comment/1370550#Comment_1370550

Thanks a ton, Francis. The quotation marks makes all the difference! I have some closure on this issue.

But I started digging around. So I started comparing the Search results with and without the quotation mark. I’m trying to understand how Search works by doing this comparison. I found it identified Notes where the word “God” is not even in the Tag. Only the word “Trusting” was is in the Tag. I wondered how it could have picked this Note. As it turns out, “Trust” and “God” are in the Note but not in the Tag. This seems odd, isn’t it? Doesn’t “mytag” Search search only the Tags?

Francis

Although this concerns searching library filters, one would infer that it should be so for doc searches as well:

You might want to report as bug.

1Cor10 31

Thank you. Is there a formal way to report a bug? I've never reported one thus far. Happy to do that.

Andrew Batishko

I’m trying to understand how Search works by doing this comparison. I found it identified Notes where the word “God” is not even in the Tag. Only the word “Trusting” was is in the Tag. I wondered how it could have picked this Note. As it turns out, “Trust” and “God” are in the Note but not in the Tag. This seems odd, isn’t it? Doesn’t “mytag” Search search only the Tags?

When you put mytag: in your query, it's going to search for the very next word or phrase in the tags. Anything after that is treated as a separate term in the query, which by default is just searching the content. And by "very next", I mean exactly that. If you have a space right after mytag: it will interpret that as an empty tag.

This means that mytag:Trust God is searching for Trust in the tags and God in the content.

If you don't have a closing " then it's invalid syntax, and the behavior is not well defined. It might treat it like the opening quote doesn't exist, or it might treat it like mytag: doesn't exist, or it might do something else entirely.

So, as far as I can see, there's no bug here. It's working as expected.