diff options
| author | blasty <blasty@local> | 2026-07-23 23:23:05 +0200 |
|---|---|---|
| committer | blasty <blasty@local> | 2026-07-23 23:23:05 +0200 |
| commit | 6bc2cc233cc65e725b94750e093709c86296612d (patch) | |
| tree | a4c42476f8038855ab13d741a7528deb5db85f41 /server/patch_server.py | |
| parent | nav: land the cursor on the ref's column, not column 0 (diff) | |
| download | ida-tui-6bc2cc233cc65e725b94750e093709c86296612d.tar.gz ida-tui-6bc2cc233cc65e725b94750e093709c86296612d.tar.xz ida-tui-6bc2cc233cc65e725b94750e093709c86296612d.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 'server/patch_server.py')
0 files changed, 0 insertions, 0 deletions