Tag mismatch error reporting

[AlanHK]

Tag mismatch error reporting.

Example: editing lines 424-6 file chapter-01.htm

<blockquote>
    <p class="noindent"><i>Intellect may fail you, but the killer instinct 
is invincible.</i></p>
  </blockquote>

If I delete the </blockquote> Sigil's Preview window shows :

This page contains the following errors:
error on line 437 at column 7: Opening and ending tag mismatch.

or if I do an F7 validation:

OEBPS/Text/chapter-01.htm Line 437 expected end of tag "blockquote"

(why can't I copy the text from this report? I had to manually retype it.)

-- line 437 is the </body> at the end of the file.


In Calibre editor if I do the same thing and run "Checkbook" it tells me:

ERROR: Parsing failed: Opening and ending tag mismatch: blockquote line 424 and body, line 437, column 9****[OEBPS/Text/chapter-01.htm]

When I have a missing tag, which happens to me at least quite a lot, what I need to know is where the OPENING tag is. Then I can usually see immediately where the missing tag should go.
Sigil just says it didn't find the end tag in the file.
So I have to scan through the whole file and check every tag pair of that type.

Or what I usually, is open it in Calibre and find and fix it at once.

Can Sigil report the location of the opening tag like this?
(And also allow text from the validation to be copied?)

[Notjohn]

Seems to me it would be faster to glance up at Line 434 and find the opening tag than to fire up Calibre!

I'm interested in the italics following the paragraph class. Does Sigil create a new class for such combinations, in your experience? It seems normal coding to me, but in my experience it gets overridden.

[AlanHK]

Originally Posted by Notjohn

Seems to me it would be faster to glance up at Line 434 and find the opening tag than to fire up Calibre!.

Yes. IF I knew to look on line 434. Calibre tells me that. Sigil doesn't.

I simplified the example. Plenty of times when I'm cleaning up some awful converted file I've waste minutes searching up and down the file through a forest of redundant nested codes looking for one orphaned tag.

I'm sure Sigil knows where it is, I want it to tell me where the start tag is and not just that the end tag isn't in the file.

Originally Posted by Notjohn

I'm interested in the italics following the paragraph class. Does Sigil create a new class for such combinations, in your experience? It seems normal coding to me, but in my experience it gets overridden.

(revised)

Sigil editor doesn't change CSS by itself.
If you have HTMLTidy active, it probably would. That's why people who edit code themselves never use it.
(Edit/preferences/Clean Source -- Pretty print just makes cosmetic changes (white space) and is quite safe. The full on HTMLTidy rewrites your code.)

One of the first things I do when I get a file is convert any CSS italic, bold spans to <i> and <b> using Diap's Editing Toolbag https://www.mobileread.com/forums/sho...d.php?t=251365 (again in Calibre, sorry).

[DiapDealer]

Originally Posted by Notjohn

I'm interested in the italics following the paragraph class. Does Sigil create a new class for such combinations, in your experience? It seems normal coding to me, but in my experience it gets overridden.

In my experience, a new class is only created when 1) the italic/bold tag encompasses the entire contents of the parent block-level tag (in this case <p>) and 2) when the Clean Source preference is is set to HTML Tidy.

If you set the Clean Source setting to Pretty Print only, no new css classes will be created. Likewise; if you leave HTML Tidy enabled, no classes will be created if the italic/bold tags only encompass portions of the parent block-level tag's content.

In short: if you don't want Sigil to create classes, then switch to pretty-print only (Clean Source).

[KevinH]

Try the Sanity Checker plugin for Sigil. It should tell you which tag it was expecting when the mismatch happened and print the queue of open tags.

KevinH

[DiapDealer]

Originally Posted by AlanHK

One of the first things I do when I get a file is convert any CSS italic, bold spans to <i> and <b> using Diap's Editing Toolbag https://www.mobileread.com/forums/sho...d.php?t=251365 (again in Calibre, sorry).

Don't be sorry. I just need to get off my lazy butt and port my calibre Toolbag plugin to work with Sigil!

[AlanHK]

Originally Posted by KevinH

Try the Sanity Checker plugin for Sigil. It should tell you which tag it was expecting when the mismatch happened and print the queue of open tags.
KevinH

Thanks, but doesn't tell me where the start tag is.

Using the same example text as my first post, tells me

Line 434 (end of the file)
Improperly nested tags: parsing end tag "body" but current parse path is "html.body.blockquote". near column 0

Originally Posted by DiapDealer

Don't be sorry. I just need to get off my lazy butt and port my calibre Toolbag plugin to work with Sigil!

Currently I often have the same Epub open in both Calibre and Sigil.
They are interchangeable 90% of the time, but each has a few features that the other lacks.

I just have to be careful to save and then reload when I switch between them.
-- Would be helpful if Sigil and Calibre noticed if the file had been changed and did it itself as some text editors do.

[rkomar]

I'm curious to know whether it is theoretically possible to know where the start tag with the missing end tag always is. I'm thinking about nested tags, and whether you can always know which start tag is missing the end tag. For example:

<tag>
<tag>
<\tag>

Which one has the missing end tag?

[AlanHK]

Originally Posted by rkomar

Which one has the missing end tag?

Yeah, it's ambiguous.

That's why I never let Sigil automatically fix code.
You need to work out the intent to fix it.

[kovidgoyal]

@rkomar: It is not possible for unstructured XML. However, the HTML 5 parsing algorithm, which is the standard algorithm browsers use to parse "tag soup" has various well defined rules for closing mismatched tags that cover most of these. calibre uses this algorithm to autofix html when you ask it too, and I believe Sigil will start doing so in the future as well.

[Notjohn]

Originally Posted by DiapDealer

In short: if you don't want Sigil to create classes, then switch to pretty-print only (Clean Source).

Well, that's been my situation for some time now (Pretty Print), but perhaps I was getting those on-the-fly Sigil classes before I made the change. (And yes, it well could have been an entire paragraph, in a list.)

Thanks for the explanation.

[KevinH]

FYI,
As Kovid said, the upcoming Sigil 0.9.0 has replaced Tidy with the gumbo-parser which is now a fully compliant html5 parser which will auto-fix these following the official html5 parsing rules. FlightCrew will become a plugin, and something like SanityCheck will become the internal tool to catch not well-formed errors.

I will modify SanityCheck to keep a queue of line-column info similar to the path info it keeps now so that you can see the line-col of the last opening tag and the line-col of the non-matching end tag.

KevinH

[AlanHK]

Originally Posted by KevinH

I will modify SanityCheck to keep a queue of line-column info similar to the path info it keeps now so that you can see the line-col of the last opening tag and the line-col of the non-matching end tag.
KevinH

Thanks, that's what I was hoping for.

[Notjohn]

Ain't Sigil great? Imagine complaining to the boffins at Microsoft about their products and getting an assurance that it will be taken care of!

[KevinH]

Hi,
I am finally back from my travels.

There is a new version of the SanityChecker v0.1.0 which should provide line and column information for the last start tag that was unmatched when tag mismatches happen.

Please let me know if this now does what you want.

Thanks,

Kevin

<html>
<head>
<title>testing & entities</title>
</head>
<body>
<p>this&nbsp;is*the*<b><i>copyright</i></b> symbol "&copy;"</p>
</html>

Now should generate this output

[(7, 0, 'Improperly nested tags: parsing end tag "html" but current parse path is "html.body". See line 5 col 0')]

KevinH