Weak search functionality

I love Logseq but unfortunately the search function in Logseq is very buggy. Below is a link to a video demonstrating an attempt to search for “water heater”.

-I first do a Ctrl-K search across all pages. It finds the correct page and block but it doesn’t take me to that block when I click on it. And because the page is quite long, it would be hard to find the block by just browsing through it.

-then I try a Ctrl-F search within the page. It cannot even find the block

-then I try a Ctrl-Shift-K search within the page. It is much slower than the Ctrl-K or Ctrl-F searches for some reason, and again it will not go to the block. I have to click on a sub-block that also has the text and then go up to the desired level.

video demonstration: 2024-10-08 buggy Logseq search.mkv - Google Drive

(and not in the video, if I try to do a Ctrl-Shift-K this-page search while zoomed into a block that has many sub-blocks, it does not show any results)

Visual Studio Code finds the block and takes me to the block just fine.

For now, for searching, I’m using a page I’ve created with a non-case-sensitive query (learned from here: Full-text case-insensitive regex). But with queries, there doesn’t seem to be a way to actually go to the page shown or move up a level.

I’m using the newest version of Logseq, and I’ve done reindexing to no avail. The page I was searching in with the video is only 1,200 lines, 108,000 characters long.

Thoughts or strategies? Thanks!

It does take you to the block—most of the time. Occasionally it does not.

My experience with this is if the page isn’t loaded in its entirety (i.e. I haven’t scrolled through the entire outline first), search won’t take me to the block I want. Usually that happens with longer outlines, but I don’t know what the cut-off number of blocks is.

Workaround is to shift-enter the search result, which will put the block into the sidebar. You can then open it on the main interface by clicking the on the block’s bullet.

Unfortunately, that’s the consequence of the current implementation of lazy load. It has made Logseq much faster overall, but the search abilities took a bit of a hit.

With Logseq DB in the pipeline, this should be a complete non-issue in the next major release. Sorry for the frustration in the meanwhile! :pray:

2 Likes

Thank you all so much for your helpful feedback. I’m very much looking forward to the DB rollout and really appreciate all of the great work on Logseq development!

I tried out the ideas shared here. I still can’t get the regular all pages search to work reliably even after scrolling through the whole of the file that has “water heater” and even with the page open. It still couldn’t find the block with a regular all pages search. (and I’ve had this issue with other pages and search items as well). So I’m stuck with queries for now.

Gorgonzola’s idea of clicking on the bullet works well with the query. Instead of needing to edit within the query (where I don’t have the full context), I can click on the bullet and go to that block on the actual page (and I could go from there up to higher levels).

But I still can’t find a way to easily see the blocks above and below (I don’t mean parents and children but the sister blocks at the same level) the block returned from my search (especially for blocks buried inside of a large page). I can zoom to it from a query, but after zooming, I can’t see the blocks around it. And then if I zoom out of the block, it just takes me to the top of the page. Any tips? Thanks!

This is strange. If you zoom out of the block you’re focused in, it should take you one level higher, not to the top of the page. When all else fails, you can use the breadcrumbs at the top of the interface to navigate level by level:

Good question. This is on a page with hundreds of siblings at the highest level. When I move up from one of these siblings I’m zoomed in to, it just takes me to the top of the page