Option to show full block paths (breadcrumbs) in List View query results and References

Feedback Feature Requests
,
1

Could we have an option to display the full block path inline in List View query
results and in the Linked/Unlinked References sections, instead of collapsing the
middle ancestors into the “Show more ancestors” (···) dropdown?

Displaying them just the way it was in Logseq OG would be perfect.

Why the dropdown doesn’t work for this

I use this a lot in Logseq OG for use cases where there’s no good alternative, and the
lack of it is the only thing keeping me on OG rather than migrating to DB. (Happy to
expand on the use cases if anyone’s interested.)

The problem is that the value of a breadcrumb is scanning — glancing down a list of
results and immediately seeing where each block lives in the tree. The ··· dropdown
destroys exactly that: it costs one click per result, shows the path in a popup that
covers the results themselves, and closes again, so you can never compare two results’
locations. For deeply nested blocks the visible part (ancestor › ··· › parent) is
often the least informative slice of the path — the discriminating context sits in the
middle, which is precisely what gets hidden.

In practice the collapse starts early: for blocks about four levels below their page,
all you get is the first ancestor and the direct parent.

There’s currently no way to opt out

I looked into whether this could be worked around without patching Logseq:

  • There’s no config.edn key and no Settings toggle for it.
  • There’s no per-view option — the List View settings cover type, grouping, sorting and
    gallery layout, nothing about breadcrumbs.
  • Custom CSS can’t help: the hidden segments aren’t hidden, they’re simply not
    rendered — the dropdown builds its contents only when you open it. CSS can only widen
    the segments that are already visible.
  • No plugin hook reaches this component either.

So a fork or a fragile custom.js DOM hack are the only options today, which is a shame
given how small the actual change looks.

Why this should be cheap to implement

As far as I can tell, the ancestors are already sent to the client for every result
(the breadcrumb payload carries the chain up to 16 levels), and the rendering algorithm
already handles arbitrary path lengths — it even inlines the folded segment when only
one would be hidden. The only thing hiding the path is a hard-coded display budget for
the inline variant, in src/main/frontend/components/block/breadcrumb_model.cljs:

:inline {:max-visible 3 :nearest-count 1 :load-depth 8}

Making :max-visible come from a user setting — something like a
:ui/breadcrumb-max-visible config key, or simply a “Show full block path in query
results and references” toggle — would cover this. It’s a change in one pure namespace,
with no schema, query or worker impact.

Would the team be open to that? If so I’m happy to open a PR.