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.

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.

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.

• https://github.com/rdipardo/nppHTMLTag/releases/tag/v1.4.1
• https://bitbucket.org/rdipardo/htmltag/src/v1.4.1/NEWS.textile

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.

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 . . . 🤔

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

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):

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

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. :-)

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.

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?

That’s basically how the HTML Tag plugin implements tag jumping, using a dictionary datatype called TStringList.

And that sir is 99% of what I’m looking for! That’s great. The only thing more I could ask for is that instead of just jumping from tag open to tag close, would be to highlight the tag open text and tag close text so that I could easily rename them. I’m thinking more in the XML context here, where tag names are essentially made up based on context and during development of a schema, are changing.

So to spell it out:

<outer0>
<mytag name="0">
    <mytag name="1">
    </mytag>
</mytag>
</outer0>

putting the cursor on the first mytag (the one with the name="0" parameter) and pressing the “magic hot-key” should select both mytag with the cursor and the matching one (the last one in this case) with multi-selection. So then, typing a new name would overwrite both instances with the new tag.

Does that make sense? 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.

Cheers.

how about Goto next node/fold at the same level? Or previous?

It’s possible with Scintilla’s current APIs, in any document with active code folding: https://sourceforge.net/p/scintilla/feature-requests/1487/#4196/ab81/b4d7

The Search=>Go to Matching Brace works fine for the standard () [] {} grouping pairs.

Angled brackets are among the “braces” that Scintilla’s own SCI_BRACEMATCH can find:

The SCI_BRACEMATCH message finds a corresponding matching brace given pos, the position of one brace. The brace characters handled are ‘(’, ‘)’, ‘[’, ‘]’, ‘{’, ‘}’, ‘<’, and ‘>’. The search is forwards from an opening brace and backwards from a closing brace.

https://www.scintilla.org/ScintillaDoc.html#SCI_BRACEMATCH

This obviously won’t be self-sufficient for navigating SGML documents, but it could be useful. If you know the start and end positions of the opening tag (by matching the first < with the first >), you can read the tag’s name and search the document for the closing tag, then send SCI_BRACEMATCH again to find where the closing tag begins and ends. The 4 co-ordinates could be held in a dictionary, e.g.

tags = {
    '<div>' :  (open_start, open_end),
    '</div>':  (close_start, close_end)
}

That’s basically how the HTML Tag plugin implements tag jumping, using a dictionary datatype called TStringList.

I tried to use SCI_GETSTYLEAT looking for style 34 which in Notepad++ / Scintilla is the STYLE_BRACELIGHT

I think SCI_GETSTYLEAT can only tell you the lexical state (or “style bytes”) associated with the text at the given position. STYLE_BRACELIGHT is a kind of overlay, possibly extractable with the right bit mask. Never tried it, though.

how about Goto next node/fold at the same level? Or previous? Then also Goto parent node.
These would be useful in any languae with hierarchical structure (not just html/xml).

Such behavior can be scripted for languages of interest. For example, I have scripts that jump to the next/previous entry at the same indent level as the current, as well as the next/previous “outdent” level.

I guess you meant “tag hightlighting” and you want “Goto Matching Tag”, correct?

He meant what he said. The default English translation (which is the nomenclature we use when helping anyone in the forum) uses the exact words that @Michael-Vincent used for the preferences:

Related: how about Goto next node/fold at the same level? Or previous? Then also Goto parent node.
These would be useful in any languae with hierarchical structure (not just html/xml).

That would have to be implemented in each of the individual lexers for each language, because each language has a different definition of “node” or “level” or whatever. Notepad++ uses Scintilla’s “Lexilla” library for defining the lexer behavior, so you would have to ask the Lexilla developers to add that feature to all of the languages that you care about, and then patiently wait for them to implement that feature (if they ever do) and then patiently wait for Notepad++ to update to the newer version of Scintilla/Lexilla which includes those new features.

If I have Preferences => Highlighting => Highlight Matching Tags (checkbox enabled), I also get “brace highlighting” on the HTML / XML tags.

I guess you meant “tag hightlighting” and you want “Goto Matching Tag”, correct?

Related: how about Goto next node/fold at the same level? Or previous? Then also Goto parent node.
These would be useful in any languae with hierarchical structure (not just html/xml).