diff options
| author | blasty <peter@haxx.in> | 2026-07-23 23:07:47 +0200 |
|---|---|---|
| committer | blasty <peter@haxx.in> | 2026-07-23 23:07:47 +0200 |
| commit | 6634ffed6e8727a9e709b136e8a27829ee38a0d3 (patch) | |
| tree | ed3fe92fff16848e4b3a2e1d0f6f62135e7096a3 /server/patch_server.py | |
| parent | fix: Tab decomp->listing reuses the nav entry so edits stay put (diff) | |
| download | ida-tui-6634ffed6e8727a9e709b136e8a27829ee38a0d3.tar.gz ida-tui-6634ffed6e8727a9e709b136e8a27829ee38a0d3.tar.xz ida-tui-6634ffed6e8727a9e709b136e8a27829ee38a0d3.zip | |
fix: refresh-after-edit keeps the edited line on screen (rename now visible)
On a large binary the renamed label appeared not to update: the edit refresh
reloaded the listing from a nav entry whose cursor/scroll could be stale, so on a
huge segment the rebuilt model primed/scrolled to the wrong index and the renamed
line landed off-screen (or in an unloaded region) -- looking like the rename
never propagated. (Small binaries hid it because everything is near the top.)
_reload_active_code now captures the LIVE listing position straight from the
widget (the source of truth) instead of trusting nav-entry tracking, so the
rebuilt model primes around the real cursor and the edited line stays put.
Verified: with _cur.cursor deliberately corrupted to 0, renaming a label at row
56 keeps it on screen (0000210E DEEPLBL:); decomp->Tab->rename and pure-listing
rename still stay on the label. rename/rename_history/comment/retype/view_toggle/
decomp_nav/decomp_follow_self/follow_xrefs/xref_labels/disasm_nav/search/mouse/
listing_view/continuous_view/func_banners/scroll_restore 70/0.
Diffstat (limited to 'server/patch_server.py')
0 files changed, 0 insertions, 0 deletions