Athan

In short, it is not clear to me that what is loaded by default equals what state the settings were when the REPL last closed.

...certain things make sense to persist and be the default next time around (e.g., themes?), but other things less so. E.g., if I temporarily disable auto-closing and forget to re-enable...

Why don't we avoid this discussion altogether and just prompt a user before exiting the REPL as to whether they want to save current REPL settings when the current REPL...

BTW: you'd still need a `last_repl_session.json` file to allow manual restore if a user's system crashes while the REPL is open and before settings and other session info could be...

In short, here is a possible summary: 1. On startup, compare the settings from the last REPL session with the "default" settings (i.e., a user's saved configuration). If these differ,...

> And I think we can figure out restoring a session upon a crash when we work on being able to save the entire REPL state along with variables etc,...

I am not a fan of having multiple keybindings for exiting the REPL. Having two is almost too many. Having three just creates confusion.

> This way we don't add any additional steps that the user probably wouldn't appreciate. Being explicitly prompted to save or affirming that one is okay navigating away from some...

> a custom configuration in any of their parent directories Good question. I think we need to remember the configuration file path of whatever configuration file was resolved and loaded...

> what if the configuration was loaded from a .js export Ugh. 🐉 's everywhere. Sure, `*.json` for now is fine. We can always revisit later wrt `*.js` support.