Should not match tags outside of comments

[cdCorey]

Recently, Comment Anchors started matching tags everywhere in my files – not just in comments. This results in tons of random trash erroneously appearing in my Comment Anchors sidebar, making it very difficult to sift through and find the actual anchors I'm looking for, to the point that Comment Anchors has become basically unusable.

[JordanDi123]

Could you please provide any examples to this? This may be caused due to a configuration error.

Thanks!

[cdCorey]

"commentAnchors.tags.list": [
	{
		"tag": "#",
		"scope": "file",
		"iconColor": "default",
		"highlightColor": "#fff",
		"styleComment": true,
	},
],
"commentAnchors.workspace.enabled": false,
"commentAnchors.workspace.excludeFiles": "**/{node_modules,.git,.idea,target,out,build,vendor,_dev}/**/*",
"commentAnchors.parseDelay": 500,

Everything worked perfectly until recently, and I haven't made any changes to my settings since I first installed the extension, so I don't see how it could be a misconfiguration. But here is my Comment Anchors settings, and a screenshot of what the issue I'm having looks like. None of these settings should have any bearing on how it parses the "TODO" comment anchor, though.

If no one else is seeing this issue, my best guess is maybe something got refactored in a recent update that's causing a bug after encountering single-character or non-alphanumeric comment anchors? Or maybe because "#" can be used as a comment delimiter in some languages? It's not a comment delimiter in the languages I'm working with, so that really shouldn't be an issue. This worked previously, so if that is causing an issue now, I'd really appreciate it if you're able to restore the previously existing functionality. Thanks.

[RAYDENFilipp]

Same issue

[NoralK]

Is there an update on this?

[lethefrost]

Same issue here, waiting for an update. Thank you developer

[Flory-1]

i have fixed the bug.

Just follow this instruction:

1. open file in extension folder: 'anchorEngine.js'
2. goto line: 396 => 'this.matcher = **'
3. edit the regex: [^\\w]\\s(${tags})(${separators})?\\s(\\[.*\\])?(.*)?
4. goto line: 699 => 'anchor = new entryAnchorRegion_1**'
5. edit the endPos: endPos + 1
6. goto line: 702 => 'anchor = new entryAnchor_1**'
7. edit the endPos: endPos + 1

This is working for me in version: 1.9.6

[RAYDENFilipp]

i have fixed the bug.

Just follow this instruction:

1. open file in extension folder: 'anchorEngine.js'
2. goto line: 396 => 'this.matcher = **'
3. edit the regex: [^\\w]\\s(${tags})(${separators})?\\s(\\[.*\\])?(.*)?
4. goto line: 699 => 'anchor = new entryAnchorRegion_1**'
5. edit the endPos: endPos + 1
6. goto line: 702 => 'anchor = new entryAnchor_1**'
7. edit the endPos: endPos + 1

This is working for me in version: 1.9.6

Would be great to have a PR with this fix, so that maintainers could take a look and advice if it is regression-safe

[PyroFlaming]

Is there any update on this issue ?

[daveteu]

This plugin is nice, but isn't this bug the BIGGEST and MOST IMPORTANT bug to be fixed?

❗️Anchors should not be scanning outside comments (or an option to turn this on).

Imaging writing the documentation for Comments Anchor using VsCode... you get lots of anchors... lots of them.

[macjuul]

Hey everyone, unfortunately I haven't had much time recently to look into this issue. The main issue is that the VSCode API lacks a way to query the context an anchor is found in, thus I cannot isolate anchors to just comments. Since the complexity of the regex has grown out of control we need to find a better solution to this, such as manually declaring a list of potential comment syntaxes to prefix the regex. I'll attempt to work on a fix for this.

Since this could introduce backwards incompatibility and break existing anchors I'll upload a testing build before publishing any new version. Sorry for the headaches this issue has caused!

[danilort]

My solution

Comment Anchors 1.9.6

FILE: out\anchorEngine.js

modify

// const MATCHER_TAG_INDEX = 1;
// const MATCHER_ATTR_INDEX = 2;
// const MATCHER_COMMENT_INDEX = 5;

const MATCHER_TAG_INDEX = 4;            
const MATCHER_ATTR_INDEX = 5;           
const MATCHER_COMMENT_INDEX = 8;

add (BEFORE: this.matcher = new RegExp):

//matchBefore (caratteri consentiti prima del TAG)
const consentitiPrimaDelTag = config.tags.matchBefore
    .map((seperator) => escape(seperator).replace(/ /g, " +"))
    .sort((left, right) => right.length - left.length)
    .join("|");
AnchorEngine.output("consentitiPrimaDelTag: " + consentitiPrimaDelTag);
if (consentitiPrimaDelTag.length === 0) 
{
    vscode_1.window.showErrorMessage("At least one matchBefore must be defined");
    return;
}

modify

//this.matcher = new RegExp(`[^\\w](${tags})(\\[.*\\])?((${separators})(.*))?`, config.tags.matchCase ? "gm" : "img"); //ORIGINALE

this.matcher = new RegExp(`((${consentitiPrimaDelTag})(\\x20{0,4}|\\t{0,1}))(${tags})(\\[.*\\])?((${separators})(.*))?$`, config.tags.matchCase ? "gm" : "img");  //OK!

add (AFTER: const tag = this.tags.get(tagName)):

let caratteriPrimaDelTag = match[0].indexOf(tagName);      

modify

//const startPos = match.index + 1;

const startPos = match.index + caratteriPrimaDelTag;   

Settings

"commentAnchors.tags.matchBefore": [
    "//",
    "#"
],

RESULT

[macjuul]

I have implemented a fix based on @danilort's examples which should solve the significant majority of false positives. I'll attach a development build which can be tested before I publish the fix live.

comment-anchors-1.10.0-dev.zip

You can install the vsix manually as follows

[danilort]

The v1.10 works well for me.

I still see some false positives.

1)

Lines 74-76 are still considered anchors (but for me they are not anchor).

They also lose the comment.

2)

Anchor that follows NL is still considered

my suggestion

For n.1: add '$' to the end of the REGEX. For n.2: replace \s to: SPACE (0x20 or TAB (\t).

// const regex = `(?:${prefixes})(?:\\s{0,4})(${tags})(\\[.*\\])?(?:(?:${separators})(.*))?`;

const regex = `(?:${prefixes})(?:\\x20{0,4}|\\t{0,1})(${tags})(\\[.*\\])?(?:(?:${separators})(.*))?$`; 

[ChaserKnight]

Is there any update on this issue? Should I follow the fix mentioned above or it will be release officially? Please let me know.

[sohaha]

My solution

Comment Anchors 1.9.6

FILE: out\anchorEngine.js

modify

// const MATCHER_TAG_INDEX = 1;
// const MATCHER_ATTR_INDEX = 2;
// const MATCHER_COMMENT_INDEX = 5;

const MATCHER_TAG_INDEX = 4;            
const MATCHER_ATTR_INDEX = 5;           
const MATCHER_COMMENT_INDEX = 8;

add (BEFORE: this.matcher = new RegExp):

//matchBefore (caratteri consentiti prima del TAG)
const consentitiPrimaDelTag = config.tags.matchBefore
    .map((seperator) => escape(seperator).replace(/ /g, " +"))
    .sort((left, right) => right.length - left.length)
    .join("|");
AnchorEngine.output("consentitiPrimaDelTag: " + consentitiPrimaDelTag);
if (consentitiPrimaDelTag.length === 0) 
{
    vscode_1.window.showErrorMessage("At least one matchBefore must be defined");
    return;
}

modify

//this.matcher = new RegExp(`[^\\w](${tags})(\\[.*\\])?((${separators})(.*))?`, config.tags.matchCase ? "gm" : "img"); //ORIGINALE

this.matcher = new RegExp(`((${consentitiPrimaDelTag})(\\x20{0,4}|\\t{0,1}))(${tags})(\\[.*\\])?((${separators})(.*))?$`, config.tags.matchCase ? "gm" : "img");  //OK!

add (AFTER: const tag = this.tags.get(tagName)):

let caratteriPrimaDelTag = match[0].indexOf(tagName);      

modify

//const startPos = match.index + 1;

const startPos = match.index + caratteriPrimaDelTag;   

Settings

"commentAnchors.tags.matchBefore": [
    "//",
    "#"
],

RESULT

Is there the release?

[macjuul]

Hello, sorry for the delays, I have been rather busy lately.

Making changes to the parser can be very dangerous and potentially break existing anchors for many existing users, so I want to be sure these changes don't negatively affect any (valid) existing anchors. I already implemented some of the suggested changes a while back however I still wasn't sure it covered all aspects of the problem.

I packaged an experimental version previously which may solve the majority of issues with the current parser. It would be fantastic if I could get some more feedback on this as well (@ChaserKnight @sohaha)

Again, my apologies for the long wait. I'll seek to make a new release in the coming days if no major issues pop up.

[macjuul]

Issue has been resolved and will be fixed in the next release.