"Current File"/"Wrap" search behavior

[ElMiko]

Not a problem, per se, but a question about intention. I just noticed that if I perform a "Count All" within a file with "Current File" as the Mode, "Wrap" deselected, and the cursor at the end of the file, it will return a "No matches found" result.

Is this intended behavior? Is the "Count All" supposed to take the cursor position into account like this?

(To be clear, I can see a use case for this approach, but I'm curious if it's intended, or whether this might be changed in the future)

[Turtle91]

Yes. It is intended. It was changed a little while ago to correct errors in previous searches results.

If you start at the bottom of the page and turn wrap off on searching the current page only…. Then it is logical you won’t get a result. It is definitely different from the previous method but it does have logic/consistency. I think the only thing left that had some tweaking to do was the “Dot All” check box in options (IIRC).

[ElMiko]

Thanks, Turtle91. It doesn't seem to behave this way when "All HTML Files" is selected (and Wrap is deselected). Is this something that will be implemented in the future?

[Turtle91]

It still works. You selected to check all the files, so it does. It just won’t wrap. This was discussed pretty extensively in one of these threads - sorry, I don’t remember which. You can search the threads though…

[Turtle91]

This is how the User’s Guide explains it: (emphasis added)

Wrap: When enabled in Current File mode, if your search reaches the end of the file, it will automatically wrap around to the beginning of the file to continue the search (or the reverse if searching Up). When disabled, searches will stop at the end of the file (or the beginning if searching Up).

When searching in a mode that uses multiple files, when your search reaches the last file (in the order listed in the Book Browser), you will need to use the Restart button otherwise the search will stop. Wrap does not apply when searching multiple files.

[Turtle91]

It might be more intuitive if the options/selections were hidden (or disabled) when other options/modes are selected, but I think the developers have higher priority features they are working on. You could add that request to the latest Sigil Requests thread if you feel strongly about it!

[KevinH]

Disabling the wrap checkbox is really not something we are considering as wrap itself only makes sense when using Current Page searches.

Maybe something down the road but ...

[ElMiko]

Originally Posted by Turtle91

It still works. You selected to check all the files, so it does. It just won’t wrap. This was discussed pretty extensively in one of these threads - sorry, I don’t remember which. You can search the threads though…

I did do a search for "Current File" and couldn't find a relevant discussion. And I did read the guide this time! Bu that section is about what happens when the Wrap options is selected. The scenario I'm talking about has it DEselected.

So I'm a still a little confused.

If I select "Current File", deselect Wrap, place the cursor at the end of the file, and "Count All", it will return "no matches found".

If I select "All HTML Files", deselect Wrap, place the cursor at the end of the last file, and "Count All", it will return all the matches in the document.

Why does one operation use the cursor position as a limiter and the other does not?

[Turtle91]

All HTML files = it searches all of the files (wrap setting is ignored)

Current File = wrap selected means it will reach the end of the file and wrap back to the other end to continue the search. wrap not selected means it will stop searching the file when it reaches the end of the file (as determined by the direction of search Up/Down).

Count all = how many matches are there based on the selections you have. If you select all files, then it searches all the files (ignoring wrap setting). If you have current file selected then it will start at the cursor position and move to the end of the file in the direction selected (Up/Down) and taking into account whether you have wrap selected.

[KevinH]

Because one is limited to a single file where direction (up vs down) and wrap (yes vs no) make sense. Anytime multiple files are selected as the target, a state based (starting state is saved so ending state is known) search is done that will clearly tell you when you have reached the end (ie. visited all matches just once). This is very useful when running search groups from saved searches, etc. Before users were forced to revisit previously handled searches, keep track of where they were , where the search started etc.

Searching only within the current file allows you to control wrapping. It also allows you to control marked text search, direction, etc.

This is all explained in the Sigil User's guide.

[philja]

Re-reading the Sigil User's Guide reveals an apparent contradiction in advice concerning the 'Wrap' option. I'm referring to the guide for versions 2.3.0 and later.

In the 'Find and Replace' chapter, specifically in the 'Where to search' section, under each of the multiple file options bullets ('All HTML Files', 'Selected HTML Files' ... etc), it specifically states:

If Wrap is turned on, it will loop around until all files have been searched.

Whereas, further along in that chapter under 'Search Options', it states the contrary:

When searching in a mode that uses multiple files, when your search reaches the last file (in the order listed in the Book Browser), you will need to use the Restart button otherwise the search will stop. Wrap does not apply when searching multiple files.

[KevinH]

The second quote is the accurate one and has been for years. I will try to remember to fix that firstquote or remove it but user guide pull requests are always welcome, too.

[philja]

Originally Posted by KevinH

The second quote is the accurate one and has been for years. I will try to remember to fix that firstquote or remove it but user guide pull requests are always welcome, too.

I'd be happy to make the mod to the Guide but I'm not familiar with using github. Can you point me to a useful 'howto' ?

EDIT: I think I've done the edit and submitted a pull request. I hope!

[KevinH]

I looked and there are no open pull requests open at our sigil-user-guide repo.
Unless you develop your own software, getting to grips with github just to submit a pr for our users guide is probably asking too much.

If you want to you can just send me a diff (patch) for the impacted xhtml file and I will see it gets applied.

If not, I can try to lead you through the process of forking the sigil-user-guide repo. Using the FolderIn plugin to read it into Sigil where you make changes and pass it through epubcheck to validate. Use FolderOut to save your changes. Then commit those changes to your fork, before using github's web interface to generate a PR request.

[philja]

Ah! It's defeated me. After extensive reading of the docs at github, I managed to create a fork and clone it to my desktop machine. I installed Folderin and FolderOut and got the src into Sigil where the edit was a doddle. FolderOut worked ok and I checked my clone content and it was updated.

Despite many efforts and lots of doc reading and hassles with passwords (which they ask for but abolished use of in 2021), tokens, installing CLI software etc- the push to my fork seemed to go ok on the cli but when I investigated the find_replace.xhtml in src on my fork online, it had not been modified (updated).

Next effort was to edit the find_replace.xhtml from line 230 inside my fork online - saved and was presented with a Commit dialog followed by a Pull request dialog which I completed. It all looked good.

But when I log in this morning, the find_replace.xhtml is still unchanged. So I don't understand where I went astray - but, it is hellish complicated.

I don't like being defeated.

Edit: Further searching online in my fork shows that after editing the xhtml file, in the save procedure I created a new branch pj7-patch-1. When I look inside this branch, my edits to the find_replace.xhtml file are there ok. And the pull request is logged as made there.

So it looks like I didn't understand how to do the Pull request. Amongst other things.

Feeling humbled.