Sigil 0.5.3 Released

[theducks]

Originally Posted by meme

Ok, I can duplicate this on Windows, but not on Ubuntu.

But just to be clear - this is only an issue if you are on a stylesheet (and possibly any non-html tab) and do a search on All HTML files (which obviously doesn't include the stylesheet anyway, although I can see why it would be a common search). If you are on an html tab and do the all html search, it should work. And it seems to be fine if you are on a non-html tab and the search is found.

I think Sigil should ignore the All setting if on a CSS, OPF, NCX.
I have had it jump (5.1) from a stylesheet search onto regular HTML pages.

[meme]

Originally Posted by theducks

I think Sigil should ignore the All setting if on a CSS, OPF, NCX.
I have had it jump (5.1) from a stylesheet search onto regular HTML pages.

The setting is for All HTML Files - and that's what it does, searches just HTML files, not stylesheets, images, etc. It means you can do your search without having to move from the stylesheet to an HTML page and it means you don't get and error message telling you to switch to an HTML page when you've told it to search All HTML.

If you want to search a stylesheet - use Current File.

[Rand Brittain]

It's definitely avoidable, but I frequently forget to switch back to "current file only" mode and end up losing data.

[Jabby]

"Tidy" no longer seems to work. I am running W7 x64 and other than that, have found no major problems. The F&R got a good workout.

Having a hit on the "find next" highlight the chapter, in the book browser, helps a lot. Many thanks for this one.

Regards - John

[theducks]

Originally Posted by meme

The setting is for All HTML Files - and that's what it does, searches just HTML files, not stylesheets, images, etc. It means you can do your search without having to move from the stylesheet to an HTML page and it means you don't get and error message telling you to switch to an HTML page when you've told it to search All HTML.

If you want to search a stylesheet - use Current File.

You misunderstood.
I am searching a stylesheet
I forgot and left the range set to All HTML
The search finishes the stylesheet and jumps to a regular page, no user intervention required.

This reaction may (not proven) have some relation to Where in the current TAB order the CSS was opened.

[meme]

Originally Posted by theducks

You misunderstood.
I am searching a stylesheet
I forgot and left the range set to All HTML
The search finishes the stylesheet and jumps to a regular page, no user intervention required.

This reaction may (not proven) have some relation to Where in the current TAB order the CSS was opened.

No, I think I understood right. If you select All HTML Files then the search will only search HTML files. If you are on a non-html file it will switch to the first HTML file in the book browser and start there. If you are on an html file, it will start with the file you are on.

Now, if you are saying you do a find in the stylesheet with All HTML files and it finds something in the stylesheet first and if you continue to find it jumps to HTML, then thats wrong - I'll retest that.


Its possible I should rethink trying to be helpful by automatically switching you to html files if you use All HTML. If there is a risk that most people will forget to change the setting when going to a stylesheet and then use replace all and cause unexpected replacements or just not understand why find did what it did, then I'll look at modifying the code to either warn you that you can't use all html while not on an html page, or switch automatically to current file. It was changed because the code was inconsistent in how it handled F&R for different tabs and it followed on from automatically switching you to code view from book view if you did a replace to avoid a dialog box. (Either way of course it shouldn't crash).

[theducks]

Originally Posted by meme

Its possible I should rethink trying to be helpful by automatically switching you to html files if you use All HTML. If there is a risk that most people will forget to change the setting when going to a stylesheet and then use replace all and cause unexpected replacements or just not understand why find did what it did, then I'll look at modifying the code to either warn you that you can't use all html while not on an html page, or switch automatically to current file. It was changed because the code was inconsistent in how it handled F&R for different tabs and it followed on from automatically switching you to code view from book view if you did a replace to avoid a dialog box. (Either way of course it shouldn't crash).

I thought I noticed I was not getting Nagged about forgetting to switch to CV when setting a Search All HTML
I had not realized that the starting page type (CSS) did not override this (ignore the all).
I was ot smarted by the Smarter Function

[ElMiko]

This has happened twice now...

regex search in all HTML files for:

([a-z])'([a-z])

and another search for:

([a-z])- ([a-z])

in both cases, the replace value was

\1\2

and in both cases, it replaced the found strings with "\1\2" instead of the appropriate references.

for what it's worth, for the following S/R, there were no problems:

S: <span class="italic">(.*?)</span>
R: <i>\1</i>

so it may be just a question of using multiple references...

(I'm running Windows Vista)

[Timur]

The problem mmat1 and ElMiko described(back references not resolving for some instances and replacing with back reference text itself, while doing step-by-step replacement) happened to me in 0.5.1 as well. Windows 7, 64-bit.

[jbacelar]

Sigil 0.5.3 ravage the user_dict.txt in words with accent (spanish).

No problem with any old versions.

XP-32

[huebi]

Originally Posted by theducks

I think Sigil should ignore the All setting if on a CSS

No, if you are inspecting the CSS and want to know where a special class is used its nice to start the search there and not change to any other (X)HTML page,

[DiapDealer]

I've had the issue with the replacement strings being "\1" or "\1\2" instead of the proper contents of the backreferences since 0.5.1 as well. But it's very inconsistent and I haven't been able to track down the exact circumstances under which it happens.

[meme]

Originally Posted by DiapDealer

I've had the issue with the replacement strings being "\1" or "\1\2" instead of the proper contents of the backreferences since 0.5.1 as well. But it's very inconsistent and I haven't been able to track down the exact circumstances under which it happens.

Originally Posted by Timur

The problem mmat1 and ElMiko described(back references not resolving for some instances and replacing with back reference text itself, while doing step-by-step replacement) happened to me in 0.5.1 as well. Windows 7, 64-bit.

Found/fixed the issue. It only happens with Replace in All HTML Files, and only if you are at the bottom of one file and hit Replace to go find the first match in the top of the next file - when you hit Replace again it leaves the \1\2 items instead of doing the replace because the location of the last found text info wasn't being updated correctly.

As a workaround, if your Replace goes to the next page, just click on the beginning of the file and do the Replace again.

I actually didn't see this at first because I already had it working in my version as part of implementing the new Spell Check find - after fixing what I thought was a new issue.

[DiapDealer]

As a workaround, if your Replace goes to the next page, just click on the beginning of the file and do the Replace again.

I was doing this (without actually knowing why) and seemed to be working for me, but I wasn't overly confident in the results. Thanks for confirming.

[theducks]

Thanks for finding this (\1 \2), I was thinking I was getting careless in my testing my search expression phase