Sigil-1.9.0 Release

[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.

[KevinH]

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?

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.

[Turtle91]

I've always thought that the "Wrap" option was pretty intuitive... if you get to the end of the file/group (either Up or Down) it would continue the Find at the beginning of the page/group until it reached the original starting position.

Could this functionality carry over to your new Find/Replace process? Is there a specific reason that Wrap is limited to the current page only??

I will, of course, adjust my brain to whatever method Sigil ends up implementing, but I regularly start searches at my current position and expect to end them at that position without any missed area in whichever file (or group of files) I have selected. If I do NOT want it to search a specific section then I manually clear the "Wrap" checkbox and specify which direction Up/Down I want the search to go and start the search from a specific location.

[KevinH]

The issue is that wrap on a current file in a single file search and wrap over a group of files are two very different things.

I had no idea that the order of search ALL HTML files actually matters to anyone, as the very first find that results in a match will become the beginning position for a completely new search and so on with and without wrap. You can easily miss things especially when wrap means two different things here.

To me I want new searches over "all html files" to always follow the same order (depending on direction set - up or down) and always not miss anything without the need for wrap to mean something different. If my target is all files, I want it to cover all files no matter how wrap is set, leaving nothing as missed (guaranteed).

If I actually want to re-run the exact same search over the same set of target files, I want something like a "Restart" button that will actually be tell Sigil to do that and it should only very very *rarely* be needed.

People seem to want to use "All HTML Files" to mean "Remaining HTML Files" even though that makes missing things even more common (with and without the wrap setting). If a search ends in the final file of a search target group, all subsequent searches will fail unless, I change what "wrap" means form wrapping in a file to now be wrapping around a set of files.

And all of this makes it impossible to skip replacements when running individual searches in Saved Search Groups which is how much of the heavy lifting for initial cleanups (especially for things based on scans) is done.

I get it that some people instead want to walk the text chapter by chapter and want to fix things wrong they find in this chapter (and then in all chapters) and then somehow return back to where they started. But that did not even work in earlier Sigil as finding your first match moved you away from your initial position (which in turn made this approach even more fraught for errors of omission). That is why I asked how people got back to where they started even under older Sigil. I still do not understand it.

That said, I can make it so that if nothing is Found in a search, that your file and cursor is restored.

I could even try something like that for Replace All and return you to the same file you started in but actual cursor position may be off if a replacement was made earlier in the current file.

I really do not want to go back to needing "wrap" to mean two different things at two different times and I really want the entire set of search target files to be searched and replaced in the order specified with or without wrap as that is what "All HTML Files" says.

Hope this explains things a bit better.

I just hope we can evolve this into a happy medium for everyone. Right now in current master I can keep position for all Counts and when nothing is found. I could add that for ReplaceAll (at least at the file level).

But perhaps the "Find First" and "Find Next" approach is the way to go in the long run. That is what I was trying to figure out.

Thanks,

KevinH

Originally Posted by Turtle91

I've always thought that the "Wrap" option was pretty intuitive... if you get to the end of the file/group (either Up or Down) it would continue the Find at the beginning of the page/group until it reached the original starting position.

Could this functionality carry over to your new Find/Replace process? Is there a specific reason that Wrap is limited to the current page only??

I will, of course, adjust my brain to whatever method Sigil ends up implementing, but I regularly start searches at my current position and expect to end them at that position without any missed area in whichever file (or group of files) I have selected. If I do NOT want it to search a specific section then I manually clear the "Wrap" checkbox and specify which direction Up/Down I want the search to go and start the search from a specific location.

[icallaci]

This discussion is very interesting, because I assumed, like Turtle91, that "wrap" (whether restricted to the current file or for all HTML files) means starting from the current position and finding the very next instance, then the next instance, and the next, etc. until it reaches the end of the current file, at which point (if "All HTML files" is selected) it moves to the next file and continues the search. (I am assuming the direction to be searched is "down." If the search direction is "up," then the the "end" of a file would actually be the "top," etc.). When it gets to the end, it starts over (sort of like an automatic "Restart Search" button) and continues until it finds no more matches. If I replace the first match, then of course I would not be brought back to my original starting point because it would no longer match the search criteria. I think this is how Sigil has operated in the past, because I purposely have re-run searches, and I don't remember any missed matches.

In other words, my definition of "wrap" means that F&R just keeps cycling through the files until I stop clicking on "Find" or until it stops finding any matches.

Anyway, your points #1, #2, and #3 would work for me. I rarely use Saved Searches, so I can't speak to point #4.

[Ashjuk]

Originally Posted by KevinH

Under Sigil-1.8, if you do a Find, the cursor will always move to the newly found location and will highlight the what was found, even opening up the next file if needed (assuming the target is set to All HTML files) never staying where it was. The only way it will not move is if nothing was ever found.

Is that the behaviour you seek (not moving the cursor if nothing is found)?

Yes. If nothing is found then, in my mind, the cursor should stay where it was.

Originally Posted by KevinH

And how do you get back to your editing location normally after doing a Find that actually finds something in Sigil-1.8?

Or are you doing a ReplaceAll at that point and just want keep the cursor where it was?

I do not use find on its own a great deal, it's more as a replacement function for me. If I do happen to use find it is usually just within the current file, and if I want to return to the last editing point I just make a mental note of the line number so that I can scroll back to it.

Originally Posted by KevinH

Thanks for taking the time to explain what you used to see and what you are seeing now with the new Find and Replace behaviour that is bothering you.

Kevin

And thanks to you for taking the time to try to help with this issue. As I said previously I am happy to continue with 1.8 as that is more than sufficient for my needs.

[snarkophilus]

@kevinh I've only just installed 1.9.0 and have just tested a search or two and find the "new search goes back to beginning of group" a little weird too. Your #1, #2, #3 seem quite reasonable. Alas I also don't use saved searches much, so can't comment in #4 (yes, keep meaning to use them more ...).

One workflow I use a lot is "^F, type something, <enter>" and I am used to that starting from the current position in the current file and searching forwards to end of current file then on to next in the group and so on. With the proposed Find First and Find Next, which type of search would <enter> choose? And if it was Find First, could this pretty please be configurable? I suppose logic like "last used Find type" might be a bit more difficult?

PS: Thanks as always to you and Diap for another release!

[icallaci]

Originally Posted by KevinH

People seem to want to use "All HTML Files" to mean "Remaining HTML Files" even though that makes missing things even more common (with and without the wrap setting).

I just noticed this comment and want to say that I expect "All HTML Files" to mean just that: ALL HTML files, not "remaining" HTML files. I use "Selected HTML Files" if I want to restrict the F&R to certain files, but even then I would expect F&R to continue to wrap through the selected files and not stop at an arbitrary point just because I started in the middle somewhere. LOL, we are a demanding bunch and you are very patient. Thank you.

[Turtle91]

Originally Posted by icallaci

I just noticed this comment and want to say that I expect "All HTML Files" to mean just that: ALL HTML files, not "remaining" HTML files. I use "Selected HTML Files" if I want to restrict the F&R to certain files, but even then I would expect F&R to continue to wrap through the selected files and not stop at an arbitrary point just because I started in the middle somewhere. LOL, we are a demanding bunch and you are very patient. Thank you.

There may be some people who are not as familiar with the new find options that were added recently (Selected and Tabbed Files)... but I definitely never expect "All HTML Files" to mean "Remaining HTML Files". I expect it to only search the remaining files if I have Wrap turned off.

[DiapDealer]

I think Kevin meant that people view "All HTML Files" as "Remaining HTML Files" in the sense that they want "Find" to start at the current cursor position/file and then move on to the "Remaining Files" (and then back to the original cursor position depending on the "Wrap" and "Direction" settings). Whereas Kevin's definition of "All HTML Files" means to start at the beginning of the first file and search to the end of the last file--once. And in its current state, "Wrap" would be rather pointless for "All HTML Files", since all files have already been searched from beginning to end.

You may not THINK you're treating it as Remaining HTML Files, but depending on the point view, you sort of are. *shrug*

But so long as everyone is on the same page as to what they want, the terminology isn't really all that important.

Note: I'm not really taking a position on whether the 1.9 changes to Search are better or worse. They're just different. So long as I understand the rules, I don't really care. I just adapt.

[KevinH]

And after a sleepless night last night due to brain cells that would not stop firing, I think I *may* have a way to get the best of both worlds without hurting the new Saved Search capability at all. No promises but give me a couple of days to see if I can keep the Restart button behaviour and no wrap across target files needed, and adjust the start position to always be the current file.

Worth a shot without having to once again rewrite the user's guide and replace all of the newly changed F&R images.

[icallaci]

Thank you! Take as much time as you need. No worries if it doesn't work out. And I hope you get some sleep tonight.

[KevinH]

FWIW, I have just pushed to master changes to always start new searches with the current resource if it is in the set of targeted search files.

This should return Sigil to using the search order people expect but still allow for SavedSearches to not use wrap when searching groups of files so that Replacements can be skipped from the Saved Search Dialog when running a large search group.

This is very experimental so I am going to need a couple of days testing it to make sure I have not introduced any new breakage.

If anyone is willing to help test on macOS, I would be happy to post a build for people to try. We could probably do a Windows build for testing if desired..

If anyone builds from source from current master and tries doing F&R or SavedSearch searches, and reports back any issues, that would help as well.

Hope this does the trick!

KevinH

[icallaci]

Wow, you are amazing. Thank you again. I look forward to giving it a workout.

[snarkophilus]

@KevinH Happy to test if there's a Win10 build available. I checked a while ago, and I think the old (a year or two ago?) CI build thing doesn't seem to exist anymore?