diff options
| author | blasty <peter@haxx.in> | 2026-07-23 23:23:05 +0200 |
|---|---|---|
| committer | blasty <peter@haxx.in> | 2026-07-23 23:23:05 +0200 |
| commit | 645b980ad94044951546a1db750b04f00a79ad87 (patch) | |
| tree | 580ea424d82be94c98621b8007e3020002997da0 /tests | |
| parent | nav: land the cursor on the ref's column, not column 0 (diff) | |
| download | ida-tui-645b980ad94044951546a1db750b04f00a79ad87.tar.gz ida-tui-645b980ad94044951546a1db750b04f00a79ad87.tar.xz ida-tui-645b980ad94044951546a1db750b04f00a79ad87.zip | |
fix: keep the pseudocode cursor/scroll when a rename re-decompiles
Renaming a symbol in the decompiler re-decompiles and refreshes (good), but the
pane rendered at the wrong scroll until the first cursor move nudged it back.
Cause: _reload_active_code only cleared loaded_ea and re-showed, and dec_scroll_y
isn't tracked on every move, so _apply_decomp fell into show()'s DERIVE branch --
a bare scroll_to that, on a freshly shown pane whose size isn't computed yet,
clamps/leaves a stale frame until the next interaction.
Now the decomp refresh snapshots the LIVE pseudocode cursor + scroll from the
widget before forcing the recompile, so _apply_decomp takes show()'s robust
_apply_scroll path (deferred re-apply + refresh(layout=True)) and repaints at the
right place immediately.
Verified on main (421-line pseudocode, 22-row viewport): before rename
cursor=54/scroll=33; after rename cursor=54/scroll=33, cursor visible -- position
preserved with no stale frame. rename/rename_history/decomp_nav/
decomp_follow_self/view_toggle/follow_xrefs/xref_labels/listing_view/
continuous_view/func_banners/search/mouse/disasm_nav green (follow_xrefs was an
ordering flake; 14/0 in isolation).
Diffstat (limited to 'tests')
0 files changed, 0 insertions, 0 deletions