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.