Describe the project you are working on:
gdscript plugins
Describe the problem or limitation you are having in your project:
When deleting a script with godot filesystem (right mouse click - Delete), I also need to manually close it from script list in ScriptEditor (if it is opened). This can be inconvenient especially when doing it often.
Describe the feature / enhancement and how it helps to overcome the problem or limitation:
Closing a script in Script Editor automatically when deleting it could resolve it.
Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
When deleting a script for example using right mouse click - Delete in Godot filesystem, the deleted script could be deleted from ScriptEditor script tabs automatically this way one wouldn't need to press right click - Close or Ctrl+W to close the script.
If this enhancement will not be used often, can it be worked around with a few lines of script?:
using plugins - maybe, not sure about "a few lines" tho
Is there a reason why this should be core and not an add-on in the asset library?:
I think plugins can do that, but I alse think that at least having an opion to automatically close scripts when they are deleted would be useful at the core level.
IMO this should be optional. VS Code keeps deleted scripts too (but appends (deleted) in their name) and it's useful sometimes.
VS Code keeps deleted scripts too (but appends
(deleted)in their name) and it's useful sometimes.
In what cases? I think if I delete a script I'd like to forget about it
btw, if I delete several scripts at the same time, then in the scripts list I have to delete them one by one.
since it looks like there is no way to select multiple scripts at the same time in ScriptEditor
_Definitely_ should be optional and off by default.
Scripts are intentionally not removed from the list so that you can recover them in case of a mistake.
I think the better solution for now would be to append (deleted) to the script name once it's removed from the FileSystem dock. Removing large amounts of scripts isn't something one does often, so I think the current workflow is fine as it is.
Scripts are intentionally not removed from the list so that you can recover them in case of a mistake.
when deleting a script, Godot asks if you really need to delete the script
Imo this is enough to avoid doing mistakes.
Btw: now scripts, when deleted, lose their names in the scripts list (you can see this after refreshing script list).
Yes, they probably lose it because there is no longer a file associated with the resource. I think the panel uses resource_path and thus deleted scripts have none. Some workaround is required to track obsolete paths, but I too think that we better keep them unless closed explicitly by a user.
I think a system like VSCode is good, but AFAIK it doesn't exactly work as described above; when you delete a file inside VSCode he does delete it entirely and closes it's open tab. It's only if something external to VSCode makes changes (such as git commands) that it keeps a reference to the old file (the 'deleted' tag)
So I think a similar system for Godot is better; if the user does something explicit inside Godot, then it shouldn't need to preserve the file (and Godot already has a confirmation window for deleting a file, so keeping it afterwards is redundant); if a change to the filesystem happens externally, Godot can tag the open file as "deleted", similar to VSCode.
Btw: now scripts, when deleted, lose their names in the scripts list (you can see this after refreshing script list).
and Godot already has a confirmation window for deleting a file, so keeping it afterwards is redundant
Scripts are removed from the script list when deleting via the FileSystem docks since godotengine/godot#40647, because it literally says: "(no undo)". 馃檪
Does godotengine/godot#40647 resolve this proposal, btw? EDIT: this wasn't backported to 3.2 yet.
Most helpful comment
I think the better solution for now would be to append
(deleted)to the script name once it's removed from the FileSystem dock. Removing large amounts of scripts isn't something one does often, so I think the current workflow is fine as it is.