Scroll to search results in find & replace

[drball]

Is your feature request related to a problem? Please describe.

I want to find a passage with a specific word. Currently I can open "Find & replace" and type my word as a query. This will tell me how many passages match the query, and highlight those passages in yellow, but I have to scroll around to be able to find them, which is difficult & time-consuming.

Describe the solution you'd like.

Tow buttons should be added to the bottom of the "Find & replace" dialog named "Next" and "Previous" (or up & down arrows). Pressing these will scroll the document towards the first result of a passage containing the search query so that the passage is in the center of the screen. Pressing "next" would scroll the screen to the next result, & previous to the previous. When the final result is reached, the next button is either disabled or will go back to the first result.

Describe alternatives you've considered.

The results could be shown as a list maybe, but the important part is that the entire screen moves so that the result is in the center of the screen. This could be animated, or a simple snap.

Additional context on this suggestion.

No response

Presubmission checklist

• I am interested in working on code that would implement this feature request. (This is not required to submit a suggestion.)
• I have done a search and believe that an issue does not already exist for this idea in the GitHub repository.
• I have read and agree to abide by this project's Code of Conduct.

[klembot]

Seems like a reasonable idea, though the concept of next/previous is a little tricky in a spatial context. What determines the ordering of results? It's tempting to say "top to bottom, left to right" but is that a universally clear ordering? Not certain.

[hhrichards]

Seems like a reasonable idea, though the concept of next/previous is a little tricky in a spatial context. What determines the ordering of results? It's tempting to say "top to bottom, left to right" but is that a universally clear ordering? Not certain.

I'd be happy with it ordered by passage id

[klembot]

Seems like a reasonable idea, though the concept of next/previous is a little tricky in a spatial context. What determines the ordering of results? It's tempting to say "top to bottom, left to right" but is that a universally clear ordering? Not certain.

I'd be happy with it ordered by passage id

I feel like that could be confusing--IDs are random. But I'm open to being convinced otherwise.

[greyelf]

I feel like that could be confusing--IDs are random.

Less "random" and more assigned based on the order of Passage creation/addition.

But I agree ordering by such would likely be confusing, due to the potential of the Passages being re-positioned around the map.
eg, Passage with ID 3 is in bottom right corner, Passage with ID 6 is in top left corner, etc...

Ordering "top to bottom, left to right" would likely make the most sense "Visually", when next/previous is used to move from one Passage to another in the highlighted result set.

[klembot]

I feel like that could be confusing--IDs are random.

Less "random" and more assigned based on the order of Passage creation/addition.

But I agree ordering by such would likely be confusing, due to the potential of the Passages being re-positioned around the map. eg, Passage with ID 3 is in bottom right corner, Passage with ID 6 is in top left corner, etc...

I think you're thinking of the IDs that get assigned on publish. Inside Twine, passages have UUIDs like e0816cb2-fe97-420f-a51f-8f2129c27ae7 that aren't visible much to users.

[hhrichards]

I actually don't think the order is too important. The important thing to me is putting each passage into the center of the screen. I waste so much time scrolling around to find the highlighted passage.

[david-donachie]

I'd second this. The "goto" function is pretty much unusable, since even when you type an exact passage name it often doesn't find it, whereas it will frequently find entirely unrelated pieces of text. The Find & Replace search is a lot better, but the lack of the "snap to passage" functionality makes it extremely hard to use in a large story.

I'd suggest just combining the two. The only real utility of the goto is the auto-navigation of the passage map.

[klembot]

@david-donachie in a new issue, could you post a screen recording of Twine not finding a passage by name? That's worth fixing. The goto function uses fuzzy matching using Fuse.js so that in theory, if you make a typo entering a passage name, it will still find it for you. It may need fine-tuning for large stories.