0.6 Beta take 4 (0.5.907)

[WS64]

Thanks Kiwidude & John!

[ElMiko]

Originally Posted by kiwidude

@ElMiko - if the selection contains line feed characters, then indeed it does look like Paste Clip is broken in this build (have fixed for next release).

However your comment about the text between heading tags - that is also text that happens to contain line feed characters in it? As if it is normal text on a single line that works fine for me? If it isn't a multiple line issue then please give us more repro details/sample file.

You're right; i misdescribed the issue. The bug appears to be even more situation specific than simply "text between heading tags"... additional testing has proved that if the selected text in question has parentheses, it trips up the application of clips.

eg:

1 <h3>A Wise Child</h3>

2 <h3>A (Wise) Child</h3>

in line 1, selecting the text between the heading tags applies the clip "<p class="calibre1">\1</p>" just fine. But in the second line, it just remains inert, as with trying to apply clips over multiple lines of text. For the record, I'm not sure if there are additional triggers other than parentheses to this bug.

EDIT: I've found 5 (or 6, depending on how you count) more characters that break the application of a clip: square brackets, carets, asterisks, back-slashes (\), and vertical slashes (|) (in this last instance, the clip is applied, but only to part of the selected text). Basically, it looks like it's having trouble escaping special characters when it applies the regex contained within the clip. Since my own understanding of reg-ex is still in what i'd consider "early stages", I'm not sure if there are other special characters, or combinations of characters that will trigger this error.

EDIT2: additional characters that cause the error: "$", "+", "?". Periods, however, don't seem to be causing a problem.

[kiwidude]

@ElMiko - ahhh, that is an interesting one. And I know exactly why that would be happening too. Behind the scenes when you apply one of those fancy \1 substitution "clips", it turns the selected text into a regular expression. The PCRE engine cannot cope with the unicode line feeds which is why your first problem occurred. However it also will of course get itself confused when being passed text that contains text like your example, as it must make sure to escape the text first in case there are any other regular expression characters in it.

I will sort it out for the next build, that is a very subtle and nice bug to find, well done .

[mmat1]

Originally Posted by meme

Regex options have moved to the chevron button at the bottom left on the Find & Replace box

I love it ....

[ElMiko]

Originally Posted by kiwidude

I will sort it out for the next build, that is a very subtle and nice bug to find, well done .

my... pleasure?? I wish i could say i'd found it in the course of diligent and professionally-minded beta testing. But it was pure dumb luck. still, let's go with "diligent and professionally minded".

[theducks]

Originally Posted by mmat1

I love it ....

Double
I really like the new F&R buttons (features)

(And I had spotted the arrow for the advanced features )

[kiwidude]

Originally Posted by mmat1

I love it ....

Awesome, about time for the good news to start appearing on this thread. A slight worry that a couple of users had problems finding the expand button. Perhaps we should leave it expanded for first time use so worst case people at least know where those options are available.

Originally Posted by ElMiko

my... pleasure?? I wish i could say i'd found it in the course of diligent and professionally-minded beta testing. But it was pure dumb luck. still, let's go with "diligent and professionally minded".

Yeah well we have spent a silly amount of hours in our own testing, which while it brought out dozens of things we could catch there was always going to be something we didn't think to try.

[theducks]

Originally Posted by kiwidude

A slight worry that a couple of users had problems finding the expand button. Perhaps we should leave it expanded for first time use so worst case people at least know where those options are available..

Brilliant idea leaving it open.

It is amazing the number of users that do not explore, or even recognize markings that mean more. (Of coarse, there is a chance that they will also never close it . These are probably the same people that still have all the feature advertising stickers on their 5 year old VCR

[meme]

So much for trying to make it subtle so it wouldn't get in the way


Thanks for the feedback so far - its annoying that a few things were missed in all the latest changes and testing, but they should be minor or avoidable.

As user_none said - only bug fixes from this point on. And with the plan to release the final version in a week we really need everyone to try it out and comment. We'll list anything found under known issues in the first post.

[meme]

The Sigil User Guide will take some time to update, but you can view the What's New page for a list of features and updates for 0.6.0.

[mmat1]

Originally Posted by kiwidude

Awesome, about time for the good news to start appearing on this thread. A slight worry that a couple of users had problems finding the expand button. Perhaps we should leave it expanded for first time use so worst case people at least know where those options are available.

Yes, but unfortunately ....

"Replace" / "Replace&Find Next" seems not to work properly

find:<p>(Chapitre[^–]+?)\K ([^–])
Replace: – (read: blank Ndash blank)
Options: Single Line, Regex, Current File

The Position is located correctly. With "Replace" nothing is replaced. With "Replace&Find Next" it just jumps to the next position.

"Replace all" works and saves the day

[meme]

Could you provide some text that you are trying to match?

EDIT: I'm not sure what text you are matching, but if I use the following then I do see a difference in 0.5.906 and 0.5.907 (.e. it change to ndash in 906 but not the current beta). Will look into it.

<p>Chapitre - 1</p>

[atjnjk]

The first exploration of this beta: Click the chevron button (what a beautiful subtle button), hover over DotAll and Minimal Match checkboxes (require patience for one second)... tada, their tooltips magically change places.
PS: Still exploring this wonderful beta land.

[crutledge]

The attached EPUB has an in-line LOI. The latest Sigil inserts the correct path for the first image and no paths for the remainder of images.

First Image:

    <div class="justify">
      <a href="../Text/The%20Enchanted%20Typewriter_0004.xhtml#front">FRONTISPIECE: I GAZED IN OPEN-MOUTHED IN WONDER</a>
    </div>

Second Image:

    <div class="justify">
      <a href="#image01">"TATTOOED THE JINGLE BETWEEN MY SHOULDER BLADES"</a>
    </div>

I load the html to Sigil and Generate TCO.
Validation reports no problems.

[DiapDealer]

Probably need to take a look at the original html before you started editing with Sigil. I'd wager to say you did some file-splitting, as well.