Possible bug?

[Lexicon]

Using Sigil 0.2.3, Windows XP 32bit. Searches on all HTML documents seem to be missing out the last document.

I've tested this on a few different epubs by opening a document other than the last one and searching (all documents, normal mode, direction all) for text which is definitely in the last HTML file. It won't find it, however if I open the last file and select search within the current file it will find the text with exactly the same search string.

Also adding a blank file to the epub and repeating the global search will find the text okay, as the target text is now in the second to last HTML file.

[theducks]

Originally Posted by Lexicon

Using Sigil 0.2.3, Windows XP 32bit. Searches on all HTML documents seem to be missing out the last document.

I've tested this on a few different epubs by opening a document other than the last one and searching (all documents, normal mode, direction all) for text which is definitely in the last HTML file. It won't find it, however if I open the last file and select search within the current file it will find the text with exactly the same search string.

Also adding a blank file to the epub and repeating the global search will find the text okay, as the target text is now in the second to last HTML file.

I have been (mostly) lucky so far. I blamed S+R misses on ME.
Nice to hear that I may have been having Help

[Lexicon]

Bizarrely global search and replace seems to be working okay, it's just global search that doesn't work to find text in the last file.

If I search for a target phrase I get the "cannot be found" message, but if I try to replace the text with something else I get a message saying that it has been changed one time. Open the last file to check and sure enough the substitution has been made.

So it seems any missed s+r's are still user error I'm afraid to say

[theducks]

Originally Posted by Lexicon

Bizarrely global search and replace seems to be working okay, it's just global search that doesn't work to find text in the last file.

If I search for a target phrase I get the "cannot be found" message, but if I try to replace the text with something else I get a message saying that it has been changed one time. Open the last file to check and sure enough the substitution has been made.

So it seems any missed s+r's are still user error I'm afraid to say

RATS !

[Valloric]

Please report it on the tracker. Instruction on doing this are here.

Frankly I think there's a bug report about this on the tracker already, and that it's caused by QDom not storing XML attributes in document order, but sorted. That bug will be fixed when Xerces is integrated.

Then again, your bug could be different, so just report it with the information necessary to reproduce it.

[Lexicon]

Sorry, Valloric, I've got signup fatigue and don't want to create a Google account. I already have a million different logins and passwords to keep track of.

I just thought I'd let people know about this so they can avoid the problem, the easiest workaround at the moment is to add a blank page at the end of the epub and then remove it just before final save.

[Valloric]

Originally Posted by Lexicon

Sorry, Valloric, I've got signup fatigue and don't want to create a Google account. I already have a million different logins and passwords to keep track of.

I just thought I'd let people know about this so they can avoid the problem, the easiest workaround at the moment is to add a blank page at the end of the epub and then remove it just before final save.

Well then it probably won't be fixed any time soon. The bug is certainly related to the document in question and the search terms used, and without this information, I can't track the bug down.

If you don't want to add it to the tracker, you can provide this info in this thread. Attach the document etc., as outlined in the link I referenced.

[Lexicon]

I don't think it is the files I'm working with, I can reproduce the behaviour with a very simple epub created from scratch in Sigil.

Using Sigil 0.2.3, Windows XP 32bit.

1. Open Sigil.
2. Select code view and enter "<p>cat</p>" (without the quotes) into the body of Section0001.xhtml.
3. Add a new text item.
4. Open Section0002.xhtml and select code view, enter "<p>mongoose</p>" (without the quotes) into the body of the file.
5. Switch back to Section0001.xhtml code view, open the find dialog and type "mongoose" (without the quotes) into the Find what box. Choose to Look in all HTML files. Options are: Normal search mode, Direction all, no other boxes ticked.
6. Click find next.

What should happen:

Sigil should find the word in the second xhtml file, switch focus to that file and highlight the text.

What actually happens:

Sigil reports that the search term cannot be found even though the text is definitely in the epub.

Workaround:

7. Add a new text item to the end of the list (there are now 3 xhtml files in the epub, the last one has not been modified).
8. Switch back to Section0001.xhtml code view, open the find dialog and type "mongoose" (without the quotes) into the Find what box. Select to Look in all HTML files. Options are: Normal search mode, Direction all, no other boxes ticked.
6. Click find next. Sigil locates the relevant text in Section0002.xhtml.

[pietvo]

I tried the above recipe on my Mac to see if it had the same bug. I had in the past noticed that Sigil sometimes couldn't find a word that I knew was in the book. However, after I successfully searched the word in the second file I wanted to return to the first file and Sigil became completely unresponsive, swallowing up CPU time. Apparently it got stuck in some loop. I had to manually kill it.

[theducks]

Originally Posted by pietvo

I tried the above recipe on my Mac to see if it had the same bug. I had in the past noticed that Sigil sometimes couldn't find a word that I knew was in the book. However, after I successfully searched the word in the second file I wanted to return to the first file and Sigil became completely unresponsive, swallowing up CPU time. Apparently it got stuck in some loop. I had to manually kill it.

I stopped using Direction "All", just too many odd things (not) happening that "cockpit error" cold not account for

Some misses in WYSIWYG turn out to be what you can't see differences in that mode.

I was searching on * * *
underneath the covers (CV) was

<p><b>* </b><b>* *</b></p>

Looks the same in BV

[st_albert]

Originally Posted by theducks

I stopped using Direction "All", just too many odd things (not) happening that "cockpit error" cold not account for

Same here. Seems that "Direction = all" leads to an infinite loop somewhere (and it ain't Cupertino )

[theducks]

Originally Posted by st_albert

Same here. Seems that "Direction = all" leads to an infinite loop somewhere (and it ain't Cupertino )

Silicon Valley local ?

Could someone else check this S+R annoyance out.

Win XP
Do a S+R, leave the S+R window, continue scrolling the document, even set an insertion point.
Now close the S+R window.
Does the document reset it's position from current?

[st_albert]

Originally Posted by theducks

Silicon Valley local ?

Born a few miles from there. But that was before there was a Silicon Valley. In fact, I don't think Silicon had been added to the periodic chart yet.

Back to our previously scheduled topic, I tried the experiment that Lexicon described, EXCEPT that I searched with Direction = Down, and it did find the unique text in the second (of two) files, switched focus (it was already open) to that file, and highlighted the text just as I'd expect it to work. Ditto if file was not open. Note that files must be in "code view," or at least all open files must be.

I repeated it with a previously-made epub having 31 files, with the same result. Searching for text that was unique to the last file resulted in the correct behavior.

BUT! Repeating the search with "Direction" = "All" gave the "not found" error.

Moral of story: Do not use "Direction" = "All".

[Valloric]

Bug confirmed and fixed.

GOD how I hate single-character bugs.

On a related note, that was one awesomely written bug report. Clear, concise, reproducible. Keep 'em coming.

Originally Posted by st_albert

Moral of story: Do not use "Direction" = "All".

To me, the moral of the story is: report the bugs you encounter.

...and double-check your corner cases. As much as I hate typos, they hate me back.

[Hitch]

Originally Posted by theducks

Silicon Valley local ?

Could someone else check this S+R annoyance out.

Win XP
Do a S+R, leave the S+R window, continue scrolling the document, even set an insertion point.
Now close the S+R window.
Does the document reset it's position from current?

Ducky:

If you're asking if (in XP):

1. You do a S&R;
2. then you close the S&R window,
3. and the cursor position in the CV window is reset (usually to the top of the file), even though you had it in the location you wanted before you closed the S&R window?
   

Then the answer is YES, it most certainly is, about 75-80% of the time. It's very annoying. I tried to capture it with Jing for Valloric, but it's just inconsistent enough wherein nearly every time I start to run the video, it doesn't bloody do it...and running Sigil and Jing simultaneously, the latter in video mode with a window size large enough to capture the action sucks the life out of my cpu.

Hitch