#15 "Find matching tag" - Slow Response

[Yaron]

Thank you so much for the HTMLTag plugin.

In medium-size files (e.g. langs.xml), the execution of the "Find matching tag" command is often very slow (30 seconds).

If the caret is on <Languages> at the top of the file, the response is fast.
If, however, the caret is on <Languages> at the bottom of the file, the response is slow.

What might cause this behavior?

[Yaron]

https://sourceforge.net/p/notepad-plus/discussion/482781/thread/1ed3f576#f496

[Martijn Coppoolse]

You're right, I've noticed it too, but haven't had the time to look into it. I might do so this weekend. I've no idea what causes this; it started quite a few Np++ versions ago. Do you know if searching backwards has also become slower recently?

[Yaron]

Hello Martijn,

I haven't encountered a problem in "Find Previous"; - but that's not equivalent to "Find Opening Matching Tag".

I do hope you find a solution.

Thank you. I appreciate your work.

[Martijn Coppoolse]

'Find Previous' with a regular expression might have changed... Cf. the following line of code:

NextTag := doc.Find('[^%\?]>', SCFIND_REGEXP or SCFIND_POSIX, Tag.StartPos, 0);

in http://fossil.2of4.net/npp_htmltag/artifact/dc40445bdd5200d3e11fff9ed31a04f7e9b93cae?ln=249

I'm not on Windows atm, so can't test it. Will look at it tomorrow.

[Yaron]

I wish I could contribute more at this stage. I'm not a pro.

I'll be looking forward to your findings.

Many thanks.

[Martijn Coppoolse]

Hm... Reading the comments in Notepad++'s own tag matching code:

// Tags matching routing rewritten by Dave Brotherstone May 2012
// to remove need for regular expression searches (especially reverse regex searches)
// Reverse regex are slow using the new regex engine, and hence cost too much time.

So that's the cause of the problem: the 'new' engine for regular expressions is slow when searching backwards. :-(
That means I'll have to find a way to avoid using regular expressions when searching backwards. Not going to happen right now, sorry.

[Yaron]

Thanks again. I hope you find a workaround.

Best regards.

[Dave Brotherstone]

Not much to say here, other than yes, backwards regex search with the new engine is pretty slow. It's not really built for that. Reverse regex search would be doable by reversing the actual regex, which I think would be pretty complicated, at least if you expected the same results. The internal tag matching routine basically emulates the tiny amount of regex that is needed using a simple search. So in your example,

NextTag := doc.Find('[^%\?]>', SCFIND_REGEXP or SCFIND_POSIX, Tag.StartPos, 0);

We'd just change that to (excuse syntax, but you get the idea)

Do
    NextTag := doc.Find('>', 0, Tag.StartPos, 0);
While(NextTag != -1 And (doc.CharAt(nextTag-1) == '%' Or doc.CharAt(nextTag-1) == '?'))

Dave

[Yaron]

Thank you Dave.

I have just recently started using VS 2013, and I can't open the HTMLTag plugin's project files in it.

I'm grateful for your help.

I hope Martijn will find the time to fix it.

Best regards.

[Martijn Coppoolse]

@Yaron: you won't be able to open the HTMLTag plugin with Visual Studio, because it was written in Delphi.
@Dave: thanks for the reminder that the solution needn't be all that complex. I'll try and implement it as soon as I can (it's a bit more convoluted than you suggested, due to my implementation of Find -- which returns an object that needs to be destroyed after use. This was one of my first real Delphi projects ever).

[Yaron]

Thank you Martijn.

Good luck!

[Martijn Coppoolse]

Yaron,

Would you try downloading the new unicode version from http://fossil.2of4.net/npp_htmltag/ and test it?

I think I've managed to fix the problem, but my life's a bit hectic atm, I'm a bit tired, and I'm not sure I haven't missed any edge cases or made some silly coding mistake. ("It seems to work fine on my machine").

If it's fine, I'll see about uploading the new version to the plugin manager sometime next week.

[Yaron]

Hello Martijn,

I do hope you get better soon.

And thank you so much for finding the time to fix the reported issue.
A brilliant work!

With your permission, a few comments (tested on langs.xml):
1)
Go to the line <Language name="normal" ext="txt"/>.
Position the caret on "Language".
Press "Find matching tag" (- the caret is moved to the end of the line).
Press "Find matching tag" again.
- Result: the caret isn't moved back.

2)
Position the caret on an opening tag (first "<NotepadPlus>").
Press "Find matching tag".
- Result: the caret is moved to the end of the closing tag.
Wouldn't it be better to always move the caret to the beginning of opening/closing tags?

3)
Position the caret on "getTransform" (appears once).
Press "Find matching tag".
- Result: the caret is moved to the closing "</Keywords>".
Is that the expected behavior (- rather than no action at all)?

---

I have compared HTMLTag plugin's behavior with that of EditPad.
http://www.editpadpro.com.

I appreciate your kindness, and truly wish you the very best.

[Martijn Coppoolse]

Hello Yaron,

Thanks for your comments!

On my machines, it's not just the caret that is moved; the entire matching tag is selected — that is by design. That's why the caret is always moved to the end (although I guess I could also put the caret at the start of the selection).
Is the matched tag not selected on your machine?

Also, when the caret is located in text between two tags, the plugin should find the first preceding opening tag, and then select its matching tag.

[Yaron]

Hello Martijn,

I hope you are doing well.

Thanks again for your excellent work.

The entire matching tag is selected on my machine as well.

Comment #1 and Comment#2 seem to be related.
If the caret was always moved to the beginning of opening/closing tags (it makes sense), then the user would get some reaction after pressing "Find matching tag" again in the example given in Comment #1 (i.e. the caret would move to the beginning of the line).

These are really minor issues, and HTMLTag plugin works like a charm.

Comment #3:
So, the bug is in EditPad. :)

Best wishes.

[Martijn Coppoolse]

I’m relatively better now, thanks.

Well... I wouldn’t say EditPad has a bug; its author just made a different design decision.

I’ll put your proposals #1 and #2 on the feature request list. Putting the caret at the beginning of a matching tag does make sense; and toggling the caret between start and end of a self-closing tag does too.

[Yaron]

Hello Martijn,

I'm glad you feel a bit better.
Life is full of ups and downs.

I liked your noble remark regarding EditPad.

Special thanks for the Feature Requests.
Please wait with them until you get much better. :)

Again, I wish you the very best.