3.3.1

RefactoringMiner Extension v3.3.1

A single-fix release: refactorings whose code element contains a bracket now render their links, instead of dumping raw markdown onto the row.

Fixed: some refactorings showed raw URLs instead of links

On duckdb/duckdb@4748928, refactoring 3 (Invert Condition) printed its description with the markdown still in it, brackets, parentheses, and two full-length GitHub URLs inline, while refactoring 5, the same type in the same commit, rendered normally. The row was unreadable, and neither code element was clickable, so the one thing the markup exists for, jumping to the exact line an element sits on, was unavailable on precisely the refactorings that needed it.

RefactoringMiner hands us each description as markdown with every code element linked to its own line. The panel tokenized that with one regex whose link text was [^\]]*, meaning a link's text could not contain a ]. The element on that refactoring is:

[if(!dict_registry[i])](…#diff-<digest>L553)

Scanning from the opening [, the first ] reached is the one closing dict_registry[i], which is followed by ) rather than (, so the match fails, and it fails again at every later [ in the string. With no link token produced, the whole [text](url) fell through to the literal-text branch and was printed verbatim. Any element carrying an array subscript, an indexed access, or a generic argument list hit this. Refactoring 5's condition has no subscript, which is why it looked fine.

The tokenizer no longer uses a regex for this:

• A link's two halves are read with a depth counter, so the text ends at its own ] with nesting counted, and the URL ends at its own ). A parenthesis inside a URL can no longer end it early either.
• What is not a complete link stays literal text, exactly as before, so a stray [ or a plain [brackets] in prose still reads as prose.
• Bold and code spans are unchanged in behaviour.

Both Invert Condition links on that commit now render as links, and clicking one lands on the right line with the element's own column range highlighted, because the link's text still matches the code element the location lookup keys on.

Nothing else changed

The fix is confined to how the description markup is read. Tagging, selection, blinking, revealing folded context and collapsed files, the hover peek, the minimap, the navigator, the edge chips, and the panel's three detail levels all behave exactly as they did in v3.3.0. Descriptions without markup, from an older feed, still take the prose path. The permission footprint is unchanged.

Reload the extension, not just the page, to pick up this build.

Fixes #33.

3.3.0

RefactoringMiner Extension v3.3.0

Mostly new ground. The refactorings panel is back in the full-width form it had before, in three sizes you pick from the options page; the descriptions it shows now link to the code they name; and the parts of a refactoring that are only reached by it, the call sites an extraction leaves behind and the statements that mention a renamed variable, are finally told apart from the parts that changed. One fix worth its own heading: with automatic activation switched on, the extension did nothing until you reloaded the page.

New: the panel comes in three sizes, and the widest one is back

The panel that lists every refactoring was a small card pinned bottom-left. That is still the default, but the options page now sets how much of the diff it takes, and with it how much of each refactoring's RefactoringMiner record it shows. All three list the same refactorings and highlight the same lines:

• Compact, the pinned bottom-left card. Type and the element it touched, one row each; the full description opens on click. Unchanged from previous releases.
• Expanded, the same card elongated along the bottom, with each refactoring's full description printed on its row.
• Detailed, a dock across the entire width of the window. The description, plus every code element RefactoringMiner reported for that refactoring (its role in the refactoring, its kind, and its file:line, each one clickable), and a checkbox per refactoring type so you can show one kind at a time.

The detailed dock is the old Refactoring-Aware-Commit-Review full-width panel, brought back as an option. Full width is what makes the long descriptions readable; a card a third of the screen wide could not show them without wrapping them into a column. Click the dock's header to collapse it out of the way, and again to bring it back; the setting stays where you left it.

The type checkboxes hide rows, and the navigator and minimap entries that go with them. Nothing is un-analysed by them and nothing in the diff is un-tagged, so a filtered-out line still lights up if you click it in the diff.

The disclosure caret is now compact-only. The two richer levels print the description on the row itself, so a caret there only opened a second copy of what was already on screen.

New: descriptions link to the code they name

RefactoringMiner sends each refactoring's description twice: as plain prose, and as markup, the same sentence with every code element linked to the line it sits on. Wherever the panel shows a description it now renders the markup, so each element is clickable and takes you to that line rather than to the refactoring's default landing spot. A feed without markup falls back to the prose, unlinked.

Arriving there, the element itself is highlighted, not the whole diff row. The row already carries the selection fill, so painting the element the same way would say nothing about which part of the line the description meant. The element takes the complement of that fill instead: the opposite hue, the opposite end of the lightness scale, and its own text colour so the code stays readable on it. Amber lines get a blue element, azure lines an orange one, flipped in GitHub's dark theme. Its extent comes from the startColumn/endColumn RefactoringMiner reports.

Clicking never navigates. The panel intercepts the click and reveals the line in place, which is what lets it unfold a collapsed hunk, expand a file hidden behind "Viewed", or mount a virtualized row first, none of which a plain jump to an anchor can do. The links stay real <a href>s, so Cmd- or Ctrl-click still opens a tab, and those addresses are rewritten to point at the page you are actually on. That last part matters because the service is called with a single commitId and cannot tell a standalone commit from a commit that happens to sit inside a pull request, so a sha request always emits regular-commit links, which point off a /pull/<n>/changes/<sha> page entirely.

New: invocations and references have their own colour, and stay out of the counts

RefactoringMiner reports two quite different kinds of location for one refactoring: the code that changed, and the code that merely reaches it. Extract Method reports the extracted method, and the call sites left behind where the code used to be. Rename Variable reports the declaration, and every statement that mentions the variable. Until now both were painted in the same left and right colours, counted the same way, and behaved the same way, so a rename of a variable used in twelve places read as a twelve-line change.

Only the location's own description separates them (extracted method invocation, statement referencing the renamed variable), and that is now what the extension goes on. Those lines:

• Take a third highlight colour, configurable on the options page next to the existing pair. The default is a violet that sits in the gap between the amber and azure of the two sides, clear of the red and green GitHub already uses for removed and added lines, and matched to the same brightness as that pair so a call site never looks louder than the change that produced it. As with the other two, a colour you pick applies in both of GitHub's themes.
• Are left out of the off-screen line counts. The pills at the top and bottom of the screen count how much of the selected refactoring is above and below the fold; they now count only the lines it actually changed, and clicking one takes you to one of those rather than to a call site.
• Do nothing when clicked. There is no counterpart to pair a call site with, and jumping on the strength of one would move you away from the change you were looking at. Clicking one is now a no-op; it will not even clear the selection you already had.
• Have their own hover instead. Short, and in RefactoringMiner's own words: "Extracted method invocation", and underneath it, which refactoring reaches this line. No counterpart preview, because there is nothing to preview.

All of this follows whatever is selected, rather than being fixed when the diff is painted. One line can be a reference belonging to one refactoring and changed code belonging to another sitting right below it; it takes its colour, its counting, and its description from whichever of the two you have selected.

Fixed: with automatic activation on, nothing happened until you reloaded

Switching on automatic activation in the options page was supposed to mean the extension came up by itself on a diff. Instead you would arrive at a pull request's "Files changed", get nothing, reload the page, and only then see the panel. The toolbar button was equally dead in that state, which made it look like the setting had broken activation altogether.

A content script is put into a page when a document loads, and never again. GitHub does not load documents when you move around it: opening a pull request from the repository page, the pull list, or a notification replaces the URL and the whole interface in place. The extension registers itself for diff URLs only, so arriving at one that way meant it had never been put into the page at all. There was nothing there to activate, and nothing for the toolbar button to talk to. Reloading worked because a reload is a real document load.

The extension now notices a tab settling on a diff and puts itself in if it is not already there, checking first so it can never end up running twice in one page. The toolbar button does the same check before it fires, so click-to-activate works on arrival too.

A second fault underneath that is also fixed: the watcher that tags new rows as a big diff scrolls was attached once to the page body, and a GitHub navigation replaces that body wholesale. It was left watching a discarded page, and rows mounted after such a navigation quietly stopped being highlighted.

Fixed: going to a refactoring took you to its call site

Clicking a refactoring in the panel, stepping to it with the navigator, or following a minimap tick would sometimes scroll you to the invocation rather than to the refactoring itself. For Extract Method, most of the time.

Where to land was decided by taking the first of the refactoring's lines that was mounted in the page, and that list is in page order, so it was really "whichever of its lines is highest up". A call site left behind by an extraction sits above the extracted method it calls, so it won that comparison. Landing now skips the lines a refactoring only reaches, and falls back to them only if it has nothing else mounted, so a refactoring is never unreachable.

Fixed: the panel stayed shut when you clicked a refactoring in the diff

Clicking a row in the panel opened that row's explanation. Clicking the same refactoring's highlighted line in the diff marked the row as current but left it closed, so the two routes to the same refactoring did not agree. Selecting from the diff now opens the explanation as well, and when the line you clicked carries several refactorings, it opens all of them, in list order.

Changed: the options page saves as you go

The Save button is gone; every control writes itself the moment you change it, and a small confirmation appears wherever you are on the page. The settings are independent one-click choices, and having one button at the foot of the page meant changing the panel size at the top ended in a scroll just to commit it. Typed fields and the speed slider are still batched, so one gesture is one write.

One new permission

This release asks for scripting, which is what lets the extension put itself into a diff you reached without a page load, the activation fix above. There is no other way to do it under Manifest V3. It grants nothing on top of the access the extension already had to github.com, Chrome shows no new warning for it, and the pag...

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.

3.2.5

RefactoringMiner Extension v3.2.5

A release focused on one theme: making the overlay's cost depend on how much of the diff is on screen, rather than on how many refactorings were detected. On a commit with 412 detected refactorings, INP went from around 1760ms to around 80ms.

Fixed: large commits made the page unusable

The extension did its work before you touched anything, and on a commit with a few hundred refactorings that work was enormous. Every repaint walked each line of every refactoring and searched the whole document for the matching diff cell, which on a page like that meant thousands of full-page searches. Those repaints were triggered by the diff itself, which mounts rows as you scroll, so the search ran again and again while you were trying to read the code.

Scrolling stuttered, clicking a refactoring in the panel took a noticeable moment to respond, and the highlights arrived late enough to look like they were flickering into place.

The matching now runs in the opposite direction:

• The detected refactorings are compiled once into a lookup table of every line they touch, keyed by file, side, and line number.
• Painting is a single pass over the diff cells currently on screen, each checked against that table. Nothing searches the document per refactoring any more.
• Resolved cells are remembered, and re-checked against what the cell is actually showing before they are reused. The Preview diff recycles its rows as you scroll, so a cell that is still on the page may have quietly become a different line.

On the 412 refactoring commit this took INP from around 1760ms to around 80ms. A synthetic stress test of 3000 diff rows carrying 1000 refactorings, well past anything seen in practice, brought a single paint from around 520ms down to around 5ms, so the page stays responsive well beyond the sizes that used to break it.

Old INP

New INP

Fixed: highlights appeared late while scrolling

Newly mounted lines waited out a 250ms delay before they were highlighted, which on a fast scroll read as highlights blinking in behind you. That delay existed because repainting used to be expensive enough that it could not be run often.

Now that a repaint is a single cheap pass, it runs once per frame instead. Lines light up as they arrive, and rows that the diff recycles into something else are cleared just as promptly.

Selecting a refactoring is now immediate

Clicking a row in the refactorings panel, stepping with the navigator, or clicking a minimap tick jumps to the line and blinks it without the pause that used to precede it. The unfolding of hidden lines from v3.2.3 still happens first when it is needed, and it is still the only thing you wait on.

The blink itself is unchanged. Same three attention flashes, same synced pulse afterwards, same speed and colour preferences. Only the work underneath it got cheaper: the pulse now toggles a known set of cells instead of re-searching the page on every tick, which is what used to make it stutter mid-scroll.

Nothing else changed

This release is entirely internal. Tagging, selection, revealing folded context and collapsed files, the hover peek, the minimap, the navigator, the edge chips, and the refactorings panel all behave exactly as they did in v3.2.3, and were verified to tag the same cells with the same data. The permission footprint is unchanged from v3.2.1.

Reload the extension, not just the page, to pick up this build.

Fixes #25.

3.2.3

RefactoringMiner Extension v3.2.3

A release focused on one theme: making a selected refactoring reachable no matter where GitHub has hidden it. This rolls up v3.2.2, which was not released separately.

Fixed: parts of a refactoring stayed dark behind folded context

RefactoringMiner regularly points at lines GitHub considers untouched. An Encapsulate Attribute, for example, is about the attribute it wraps, but GitHub sees that line as unchanged and folds it away behind the little blue arrow in the gutter, showing only a few lines of context around the edit itself.

The result was a refactoring that lit up in pieces. The added getter would highlight, while the attribute it was created for sat inside the fold and never lit up at all, with nothing on screen to say anything was missing.

Selecting a refactoring now opens what GitHub folded away:

• The extension finds the specific fold hiding each line and clicks GitHub's own unfold control, stepping through longer folds until the line appears.
• A selection now tracks every line the refactoring touches, on both sides of the diff, rather than a single representative line. Previously, if that one line happened to be visible, nothing was ever unfolded.
• Freshly revealed lines are highlighted straight away, so the whole refactoring lights up together on the first blink.

Fixed: refactorings inside files marked "Viewed" were unreachable

Ticking Viewed collapses a file, and a reviewer part-way through a pull request has most of them collapsed. Clicking a refactoring that lived in one of those files did nothing useful, and with every file viewed the refactorings panel stopped responding altogether.

There were two causes wearing the same symptom. On the classic diff a collapsed file keeps all of its rows, just hidden, so the extension happily highlighted lines nobody could see. On the newer Preview diff the rows are not rendered at all, so the file could not even be located.

Clicking a refactoring now opens the file it lives in:

• Collapsed files are identified and expanded before the refactoring is selected, on both diff layouts.
• Your review progress is left alone. The file expands and stays ticked as Viewed. The extension never unticks it, because that state is your record of how far through a review you are.

Built on GitHub's own controls

Both fixes work by driving the same buttons you would click yourself, the unfold arrows and the file chevron, rather than calling GitHub's internal endpoints. That keeps them working when GitHub changes those endpoints, and it means no additional permissions or access tokens are needed. The permission footprint is unchanged from v3.2.1.

Release screenshots

3.2.1

RefactoringMiner Extension v3.2.1

A polish release focused on fixing the refactoring hover tooltip, a lighter permission footprint, and a cleaner options page.

Fixed: hover tooltip showed the wrong counterpart

On a complex diff, a single line can belong to more than one refactoring at the same time (think an Extract Method whose body also contains an Extract Variable). The tooltip kept track of all of them but only ever read the first when it built the "other side" preview, so hovering a line could show you the counterpart of an earlier refactoring instead of the one under your cursor.

Now the preview is tied to what you're actually looking at:

• When a refactoring is selected (blinking, or stepped to in the navigator), the tooltip scopes to just that one and shows its counterpart lines.
• When nothing is selected, it shows every refactoring the line takes part in, each with its own title, so a shared line is never misleading.
• The tooltip's position was tightened too, so the preview sits cleanly against the line you're hovering.

Slimmer permissions

The extension no longer requests the activeTab permission. It now runs on its storage and GitHub host permissions alone, so it asks for less access to your browser while behaving exactly the same on supported diffs.

Options page polish

The options page got a cleaner, more scannable layout across all of its controls (activation mode, before / after highlight colors, blink speed, page theme, and the standalone-service settings). The default highlight color was also corrected so a fresh install looks right before you customize anything.

Refreshed icons

New toolbar and store icon set, with the in-page logo sized correctly for both light and dark themes.

Release screenshots

3.2.0

RefactoringMiner Extension v3.2.0

This release reworks how you navigate refactorings on large diffs and cleans up the whole in-page experience.

New: focus navigator pill

The old pinned marker lines are gone. On big refactorings they piled up without limit and ended up covering the entire screen, which made the diff unusable exactly when you needed it most.

They're replaced by a single, fixed-size navigator pill at the top of the page:

• Step through refactorings one at a time with ‹ / › or the j / k keys.
• Each step reveals the refactoring, blinks it on the diff, and centers it, un-collapsing a folded or collapsed file first if it has to.
• It's always one row tall, so it never grows or takes over the screen, no matter how large the change is.

Two companion aids stay out of your way:

• A slim minimap on the right edge with one tick per refactoring and a viewport marker.
• Edge chips that appear only when a selected refactoring has lines above or below the fold, and point you to them. At most one per edge, so they can't stack up either.

Refactorings panel

• Collapsed rows now show just the refactoring type for a clean, scannable list.
• Click a row to expand it and reveal a formatted explanation of the change (RefactoringMiner's description, broken into one readable line per clause) along with a one-line summary.
• Clicking a row still blinks that refactoring across both sides of the diff.

Customizable highlight colors

Set your own before / after highlight colors from the options page, with a live preview. Changes recolor any open diff instantly.

Click-to-activate

The extension now waits for a click on its toolbar icon before analyzing a diff, so it only runs when you want it to. Prefer the old behavior? Turn on Automatically activate in the options page to have it run on supported diffs automatically.

Other

• Standalone RefactoringMiner service settings (URL, token, timeout) remain in the options page for repos that don't run the action.

3.1.5

v3.1.5

Patch: refactoring selections now work on files GitHub collapses behind a
"Load diff" button.

Fixed

• Selecting a refactoring (from the report panel or a deep link) whose lines
  live in a collapsed large-diff file did nothing — the lines were never in the
  page, so there was nothing to highlight. The extension now clicks GitHub's own
  Load diff / Expand all controls to reveal the file, waits for the line
  to render, and then highlights it. Works on both commit and PR diffs, and on
  the classic and React (/changes) views. (#10)

Notes

• Already-visible lines are unaffected — the reveal step is skipped when the
  line is already on the page, so there's no added delay in the common case.

3.1.1

v3.1.1

Improved

• Pinned-line bars now read like real code. When a selected refactoring
  scrolls out of view, the floating "peek" bars at the top and bottom edges now
  keep each line's indentation instead of flattening it to the left margin.
• Bottom peek bars are back in reading order. Lines pinned at the bottom edge
  now stack lowest-to-highest line number (top to bottom), matching the top bars,
  so a multi-line refactoring reads in its natural order in both stacks.

3.1.0

version update