Global search for blocks with multiple keywords

Im not sure i understand you correctly, you mean ‘why global search cannot do this?’?

@GreenChocho: it is a feature request, I don’t want to make things more difficult. I was just trying understand the thinking, but it seems I am missing a point and am therefore making things difficult.

It is probably best to leave it at this. I want to thank you for your patience.

One of the example I could think of right now is if i want to collect a hypothesis statement relating to 2 constructs. Lets call them X and Y.

So my search will be: “Hypothesis” and “X” and “Y” (or regex equivalent of this search)

As all academic paper will contain “Hypothesis”, the current global results will return Note that contain X and Y

The current feature requests will give me a list of block ID for those Hypotheses.

Then I can use the “copy search results” function or the Text {expander} plugin to show all these results as embeds.

From this, i can see how many studies have explored direct effects, how many have explored conditional/mediating effect…

Or can you help clarify how I can explain clearer?

@GreenChocho

Example: if i got articles on “Team Diversity”, which have argument on team dynamics and team cognition.
But i want to find causal arguments on the relationship between “Team Diversity” and “team cognition” only, then the current global search function will not be able to help. I need to use the workaround specified in the 1st post.

How does block search make this easier than Global search?

Currently, Global search will not return the block/line results if you only search by keywords.

If you use the regex in the 1st post, then global search will return the block level results.
BUT you will have to click the “…and xx more matches” in each note to see the block.
Then you will need to manually create an embed (or use the WorkBench plugin) to send it back to your current working note.

IF this feature request is implemented. Then i can just use the copy search results function or Text Expander to gather all this block (block only, not FULL note) inside my current working note.

Possible operator:

  • scope:line
  • scope:innermost-block // useful when nested blocks are recognized
  • scope:block
  • scope:innermost-chapter
  • scope:h6-chapter
  • scope:h1-chapter
  • scope:chapter
  • scope:file // this is default now

Restricting scope at higher levels is already done by “path” and “file” operators:

  • path:“folder1/folder2” // restricts search to content of relative path like search in Windows File Explorer.
  • path:"/folder1/folder2/file3.md" // like above but restricted to one file
  • file:“file3.md”

But that is rather in another sense, matched terms still have to occur within the same file so “scope:file” is currently the upper limit for the scope.

Reference: https://publish.obsidian.md/help/Plugins/Search

Ability to nest “scope” operator in groups is desirable.
For example: “(term1 term2 scope:line) term3” to match line with term1 and term2 only in the files which contain also term3 anywhere.

scope:line would work also for table rows (like database records, although not distinguishing fields/columns)

EDIT: Partial implementation is now promissed in posts #30 and #33.


Another helpful behavior in this pursuit would be option to rank/sort search results based on closeness of keywords in the match.

2 Likes

@GreenChocho: OK, got it. The last paragraph makes the advantage of this FR clear.
Thank you, kind sir.

1 Like

I also enjoyed the discussion :smiley:

1 Like

My apologize if my tone sounds offensive. I didn’t mean it. Acturally I am so grateful that Obsidian team let me use such a great app for free. Also thanks for your advice.

tag:#idea -#done cannot filter the 1. balabala #idea, this is because the search is based on whole file not a block or a paragraph. So tag:#idea -#done give desired result.

You could try it by creating a demo.md file and copy paste these two paragraphs to the file, then search by tag:#idea -#done, you will find that the demo.md doesn’t appear on the result.

1 Like

test1

Hope this gif could illustrate what I mean.

The keypoint for a note taking software is how they consider the basic component. For Roam liked Apps, such as Roam, Dynalist, Workflowy, it is Bullet, which also called Block. For Obsidian, I think originally it is a File.

According to many user’s requirements, now Obsidian provides Block reference, so if Obsidian wants to change the basic componet from File to Block, then there is still a long way to go, Block reference is not the end point. Or because the limitation of Obsidian’s infrastructure, maybe the File still is the basic componet, which means Roam will not be it’s competitor. Unfortunately, many people still compare Obsidian with Roam.

As a free user who take advantages from Obsidian, I just hope a feature request could give dev team more information to consider their goal for a better notetaking app.

As I said before, if someone, especially someone from Obsidian team feels offensive because my tone, I didn’t mean it. I consider it is a contribution that posting some ideas to the forum.

Seems the gif cannot display correctly. Post 4 pictures here, hope it could help:




1 Like

nice illustration, explains itself.

1 Like

+1 on this. I missed this and created a duplicate thread (Search for lines matching query), but I like the additional scope defined here.

1 Like

+1 on this idea as wellll

It’d be great to be able to search for lines matching search terms rather than entire documents.

E.g., searching for Licat "- [ ]" would return:

// SomeFile.md
- [ ] Ask Licat about search per line

but would not return:

// SomeOtherFile.md
Licat said something
- [ ] Some unrelated TODO

This could have many uses, but personally for me it’d enable a TODO flow described here: How do you handle tasks in Obsidian?

3 Likes

Yes, please. This would be huge with the embedded search results.

I think you could then write a query that shows you incomplete tasks from the past X days and put that in your daily note template.

2 Likes

I have also requested for this. Would you like to add your support here too?

A line: operator will be introduced in an upcoming release.

3 Likes

If there are duplicate request, just flag them to the mods. No need to ask people to add their support and create duplications.

Will do.

section: and block: will be added too.

3 Likes