I was experimenting with a multiline regex and defaultHighlight type "capture-groups:n,m…"
in order to accommodate multiline block commented TODOs and match the highlighting for their opening and closing syntax. I actually ended up switching the highlight type back to my original "text-and-comment" style, although in the process of tinkering I noticed an issue with "todo-tree.tree.labelFormat".
My regex
"(?://|#+|;)[ \\t]*($TAGS)|/\\*\\s*($TAGS)[\\s\\S]+?\\*/|<!--\\s*($TAGS)[\\s\\S]+?-->"
seems to be working perfectly for highlighting in my use case (I'm only really dealing with js / shell / xml -style comments), and seems to circumvent the issues described in #644 and #666 . This took a fair bit of trial-and-error as I'm definitely no expert, and almost undoubtedly there is a more efficient way of doing it. I ended up leaving out the capture groups anyway when I reverted to "text-and-comment".
As to the specific issue, I use solely the "${after}" text for the label, but with multiline TODOs the entire tag, label and closing block are all printed in the tree. Furthermore, if the tag appears on the same line as the comment opener, then any additional text on that same line is omitted entirely. I can successfully strip the comment closer from the label by specifying
"todo-tree.regex.subTagRegex": "-->|\\*/"
but this only seems to work for single-line block comments.
Arbitrary example:
// @TODO foo bar
// nothing
/* @TODO foo bar */
// nothing
/*
@TODO foo bar
*/
// nothing
/*
@TODO foo
bar
*/
// nothing
/*@TODO foo bar
*/
// nothing
/*@TODO foo
bar
*/
// nothing
renders as:
My initial experimentation got me wondering if it was possible to extend the "capture-groups" functionality to "labelFormat" as well in order to solve the problem above by capturing the text between the tag and block comment closer, ie.
"(?://|#+|;)[ \\t]*($TAGS)(.*)$|/\\*\\s*($TAGS)([\\s\\S]+?)\\s+?\\*/|<!--\\s*($TAGS)([\\s\\S]+?)\\s+?-->"
then printing ~"capture-groups:1,2,3"~ "capture-groups:2,4,6"? (I forgot the $TAGS are also captured).
Hopefully I've explained all that clearly enough anyway - lmk if not (or if I've completely misunderstood something along the way), and thanks for making such a useful tool!
I was experimenting with a multiline regex and
defaultHighlight type "capture-groups:n,m…"in order to accommodate multiline block commented TODOs and match the highlighting for their opening and closing syntax. I actually ended up switching the highlight type back to my original"text-and-comment"style, although in the process of tinkering I noticed an issue with"todo-tree.tree.labelFormat".My regex
"(?://|#+|;)[ \\t]*($TAGS)|/\\*\\s*($TAGS)[\\s\\S]+?\\*/|<!--\\s*($TAGS)[\\s\\S]+?-->"seems to be working perfectly for highlighting in my use case (I'm only really dealing with js / shell / xml -style comments), and seems to circumvent the issues described in #644 and #666 . This took a fair bit of trial-and-error as I'm definitely no expert, and almost undoubtedly there is a more efficient way of doing it. I ended up leaving out the capture groups anyway when I reverted to"text-and-comment".As to the specific issue, I use solely the
"${after}"text for the label, but with multiline TODOs the entire tag, label and closing block are all printed in the tree. Furthermore, if the tag appears on the same line as the comment opener, then any additional text on that same line is omitted entirely. I can successfully strip the comment closer from the label by specifying"todo-tree.regex.subTagRegex": "-->|\\*/"but this only seems to work for single-line block comments.Arbitrary example:
renders as:
My initial experimentation got me wondering if it was possible to extend the
"capture-groups"functionality to"labelFormat"as well in order to solve the problem above by capturing the text between the tag and block comment closer, ie."(?://|#+|;)[ \\t]*($TAGS)(.*)$|/\\*\\s*($TAGS)([\\s\\S]+?)\\s+?\\*/|<!--\\s*($TAGS)([\\s\\S]+?)\\s+?-->"then printing ~"capture-groups:1,2,3"~"capture-groups:2,4,6"? (I forgot the$TAGSare also captured).Hopefully I've explained all that clearly enough anyway - lmk if not (or if I've completely misunderstood something along the way), and thanks for making such a useful tool!