A Restore whose ThemeFile fails to load changes no theme: the session goes on showing the one it did, its file still the one named

A Restore makes a fresh core, which started at the default theme and
asked for the dump's ThemeFile; when that file had broken since, the
failure reverted to what the fresh core had loaded, nothing, and ink
became orchard. A Restore that asks for a ThemeFile now carries over
the theme the old session showed and the file it loaded (and its Theme,
unless the dump names one), so a failure there changes nothing.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

1 files changed, 10 insertions, 0 deletions

diff --git a/src/dump.zig b/src/dump.zig
index e76bb1a2..fa21eaa4 100644
--- a/src/dump.zig
+++ b/src/dump.zig
@@ -888,6 +888,16 @@ fn initDump(gpa: std.mem.Allocator, opts: Options, zon_bytes: []const u8, previo
     p.locations_config = st.locations_config;
     p.settings.tree_context_tag_style = st.tree_context_tag_style;
     applySettings(p, st.settings);
+    // A dump naming a ThemeFile asks the host to load it again: until it
+    // has, and for good if it fails, the theme this session showed goes on
+    // (a failed ThemeFile changes nothing, a Restore's included), unless
+    // the dump names a Theme of its own.
+    if (previous) |old| if (p.theme_file_path.get().len > 0) {
+        const names_theme = for (st.settings) |line| {
+            if (std.mem.startsWith(u8, line, "Theme ")) break true;
+        } else false;
+        try colors.carryTheme(p, old, !names_theme);
+    };
     for (st.mounts) |mount| {
         var already_mounted = false;
         for (p.fs.mounts.items) |existing| {