diff options
| author | blasty <blasty@local> | 2026-07-23 22:43:50 +0200 |
|---|---|---|
| committer | blasty <blasty@local> | 2026-07-23 22:43:50 +0200 |
| commit | b8240ddf4af934f2afff896b497ac4c639c0d1ab (patch) | |
| tree | 7533aac26b4754965b843c344a5df6953ed19f32 /server | |
| parent | nav: jumping from the decompiler stays in the decompiler (diff) | |
| download | ida-tui-b8240ddf4af934f2afff896b497ac4c639c0d1ab.tar.gz ida-tui-b8240ddf4af934f2afff896b497ac4c639c0d1ab.tar.xz ida-tui-b8240ddf4af934f2afff896b497ac4c639c0d1ab.zip | |
fix: Tab back from a decomp jump returns to the listing cleanly
Regression from the decomp-jump feature: _open_decomp_entry clears
_decomp_return, so Tab out of a jumped-to pseudocode view hit the fallback that
just re-showed the (stale) listing widget WITHOUT reopening it and left
_cur.view == "decomp". Two visible symptoms:
* the listing showed the wrong/old function, and
* a subsequent rename ran _reload_active_code -> _open_entry(cur), which saw
view == "decomp" and bounced back into the decompiler; the rename also
appeared not to propagate (you were looking at stale pseudocode).
Fixes:
* Tab from decomp with no F5 snapshot now opens the listing at the current
pseudocode line's address (a real listing view, _cur.view = "listing"),
so the correct function shows.
* _reload_active_code forces _cur.view = "listing" when refreshing the
listing, keeping the entry consistent with what's on screen.
Verified: F5 -> follow ref in decomp -> Tab -> listing shows the TARGET function;
renaming a label there stays in the listing and reflects the new name
(RELABELED: and 'jnz RELABELED'). view_toggle/decomp_nav/decomp_follow_self/
follow_xrefs/xref_labels/rename/rename_history/disasm_nav/search/mouse/
listing_view/continuous_view/func_banners 70/0.
Diffstat (limited to 'server')
0 files changed, 0 insertions, 0 deletions
