0.6 Beta take 4 (0.5.907)

[Gunnerp245]

When deleting a sectionxxxx.html in .906 the book view/code view would advance to the next sectionxxxx.html automatically; in .907 it does not.

[meme]

It seems to work ok for me. Just to be sure - when you delete a file in the Book Browser window on the left, the selection should move to the next file shown in the Book Browser. It does not change the tab (unless the file you deleted was open in the current tab). Can you list your exact steps?

[theducks]

Originally Posted by Gunnerp245

When deleting a sectionxxxx.html in .906 the book view/code view would advance to the next sectionxxxx.html automatically; in .907 it does not.

IMHO It is not that the selection so much moved to... as that file collapsed into the current cursor location.
OTOH Merge seems to deliberately open the destination file (if not open) and give it focus.

[Oldpilot]

For what it's worth, the latest Beta (Beta-Beta?) takes longer to crash than did the first version I tried, and it actually does crash (Has Encountered a Problem and Needs To Close) rather than simply vanishing off my screen. I actually opened, looked through, and saved an epub created by the previous build (5.3?). It wasn't until I tried to open a new html file that it went pear-shaped.

[meme]

Originally Posted by theducks

IMHO It is not that the selection so much moved to... as that file collapsed into the current cursor location.
OTOH Merge seems to deliberately open the destination file (if not open) and give it focus.

Exactly - two ways of describing the same behaviour

Delete does not open the newly selected file anymore as it is not necessary and wastes time and clutters up your tabs if all you want to do is delete the file. But Merge opens the file since you almost certainly want to see the effect of your Merge.

Originally Posted by Oldpilot

For what it's worth, the latest Beta (Beta-Beta?) takes longer to crash than did the first version I tried, and it actually does crash (Has Encountered a Problem and Needs To Close) rather than simply vanishing off my screen. I actually opened, looked through, and saved an epub created by the previous build (5.3?). It wasn't until I tried to open a new html file that it went pear-shaped.

If there's any chance you could post the epub or PM a link to kiwidude and myself that would be great.

When you 'open a new html file' - what did you do exactly: add a new blank html file, File->New EPUB, or open and select an html file from your disk? (if the latter can you post/pm that as well).

So are you saying it crashed (actually exited after you confirmed the prompt and it didn't just open a blank epub) when you loaded a file - not when you were doing something with the file? The distinction is important because a 'crash' when loading a new file is somewhat understandable - although lots of cases have been coded for, there may still be some very troublesome HTML or EPUB files that may not be able to be handled by Sigil. Crashes when adding an html file or when doing an operation are not expected.

[kiwidude]

@meme/Oldpilot - Oldpilot reported issues with the 905 beta as well and sent me an ePub at the time that worked perfectly fine for me. I am inclined to believe it is some other software/Qt conflict on their machine of some kind, particularly since they claimed continuous crashes with new epubs etc.

My suggestion at the time was for them to try Sigil on another machine, a virtual machine or safe mode with the same epub inputs etc. Something Oldpilot said they would try and that is the last I heard from them.

So unless this time around there really is a problem with a specific ePub (always possible, but based on the previous experience I would suggest unlikely) the onus is really on Oldpilot to try a different machine and see if they have the same issues. Because *nobody else* has reported the same issues on Windows systems. Whether Sigil 0.5.3 works or doesn't has little relevance, as so many components and code have changed. It might be some antivirus type conflict, hardware level like the historical Wacom issues, graphics drivers or any one of a number of other environmental issues. If we can't replicate it, we can't do anything about it.

[mrmikel]

Kiwidude

I found that bug you were looking for. I added a paragraph tag through clip, then I pressed the control period. It inserted the </p>. Then I switched to book view and got the red warning in book view about the tags not matching. It appears that an extra </p> tag got inserted just above </body> when I pressed control period. I eliminated that and it went away.

This is the section in question.
<p class="capt">THE AIR PLAN FOR THE LANDINGS IN NORMANDY, 6 JUNE 1944</p> <!-- Mirrored from http://www.ibiblio.org/hyperwar/UN/U...RAF-III-5.html by HTTrack Website Copier/3.x [XR&CO'2010], Wed, 26 Sep 2012 11:59:12 GMT --><!-- Added by HTTrack --><!-- /Added by HTTrack -->(extra /p tag was here.)
</body>
</html>

[kiwidude]

@mrmikel - sorry you have me confused. Is this something you are able to replicate at will? If so, can you give us the exact steps (and attach a sample epub if that is necessary)? Because if I just take your paragraph text above and switch to BV it works fine. If I add a </p> at the point you put the "(extra /p tag was here.)" then as expected I get an interactive prompt warning me it is not well formed preventing me switching to BV.

And if instead I hit ctrl+. at that position, the text that gets inserted is "</!-->". Now that is a bug in the insert closing tag logic, but it isn't the cause of your issue.

[meme]

First, Book View is the left of the 3 icons on the tool bar (a book which is Book View, a book with <> on it, which is Preview, and just <> which is code view). The Red text only appears in Preview. Are you sure you are switching to Book View and not Preview View.

Second, can you be more precise about what text you are adding by clip and where. e.g. are you just adding a "<p>" - and if so I assume manually typing "<p>" has the same effect (just to eliminate clip from this discussion).

In other words can you list your exact text before you do a ctrl ., and tell us where you click before you press ctrl ., and what the text is after you press it, and what happens when you switch to Book View after.

The </p> should only have been added where you pointed if there was an open p before it. But in your text the previous open tag is <!-- and so I get </!--> when I do ctrl . (which is wrong, but not the issue you stated). Hopefully we can find the issue.

[mrmikel]

It was blank at the beginning of THE AIR PLAN. I right clicked and selected from imported clips, the <p class="capt">. I went to the end of JUNE 1944 and used control period to insert a </p>. Then I clicked on book view and got the red screen message. I went back to code view and saw that an extra </p> was added just before </body>. I deleted it and then it went back to book view without any further problem.

It may not be a consistent thing. I have not encountered it until this morning since the last time.

[kiwidude]

@mrmikel - I'm sorry but that just isn't sufficient detail to reproduce this, and it seems meme can't either so I know it isn't just me. There must be something else involved, be it the document or the steps leading up to this. Even your description doesn't make sense - doing ctrl+period at the end of the text where you said the extra </p> was won't put one there due to the bug in insert closing tag both of us mentioned.

Please try it again yourself with a full set of steps, and give us the exact attachment, email if necessary.

[mrmikel]

I will try again, but it has been several days since the last time.

I did not put the cursor at the end of the comment, I put it much before it and an extra </p> ends up at the end before the </body> tag in addition to the desired location.

I will try to edit down that same document and see if I can get it to do it again.

[Gunnerp245]

@meme
@kiwidude
@theducks

Originally Posted by Gunnerp245

When deleting a sectionxxxx.html in .906 the book view/code view would advance to the next sectionxxxx.html automatically; in .907 it does not.

I see a what is happening...

If deleting the 'first' file, e.g. section001.html, in the book browser tab the next file, e.g section002.html, in the list is automatically shown in the book/code view.

However, when deleting any file from the book browser tab that is also open in the book/code view tab, the deleted file is closed and the next file already open in the book/code view tab is shown.

This seems normal and not an issue.

[mrmikel]

Another thank you for a feature I probably have discovered years after everyone else...double clicking on the file in flight crew to take you to the location of the issue.

[theducks]

Originally Posted by mrmikel

Another thank you for a feature I probably have discovered years after everyone else...double clicking on the file in flight crew to take you to the location of the issue.

Most of the time

The dread: "...Reference of some kind..."