3.2.7

RefactoringMiner Extension v3.2.7

Three fixes, each about the extension doing nothing useful in a situation where it should have: analysing a commit against a server that no longer exists, clicking a refactoring on a very large diff, and highlighting an annotation instead of the method that was renamed. This build also carries what 3.2.6 shipped, which was never released on its own.

Fixed: standalone analysis was broken for everyone

Commit pages, and repos that don't run the Action, are analysed by a hosted RefactoringMiner service rather than by a published feed. That service was rminer.encs.concordia.ca:8000, and it is down, so standalone mode failed for everybody with a service error in the panel.

It now points at https://rminer.gveloso.com/RefactoringMiner. Nothing else about the request changed: same parameters, same whole-PR and single-commit behaviour, same response shape, and the new host still sends permissive CORS headers, so the extension asks for no new permissions.

Stored settings are migrated. Anyone who had ever pressed Save on the options page had the old address written into their synced settings, and a stored address always wins over the default, so changing the default alone would have left them pointed at the dead server. A saved address on a retired host now resolves to the current one, in the extension and on the options page alike. If you set your own self-hosted server, it is left exactly as you set it.

Fixed: clicking a refactoring on a very large diff did nothing

No highlight, no scroll, no blink. GitHub virtualizes a big diff per file, not just per row: it sizes a placeholder for each file and keeps only the handful around the viewport in the page. A 1,000 file commit has about five real files in it at any moment. Every way the extension had of reaching a line starts from a row, a file box, or a fold control, so for a file that wasn't there it found nothing at all and the click looked dead.

Several separate faults were stacked underneath that, and all of them are fixed:

• Files behind "Large diffs are not rendered by default" were unreachable. Looking up a file matched the file tree entry in the sidebar, which renders before the diff does, so the extension searched a link with no "Load diff" button, no chevron and no rows under it, and found nothing. The tree link is now a last resort rather than the first match.
• The unfold walk clicked the wrong arrow. It stopped searching at the first ancestor holding any expander, which on a large commit is the hunk header row itself. With no line of the relevant side in view to measure against, it treated the whole file as one gap and pressed an arrow at the wrong end of it, wasting one of its rounds. It now widens its search until it can actually place the fold.
• Files the diff never mounted are now mounted on demand, by driving GitHub's own file anchor, with retries. A mount was measured taking over four seconds on a 1,000 file commit, and a click can be swallowed outright while the page is still hydrating.
• Files are opened one at a time, and the one you are being taken to is opened last. Opening a file navigates to it, and the virtualizer then throws out whatever is now far away. On that same commit, a refactoring spanning two large files loaded the first file's 1,208 rows and then discarded every one of them when the second opened, so there was nothing left to highlight.
• Scrolling to a far target now arrives. A freshly mounted file can sit hundreds of thousands of pixels down the page, and the virtualizer rubber-bands any long jump back to the edge of what it has measured, which is why GitHub's own tree clicks stop short too. The scroll now re-issues itself at a pace the page can absorb until it gets there. Any real input from you, wheel, key or pointer, takes the wheel back immediately. Nearby targets keep the single smooth centring they always had.
• A safety net for the case where all of that raced. If the page moved enough during a reveal that the highlight had nothing left to attach to, the landing spot is reopened and re-tagged once, with nothing after it to move the page away again.

Fixed: renamed methods highlighted @Override instead of the signature

For a refactoring covering a whole declaration (Rename Method, Move Method, Pull Up and Push Down Method, Change Modifier, and their class-level equivalents), the extension highlights one header line rather than the whole body, which would flood the diff with colour.

Which line that was came straight from RefactoringMiner, and RefactoringMiner reports a declaration as starting at its first line. On an annotated member that first line is @Override. So a Rename Method lit up an annotation on the left and the identical annotation on the right, said nothing about the method that had been renamed, and left the signature one row below it dark. On code that annotates most of its methods, which is most Java code, this was the normal case rather than the edge case.

The header line is now read from the source on the page instead of taken on faith. Within a small window at the top of the declaration the extension steps over annotations, Python decorators, javadoc and block comments, and blank padding, and stops on the first line that is none of those. An annotation whose arguments run across several lines, such as @RequestMapping(value = "/x", and its continuation, is followed to its end rather than mistaken for the signature. Everything else in that window stays unhighlighted, so a declaration still contributes exactly one line per side, as it always did.

Folded context is handled to match, so the signature lights up even when GitHub hid the annotations above it as unchanged context, and jumping to a refactoring from the panel, the navigator or a minimap tick now lands you on the signature line.