New Ctrl + P search looks nicer, but is less predictable and less powerful

I really like the new look of the new Ctrl + P search. I can also see the intention behind the design change: It is focused on opening #Documents. The document name is the bold part of a search result.


A search result now consists of 3 parts:

  • Breadcrumbs: The path leading to the document.
  • Document: The document where the search result is in.
  • Rem: The actual rem matching the search string

So far the theory I (maybe wrongly) deduced. There are some inconsistencies/bugs/design decisions that I am still trying to figure out. Here are some unordered thoughts.

Always show full path


This is the old Ctrl + P result display for the example above. (This design is still used in [[ and Ctrl + S.)


I always would like to see the full context when deciding which Rem to open. For example if I have some notes scattered over some daily documents it looks like this:

Compare to

Project A and Project B could be on different daily documents. Then I’d need to check each one to see where the info is that I’d like to work on. If I have not yet created a (top-level) rem for MyConcept then I have not even the option to go to the MyConcept page and look at the unlinked references portal. And creating a search portal is quite a lot of friction for just wanting to open a rem.

Here is how I would like to have it look:


There are cases where a non-document rem is bolded.

I don’t know yet what the conditions for this are. Maybe if there isn’t any document in the path.


Here Research is a folder, the other are plain rem.


Here Custom CSS is not a document.

What are the exact rules for how a result is displayed? What are the parameters that determine how a search result is displayed or if it shows up at all?

Bug: Some non-document top-level rem are not showing up in Ctrl + P

This happens even if I fully match the name. It does not happen for all rem though. It shows up in Ctrl + S as the first result. In my case it’s the plain top-level rem test where I sometimes write up some test cases.

For the bug you have described at the last, I came across that too. Just sharing what I discovered:

  • If it is a non-document non-top level rem, and if it is open in a portal somewhere, then that result is displayed as the first result, but it shows as if that is it’s natural hierarchy
  • Once we close that portal, then it displays as a top level rem
1 Like

I think it should definitely be a toggle and possibly count headers as “big breadcrumbs” (bread slices?..).