Goto Matching Brace for HTML/XML

Lycan Thrope

@Michael-Vincent ,
I’ve read the other responses with interest, and maybe I’m out in left field on this, however, what I see in your code, is that you’re using if, to check for what I presume is the matching tag position. Correct?

And if that is the case, and I’m spitballing here, it looks like to be, that your code upon a successful find, is following the next instruction, which is: _pEditView->execute(SCI_SETINDICATORCURRENT, SCE_UNIVERSAL_TAGMATCH);

Unless that if condition is supposed to return a true/false logic, or an actual position, it seems like it’s doing what you want, but it’s just not returning a value to you, and since I can’t see any other code, such as maybe a variable to hold that value so you can evaluate it, isn’t the code doing what you want?

Like I said, I’m not real experienced with doing anything with the Scintilla or Editor messages, but from my humble programming capability, I’m just pointing out what I normally would expect to see regards code. For instance, in a, VM type environment like dBASE’s command window, you can issue code to check for things, and it will do the job, but if you didn’t give it a variable to hold that value and then display it, it will do what you ask without returning that value visibly? Understand what I’m taking note of?

I guess I need to try and dabble in this to see what’s going on, but from an outside perspective, that’s what looks like is happening to me. :-)

Edit: I should have read past @PeterJones 's response. :-), now I see what you’re asking about, but I think what you’re saying you want it to do, seems to me to be counterproductive to finding the matching closing tag, if it also highlights unrelated tags that aren’t really that specific tag’s closing tag. Understand what I’m getting at? Sorry if I misunderstood the desired end result as it wasn’t really clear to me in your original post. In hindsight, if it’s possible, wouldn’t you want that condition to loop and find all those positions as well as starting positions and saved into an array so you can re-reference them and color them in sequence of matches?

Michael Vincent

@Lycan-Thrope said in Goto Matching Brace for HTML/XML:

in your code

It’s not my code - it’s Notepad++ code “notepad-plus-plus/PowerEditor/src/ScintillaComponent/xmlMatchedTagsHighlighter.cpp”

A picture worth a thousand words, I want to do this:

(source: https://github.com/formulahendry/vscode-auto-rename-tag/raw/HEAD/images/usage.gif)

Seems the pasted picture isn’t animated, but the link to the original is. I’m happy to press some magic key-combo as well before typing to “Select matching HTML/XML tag”.

Cheers.

Lycan Thrope

@Michael-Vincent ,
Thanks for that clarification. So you want to be able to select the word in the opening and closing tag, which will allow you, at the first key press, to insert in front of the tag at both positions to insert the text you type. Correct? That’s interesting and maybe that’s a worthwhile capability that the developers may like to include if it doesn’t already exist in a magic key. :-)

Edit: Again, since I don’t have the experience, but couldn’t a Python script do that for you? Find the tags, highlight them, put insertion points at the beginning of both of the tags text, and then insert the keypresses. Sounds doable. :-)

rdipardo

@Michael-Vincent said in Goto Matching Brace for HTML/XML:

I want to do this:

Your GIF shows a VS Code extension which has been superseded by the rename tag feature (basically F2, “rename all occurrences,” but only affecting the matching tag):

vscode-v141-tag-rename

I think the closest you could get with Notepad++ right now would be manual selection with multi-editing enabled, e.g.

npp-multi-replace

Michael Vincent

@rdipardo

Correct. So I take it my feature request:

If I document this as a feature request Issue on the HTMLTag GitHub, would there be a slight chance of adding that?

I’d consider a PR myself, but alas, I don’t know Pascal.

won’t be considered?

Here is my hacked NppExec script. It does “basically” what I want, but uses folding to find the matching tag, not ideal.

Note it does not handle if there are multiple of the same tag on the same line:

::selectMatchingTag
NPP_CONSOLE keep

NPP_CONSOLE disable
NPP_EXEC lang
NPP_CONSOLE enable
IF "$(LANGNAME)"=="XML" GOTO START
IF "$(LANGNAME)"=="HTML" GOTO START
NPP_MENUCOMMAND Search\Go to Matching Brace
GOTO END

:START
SCI_SENDMSG SCI_GETCURRENTPOS
SET LOCAL STARTPOS = $(MSG_RESULT)
SCI_SENDMSG SCI_INDICATORVALUEAT 27 $(STARTPOS)
SET LOCAL CURRINDIC = $(MSG_RESULT)

IF "$(CURRINDIC)"!="1" GOTO END

SET LOCAL REVERSE = 0
SET LOCAL STARTTAGLINE = $(CURRENT_LINE)
SCI_SENDMSG SCI_GETLASTCHILD $(CURRENT_LINE) -1
SET LOCAL ENDTAGLINE = $(MSG_RESULT)
IF $(ENDTAGLINE)==$(CURRENT_LINE) THEN
    SET LOCAL REVERSE = 1
    SET LOCAL ENDTAGLINE = $(STARTTAGLINE)
    SCI_SENDMSG SCI_GETFOLDPARENT $(CURRENT_LINE)
    SET LOCAL STARTTAGLINE = $(MSG_RESULT)
ENDIF

// CURRENT_WORD automatically selects it as well
SET LOCAL STARTTAG = $(CURRENT_WORD)
SCI_SENDMSG SCI_GETSELECTIONSTART
SET LOCAL STARTTAGSTARTPOS = $(MSG_RESULT)
SCI_SENDMSG SCI_GETSELECTIONEND
SET LOCAL STARTTAGENDPOS = $(MSG_RESULT)

IF $(REVERSE)==0 THEN
    SCI_SENDMSG SCI_POSITIONFROMLINE $(ENDTAGLINE)
    SET LOCAL ENDTAGSTARTPOS = $(MSG_RESULT)
    SCI_SENDMSG SCI_GETLINEENDPOSITION $(ENDTAGLINE)
    SET LOCAL ENDTAGENDPOS = $(MSG_RESULT)

    SCI_SENDMSG SCI_SETSELECTIONSTART $(ENDTAGSTARTPOS)
    SCI_SENDMSG SCI_SETSELECTIONEND $(ENDTAGENDPOS)

    SCI_FIND "NPE_SF_WHOLEWORD | NPE_SF_SETSEL | NPE_SF_INSELECTION" </$(STARTTAG)>
    IF $(MSG_RESULT) == -1 THEN
        GOTO END
    ENDIF

    SCI_SENDMSG SCI_GETSELECTIONSTART
    SET LOCAL ENDTAGSTARTPOS ~ $(MSG_RESULT) + 2
    SCI_SENDMSG SCI_GETSELECTIONEND
    SET LOCAL ENDTAGENDPOS ~ $(MSG_RESULT) - 1
ELSE
    SCI_SENDMSG SCI_POSITIONFROMLINE $(STARTTAGLINE)
    SET LOCAL ENDTAGSTARTPOS = $(MSG_RESULT)
    SCI_SENDMSG SCI_GETLINEENDPOSITION $(STARTTAGLINE)
    SET LOCAL ENDTAGENDPOS = $(MSG_RESULT)

    SCI_SENDMSG SCI_SETSELECTIONSTART $(ENDTAGSTARTPOS)
    SCI_SENDMSG SCI_SETSELECTIONEND $(ENDTAGENDPOS)

    SCI_FIND "NPE_SF_WHOLEWORD | NPE_SF_SETSEL | NPE_SF_INSELECTION" <$(STARTTAG)
    IF $(MSG_RESULT) == -1 THEN
        GOTO END
    ENDIF

    SCI_SENDMSG SCI_GETSELECTIONSTART
    SET LOCAL ENDTAGSTARTPOS ~ $(MSG_RESULT) + 1
    SCI_SENDMSG SCI_GETSELECTIONEND
    SET LOCAL ENDTAGENDPOS = $(MSG_RESULT)
ENDIF

// ECHO $(STARTTAGLINE) ($(STARTTAGSTARTPOS)-$(STARTTAGENDPOS)) -> $(ENDTAGLINE) ($(ENDTAGSTARTPOS)-$(ENDTAGENDPOS))

// SCI_SENDMSG SCI_GOTOPOS $(ENDTAGSTARTPOS)
SCI_SENDMSG SCI_SETSELECTION $(STARTTAGENDPOS) $(STARTTAGSTARTPOS)
SCI_SENDMSG SCI_ADDSELECTION $(ENDTAGENDPOS) $(ENDTAGSTARTPOS)

:END

rdipardo

Correct. So I take it my feature request:

If I document this as a feature request Issue on the HTMLTag GitHub, would there be a slight chance of adding that?

I’d consider a PR myself, but alas, I don’t know Pascal.

won’t be considered?

Come to I think of it, someone asked a while back if HTML Tag could select both matching tags at once. If that were combined with multi-caret editing (with a workaround for the current limitation to mouse-guided selections only), we might have a decent alternative to tag renaming in VS Code . . . 🤔

Michael Vincent

@rdipardo said in Goto Matching Brace for HTML/XML:

a workaround for the current limitation to mouse-guided selections only)

There is no such limitation programmatically. You just need to use SCI_SETSELECTION and SCI_ADDSELECTION to create the multi-caret editing on the two tags - begin and end. My NppExec script above does exactly that.

Cheers.

rdipardo

@Michael-Vincent said in Goto Matching Brace for HTML/XML:

There is no such limitation programmatically.

I see that now, except for one subtle edge case. After sending SCI_ADDSELECTION, if you press the up or down arrow key (not left or right), both carets will remain until you press some other key or cancel the additional selection.

I’m not able to trap VK_UP or VK_DOWN becasue those keys don’t count as SC_CHARACTERSOURCE_DIRECT_INPUT, and the plugin’s key listener is deliberately conservative about the type of characterSource it acts on (to prevent auto decoding from being too disruptive).

If it becomes a real problem, the About dialog has a clickable link to the bug tracker.

Michael Vincent

@rdipardo said in Goto Matching Brace for HTML/XML:

After sending SCI_ADDSELECTION, if you press the up or down arrow key (not left or right), both carets will remain until you press some other key or cancel the additional selection.

Yes, I noticed that with my script too. I’m used to it when I have multiple caret editing. I just normally pressed the escape key to go back to single caret.

Cheers.

Michael Vincent

@rdipardo said in Goto Matching Brace for HTML/XML:

After sending SCI_ADDSELECTION, if you press the up or down arrow key (not left or right), both carets will remain until you press some other key or cancel the additional selection.

I’ve tried it out and it behaves exactly how I anticipated. This is great - bravo!

Cheers.

Si Dhie

This post is deleted!