Syntax Highlighting extra feature

[jackie_w]

I just read in one of the other threads that the Editor's syntax highlighting was written from scratch. As such I wonder whether it might be possible to introduce a feature which I've found endlessly useful in Notepad++ over the years.

If one left-clicks anywhere inside a tag then that tag and its corresponding end-tag are highlighted. e.g. in the following html:

<p class="tx"><span class="bold"><span class="it"><span class="dropcap">T</span><span class = "sc">his</span> is a paragraph</span> with lots of spans.</span></p>

Clicking anywhere in the <span class = "it"...> tag would show like this (except NotePad++ colours background rather than foreground text):

<p class="tx"><span class="bold"><span class="it" id="urhere"><span class="dropcap">T</span><span class = "sc">his</span> is a paragraph</span> with lots of spans.</span></p>

The lack of this feature in Sigil often made sorting out spaghetti nested html easier in the old ebook Tweak for me because I could use my normal editor. Retail Publishers seem to love endless nested divs which don't actually do anything.

[theducks]

Tag pair matching
Yes!

To be honest, I rarely need to use this feature EXCEPT when tweaking (de-nesting) some commercial books.

While not incorrect, Why use all those added levels of Divs and Spans?

Having a simple stylesheet for the 'page type' seems so much nicer than:

<div class='body'> 
<div class="chapter">
 <div class=ChapterHead"> ... with even more nested divs...</div>
<div class="chapterbody">

Thankfully, most books are NOT coded this way

Having this feature would help with Paragraphs that use (and need to) many <spans, some even nested.

right-click: show/jump to closing tag

[arspr]

Another vote for that tag highlighting idea (and the jumping right click option)

[kovidgoyal]

There are lots of editor enhancements on my todo list. Autocomplete, auto-indent, tag matching and so on. However, these are all nice to have features that will cause a performance hit as well and are therefore not high priority.

[arspr]

Sorry about the post length but I haven't been able to make it shorter.

Another related suggestion. But entering brainstorming mode (so please do not laugh quite loudly if some of the things I say are plainly sci-fi)

As this thread has begun, one of the common issues with books is overnested, overcomplex chain of tags. So one of the "possible" common editings is fine-tuning and removing that unnecessary tags, collapsing them in more simple patterns.

But it is not so easy to do in an automated way with common Search and Replace All tools. Because you have to set up a search which covers for the starting tags, the contained code/text and then the ending tags. So your S&R must catch: <tag1 to remove><tag2 to remove>...<even more tags to remove>Content</ending tags>...</tag2></tag1> and then transform it in <new tag>Content</new tag>.

You are forced to use Regex and, in fact, to use VERY complex Regex settings even if possible. And always prone to errors because you cannot really "program" in regex something about look for the ending tags of this. You always look for text patterns, and maybe your very first </tag2></tag1> match comes from even another nested pair of similar tags, so you can make fatal mistakes.

Would it be possible to add (a) S&R option(s) about tag modification so just an initial "tag" search would be needed and the software would automatically modify their ending tags? No additional need to include "code" about the general content and ending tags in either the Find or Replace boxes. (IIRC Sigil is supposed to do it in some cases but I never found it quite reliable in any way).

Apart from the coding difficulty/effort which I cannot evaluate, if possible, this new feature could be launched through a new drop-down menu in addition to Normal/Regex and Search Location. Let's call it Automatic Tag update. It would have (remember I'm on brainstorming mode) three possibilities:

• OFF. No more explanation needed.
• CONSERVATIVE. It means that the matched searched text will be changed into the replacement text ONLY when their related closing tags are all continuous with no additional content in the middle. In other words if I have ...whatever content.</tag2> More content here in the middle</tag1>, its initial starting tags match would be filtered out from the search results.
• AGGRESSIVE. The opposite. All the Find matches are considered. In a situation like the previous one, what you would get after the replacement is made would be ...whatever content. More content here in the middle</new tag>. I mean all the closing tags of the replaced code are actually deleted and the new closing tag is inserted in the original last position.

I suppose there are lots of difficulties about a coherent implementation of this powerful feature but it can open a whole new world in the way of cleaning existing and absurdly complex ebooks.