MobileRead Forums - View Single Post - Possible To-Do List for Future Sigil Releases Post Sigil 1.8

KevinH · 10-27-2021, 10:11 AM

So it is not an "ignore" button then? You may be asking for something similar to what Tex2002ans is asking. I am still not sure so a short video would definitely help.

Just so that you and others better understand searching and replacement inside Sigil:

Searching a group is not a single result set (ie. it is not a database-like search result set). It always sequentially finds each term in each xhtml file (also sequentially) and either counts them or does a replacement.

In replacement mode, it will sequentially replace that item and then start looking from there for the next match. If you decide not to replace, the cursor is not updated and so I think it is re-finding the same match. Moving the cursor forward one character before find next should skip to the next match in that same child (which is what my proposed ignore button would do under the hood).

Viewing it like a flat set is not easy as any replacement earlier in a file (or lack thereof) will invalidate all match positional information later in that same file as characters are added or removed from that string / file. This is especially true for the next child in the search group as earlier and later children positional information will be invalidated. That is why children are searched for sequentially in a string/file and a single match at a time.

For a single child search in a single file you can build up a file change set and sort them by starting position and apply the changes in reverse order to the file to prevent invalidating other results for that search term in that one file. But this is not possible for other search term replacements from a search group as they may actually overlap or build upon each other by design.

In fact with a sequence of regular expressions you can use the first to identify things and mark them and then use the second to examine the resulting marks to decide which to update and change and then in the third clean up any leftover markers generated by the first but not handled by the second. This must be done sequentially but it allows for very very complex conditions in regular expressions to be broken down unto a sequence of much simpler to follow regular expressions.

So yes, please show a short video of what is wrong and what you want it to do given the above.

Thanks,

KevinH

10-27-2021, 10:11 AM	#12
KevinH Sigil Developer Posts: 8,807 Karma: 6000000 Join Date: Nov 2009 Device: many	So it is not an "ignore" button then? You may be asking for something similar to what Tex2002ans is asking. I am still not sure so a short video would definitely help. Just so that you and others better understand searching and replacement inside Sigil: Searching a group is not a single result set (ie. it is not a database-like search result set). It always sequentially finds each term in each xhtml file (also sequentially) and either counts them or does a replacement. In replacement mode, it will sequentially replace that item and then start looking from there for the next match. If you decide not to replace, the cursor is not updated and so I think it is re-finding the same match. Moving the cursor forward one character before find next should skip to the next match in that same child (which is what my proposed ignore button would do under the hood). Viewing it like a flat set is not easy as any replacement earlier in a file (or lack thereof) will invalidate all match positional information later in that same file as characters are added or removed from that string / file. This is especially true for the next child in the search group as earlier and later children positional information will be invalidated. That is why children are searched for sequentially in a string/file and a single match at a time. For a single child search in a single file you can build up a file change set and sort them by starting position and apply the changes in reverse order to the file to prevent invalidating other results for that search term in that one file. But this is not possible for other search term replacements from a search group as they may actually overlap or build upon each other by design. In fact with a sequence of regular expressions you can use the first to identify things and mark them and then use the second to examine the resulting marks to decide which to update and change and then in the third clean up any leftover markers generated by the first but not handled by the second. This must be done sequentially but it allows for very very complex conditions in regular expressions to be broken down unto a sequence of much simpler to follow regular expressions. So yes, please show a short video of what is wrong and what you want it to do given the above. Thanks, KevinH