spyder-ide / ux-improvements

Discussion about UX improvements for Spyder 5 and beyond
4 stars 2 forks source link

What working directory should be set when a project is closed? #74

Open ccordoba12 opened 1 year ago

ccordoba12 commented 1 year ago
CAM-Gerlach commented 1 year ago

Indeed we've discussed this at some length quite a while back, and my personal viewpoint is essentially unchanged that these forced console restarts are unnecessarily disruptive for fairly small gain and greatly increase the friction in using/switching projects especially for the users positioned to take fullest advantage of them (those with many files open and working on multiple differnet projects at once), and making them much less lightweight than intended (which is their primary benefit over other IDEs' approaches). So, my first preference is:

Another option (discussed before) would be to not remove all consoles when closing a project. In that case, this problem would become inexistent. [sic]

That being said, I do want to note that the concern

However, that could be confusing for users in case they have multiple consoles and they don't remember the cwd of the last one with focus. In that case, they could feel that Spyder is setting a random directory as the new cwd.

points to a bigger issue—it indeed is quite arbitrary to do this, since the user may have many consoles open, some in different environments and possibly some (or even all) that are remote consoles that don't have a meaningful local cwd. Therefore, it doesn't really make sense to just pick one of them at random to restore. Rather, if we are going to do this, they all should be restored (and preferably their respective Python interpreter, otherwise its a real pain setting them all up again). And taking it a step further, it should ideally be done for projects too.

This would be, presumably, somewhat more complex to implement than just leaving any open consoles alone, which avoids the issue entirely and also preserves the state of the user's session (variables, etc), which may be expensive to recreate. On the other hand, it does actually provide substantially more compelling benefit than before to switching consoles when switching projects (since the user could have multiple sets of consoles in different environments/working dirs per project), while reducing the harms (only the transient session state is lost and needs to be retrieved again, not the consoles, CWDs or interpreters of each). I'm still not sure if its worth it, but either would be a lot better than the current behavior.