It should only match tag word bondary

[Fred-Vatin]

My tag or alias are todo and issue. I don’t expect every word beginning with this letter matches.

Here is a screenshot.

[Zxynine]

Should be fixed, a space or semicolon is required between the tag and anything else to signal that it is a tag not part of a word. Will work on allowing users to set their own required tag separators in a future update.

Let me know if this fixes the issue and I will close it.

[Fred-Vatin]

Tested and confirm the fix.

[Fred-Vatin]

There is a drawback with this fix.

Before, I was able to style a whole line with this :

{
    "tag": "====",
    "aliases": [
        "-----"
    ],
    "color": "white"
},

Maybe we need a property "isPrefix": true. It would treat the tag as a prefix implying the style should apply to the whole line. What do you think ? The regex would be something like this in this case.

"evenbettercomments.highlightTagOnly": false can’t solve it.

Another tag property could be useful : styleCommentSymbol: boolean. Or even more fine-grain with styleMonoCommentSymbol: boolean plus styleMultiCommentSymbol: boolean.

Currently, with the style above, it is inconsistent. Monoline symbol is styled. Multiline symbols are not.

[Zxynine]

There is a drawback with this fix.

Before, I was able to style a whole line with this :

{
  "tag": "====",
  "aliases": [
      "-----"
  ],
  "color": "white"
},

Maybe we need a property "isPrefix": true. It would treat the tag as a prefix implying the style should apply to the whole line. What do you think ? The regex would be something like this in this case.

"evenbettercomments.highlightTagOnly": false can’t solve it.

Another tag property could be useful : styleCommentSymbol: boolean. Or even more fine-grain with styleMonoCommentSymbol: boolean plus styleMultiCommentSymbol: boolean.

Currently, with the style above, it is inconsistent. Monoline symbol is styled. Multiline symbols are not.

Ah so technically I believe it actually is working in that example, what you are seeing as the problem is the start and end brackets are not coloured, only the text in between them is, this is because if you had a multi line comment and a tag just at the top on the same line as the block start, the colouring on the start and end bracket would be inconsistent and look off. I did add a setting which would fix that but it also may not be something you like, if you take a look at the read me, you’ll see an additional settings option for something like “allow full block highlighting” or something like that, basically with that setting, if you placed a tag on the same line as the start delimiter, the entire block will be given that style including the start and end delimiters which seems to be what you’d like, however I’m not sure how it will work in combination with highlighting tags only. There does not seem to be an easy way to get the symbols to also be highlighted in a consistent manner, I may need to add another parsing step to look for monoline block comments to control highlighting on them appropriately.

[Fred-Vatin]

Ah so technically I believe it actually is working in that example.

No, the match is actually the same value as the tag. Same number of = in the tag and in the example. If I add a = in the comment, it doesn’t match anymore and it is predictable to avoid the problem of the title of this issue.

Personally, I prefer the delimiters not to be styled. I just noticed something that might be more predictable by user settings.

[Zxynine]

So I believe I understand what you are saying, the issue is that now the match is only made for exactly the value set as the tag and never more if someone wanted to highlight a line like:

// ==================

But only had the tag set as "===" then it would fail because it is requiring them to use it like:

// === ===============

To get the highlighting, did I understand you correctly?

I think that this problem actually was removed only partially because of me setting the separators to space or colon, I removed a little bit in the parser that was actually matching for any number of tags in a row, so something like

//TodoTodoTodo: Some comment stuff

Was also matching and so combined with a more strict setting for a separator between the tag and comment, the functionality was removed. This is also tricky to implement with how tags are currently found, I may be able to add in an option that lets you match for the last character repeated.

[Fred-Vatin]

Yes. And in this comment I suggest to add a property "isPrefix": boolean to process those kind of tags.

[Fred-Vatin]

I hadn’t notice that the rendering for online comment is greedy. The comment symbol is styled too with "evenbettercomments.highlightTagOnly": true

Compared to multi lines comments

[Zxynine]

Moved further discussions to new issues: #9, #10 as to close this issue since the primary topic of it had been solved.