Replies: 2 comments
-
Agreed. There's too many things about the way we reload things that break if we don't actually do a full restart. Specifically; things like overloading functions; if you overload a function in the user module, it simply adds a call frame every time you do this. Could lead to really confusing behaviour. Likewise, plugins don't have to pay attention to their configs after they're loaded. It's good when they do, but currently things can get weird if you change the configs post-launch. We should probably do some tests with all the core plugins, and all plugins in the plugins repo to see if any of them require specific changes for this to work. |
Beta Was this translation helpful? Give feedback.
-
This is being implemented in #1456. |
Beta Was this translation helpful? Give feedback.
-
As reloading the user/project module is a bit finicky and prone to problems caused both by the content of the module itself and by how plugins are written, I think that we should focus on getting
core:restart
to be as seamless as possible and use that instead.Restarting is already pretty fast, and only a couple of things from core are needed to make it more seamless (for example we don't preserve multicursors and undo history).
On the plugins side, I think that we should provide a way to specify what to save and how to reload that. A solution (that needs to be expanded) was proposed in #438.
On module save, we could ask the user if they want to restart or keep going.
If we get to a point that
core:restart
really is seamless, we could decide to prompt the user only if there are unsaved docs (core:restart
already does it, but a more appropriate message about module reloading should be shown in that case).Possible problems with this approach would be mostly caused by plugins that don't save their state correctly, and plugins where state saving is not really trivial (for example a terminal plugin could have troubles keeping the open processes).
Beta Was this translation helpful? Give feedback.
All reactions