Block References Issues and Ideas for Improvements

I’m trying to leverage block references more in my notes, and I’m experimenting with a workflow where I write most of my notes in my daily notes, then create dedicated pages with references to blocks in my daily notes, but I’m running into some usability issues.

I’m wondering if anyone has solutions for some of these issues or if there could be some enhancements in logseq to make this easier.

  1. Block references don’t appear in search
    If I create a block in my daily notes, then create a reference to it somewhere else, only the original text appears in search. This makes it difficult for me to find information when using block references.
    It would be nice if the references also appeared in global search.

  2. Block references with [[tag]]s don’t appear in linked references or graph view
    If I create a block with a [[tag]] in my daily notes, and a reference in a dedicated page, only the original block from the daily page appears in linked references for [[tag]], not the dedicated page with a block reference. It also does not appear in the page graph or global graph.
    I would be interested in having block references with tags also appear in the linked references view.

  3. Creating references of references
    I’m building dedicated pages out of block references to my daily notes. For example, I may write about an equation in my daily notes, then create a dedicated page for that equation with a block reference to my daily notes.
    When I want to create another reference to the equation, it would be nice to go to the dedicated page with a block reference and option drag it somewhere else. However, this will create a reference to the reference, which is usually not what I want.
    I think a good option or default behavior would be to create a reference to the original instead of a reference to a reference.

Let me know if this makes sense, or anyone has a solution to some of these problems.

Upvoted. I’ve been working around them (for example for 3 I always make sure to copy the original), but that adds undesirable friction.

For 2 I would remove the tags on the original block and transfer them to the “evergreen” one when I feel the original block is no longer useful (if needed I can always find it by clicking the block reference in the dedicated page - just one click, so it’s very retrievable even without tags.) It made sense to me as tags serve 2 purposes:

  • retrieval, especially for things that need to be processed further
  • organization, for automatically positioning the note in a networked graph

And it is the “evergreen” note that has been organized properly, both internally and in relation to other notes (, while the original block is in journals and you know most people don’t want to enable journals in graph for a reason.)

3 Likes

This video from @Bas_Grolleman describes the workflow I’m interested in as well.

1 Like

Upvoted as well

I’m rather new to Logseq & keep having the same issue. I thought it was just me missing how Logseq operates compared to other apps I’ve used

I was trying to jot everything down in the journal so I don’t have down time trying to figure out where to put things. Later on, I struggle if I should use a block or page reference as the linked reference section will only show the page reference & not the block references to that block

Anyways, you have my vote

1 Like

Hi, some thoughts:

Re 1.
This is because global search is for free-text content and does not resolve block ids further. One solution would be to extend this widget. An alternative I’d prefer is to give blocks a name, like with pages. For complex cases, queries are the most flexible solution - and I think it would be useful to base everything around queries on low-level and make them first-class citizens. For example provide per-page queries or make queries reusable.

Re 2.
These seem to be multiple requests:
a) Improve graph widget to include blocks in some way
b) Improve Linked References view
c) Allow graph queries / to search for transitive links

(b) You can see in source code, that linked references currently only deal with page backlinks, not blocks.
I agree, it would be cool to have a short summary of all directly linked blocks inside page tag at the bottom, similar to page back links of tag. But your example is a bit different, see next.

(c) Linked references only show direct links. You have a block that links to another block, which itself links to [[tag]]. So being on page tag you won’t get the indirect links. I am hoping, they will allow for graph queries in future to catch those “transitive” links to - this would be a game changer (e.g. with ontologies)!
This tweet and GitHub - cozodb/cozo: A transactional, relational database that uses Datalog and focuses on graph data and algorithms. Time-travel-capable, and fast! sound promising and might be combined with the upcoming query builder too.

Re 3.
Doesn’t right-clicking on the block reference → “Copy block refs” work for you?

1 Like

Hey @venture-comp I really appreciate your thoughtful response.
For search, I’m proposing that it would search block references as well. It doesn’t seem like the named blocks would help in that case. It may be possible to resolve the content in the blocks using an advanced query.

For 2, I’m proposing that the linked references, unlinked references, and page graph would work with tags in block references.

For the copy block refs, it doesn’t work for me, because if I make pages out of linked references, copy block ref creates a reference to the reference, which is error-prone and makes it even harder to find information. This could partially be solved by a plugin to implement a variant of copy block ref, but I don’t think I can make it work with option+drag which I’d prefer