Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Block/heading queries #30

Open
rapatel0 opened this issue Mar 6, 2021 · 14 comments
Open

Block/heading queries #30

rapatel0 opened this issue Mar 6, 2021 · 14 comments

Comments

@rapatel0
Copy link

@rapatel0 rapatel0 commented Mar 6, 2021

It would be great to be able to filter based on block or sections link in the standard search.

@blacksmithgu
Copy link
Owner

@blacksmithgu blacksmithgu commented Mar 8, 2021

I'm currently working on fancy new query syntax for block/section-level queries (as well as link-based queries). Do you have any examples in mind, so I can make sure it's supported?

@robhawkes
Copy link

@robhawkes robhawkes commented Mar 13, 2021

Not sure if this fits into blocks/section-level but a use-case I have is that I define events across random files as list items:

File 1:
- Some event in File 1 #event #2021-03-01
- Another event in File 1 #event #2021-03-02

Another file:
- Some event in File 2 #event #2021-03-01
- Another event in File 2 #event #2021-03-02

Those files may contain all sorts of other content surrounding the list items, and the list items could be spread out across each file.

From there I'd like to pull those line-items into a consolidated list somewhere else. This is how I currently do it with the official query syntax (removed backtick to show as code):

``query
line:(#event)
``

Or if I wanted to only show line-items relating to this month:

``query
line:(#2021-03)
``

The problem with the built-in queries is that the output is noisy and cumbersome and cannot be configured, unlike Dataview.

@rapatel0
Copy link
Author

@rapatel0 rapatel0 commented Apr 14, 2021

Here's an example - I have a morning checklist in my Daily notes

    - [x] #Health/Vitamins Vitamin D
    - [x] #Health/Vitamins B12 Vitamin
    - [x] #Health/Vitamins Iodine
    - [x] #Health/Vitamins Calcium 
    - [ ] #Health/Vitamins Omega3s
    - [x] #Health/Water Fill Water Jug

With Dataview i could do some analytics on how often I'm actually doing stuff if that makes sense. Could sub stratify on vitamins or health in general, for example

@FekketCantenel
Copy link

@FekketCantenel FekketCantenel commented May 8, 2021

I am stubbornly attempting to replicate how, in Roam Research, you dump notes into your Daily Note like so:

  • "new quote I found about producitivity" —Person #quote #producitivity
  • idea for something to do with my [[Productivity MOC]] #productivity
  • just a note about how I got a lot done today #log #producitivity

Then on a Quotes page, I would use a dataview to pull all the lines tagged #quote and display them, ideally grouped by secondary tags.

On my Productivity MOC, I'd have:

  • a section for related tasks (already doable with the dv.taskList function)
  • related quotes (a dataview of lines with both #quote and #productivity
  • a log of related events (#log #productivity)
  • any other miscellaneous related ideas (#productivity -#log -#quote -#processed)

The latter three are technically possible with the vanilla query codeblock but only shows a portion of the retrieved text. @robhawkes is exactly right re "the output is noisy and cumbersome and cannot be configured, unlike Dataview."

(The Obsidian expectation seems to be that I create a new page for every single quote, which is cumbersome and would clutter my precious Graph View.)

@M-bot M-bot changed the title [Feature Request] Block/heading queries Block/heading queries Jul 22, 2021
@evfro
Copy link

@evfro evfro commented Oct 7, 2021

I am also very interested in this feature. My typical use-case is as follows.

  • I dump new ideas and tasks into daily notes.
  • If tasks belong to specific projects, I place then under the link to a project.

For example, in my daily note 2021-10-07 I may have the following (mind indents):

[[Project A]]
  - [ ] task of project a

[[Project B]]
  - [ ] task of project b

I also have a separate note with project-related task queries, where I want to gather tasks not only from project pages directly, but also from all other pages including daily notes.

There, I'd like to have the possibility to list tasks of only specific projects. Currently, the following query

``dataview
task 
from [[Project A]]
where real and !completed
``

would return tasks for both projects:

2021-10-07
  - [ ] task of project a
  - [ ] task of project b

as it only checks for link existence, but does not limit the query to a block scope.

Not sure about the syntax to specify block scope in such query, though. As was already mentioned above, from the standard Obsidian query perspective, the task can be accomplished by e.g.

``query
line:"Project A" task-todo:""
``

that would display

2021-10-07
  [[Project A]]
    - [ ] task of project a

But standard Obsidian queries are not very convenient for what I'm trying to achieve. They lack interactivity and one has to manually expand query results, if there are many tasks under the project.

It seems that having block scope specification for dataview queries would be a perfect solution for the described scenario. It would facilitate two potentially independent regimes:

  1. brainstorming, when new ideas and tasks are generated without switching contexts (daily notes <--> project pages), so that creative process is not interrupted;
  2. planning / analyzing, when a more consolidated and organized view is required.

@blacksmithgu
Copy link
Owner

@blacksmithgu blacksmithgu commented Oct 13, 2021

Block/heading queries are high on my TODO list. Support will probably come through DataviewJS first (since it is easier to expose data there), and then in queries via the improved query syntax later.

@blacksmithgu blacksmithgu added this to the 0.5.0 milestone Oct 13, 2021
@rlopeznegrete
Copy link

@rlopeznegrete rlopeznegrete commented Oct 17, 2021

Will follow as I'm keenly interested in this functionality. Hopefully soon...

Thanks a lot for this great plugin!

@iris2jane
Copy link

@iris2jane iris2jane commented Oct 20, 2021

Wow~I really want to associate the blocks in the outline with CSV or markdown files and present them in outline order👇

截图_20215820125839

@kurtharriger
Copy link

@kurtharriger kurtharriger commented Nov 18, 2021

I am also experimenting with using block ids as a method to store metadata for tasks in yaml instead of inline text. I find putting metadata on same line begins to feel noisy.

I found that if the task has a block id I could grab the blockid from the link and store the metadata in yaml.

And now I am thinking it would be great if I could add yaml metadata to any block id, but there doesn't seem to be an easy way to query a list of block ids yet.

@blacksmithgu
Copy link
Owner

@blacksmithgu blacksmithgu commented Nov 18, 2021

@kurtharriger I can see same-line metadata being quite noisy - there is incoming support for adding metadata via sublist elements, though that is also a little noisy. Being able to externally store metadata by { file, section, block } ID is an interesting idea - there is incoming support for easily loading YAML data (via dv.io.yaml()), which should make homebrewing this via scripts a little easier. Block IDs are being added as available metadata to tasks; I'm experimenting with also indexing any markdown block that has an explicit block ID (which is paragraphs, headers, and list items currently).

@charleshan
Copy link

@charleshan charleshan commented Nov 18, 2021

indexing any markdown block that has an explicit block ID (which is paragraphs, headers, and list items currently)

This would be a big improvement but if you were to do this, wouldn't it be better to index every line? It looks like Obsidian is already doing this.

``query
line:keyword
``

Obsidian has different search operators for content, line, blocks, section, etc.

https://help.obsidian.md/Plugins/Search#Search+operators

@person-al
Copy link

@person-al person-al commented Jan 9, 2022

I'm also glad to see this on the roadmap! I'd also like to be able to access Dataview fields on a "per section" basis. My use case is files that contain different sections of the same types of data in them, for example:

# Books I've Read This Year

## Tale of Two Cities
Start Date:: 2021-01-01
End Date:: 2021-01-05
Rating:: 5
Genre:: Classic
Would Recommend:: true

## War and Peace
Start Date:: 2021-02-01
End Date:: 2021-02-20
Rating:: 3
Genre:: Classic
Would Recommend:: false

The goal being to be able to treat "sections" of a file the same way we currently treat files. So in addition to having
dv.page("books/Books I've Read This Year.md"), which produces a page object with all the fields available as properties, one could also do:
dv.page("books/Books I've Read This Year.md").sections(), which would return an array of section objects that also contain all the fields in that section available as properties.

The DQL, perhaps, could have something like...TABLE section.name, file.day FROM <source> the same way we currently have TABLE file.name, file.day FROM <source> available?

Not trying to be prescriptive here, just trying to share some thoughts/ideas, since it is such a complicated request as you've noted. I think the biggest complication in my mind is how to deal with the different levels of sections. Some people may want H1, some may want H2... you may actually need to add some kind of dataview field or tag to the header to denote to dataview how the page should be divided into "sections". Or perhaps it only supports it's lowest level section.

Thanks so much for your work on this plugin, you've enabled so many of us to supercharge Obsidian. You've done an incredible job!

@oreothepony
Copy link

@oreothepony oreothepony commented Feb 23, 2022

I'd really like to be able to treat sections as a sort of alternative to objects in YAML. Different levels of headers could denote nesting, for example:

# top level:
 ## middle level:
  ### bottom level
 ## middle level 2

If there was no middle level, it would go straight to the next one down (the bottom level).
This way I could loop over the sections and selectively extract which metadata I want.

@Zygar
Copy link

@Zygar Zygar commented Mar 7, 2022

Stoked to see this is in the roadmap. Similar use-case to @evfro here:

March 7, 2022.md

- Some random notes from a day
- [ ] A random task from a day
- [[A project name]]
  - Some meeting notes 
  - Some more meeting notes
  - [ ] Action from that meeting
      - Some extra context 
      - Some more context, maybe even some #tags or other metadata. 
  - [ ] Another action from that meeting 
  - [[T52-A really big task]]

T52-A really big task.md
---
for: [[A project name]]
---
- [ ] The task in question
   - A bunch of extra context

I'd love to be able to query [[A project name]] and receive something like:

  • Action from that meeting 🔗March 7th, 2022
  • Another action from that meeting 🔗March 7th, 2022
  • A really big task 🔗T52-A really big task

Ideally with the ability to filter based on whether the task's child (or parent, or parent file) contains certain metadata (e.g. #deep-work); a link to its original page, and foldable/unfoldable context (children of block)

This would be a gamechanger to my variant of GTD and finally get me off Roam Research!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet