You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Seperate issue / pr links (#id) from linkify-code #5063
than making a hyperlink of a URL which already exists in the code.
To me it is the other way around, links in code comments are enormous and nobody wants to manually select and open via context menu/drag and drop all the time.
For example, this feature could be called linkify-hash-id maybe ?
And would linkify #5063 in code comments but not example.com
First, it's not "hash id" but "number sign and number".
Second, we are unlikely to split it into two features that are pretty much the same Implementation.
As far as Refined GitHub is concerned, we want to linkify both, so we don't split features just to increase granularity. Splitting the feature would duplicate a lot of code and lower performance. For example there's a simple watcher/loop that calls those 2 functions; If we split the feature, we'd need 2 watchers… and then both of them will be enabled by default.
Also I don't see the need to split this specific feature; If you don't want to click full links, don't click them.
Activity
kidonng commentedon Nov 10, 2021
To me it is the other way around, links in code comments are enormous and nobody wants to manually select and open via context menu/drag and drop all the time.
First, it's not "hash id" but "number sign and number".
Second, we are unlikely to split it into two features that are pretty much the same Implementation.
amithm7 commentedon Nov 10, 2021
Some maybe, but you can't select and right-click
#5063to open it.Never heard of "number sign", I see that it's what used in USA maybe? Never been there.
idbecause it identifies a PR / Issue.Implementation maybe but I am asking for a different option for each.
Edit: I see separate implementations.
fregante commentedon Nov 10, 2021
As far as Refined GitHub is concerned, we want to linkify both, so we don't split features just to increase granularity. Splitting the feature would duplicate a lot of code and lower performance. For example there's a simple watcher/loop that calls those 2 functions; If we split the feature, we'd need 2 watchers… and then both of them will be enabled by default.
Also I don't see the need to split this specific feature; If you don't want to click full links, don't click them.
amithm7 commentedon Nov 10, 2021
@fregante ,
linkify-codecan remain, but it can have sub-features, right?Also, the preferences / options page needs some organization.
kidonng commentedon Nov 10, 2021
Please keep the conversation constructive. As mentioned above this is a very niche request and we are not going to support it.
If you really want it, please consider maintaing a fork yourself (it's not difficult and can be automated).
Organized feature descriptions with categories are present in the README.