Thanks for your feedback.
I can do "if nothing is found do nothing" in the quick followup release but I need one additional piece of info ...
If the current file is part of the targeted file group, do we look just from the current cursor forward to the end of the targeted file group for a match , or for any match in the full targeted group (both before and after the current file)?
As for "Find First" and "Find Next", I am thinking about the following as being their behaviour:
1) If a user uses "Find First" when the target is a group of files (tabbed, selected or all files), it will treat it like a new search and start the search as the first file in the selected file group with order determined by the Book Browser (and what is in Tabs if that mode is selected).
2) If a user uses "Find Next" even if they have just changed what they are looking for), it just moves to the next match position using where ever you are now in the order and stop when it reaches the last file in the search group order.
This will in fact miss files that were earlier in the order than the current file and even possible miss things earlier in that very file.
To get those missed files, the user will have to use "Find First" purposefully or manually move to the first file in the group and position the cursor at the top and start searching from there.
3) If the user uses "Find Next" and the current file is *NOT* part of the targeted file group (ie. you are editing in a css file but then tell it to do find and replace in all html files) a "Find Next" will be treated effectively as a "Find First" since there is no "next" to find when the current file is not part of the search group.
4) Changes will also have to be made to Saved Searches as you do not want the end point of the previous search in a search group to impact all later searches in search group (ie. if your last search ends in the final file of the target groups you do not want all later searches to say nothing was found. Effectively, Saved Search groups must always restart from the beginning when a change in search is made (as is its behaviour in Sigil 1.9.0).
Is this the behaviour you are seeking?
If so, please note, the user must remember to use "Find First" instead of "Find Next" any time the search term is changed otherwise the last search may be at the end of the file group order and therefore all later searches will report nothing found. That was the exact behaviour I was trying to avoid as overloading "wrap" to mean one thing in Current File mode and something completely different in multiple file modes is just not the right thing to do in any case.
Using a "Restart Search" button and always restarting search if a change in what is being searched for is made, prevents these issues.
And fwiw, these types of changes would not be made in a quick follow-up release.
Thoughts?
Quote:
Originally Posted by icallaci
Thank you! I really like the idea of "Find First" and "Find Next." To answer your questions:
1) Is that the behavior you seek (not moving the cursor if nothing is found)? Yes.
2) How do you get back to your editing location normally after doing a Find that actually finds something in Sigil-1.8? I don't usually need to return to the original editing location. If I happen to notice an unrelated problem nearby, I will copy a key phrase so that I can return to it after I finish the original F&R. When I start a F&R, I move the cursor to a point just prior to the first instance, click Find, then Replace. After I make sure my replacement did what I expected, I either do a Replace All or else I step through a few more replacements to make sure it is behaving as expected. On complicated regex replacements, I may step through one at a time using Find and Replace to verify each one is correct. This is why Find Next/Find First would be extremely helpful and would probably solve the issue for me. I don't really need to return to my original editing position.
If you could find a way to implement Find Next/Find First, that would solve my problem. Thank you so much.
|