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.