Zxynine / EvenBetterComments

My take on the better-comments extension which incorporates many pull requests and multi tag definitions
https://marketplace.visualstudio.com/items?itemName=Tion.evenbettercomments
MIT License
11 stars 1 forks source link

New properties and settings to improve performance and fine-grain customizations #5

Open Fred-Vatin opened 1 year ago

Fred-Vatin commented 1 year ago

I open a new issue to be more general.

This another extension TODO Highlight v2 has interesting settings.

For performance issue, one important setting would be :

"evenbettercomments.exclude": [
  "**/node_modules/**",
  "**/dist/**",
  "**/bower_components/**",
  "**/build/**",
  "**/.vscode/**",
  "**/.github/**",
  "**/_output/**",
  "**/*.min.*",
  "**/*.map"
]

A new tag property

"evenbettercomments.isCaseSensitive":boolean

Currently if is insensitive only. Maybe a user would only want to style if match a case sensitive tag or alias.


A new tag property

"isRegexPattern": boolean

If true, instead of a keyword user can set a regex pattern in the tag property like:

"tag": ".+?\s(My Match)\s?:\s?other match"

image

If group is matched and the other property "highlightTagOnly": true, then only style the matched group else style whole matched string.

Zxynine commented 1 year ago

I open a new issue to be more general.

This another extension TODO Highlight v2 has interesting settings.

For performance issue, one important setting would be :

"evenbettercomments.exclude": [
  "**/node_modules/**",
  "**/dist/**",
  "**/bower_components/**",
  "**/build/**",
  "**/.vscode/**",
  "**/.github/**",
  "**/_output/**",
  "**/*.min.*",
  "**/*.map"
]

A new tag property

"evenbettercomments.isCaseSensitive":boolean

Currently if is insensitive only. Maybe a user would only want to style if match a case sensitive tag or alias.

A new tag property

"isRegexPattern": boolean

If true, instead of a keyword user can set a regex pattern in the tag property like:

"tag": ".+?\s(My Match)\s?:\s?other match"

image

If group is matched and the other property "highlightTagOnly": true, then only style the matched group else style whole matched string.

I do like the exclude idea, it would be great for performance so I will be adding that.

A case insensitive option is something I’ve been wanting to add but haven’t figured out a great way to do so as the tags are all compiled into a single regex search and so I need to figure out a good way to allow that option. It pay be possible to turn a tag like “todo-” into the regex “[tT][oO][dD][oO]-” before I compile them so that it can match without worrying about the case for that specific tag but maybe there is a better way.

For regex patterns, i don’t know how exactly to make it work in a way that makes sense for users, there will be so many compromises and edge cases everyone would need to take into account when doing that as I actually use two sets of regex for each of the four to five cases of comments, the first regex locates the comment and the second regex locates the tag within the comment, I do this for simple monoline comments (nothing else but comment on a line) , mixed monoline comments (comments that come after code on same line), simple multi line comments (block comments that start on their own line), mixed multi line comments (block comments that start on the same line as code or the end of other block comments), and then a JavaScript specific block comment regex because js doc has a unique standard for comments. Each of those has their own unique edge cases and would be a nightmare to provide a regex that would treat them all fairly.