In the browser version search is built into the browser by doing CTRL+F, but the desktop version (Linux for me) does not. I would like to be able to search the currently open note without searching everything.
Thanks for your request. I ran out of votes but I want to support this
More than once I have been in a situation where I wanted to search the open page and “see” where certain words are mentioned.
This would be in addition to the existing “Search within side” which shows blocks and opens those blocks. That’s useful too, but a different usecase.
Ctrl + Shift + U is what you are looking for. (Titled “Search in the current page”)
But I agree, that it does not work for example in the Keyboard shortcuts page or in an “All pages” page…
Thanks for your reply.
This is what I meant with:
And at least for me - this is not the same usecase.
For example, no matches are found in the linked reference or in the query results.
Looking for the occurrence of words on a page and jumping to those places is often a better option for me than just seeing a list of blocks.
Yes, it’s similar - but - at least for me - I often wish I could just jump from one occurrence to the next on the current page.
I tried that shortcut, but I am looking more for a search feature like in a browser where it will highlight the instances on a page and start going through them.
Did you try doing “Ctrl+K” This opens the Search bar which you can use the do “Search for pages” and “Search within current page”
This would be very useful to search across linked and unlinked references of a page. Considering that pages may simply be aggregators of references, it’s an important use case. Think about
[[recipe]], I open that page and want to search across my recipes that ultimately reside in the journal.
That shortcut does nothing in my Logseq on Linux. Ctrl+Shift+K does some sort of “search in page” but only highlights the search query and doesn’t place the cursor on it. If you press Enter, Logseq creates a page with the search result as its name. If you want to perform an edit next to the search result (very common use case). you have to visually remember where the search result(s) were, then manually navigate there. This is, by far, in my 25+ years of desktop and mobile computing, the worst search experience I’ve seen in a text editor.