diff options
| author | blasty <peter@haxx.in> | 2026-07-23 22:52:54 +0200 |
|---|---|---|
| committer | blasty <peter@haxx.in> | 2026-07-23 22:52:54 +0200 |
| commit | 081b62360e937fd44bd4d2518dee2543dc51fd2a (patch) | |
| tree | b3af96f593a15019b2748347186f5e9334d15718 /spawn.sh | |
| parent | fix: Tab back from a decomp jump returns to the listing cleanly (diff) | |
| download | ida-tui-081b62360e937fd44bd4d2518dee2543dc51fd2a.tar.gz ida-tui-081b62360e937fd44bd4d2518dee2543dc51fd2a.tar.xz ida-tui-081b62360e937fd44bd4d2518dee2543dc51fd2a.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 'spawn.sh')
0 files changed, 0 insertions, 0 deletions
