It is not possible to preserve the italic, bold or any other attribute when replacing.

For instance:

you want to replace "is one" with "is not one". What should be italic? "not" or "one"? How about replacing it with "is not long"? Or if you're replacing "is one paragraph" with "is not good", what should be italic?

This goes into some higher theory about parse trees and parent-child descendants. Point being, you can't know in advance when you're replacing that some part of the text should become a child of the current element. It's theoretically impossible.

Every word processor I know does what Sigil does too.

RC2 is now online. Blog post with info here.

It would help some if the blog post had a link to the download page.

Overall excellent work. :)

Under help - about you should update the version with each release. Now it says 0.2.0 I would have expected it to say 0.2.0 rc2.

I'm easily confused and since it wasn't there I wasn't sure if I had actually updated on one of my machines.

Sigil looks very good.
I have a couple of questions;

When I do a Ctl+S or select SAVE from the file menu, I get the screen which says it cannot save htm.

When I do a SAVE AS, the only option is to save as Epub.

I would like to save the work file.

Where do I err?:blink:

Well save it as epub then. :)

Epub is Sigil's native file format.

Found a possible showstopper in Search and Replace.

Issue 378: version 0.2.0 RC2 search & replace for "all html files" hangs if the Find search string is not found. Works OK if you select look in "current file". Operating system in Windows XP.

I had a hang
I was looking for: * * * *
and I had wild card checked.

You'll need to provide more information than that. See the wiki page.

I just noticed you said you were using wild cards with that search string. If that is the case, then the hang is not a bug in Sigil, the problem is with your search string.

What you had is called Regex Catastrophic Backtracking. Matching that string takes an exponential amount of time, so Sigil just keeps trying to match it, counting the chars, backtracking, counting more, backtracking etc.

With that search string used as a wildcard, you would hang everything from Perl to grep to any other application. Read the linked page.

Long story short, the bug is in your search string. :)

I realize that :o :o :smack:

There needs to be a graceful way to abort when you mess up :D

I lost my un-saved work because the only way was Kill Process

There is no graceful way to abort that operation.

Say you're working in the python console. You type in 2**2, it prints out 4. The you type in 2**3, it prints out 8. Then 2**4, result 16.

Then you type in 2131434234532**38728284872.

It's not going to tell you "Hey smartass, that will take a couple of years". :)

Point being, the computer is doing what you told it to do. You can't blame it for that.

I'm not sure, but maybe PCRE can detect catastrophic backtracking. I plan on integrating it, so we'll see then. But I can't force QRegExp to behave differently. And it's not doing anything wrong, it's matching the way you told it to.

What it's doing wrong is , it's not allowing the user to interrupt and abort the matching operation.

... or there could be some setting to "abort operation if it has taken more than X seconds and it's not yet finished", with a helpful message of what could be wrong and how to modify X if needed.

I'll take a look, but it will not be easy to do. Not by a long shot. Cross-file searching is done with many threads, and making sure something doesn't explode when you kill them takes a while.

It certainly won't be in the final 0.2.0. Only showstopper bugs and trivial features are getting in now.

64 bit Windows default install folder
 

This is a bit of a nitpick, granted, but is there a reason the 64 bit windows installer defaults to "Program Files (x86)", where 32 bit applications go, instead of "Program Files", where 64 bit applications go?