twinejs
twinejs copied to clipboard
klembot
Search mode for text editor
🛑 Only PRs related to localization are being accepted for Twine 2.4 right now.
🛑 Only PRs that fix bugs will be accepted for Twine 2.3. No PRs that add new features or modify existing functionality will be accepted.
I am aware that this is for twine 2.4 and it is too early now. So I take no offence at all when nothing happens yet. But I give it a chance because it looks like a small change, which should not have any side effects.
Description
Ctrl-F for searching Shift-Ctrl-F for replace Alt-G for jumping to line
see https://codemirror.net/demo/search.html for all keybindings
Issues fixed
Credit
Please put an X in one of the squares below only.
[ x I would like to be credited in the application as: SimonHeimberg
[ ] I would not like my name to appear in the application credits.
Presubmission checklist
Put an X in the squares below to indicate you've done each step.
[x] I have read this project's CONTRIBUTING file and this PR follows the criteria laid out there.
[x] This contribution was created by me and I have the right to submit it under the GPL v3 license. (This is not a rights assignment.)
[x] I have read and agree to abide by this project's Code of Conduct.
I've implemented a find/replace panel inside the Harlowe Toolbar… one could argue that it shouldn't be story format-specific, but I took the opportunity to incorporate some format-specific search options (search in prose vs. search in code, where the notions of "prose" and "code" are tied to the format's syntax). I guess other formats could provide their own find/replace functions that offer similar options.
As such, I'm not sure how this PR would fit in to the current Twine 2.5 UI. Maybe it would be good as a simple fallback for formats without editor extensions?
I'm really sorry for letting this PR sit so long. I would be willing to consider adding search in the passage editor now, but the process for UI-related PRs has changed--please see the CONTRIBUTING file. We should agree on the UI before implementation begins. I do think something we'd have to work through is that there would need to be a way for users on touch-centered devices to make it work; it couldn't be something we expose only through keyboard shortcuts.
