mirror of
https://github.com/l0ng-ai/tty7.git
synced 2026-09-22 00:02:23 +00:00
l0ng-ai
b23e0feb55
The code panel hangs off the tab, so closing the tab drops every buffer in it. `editor_close_file` asks before closing a *file*, and the file tree marks a dirty one — but nothing outside `code_editor` read `dirty` at all, and `tab_close_reason` looked at `pane.terminals()` and nothing else. Every close path that went through the tab took the edits without a word. The ordinary ⌘W is one of them. `CloseActiveTab` reaches `editor_close_active_if_focused` only while the editor has focus; with focus in the terminal — which is where it is after you edit a file and go back to the shell — it goes to `close_pane`, and a last pane takes its tab. Type into a file, click the terminal, press ⌘W, and the text is gone with no dialog. `UnsavedEdits` is checked first wherever a reason is derived. Of the three, it is the only loss that cannot be undone by doing the thing again: a killed command can be re-run and a dropped SSH link reconnected. Three paths, because the tab can end from three directions: - `tab_close_reason`, for a tab closed as a tab. - `focused_pane_close_reason`, because `close_pane_inner` carries its own `confirmed` into `close_tab_inner` so the tab does not ask twice — which means a question the pane never asked is never asked at all. - the bulk closes, which pass `confirmed` and so cannot ask. They skip instead, on the same footing as an SSH profile that asked to be warned about. Deliberately not the footing of a busy tab: busy is the state most tabs on a working window are in, so skipping it would close nothing, while unsaved edits are rare and unrecoverable. Both loss paths were run against the unfixed code and fail there. The third test — a saved buffer still closing outright — passes either way on purpose: it holds the guard to the edits rather than to the mere presence of a code panel.