search

klembot / twinejs

Twine, a tool for telling interactive, nonlinear stories
https://twinery.org
GNU General Public License v3.0
2k stars 296 forks source link

Find/Replace freeze in large story #1117

Open aeonwalk opened 2 years ago

aeonwalk commented 2 years ago

Describe the bug.

Accessibility issue: I type quite slowly due to a disability so perhaps Find is updating faster than I type. I have Find/Replace issues on a long story (741068 Words, ~13MB) in SC 2.4. I have to C+P queries (works fine) as typing queries shorter than ~4 characters crashes. This does not occur when using my regular system settings Find/Replace in other programs.

Steps to reproduce:

Simple Find/Replace query in long story

Expected behavior:

Allow for more time to complete typing search string before refeshing search of entire document.

Additional context on this problem.

Motor disability requires adjustment to feature.

Twine version number

2.36.1 (running in 2.4)

Does this problem occur with the web version of Twine or the desktop app?

Desktop app

What operating system does this problem occur on?

macOS

If this problem is occurring with the web version of Twine, what browser does it occur on?

No response

Presubmission checklist

klembot commented 2 years ago

Sounds like this is caused by the logic to update highlighting on passages based on your search criteria taking a long time (that's a large story indeed!). The delay is set right now to 0.25 seconds after the last character is typed... we could try bumping this to a larger number but I'm not sure what that number should be.

aeonwalk commented 2 years ago

One other thought -- maybe the delay could be set for longer in longer stories? For reference, I've noticed this issue in stories of size 12 and 19mb, seems fine in all of my smaller stories.

Yes, but it will be tricky to figure out what the right threshold would be--it'll vary by how powerful someone's computer is, what browser they're using, etc. I think an issue is that these updates pile up as you type, and a smarter approach would be to handle them more intelligently... but it's tricky. The UI basically sends an "update passage highlighting" message to the backend, which the backend processes more or less on its own and doesn't have a (obvious) way for it to communicate back to the UI "I'm done," because usually the "I'm done" signal is that passage highlighting updates.

Does the "Find & Replace" functionally try to search base64 data (like that of an embedded image) for the supplied query?,

Yes. Not sure how we'd do otherwise, but I suppose it's possible to write something that would recognize a base64 encoded string?

greyelf commented 2 years ago

@klembot Does the "Find & Replace" functionally try to search base64 data (like that of an embedded image) for the supplied query?,

@aeonwalk Does your 13MB sized project only consist of prose and code, or have you embedded base64 data in it?

aeonwalk commented 2 years ago

@greyelf not that I am aware of -- if it matters, I generally handle images like so: < div class="abc">< span class="xyz">[img["a/b/c.png"][passageA][$a to 'hi']]< /span>< /div>

hituro commented 2 years ago

This sounds like a need for something like a debounce() on the highlighting, to be able to delay the update, and then cancel it as typing continues (which I think you are already doing) but also just to cancel the existing highlight as the next one comes in. Can the backend just dump the highlight process if a new one arrives?

klembot commented 2 years ago

Yeah, we are debouncing updates based on input.

As for interrupting a highlight, I agree, that'd be a solution but not sure how we'd do that without building a scheduling system, which is a little intimidating--right now, it's synchronous.

aeonwalk commented 2 years ago

Hi Chris -- thanks for your reply, I would appreciate any adjusting you may be able to do here!

So a few ideas as to how long a delay may work... However twine was setup before 2.4 never gave me this issue (even in the same huge story), but I understand if too much has changed to migrate find-replace backwards at all. As for the delay time, strings of two characters are usually the worst in terms of freezing the program -- even strings of three only cause occasional crashes.

Due to my condition I type only about 40 wpm at best, so by my math, on avg. 4.7 letters/per word *40 wpm / 60 sec is ~.3 seconds per letter. So a 3-character string takes me almost a second to type. I don't know if a 1-second long delay feels too slow for most users but it might be worth a try.

Anyway thanks for looking into this. By the way, I LOVE twine, been using it for almost 3 years -- it is super intuitive and well made, and has helped me so much in developing many things, and is just getting more awesome as time goes on!

Best and thanks again, Max

Max Greiner [phone number removed]

On Sat, Apr 23, 2022 at 6:17 PM Chris Klimas @.***> wrote:

Sounds like this is caused by the logic to update highlighting on passages based on your search criteria taking a long time (that's a large story indeed!). The delay is set right now to 0.25 seconds after the last character is typed... we could try bumping this to a larger number but I'm not sure what that number should be.

— Reply to this email directly, view it on GitHub https://github.com/klembot/twinejs/issues/1117#issuecomment-1107519438, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYXEVB2ZFV63MF4WJ6VJJ43VGQIBFANCNFSM5TPBCHWA . You are receiving this because you authored the thread.Message ID: @.***>

klembot commented 2 years ago

Edited the comment above to remove a phone number--will respond more substantively later.