diff options
| author | blasty <blasty@local> | 2026-07-23 23:07:47 +0200 |
|---|---|---|
| committer | blasty <blasty@local> | 2026-07-23 23:07:47 +0200 |
| commit | 2dac219225a9448ec20f479fa8488232e36586cc (patch) | |
| tree | bc7fdd0481a2f51820042eaf1ce58da789c9d9de /server | |
| parent | fix: Tab decomp->listing reuses the nav entry so edits stay put (diff) | |
| download | ida-tui-2dac219225a9448ec20f479fa8488232e36586cc.tar.gz ida-tui-2dac219225a9448ec20f479fa8488232e36586cc.tar.xz ida-tui-2dac219225a9448ec20f479fa8488232e36586cc.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')
0 files changed, 0 insertions, 0 deletions