Todo-tree: [feature]: show and link github issue label next to todo label

[muuvmuuv]

I recently saw a repository (can't find it anymore) where they used GitHub issues to track all bugs/features etc. which makes totally sense for bigger issues. They way they have added them into the code was through adding this:

// <TAG>(#<ISSUE_NUMBER>): <LABEL>
// BUG(#XXX): Layout breaks here

I think this is a nice idea and todo-tree would need just tiny improvements regarding the regex. I have tried it in my terminal with this command which works there but not in VS Code (and does not cover MD tasks).

rg --ignore-case --line-regexp -e "((//|#|<\!\\-\\-|;|/\\*|^)\\s*(BUG)(\(#.+\))?:.*)" regtest.txt

Example file:

// BUG: asdasd
/* BUG: asds */
// BUG(#23): asdasd
/* BUG(#23): asds */
# BUG: asdasd
/* BUG asds */
# BUG asdasd
<!-- BUG: asdasd -->
# bug: asdasd
<!-- bug: asdasd -->
# BUG(#23): asdasd
<!-- BUG(#23): asdasd -->
// bug(#23): asdasd

Linking the issue number to the GitHub issue and adding the issue label next to the "todo" like GitLens does it or when it doesn't provide any label would also improve the visual experience. Something like this:

What do you think about it? I'm currently using it in one of my projects to track where I have open issues when I'm too lazy to open GitHub issues page and to better see where it came from (normally I would have added the file path with line number in GH issues).

[Gruntfuggly]

Do you just mean extending the regex so it finds these items, or doing some automatic look up based on the issue number?

[muuvmuuv]

@Gruntfuggly both ^^

[Gruntfuggly]

I've implemented something allowing the text after the TODO to be processed with a regex, which allows the label to then be formatted.

E.g.
with config like

   "todo-tree.highlights.customHighlight": {
        "BUG": {
            "formatRegex": ".*\\((\\#.*)\\).*",
            "labelFormat": "Github Issue:${1}"
        }
    }

it can match

code(); // BUG (#230)`

And put
Github Issue: #230
in the tree.

It would be fairly easy to add something to allow double clicking the tree item to open the issue in github.

I think the icing on the cake for you would be to fetch the issue title from github and put
Github Issue #230 Issue title
in the tree?

The problem is that it would need an asynchronous look up and I don't know how that would affect performance. Is that what gitlens does? I thought it just got the information from the local repo.

[muuvmuuv]

Uh, that is nice, thank you for that!

Yes, that would be the _icing on the cake_ for me ^^!

GitLens uses local .git information. I don't think async fetching would be such a performance cost because that is what async is for but I would say it should be opt-in and the user must provide the GH token by himself to activate it.

[muuvmuuv]

Anyway what do you think about the idea overall? I don't mind if it is out of scope or if you think there will be no much use of it. It was just an idea of mine :)

[Gruntfuggly]

I'll carry on looking at it, but it might be quite a large change. I'll keep you posted :grin:

[Gruntfuggly]

I've been doing some experiments - I can get the issue details.

Did you want the tree itself to be updated with the issue title? Or just shown next to the highlight in the code itself?

[muuvmuuv]

I think showing it next to the highlight is enough but would also helpful in the tree view if there is just // BUG(#XX):. I don't even know how the API limit of GH is handled but I think some kind of caching would be great, so I will see the labels when I'm offline as well and to not exceed any kind of limit. Maybe save the timestamp and labels of one file and only update every minute or when a new commit/pull/push has been made.

[Gruntfuggly]

I think this might make sense as a separate extension then. It would be much simpler - it feels like shoehorning into the tree view is wrong.

Adding "BUG(#XX)" to the tree can be done with the extension as it is.

I can create a new simple extension that looks for // BUG (#XX) (or similar via a configurable regex) and automatically retrieve issue details to put in an annotation (and even more details in a tooltip maybe).

It doesn't even need any authentication - just the repo name and repo owner's name.

Any ideas for an extension name?

[muuvmuuv]

Good idea! That is why I have initially said it may be out of scope of this plugin.
What about „inline-issue-labels“

[alystair]

I've actually done some work in this direction, by (badly) modifying a github specific extension that links #123, project#123, user\project#123 style comments directly to issues. I made it generic (we use GitLab) via remote domains listed in the local .git config.

Originally I was planning to email Grunt to see if he was interested in working together on it as I don't know jack about extension dev (I edited the extension's generated JS directly) but I got distracted. So hey, here we are ^^

Agreed that it's out of scope, but complementary if done well. I could do the initial heavy lifting, and you'd ensure it actually works as an extension, has settings, etc.

[alystair]

At the very least I can provide my kludge code and you can take the best bits/concepts for a new extension. My dream would be to grab the issue title and integrate it into tooltips but it's non-trivial.

[alystair]

Ok, I posted a link to the code here https://github.com/dt/ghlink/issues/13 as that's the source that I modified (although I used the generated JS instead of the original TS, oops).

Don't let the regex scare you (too much). I made a regex101 that explains it. It's pretty much chunking various URL parts. VSCode might have a built-in URI thing but as I said before I have zero experience with VSCode extensions outside of hacking this one...

Only gotcha is that it also matches numbered hashtags in quotes, which might appear in some HTML/JS code.

[Gruntfuggly]

Looks like this might have native support soon:
https://code.visualstudio.com/blogs/2020/05/06/github-issues-integration

[muuvmuuv]

Yeah, read that right At that moment on Twitter ^^ feel free to close it

[alystair]

Another nail in the GitLab coffin - oof.