diff options
| author | blasty <blasty@local> | 2026-07-23 22:52:54 +0200 |
|---|---|---|
| committer | blasty <blasty@local> | 2026-07-23 22:52:54 +0200 |
| commit | 1540b3904dbf605a881121f9571a1b021168af00 (patch) | |
| tree | 038b40ec04978c7feaf3039a274226a5bd81d86f /server | |
| parent | fix: Tab back from a decomp jump returns to the listing cleanly (diff) | |
| download | ida-tui-1540b3904dbf605a881121f9571a1b021168af00.tar.gz ida-tui-1540b3904dbf605a881121f9571a1b021168af00.tar.xz ida-tui-1540b3904dbf605a881121f9571a1b021168af00.zip | |
fix: Tab decomp->listing reuses the nav entry so edits stay put
The previous fix reopened the listing via _goto_ea(push=False), which made _cur a
DETACHED entry (not _nav[-1]). Cursor moves update _nav[-1], so _cur.cursor went
stale: after moving to a label and renaming it, _reload_active_code ->
_open_entry(cur) restored the stale cursor and scrolled the just-renamed label
off-screen. The rename actually applied (model showed the new name) but the view
jumped away, so it looked like it "didn't propagate".
Now Tab from a jumped-to pseudocode view converts the CURRENT entry (which is
_nav[-1]) to a listing view in place (_toggle_to_listing): set view="listing",
position at the current line's address, and reopen. Cursor moves keep updating
the same entry, so a subsequent rename reloads at the cursor and the renamed
label stays on screen.
Verified: decomp jump -> Tab -> move to loc_ label -> rename: cursor stays on the
label, which now shows the new name (00002040 ZZLABEL:) in the viewport.
view_toggle/decomp_nav/decomp_follow_self/follow_xrefs/xref_labels/rename/
rename_history/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