Text search - how to remove search query while staying in place?


Sorry if this is a stupid question, but I couldn’t find an answer to it.
When I search within my documents, the search function itself works really well.
However, when I find the bullet point I’m looking for I want to be able to highlight it / set my marker at that bullet point, and then remove the search query so that the document is “back to normal”, only with the bullet point I was looking for highlighted / ready for further editing. When I search using tags this works just fine - I find the bullet point I’m looking for, highlight the point, remove the tag from the search field, and now I can continue editing the bullet point with the rest of the page showing unfiltered. However, when I do a free text search this doesn’t work. When I remove the text in the search field I’m automatically moved to the top of the page, even if I have certain sections highlighted.
Am I doing something wrong here?

Thank you very much for your help.


I don’t think you can do that. I’ve never done it.

Personally, I either do my edits with the search in place, or click zoom to focus in on the item and it’s children, or just click the expand bullet to collapse it then expand it again, which causes ALL the children to show up rather than just the searched ones.

Suggested feature for the team:

Set cursor to anywhere in the search results.
Exit search, brings you to the full document but leaves cursor at this new spot in the document.
Avoid this only by keeping cursor on the sesrch line.


Thanks for the replies, guys! Then I know it’s not currently possible - good to know!
Would be great if this could be implemented as a feature in the future - so I support Alan’s suggestion.

Have a great weekend, guys!

1 Like

It works for me - I click somewhere in the desired node, press ESC two times and document is scrolled to the node with cursor in position where I leave it before hitting ESC

Not for me.

The first ESC causes the blinking | cursor to disappear and the node to unselect, and the second ESC clears the search box and the node is no longer anywhere in view.


Same thing here, George3.
I tested on both the stand-alone OSX app and in Chrome.

I have also tested this and as a reflection on what @BigChungus experienced:
IF you have the particular level collapsed before the search, it will not remain there after esc-esc , because it will recollapse it as it was before the search/filtering.
HOWEVER if you expand-all the document before searching/filtering, it will remain in place after esc-esc ing.

+1 for the need to be able to do this also on collapsed lists, but at least there is this workaround for now.


I posted this in another thread as well, but though people might find it useful here. It explains how the search works, and yes, there is a gap. Here is my post below…

I would like to start my search from the top level of my document, and find something two or more layers in. For example, I search for “Day”, and that takes me to results, and I click on one at “Year Plan - Quarter Plan - Month Plan - Week Plan - Day Plan”. That is 5 layers deep.

If “Year Plan - Quarter Plan - Month Plan - Week Plan - Day Plan” was already an open node, when I hit escape twice, it will take me to that node. That is good!

If that node was not already open, let’s say it was only “Year Plan - Quarter Plan” that was open, with all other nodes underneath being shut… And then I do the search for day… I click on “Day Plan”. Then… when I hit escape, it will take me back to “Year Plan - Quarter Plan”, and not all the way to “Year Plan - Quarter Plan - Month Plan - Week Plan - Day Plan”, which is where I want to go. Please note, I want to get there without zooming in.

The only way I can see to get “Year Plan - Quarter Plan - Month Plan - Week Plan - Day Plan” without being zoomed in on “Day Plan”, is to do a search and find it. Hit the escape button, and then manually dig for it now that I know where it is… Or am I missing something??

Or rather than going to the full document, it goes back to the origin of your search… if you search from two layers in, and find something four layers in, it goes back to that second layer, but now the searched result is open from that page, where as before it may have been shut.

I see how it’s supposed to work, guys.

@Shida: I remember we did something for something similar to this, is that correct?

Yes to this as a mod. I’ve just spend a confusing several minutes trying to understand this. Even with the work around [expand all > search > esc, esc], you’re left with having to find the top node again to do the collapse back to normal.

Then it hit me that the current functionality is more of a focusing filter. It let’s you focus on something (the searched item) while reading/changing it and it’s immediate surroundings. When done, [X] or esc, esc to pop back out. This is good, so I wouldn’t get rid of it.

What’s needed is another semantic. Maybe, [Go Find]. Find a spot (with the same search syntax), then stay there upon exit.

So, current search = focus filter
and, added search = go find

1 Like

Spoke to soon. Current search does not function like I thought. Esc, esc does not take me back to my pre-search location. In fact, it closes the document I was working on. When trying to replicate my original understanding, I found out that I must click on the [Go back] link of a global search. Exiting a local document search (without having engaged another node) takes me back to pre-search location. Engaging another node in the same document during the search leaves me in the new location.

All bets are off at this point. I’m so confused about the logic behind the various search scenarios that I’m just going to consider it a limited value added for the time being.

1 Like

Not for me. That sounds weird. When I am in a node and hit the search in doc hotkey, search something, then hit ESC ESC ESC ESC ESC (doesnt matter how many more times) I just end up where I was the moment before I hit the hotkey. No document closing. No changing node. Are you on default hotkeys? Did you assign ESC to a “close doc” hotkey or something?

Dear devs,
So what’s the status on this?
How can I search, and jump to the position of a result without being forced to change the zoom level?

I still want to see the full document, just get the cursor to the selected result position (which is the most basic search functionality in any other editor).

There must be a way to do this… Please help!



Is there any work being done on this? I find this search experience maddening. So disorienting and unintuitive.

If a searched node is collapsed you have to manually dig it out after exiting search?

The point of search is often to find a thing AND move to that place because you want to edit/reference other parallel information that exists there. Search is just as much about location and tertiary information as it is finding ONE specific thing.

But currently you have to exit search - then back track manually down the hierarchy expanding nodes as you go. And the tertiary information may not even be in that location once you get there.

Wish this had a more intuitive implementation. Search. Expand hierarchy to that precise position. Exit search. Maintain position.

Search, and orienting yourself after a search, are so essential to sifting tons of information.


You can use browser’s search instead Dynalist’s search if you really don’t want to edit in place or zoom in to an item. For example in Chrome you can’t use Ctrl + F (you can change keymap for search then still use Ctrl + F), click the three dots in the top right corner, than click Find.

1 Like

Browser search is an option that introduces other similar problems. Among other things, it doesn’t find items if a node is collapsed.

So at a minimum a hacky workaround is needed - like “un-collapse all” etc. Which, if you have a huge note, is massive overkill when you’re really just after a clean, elegant, surgical solution (to cleanly reveal a single branch position, at the top level, and maintain that position after you close out of search.)

This ability to organize active data, and bury less relevant data is what makes Dynalist great. So why expect the user to reveal EVERYTHING and thus muck up the effort they’ve put into arranging their layout?

Even then, browser search can only find strings in the file that is currently open in your browser, items buried in other Dynalist files/folders cannot be searched.

Most importantly this option doesn’t work when you are not using Dynalist within a browser.

1 Like