Spyder: When newly created, unsaved file open, running any file triggers the save as dialog

[CAM-Gerlach]

Description

If any newly created, unsaved "untitled#" file is open with any text added, attempting to run (F5 by default) any other file, even if already named and saved, triggers the save as dialog for the untitled file. Is this the desired behavior? It would seem this should only be triggered on attempting to run the unsaved, untitled file, not any other arbitrary, unrelated file as saving the former is not nominally necessary to run the latter, whereas it is for running just that untitled new file. To note, this behavior is _not_ triggered if no text has been added to the new file besides the new file template.

What steps will reproduce the problem?

1. Open at least one saved file
2. Create a new file, and add some text to it
3. Switch back to the saved file, and attempt to run it (by default, F5)

What is the expected output? What do you see instead?
Expected: Running saved/existing file does not trigger save as dialog box for new file; only running new file does.
Actual: Running any file, new or existing, that is open triggers the save as dialog for the untitled file.

Please provide any additional information below

Observed on multiple systems, environments and OS versions.

Version and main components

• Spyder Version: 3.2.4
• Python Version: 3.6.3
• Qt Versions: 5.6.2, PyQt5 5.6 on Windows 10 Pro x64 and Windows 8.1 Pro x64

Dependencies

pyflakes >=0.6.0 :  1.6.0 (OK)
pycodestyle >=2.3:  2.3.1 (OK)
pygments >=2.0   :  2.2.0 (OK)
pandas >=0.13.1  :  0.20.3 (OK)
numpy >=1.7      :  1.13.3 (OK)
sphinx >=0.6.6   :  1.6.3 (OK)
rope >=0.9.4     :  0.10.5 (OK)
jedi >=0.9.0     :  0.10.2 (OK)
nbconvert >=4.0  :  5.3.1 (OK)
sympy >=0.7.3    :  1.1.1 (OK)
cython >=0.21    :  0.26.1 (OK)
qtconsole >=4.2.0:  4.3.1 (OK)
IPython >=4.0    :  6.1.0 (OK)
pylint >=0.25    :  1.7.4 (OK)

[ccordoba12]

Is this the desired behavior?

I think it could be improved by making F5 to save only the file that's going to be run, instead of all files.

[CAM-Gerlach]

I think it could be improved by making F5 to save only the file that's going to be run, instead of all files.

Indeed; that's what I was thinking of. That's the behavior I, as I user, would naively expect, and conversely might not expect other files to be saved (and there are certain corner cases where that could post an active problem). I just wasn't sure if there was another reason behind the behavior that superseded that.

[jnsebgosselin]

I think it could be improved by making F5 to save only the file that's going to be run, instead of all files.

I do not agree with this change. For example, let's say I have two files:

File1

def do_something():
   print("Do something")

File2

from file1 import do_something

do_something()

Let's say that I do some changes to File1 and then run File2. This is very convenient in this case to have F5 save all files before running File2. From my understanding, with the proposed change, I would have to think and explicitly save File1 before running File2 with F5.

This is something I do not want.

[CAM-Gerlach]

Hmm, I see...I was wondering how common that was; I usually save (perhaps a little too) obsessively so I don't see that as often, but it certainly does come up. On one hand, I can think of several cases where the opposite would be desired (unfinished/breaking changes to a dependent file, testing something temporarily without wanting it to be saved, and of course the unsaved files issue here), and a save-all command does exist adding only one extra keystroke for situations where the user wanted to save their files first. However, since "Save all files before running script" is a user-visible pref option in the GUI, which when disabled only saves the current file (from what I understand, is essentially the behavior being proposed by @ccordoba12 ), this seems to be already possible currently .

I guess the only potential quibble at that would be its enabling by default, so that a newer user might be surprised at that being the default (explicit is better than implicit, and all that) but on the other hand another user might be surprised why running a script doesn't take into account heretofore unsaved changes in another module, so perhaps its a wash.

In any case, what I would suggest is simply not saving only new, untitled/never-saved files (other than the current one) when that option is checked; being never saved and named, it is not really possible that they could be referenced in the current file, and thus essentially can not affect its behavior if not saved. Therefore, this would have no impact on cases like @jnsebgosselin brought up (and I and I'm sure many others encounter as well), while not being a nuisance (and not really serving the intended purpose) when another new/untitled file is present. Thoughts?

[jnsebgosselin]

Thank @CAM-Gerlach your comments.

I think the only thing there is to consider here is whether to check the Save all files before running script by default or not. I don't know what the default should be, but I know that checking this option is going to be the first thing I do when setting up Spyder for the first time if we change it :)

I would still pop the dialog for new untitled/never-saved files since, well, that is what I expect by checking the Save all files before running script option.

[CAM-Gerlach]

I think the only thing there is to consider here is whether to check the Save all files before running script by default or not. I don't know what the default should be, but I know that checking this option is going to be the first thing I do when setting up Spyder for the first time if we change it :)

Haha, on balance I think I'd _probably_ leave it on too and just endure the annoyance when I have a new unsaved file open (for experimentation, when deciding on a proper name, when setting up a basic structure...). I have no real opinion here, as I can see reasons for either as a default.

I would still pop the dialog for new untitled/never-saved files since, well, that is what I expect by checking the Save all files before running script option.

Hmm, I'm not sure about this one. Intuitively, if one considers the reason for that option as being what you stated above (which makes perfect sense), it would make sense to save any other already saved files, but not untitled/never-saved ones as they cannot have anything to with the matter at hand (running a different script), particularly having to name and choose a location for them (forced Save-As) which is an entirely separate task.

If one wants to explicitly save all files including untitled ones, they can just hit the Save All shortcut to do so (which only needs to be done once, after which the new files will save automatically when running since they are now named), while on the other hand if one wants to simply run the current file making sure all open potentially related files are updated, they have to hit cancel on the Save As dialog box every time they do so for each new/not yet saved file if they want to keep them unsaved, or go through the directory selection, naming and saving process for that not (yet) related file just to run a different one.

Its not the end of the world either way, and I understand your strict consistency argument for forcing the Save As (though only if one considers the "Save" command to be equivalent of the "Save As" command...but that's arguing semantics), while my suggested approach seems to make more sense to me if one looks at it from the perspective of what actually motivates of that option beyond naively concatenating two separate commands, as well as from the perceptive of user inconvenience/practicality. But I'm a n00b, what do I know :)

[jnsebgosselin]

This makes sense. I agree we could skip the Save As dialog for newly/unnamed files when hitting F5. I Let's see what @ccordoba12 think.

[ccordoba12]

This was fixed by PR #10115.