Is there a plugin that allows to search for both pages & blocks when making a reference?

Customization
1

Let’s say I want to make a reference to a bullet point somewhere in my graph. I don’t remember right off the bat if that bullet point was a page or a block. In vanilla Logseq it seems I have to investigate on the spot : try typing the bullet’s content with both [[ and ((, or open search to go to the content and see whether it has a parent block. (God forbid I don’t remember the exact keywords for my content and have to bounce in between these three methods a couple times)

Is there a plugin that allows me to not care about the file status of what I’m referencing ? Ideally I’d just always be typing [[ followed by my inline search terms, the plugin would show a dropdown with content suggestions from both pages and blocks, and if the content I pick happens to be a block the plugin would just fill the relevant ((uuid)) link.

2

Yeah, I want that too, actually I just create a feature request relating to this. Go vote for it!

1 Like
3

Related: Block reference to allow ((page-name#block-ref-name)) not just UUID - #4 by and_yet_it_moves

I think, it makes most sense to go one step further and unify pages and blocks. So everything is a block, similar as Tana does with nodes.

1 Like
4

I agree. The one difference is Logseq is trying to be an offline-first filebased tool, unlike Tana. That comes with some trade-offs and the pages vs blocks (aka files vs file lines) distinction seems to come from an early one of these constraints.

In the app I do wish pages could be just “a block with no parent” rather than a completely distinct concept

5

Yeah, there might have been historic reasons for this decision. But offline and file-based does not speak against a unified block (IMO).

File system is just the current storage to save your pages - aka blocks, that can be persisted in form of files.

Treat all pages as independent sibling blocks under an abstract root node (I guess its called Library or so in Tana).

Now file system is completely abstracted away. At some point we all could even agree to switch persistence layer to be an SQLite database or EDN.

All notes and queries are unaffected, because they rely on blocks as smallest unit.

No inconsistencies with pages and blocks (queries etc.). Profit :slight_smile:

1 Like
6

Agreeing that a unified concept of pages and blocks, as presented to the user, doesn’t necessitate departing from .md files on disk.

Going in this direction could be one of the most important decisions LogSeq could make.

2 Likes
7

Having further thought about this, logseq namespaces could also be simplified.

A filesystem-level page hierarchy representated by the page title foo/bar/baz is nothing more than following block-level content in one file:

- foo
  - bar
    - baz

or more specifically with a page/file foo.md:

- bar
  - baz

, as blocks already have a parent/child relation and child blocks inherit tags etc. from parent.

No need for complex file name patterns anymore replicating the page hierarchy.

Also interesting: Wouldn’t it be cool to have a hierarchical view and search tree of blocks, similar to current hierarchy tree of pages widget at the bottom of a non-leaf page?

Tana has consequently thought this model through.
(not affiliated in any way with the product, just have watched their introduction series and have been impressed. Still much more a logseq fan!)

This change might simplify logseq’s mental model for development and user features.

2 Likes