Quick Question

[Doitsu]

Originally Posted by DiapDealer

How exactly does highlighting the closing tag help though?

For example, poorly converted books might contain redundant nested <div> tags. Tag highlighting helps to identify the closing tag and prevents users from deleting the wrong tag.

[DiapDealer]

That may be the difference. I never bother trying to manually untangle an unruly div nest (even though 'Prettify' makes divs fairly easy for me to navigate) these days. So I'm never really looking for a particular closing tag in the first place. If the markup in question can't be safely/quickly regexed, then I turn to a parsing tool to safely match and delete/change tag pairs. Knowing where the closing tag is ahead of time provides no benefit in my editing process. *shrug*

[un_pogaz]

In the same vein as Doitsu, it can also be useful when a large number of <span> are using it or when an aberrant use is made of it.

I know that here we are all more or less expert, and that we avoid this kind of situation, but when we try to repair a book... from the internet , conversion problems or the use of poor quality WYSIWYG editor are common.

And then it's not a big highlight red. The example of Notepad++ is excellent: discreet, but easily visible if you look for it specifically.

(Obviously to the extent that it can be implemented)

[DiapDealer]

If only there were a parsing tool (usable within Sigil) that could help a user easily and safely change/delete tag pairs (even in a rat's nest of nested elements) without needing to know which particular closing tag went with which opening tag.

[Doitsu]

Originally Posted by DiapDealer

If only there were a parsing tool (usable within Sigil) that could help a user easily and safely change/delete tag pairs (even in a rat's nest of nested elements) without needing to know which particular closing tag went with which opening tag.

And what parsing tool might that be? (I know that CTRL+. will add a closing tag, but don't know any keyboard shortcut for deleting tag pairs.)

[DiapDealer]

I think it has the words 'Tag' and 'Mechanic' in the name.

[Doitsu]

Originally Posted by DiapDealer

I think it has the words 'Tag' and 'Mechanic' in the name.

Sounds vaguely familiar. Are you sure that it works as advertised

[DiapDealer]

Originally Posted by Doitsu

Sounds vaguely familiar. Are you sure that it works as advertised

Most of the time.

[theducks]

Originally Posted by DiapDealer

That may be the difference. I never bother trying to manually untangle an unruly div nest (even though 'Prettify' makes divs fairly easy for me to navigate) these days. So I'm never really looking for a particular closing tag in the first place. If the markup in question can't be safely/quickly regexed, then I turn to a parsing tool to safely match and delete/change tag pairs. Knowing where the closing tag is ahead of time provides no benefit in my editing process. *shrug*

Baen has one of the messiest (unnecessary) Div nests I have seen. Whatever Slit method they use, I generates a additional Nested Div per Chapter (file)

This is my BaenDeDiv search (I adjust the calibre# as it varies

Find="(?sm)<div class=\"calibre4\" id=\"calibre_pb_\\d+\">\\s+<p (.+)</p>\\s+(<div class=\"calibre6\" id=\"calibre_pb_\\d+\"></div>\\s+)*</div>"
99\Replace=<p \\1 </p>

By the last chapter, it can be 30+ levels (I repeat this Replace All many times until Not Found status appears)

[DiapDealer]

So you don't need to know where the closing tag is either! You just run your regex repeatedly.

[Tex2002ans]

Originally Posted by Doitsu

For example, poorly converted books might contain redundant nested <div> tags. Tag highlighting helps to identify the closing tag and prevents users from deleting the wrong tag.

Agreed, and one of my favorite sayings I always promote: at-a-glance.

When you're trying to correct ugly code, seeing the highlight out of the corner of your eye at-a-glance speeds up debugging.

Those fractions of a second add up!

Again, back to the URL examples, many times you get junk where URLs are duplicated near punctuation:

<a href="reallyreallylongurl">"Example article</a><a href="reallyreallylongurl">"</a><a href="reallyreallylongurl">.</a><a href="reallyreallylongurl"></a>

where you want clean:

<a href="reallyreallylongurl">"Example article"</a>.

(This error is very common where authors are designing purely WYSIWYG [articles from CMSes, Google Docs, DOCX].)

With Highlighting Tags

You click in the first <a>, see the matching </a> in your peripheral.

Your brain goes into "debug the code" mode:

• Click in 2nd <a> and see 2nd </a> highlighted.
  
  • Your eyes jump to the highlight, then move left 1 position. You see " should've been in previous link.
• Click in 3rd <a> and see 3rd </a> highlighted.
  
  • Your eyes jump to highlight again. You see the closing . wasn't meant to be </a> at all.
• Click in 4th </a>.
  
  • Expect a given <a> tag to light up. Doesn't happen. Hmmm...

With Syntax Highlighting

You click in the first <a>.

"Debug the code" mode:

• Your eyes begin skimming <a href="reallyreallylongurl">"Example [...]
  
  • Your eyes jump to the nearest </a> you can see.
    
  • May land on 2nd or 3rd </a>, especially when URLs + inner text gets very long.

Your eyes are going from left->right.

The colors help, but once you start seeing lots of <a> and </a> close together, the markup can visually merge into a big blob. Brain trying to parse and look through markup/colors at the same time.

Computer instantly parses. No errors. Brain very slow and error prone. Computer help brain. Brain feel better! Brain not need work so hard!

Side Note: On all this UI/UX design and QoL enhancements, there was this set of fantastic videos by Tentacrul covering little niggles and inconsistencies adding up:

• "Music Software & Bad Interface Design: Avid’s Sibelius"
• "Music Software & Interface Design: MuseScore"
• "Music Software & Interface Design: Steinberg's Dorico"

He breaks down:

• Eyes needing to bounce back and forth.
• Common things buried in menus (and menus in menus in menus)
• Checkboxes with reset buttons
• [...].

then gives recommendations on how they can be enhanced. Lots of great info that could be applied across many programs.

Originally Posted by DiapDealer

If only there were a parsing tool (usable within Sigil) that could help a user easily and safely change/delete tag pairs (even in a rat's nest of nested elements) without needing to know which particular closing tag went with which opening tag.

In the case of <a>, I also make heavy use of Tools > Reports > Links. Absolutely fantastic for spotting junk in links.

But again, that's sometimes where Calibre's highlighting is more helpful. As I'm jumping around the book, clicking into <a> tags, you can more quickly/easily parse code using your eyes.

Side Note: Another method I've used is this one:

Search: (<a href="[^"]+">)([^<]+)</a>\1
Replace: \1\2

OR:

Search: (<a href="[^"]+">)([^<]+)</a><a href="[^"]+">
Replace: \1\2

First one catches exact same URL right next to each other. Merges them together.

Second one catches any URL right next to each other. Merges them together.

And yet another basic:

Search: </a><a <---- Put a space here

points our links that are right near each other. Usually something fishy's going on when that happens.

Originally Posted by Doitsu

Sounds vaguely familiar. Are you sure that it works as advertised

I never heard of this tool in my life.

[Hitch]

Originally Posted by DiapDealer

I think it has the words 'Tag' and 'Mechanic' in the name.

Oh, yes, wondrous.

But may I add my wee voice to the "it would be lovely to be able to highlight the matching tag" group? IF it's convenient, of course.

Hitch

[Thasaidon]

Originally Posted by Hitch

Oh, yes, wondrous.

But may I add my wee voice to the "it would be lovely to be able to highlight the matching tag" group? IF it's convenient, of course.

Hitch

Of course you may. Your "wee voice" is always welcome.

I agree. IF the work needed to implement the above is doable, not excessive and convenient I am sure KevinH and Diap will seriously consider implementing it in a future release.

N.B. Guarantees and/or timescales should not be requested!

[Hitch]

Originally Posted by Thasaidon

Of course you may. Your "wee voice" is always welcome.

I agree. IF the work needed to implement the above is doable, not excessive and convenient I am sure KevinH and Diap will seriously consider implementing it in a future release.

N.B. Guarantees and/or timescales should not be requested!

Of course! One has no right to harangue or beleaguer those who nobly volunteer their time.

We do still see a lot of cleanup, with stuff that's so nested that it's devolved backward right into its own egg, so...tag matching would be loverly.

Hitch

[Thasaidon]

Originally Posted by Hitch

Of course! One has no right to harangue or beleaguer those who nobly volunteer their time.
Hitch

I apologise Hitch, I have just realised my N.B. comment might have been taken to be aimed at you.

It most Certainly Was NOT!

Unfortunately there are some forum members who I think, shall we say, are over forceful and sometimes verge on disrespectful in the way they put forward RFQ's to KevinH and Diap. It was people of this water I was addressing.