✨ New files should not be saved to location until manually saved

[austincondiff]

Is your feature request related to a problem? Please describe.

Sometimes users just want to create a new file for a scratchpad, to type out some ideas, to paste content in and play around without any repercussion, make a simple todo list, or just take notes. Currently if creating a file via "File → New" or ⌘N will prompt you to select a location before a new file is created. This doesn't allow for on-the-fly file creation because these files shouldn't have a location, that is until the user decides that they want to keep the file and save it in a particular location.

Describe the solution you'd like

Upon creating a new file via "File → New" or ⌘N, CodeEdit will create a new tab with an empty editor immediately. No file will be saved to a known location however these tabs will persist across application restarts. There is no limit to how many new unsaved files a user can create in a workspace. When the user attempts to save the file, CodeEdit will prompt the user to select a location. If the user attempts to close the tab before saving, CodeEdit will warn the user before this is unsaved and by closing the tab they will loose the contents of that file if they proceed.

Additional context

Screen.Recording.2023-02-20.at.12.16.52.PM.mp4

The proposed behavior is how VS Code currently behaves.

This also applies if the user creates a new file from the Welcome Window.

If the user creates a new file by right clicking a folder in the project navigator and clicking New File, it will add the new file there and not create any empty tabs as specified above.

Screen.Recording.2023-02-20.at.1.36.28.PM.mp4

As shown in the video above, untitled files should be stored as a temporary file in our Application Support folder until the user saves. Then it can be moved to the user-defined location.

[RenanGreca]

I can look into this, since I have been working on the file creation process.

[richardtop]

Very important issue, it's how the Apple's TextEdit, as well as CotEditor work.
In addition, Sublime Text supports this behavior.

I'd like to contrast this with Xcode which requires saving a playground before actually being able to run any code.

[austincondiff]

@RenanGreca how is this coming? Are you still working on this?

[richardtop]

Is this fixed?

[matthijseikelenboom]

No, not fully at least. The branch ISSUE-1070 contains a big part of the implementation, but there are two crucial bugs that prevent it from getting merged to main. Both of the (known) issues are noted in the PR. But the biggest is that saving doesn't work properly anymore.

[austincondiff]

@matthijseikelenboom which bugs are these specifically? Is there a draft PR out for ISSUE-1070? We need to track this so we can get this done and out of the way.

[matthijseikelenboom]

There was a PR open, but it took too long to find the causes and remove the bugs. So I've merged it into a separate branch and there is no draft PR open for the fixes.

The issues are noted, like I said, in the merged PR. There are no public issues open for them because the bugs are not present in main or releases. But I can list them here:

• When the user tries to edited the file when it is no longer a scratch file, the save functionality doesn't work anymore. Cause is unknown, hard to debug.
• When the user decides to delete a scratch file, the editor will give a popup for the second time when the application is quit. This can have something to do with the nesting of NSDocument in the app...?

I suggest @thecoolwinter, @activcoding or @Wouter01 (if he has the time) to take a look at it

Branch url: https://github.com/CodeEditApp/CodeEdit/tree/ISSUE-1070