fix: task tags are ignored if not at the start of a comment

[sebthom]

as of the last release task tags are only evaluated if they are at the beginning of a comment.
this PR restores the previous behaviour of evaluating task tags anywhere in the comment.

[rubenporras]

Hi @sebthom ,

If we remove the "^", I think we not need the "*", I think \b should be sufficient, instead of \b*.

I have a bit more time this morning, and I think that the problem is not the regex, but the fact that the comment delimiter is part of the comment string, commentText in my case contains "-- TODO this and that", and not " TODO this and that". So ^\\s* will never match any comment.

Is that maybe the problem? A bit above there is a check

					if (commentText.length() < 3)
						continue;

I am not sure how it all fits together but if the comment separator is going to be part of the string, that condition will almost always be true, so one could as well remove it and rely on the matcher, I do not think performance wise it is much of a speedup, since in this case most comments will pass that condition. In addition there is no hint that task patterns must have more than n characters.

Sorry for the bunch of unstructured information/questions. I do not know the code at all, so I am just commenting just in case you have overlooked something. If not, you can ignore my comments.

[sebthom]

If we remove the "^", I think we not need the "*", I think \b should be sufficient, instead of \b*.

That is correct. I changed it. Thanks!

I have a bit more time this morning, and I think that the problem is not the regex, but the fact that the comment delimiter is part of the comment string, commentText in my case contains "-- TODO this and that", and not " TODO this and that". So ^\\s* will never match any comment.

Interesting. In the languages that I am using/testing (Dart and Haxe), the commentText does not contain the comment delimiter. Maybe it depends on how the textmate rule is defined.

Is that maybe the problem? A bit above there is a check

					if (commentText.length() < 3)
						continue;

I am not sure how it all fits together but if the comment separator is going to be part of the string, that condition will almost always be true, so one could as well remove it and rely on the matcher, I do not think performance wise it is much of a speedup, since in this case most comments will pass that condition. In addition there is no hint that task patterns must have more than n characters.

I am hitting that condition quite often in Dart and Haxe so I would prefer to keep that check.

[rubenporras]

BTW: Our single line comment is defined as

        "linecomment": {
            "name": "comment.line.double-dash.avqscript",
             "begin": "(^[ \\t]+)?(?=--)",
             "beginCaptures": {
               "1": {
                 "name": "punctuation.whitespace.comment.leading.ts"
               }
             },
            "end": "(?=$)"
        },

Then if the line has the text " -- TODO this and that" then the variable commentText has first the content " ", and the token is "comment.line.double-dash.avqscript-punctuation.whitespace.comment.leading.ts" and then "-- TODO this and that" nd the token is "comment.line.double-dash.avqscript".

[rubenporras]

This looks good to me now. IIRC, it is the same regex that we had before the last release

[sebthom]

This looks good to me now. IIRC, it is the same regex that we had before the last release

That was actually my intention with this PR but I apparently needed some attempts...