Add option to automatically transclude the results of embedded query

[datum]

Use case or problem

The embedded search block does not allow for embedding the results like the link notation ![noteName]. This feature could be extremely useful because it would allow for a note that is a consolidation of notes automatically selected by search criteria, yet rendered as one complete document. Future notes meeting the criteria would automatically be added, without the need to touch the consolidation note.

Proposed solution

Allow an option to embed the results, perhaps through a reserved identifier. For example:

```querye

Thus querye (instead of just query) requests an embedded result.

Current workaround (optional)

Related feature requests (optional)

[elwee]

This would be extremely useful to reduce the amount of time spent organizing notes as well as reducing the number of notes in general.

For example, I like to keep my morning pages in a section of my daily note (keeping them separate would mean creating around 730 notes per year). Instead, if I only want to see my morning pages, I could just create a note like this:

with each morning page embedded of course. The search query could be restricted to specific date ranges for performance. The embed could, for example, include anything until the next same-level (or greater) heading. So embedding a level-2 heading would include all the following level 3-6 headings.

This feature would also partially help with this other feature request: Continuous chronological feed of the Daily Notes

Instead of using ```querye, I would prefer a (persistent) toggle button and I would place it next to these (currently missing) buttons:

[I-d-as]

I was so happy to see this request already exist!

I think this feature would be so crucial helping those of us who work on a meandering path quickly and effectively get started on complex tasks. I often like knowing I have the materials available and accessible to me and with this I could quickly create notes that get a certain system in place without having to fully populate it first in order for it to make sense later. I could start a couple of them and it would later be clear to me where I was headed despite whether the query search returned the results I clearly was looking for yet.

For example, if you know that there is a certain concept in your vault that is applied within various contexts and has yet to be identified or organized, you could create a note with one of these truly transcluded queries searching for a tag of that concept even though those notes and/or MOCs and/or compilations of embedded examples have yet to be developed. To get going you could create a few different flavored compilations of embedded headings from other notes where a specific flavor of that concept occurred. The goal in this workflow would be to avoid tagging the large source notes with the tag and hurting the focus of the embedded query. Instead you would quickly flesh out these comp notes and they would embed and also direct you to the source without complicating vault. You could nested tag the Concept/element and then hunt down the locations that occurs, silo them into headings within their source notes and embed the heading in that specific flavor (element) based concept comp notes which would get the tag (that the query searched).

It is besides the point, but you could even quickly do this for several other concepts and sub elements with the plan of embedding the query notes within a composite note itself.

It may feel kind of hacky and go against the best practice of permanent vault organization, but these are not for that purpose. These are for building something new out of pieces of the pieces that already are organized within your vault, and doing it quickly before the flow and energy has passed.

It would be particularly cool if you could link to these query results from within note, so as to again avoid complicating your vault and graph. With that linking, you could to add some commentary at the top of your composite notes about some of the query results transcluded below while actually pointing to them. For example, you could write commentary relating a couple of the query results you know would be shown below in preview mode and actually link to them in note as if they were headings within the query block.

Sorry for the length. I will edit down for clarity and probably eventually create a focused feature request for this ability I mentioned at the end, but I wanted to at least demonstrate a strong interest in this feature with specific possible workflows that it would make possible among the much more obvious ones.

Thanks.

[desk7]

I have a similar problem. I made an embedded search for searching words in line: but I can’t see the whole line in the search results.
I think that it could be added a reserved option (eg expanded:on) that will expand in search results (in particular in the embedded search results) the text in this way:

• if you search by line, it will show the whole line
• if you search by block, it will show the whole block
• if you search by section, it will show the whole section
• if you search by block, it will show the whole block

What do you think?

[elwee]

Yeah that seems like a nice elegant solution!

[elwee]

I really hope they will consider this feature request because it would be a real game changer.

Perhaps one of the reasons why it is not more popular is that the title is a bit cryptic.
“Transcluded query results” would perhaps be a more fitting title and draw more attention, what you think?

[GreenChocho]

Use case or problem

I think the new line/block/section operators for search is wonderful!!!

I would like to suggest to add the line/block/section function to copy search results (in addition to the current function returning the [[Notename]]).

When the user use line operator, the “copy search results” would generate block ID for each line matched (if ID already generated, then use the current ID), then show that in the “copy search results” modal.

For example:

• Search for line(termA termB)
• click on Copy search results, the results would show: [[Note1#^1st_line_matched]], [[Note1#^2nd_line_matched]], [[Note2#^1stlinematch]]

[JAG]

I thought that the line/block/section syntax was going to be used to return the line, block, block or section that meets the query (which would be super useful). This would be an alternative to that functionality.

[andypassion]

That would be very very very very helpful!!!

[elwee]

Another use case for this feature could be consolidating tasks across the entire vault.

Suppose you have several todos scattered throughout your vault. You could create a new note with an embedded query searching for todo items. This feature would allow us to embed all todos in a single page, separated by file name or block title.

Similar to this picture (source):

Now, I heard there are plugins out there which mimic this particular use case. But this just goes to show how many possibilities this primitive feature would unlock.

[ReaderGuy42]

Has there been any update or workaround on this?
This would be great!

[bhickta]

Great feature to have

[Jppm]

I support this one as well, feeling it can be a game changer in terms of tool putting it even in front of the best on this query & backlink aspect

Indeed a major use case is to build list over time. To take an example a list of books to read. Instead of maintaining a page for these I could simply enter them in the daily note (or in whatever other pages) , create a “query note” for these and **have the ability to edit this note **
The benefit of being able to edit would be to assign new categories or reorder the various items . Again in my example let’s assume I have book to read 1/2/3 I could have a reorganized query note with
**Urgent to read **
Embedded line book to read 3
Embedded line book to read 1
**Less urgent **
Embedded line book to read 2
Whenever I have a new book to read there could be some additional section with new …
Benefit of having embeds / transcluded is that 1/ reduce a lot the time to build index and moving info from one place to another , just by creating query notes rather than having to copy paste constantly
2/ ability to use the block in some other place with the same mechanism for instance in the “stuff to read” page or any other

I feel plug-in today concentrate on these aspects for TODO but the issue is the same aka ability to consolidate and filter and reorganize how you want certain list that otherwise leave elsewhere

I hope I bring some clarity to the topic and use cas me here .

[vincentt]

Is it possible to show more context on the embed query block?

[scwunch]

+1 for the idea of expanding context based on search-specificity
(And if I was allowed to do +3, I would do that too.)

A slight snag I can see with this plan is that the default is to search the whole file… but you wouldn’t want to follow the natural extension of your logic and show the whole file in that case.

[IDtheTarget]

This would give me exactly what I need for my health journal. Then I could pull the blocks that are of interest to each of my doctors without giving all of them information they don’t want.

[benbo]

Really wanted this feature too. After fiddling with a few ideas, I came up with a workable solution using regular expressions with the core Search plugin. As an example, this is how I extract all my gratitude items from my Daily Notes.

1. For each text block I want to transclude, I start it with a header.
   Example: ### Gratitude
2. I mark the end of the text block with an empty line.

Below is query code. It’s pretty cryptic so let me break it down:

(/(?<=^### Gratitude)[^]+(?=\n\n)/)

• The first part of the regex means look for the “### Gratitude” H3 header, but don’t include it in the match. The latter is known as Lookbehind Assertion.

(?<=^### Gratitude)

• The second part of the regex means match everything until you see 2 consecutive newline characters, but don’t include the newlines in the match (Lookahead Assertion).

[^]+(?=\n\n)

Here is a screenshot of the search results.

If someone can tell me how to create a custom CSS that removes the yellow hightlight, that would be sweet.

[elwee]

It is now but:

1. It is extremely glitchy. If you have a moderately long list of results and click on the arrows to show more context for an item positioned deep down in the list, then the view will suddenly jump back up.
2. The context is not fully rendered, at least as of version 0.12.x. I would expect at least some primitive features like todos and basic formatting to render properly like in Roam and Logseq.
3. You can only show more context on a per-item basis and if you close the file, you have to manually restore everything item by item.

In my opinion query blocks could have been Obsidian’s most powerful feature but it does not look like the developers have any intention to improve on it anytime soon.

With a minimal note structure (made easy by templates) and full-featured query blocks it would be possible to solve most content management problems without having to rely on manually-curated MOCs or waste time on other organizational tasks. While plugins like Dataview partially solve some of these issues, it is always possible that development of such plugins suddenly stops. So native query blocks would be a safer bet for most people.

[hy2play]

Thanks for your regex idea. Solved my problem.

And I use the below custom CSS to remove the yellow highlight, as well as the header text and icon. Hope it helps.

/* Hide the query header text */
.internal-query-header-title {
    display: none;
}

/* Hide the query header icon */
.markdown-preview-view .internal-query.is-embed .internal-query-header-icon {
    display: none;
}

/* Stop highlighting found element */
.search-result-file-matched-text {
    color: inherit;
    background-color: inherit;
}

[dvd]

Thank you for this idea. It’s what I was looking for. I realize the thread is old-ish, but I expanded the approach to the regex to cover my cases, so figured I would share it in case it’s helpful, or in case anyone can help me improve it.

In particular I wanted to account for content in a block that includes multiple line returns, or the case where the block is at the end of the file without a return. (Basically, it’s about not trusting myself to get the format right all the time.)

/^## #client\/project1(?:[\s\S]*?(?=\n#{1,2} )|[\s\S]*)/

This is where I ended up after a lot of trial and error. So far it’s not thoroughly tested, but seems ok. If anyone finds flaws or can improve on it, please . . .

Here’s what it does:

First match a 2nd level (h2) heading. (That’s just my convention. It could be any level, but needs to be consistent.)

^##  

Next, I match a nested tag for client and project.

#client\/project1

Finally, I put the rest inside a non-capturing group to match the balance of the content under this heading.

(?: . . . )

This looks for all content up to another heading of the same (h2) or higher (h1) level, using a lookahead. Or, alternatively, it just goes to the end.

[\s\S]*?(?=\n#{1,2} )|[\s\S]*

The *? stops at the first match, so that it doesn’t maximize the match, and barrel through to the last h2 in the file.