Search results anchoring

I can’t believe there isn’t already a thread for this, but I have spent some time searching, to no avail! Please let me know if I should delete this…!

When doing a document search, you click on the relevant page in the results list and it opens in the main window, but doesn’t position the cursor at the result itself. I can’t quite work out where it does scroll to, but it seems random.

I’d suggest it’s standard practice to scroll to the position of the first instance of the searched-for word. Seems odd (and annoying) to have to manually scroll up and down each time to find where the highlighted term is hiding.

If you have a mac try cmd + g. This jumps from result to result.

1 Like

True, and it’s quicker than scrolling, but still an extra unnecessary step.

The search in the document starts where you positioned the cursor the last time you were in this document. (at least I think so :slightly_smiling_face:)

If you always want to start the search at the beginning of the doc, type cmd + arrow up before you search with cmd + g.

As noted here you only need to use the Find Next keyboard shortcut (Ctrl+G / ⌘G). This works even with the focus in the binder, so all you have to do is click to view a section, then hit the shortcut to jump to it. For most purposes that may mean pressing it 23 times instead of 22, particularly if one loads all of the search results into the editor as a Scrivenings session so that point-to-point navigation is unnecessary.

This isn’t done “by default” because we don’t know why you are searching, basically. You might be searching more as a form of navigation than actually looking for the text you searched for. Personally I would find it very frustrating if when jumping between sections in a search result, the software always scrolled to the first hit, as often I jump between search results or items in a search collection, while editing and writing. I want the editor to go right back to where I stopped typing. This would be especially disruptive when jumping back and forth between items in the list, making little spot edits here and there.

Bear in mind, those using Project Search to find phrases in the text editor at least have something they can jump to with Find Next. Where the cursor was previously has nothing at all—every single time you used this tool to navigate with, it would require manually scrolling around and reading through text, trying to remember where you left off. That would be so bad that it would effectively mean it could no longer be used for that purpose.

So, by making this something that is asked for, with an explicit command, we put you in full control on your side of things instead of taking the control away from everyone and chopping off an entire use case from the software (search as navigation).

Incidentally, if your use case is solely to jump to the first hit in a specific document, rather than gathering a list of documents to work with, then Quick Search is precisely the tool you’re looking for. At the bottom of the search results list are contextual matches. By clicking on those instead of the navigational matches at the top, you will be conveyed directly to the first hit as part of the navigation event.

3 Likes

Thanks for the thorough explanation!

Your use case makes complete sense, though tbh I’d still prefer it to work the way I described for my own use case, optionally. The ⌘G shortcut is ‘only’ one extra step, but it doesn’t start from the first instance, so does need the second step up a page-up keystroke to get to the beginning. For a quick scan across multiple documents, it’s two extra steps for each click of a document in the results.

It’s all workable as-is, but I’d definitely like the option to have each page result just start from the first result – while there are good reasons why this doesn’t happen given the context of a writing app, it’s still ‘standard’ behaviour for most apps and would still be useful I think for use cases like mine.

Thanks again, great app…!

1 Like

For a quick scan across multiple documents, it’s two extra steps for each click of a document in the results.

For that specifically, unless you have a strong reason not to, just select all of those documents you want in the results sidebar with Ctrl+A / ⌘A or Shift-clicking for a smaller selection, and switch to Scrivenings mode. Not only do you now no longer have to bounce around whenever you reach the end of one section, to go to the next, but Scrivenings sessions like this always start at the top, and editing multiple items this way doesn’t disturb their internal “last cursor position” settings.

That little ‘hook’ button up by the “Search Results” heading in the sidebar is also similar to ⌘A. The main difference is that it actually loads the search result list into the editor, as a formal container, with its own potential for settings, like locking the group view mode to Scrivenings, where as Shift-clicking and Ctrl+A just create informal “multiple selections” that vanish the moment you go elsewhere.

So yes, there can be one extra step of selection involved, but ideally you should only need to do that once rather than for each individual search result hit.

1 Like