Switch to project or create new

[filippocrocchini]

This closes #152.
When switching to a new project allow for creating a new one the same way as you do by saving a file.
This also include a small fix to the open file dialog, it no longer shows the save as option if the file name matches exactly with an existing file.

This is what it looks like:

After a new project is created and switched to, it will open the newly created project config so that you can edit it.

I added "Open or Create a Project" to the welcome screen. I also tweaked the vertical alignment of the right side so that it's visually centered with the left side.

[filippocrocchini]

Let me know what else needs to be changed, I'm still figuring out the codebase.

[focus-editor]

Thanks for your MR - I will review this when I can, quite busy now, sorry

[focus-editor]

I'm still busy but I've had a quick look and I can already say that I don't want to mix switching to project and the creation of a new project.

Instead the plan was to add a new dialog where the user would just type the name of the project without specifying any path and it would save it to the global project directory. Then we wouldn't have to pollute the existing dialogs with this extra logic and also would avoid the users accidentally creating new projects when they mistype the name of the project they want to switch to.

Also, the convention going forward is to keep the name of the action as close to the display name of the action as possible - i.e. we shouldn't call an action "Open Project" when the underlying action in code is called switch_to_project

[filippocrocchini]

I see, yeah I was unsure of how you wanted to approach the issue. My idea was to try to contain the amount of commands. In this case I agree that having a dedicated "new project" probably makes more sense. I'll see if I can add that instead in the coming days. Thank you for the feedback!

[filippocrocchini]

I have some questions I have been thinking about:

1. How would you prefer handling creating a project with a name that already exists? Maybe doing something similar to how github handles naming a repository? E.g. showing "Project name is available." / "Project name is already taken." under the input box.
2. Do we want to allow people to create a project in a specific directory instead of the global one? And in that case, do we want to use the save file dialog box, with the default path to the global config folder? That way we solve issue 1 for free as well.
3. Should new_project also switch to it once it's created, and open the config? Instead of having to do new_project -> switch_to_project -> open_project_config.
4. What would you think the new project-config should contain:
   1. Default/example config
   2. Global config copy
   3. Default/example config but modified --ideally commented out-- to avoid overriding global config keybindings/colors/setting and whatnot

[focus-editor]

These are difficult questions - at this point I'm not sure what would be best, but this is what I had on my list - this is not a 100% list of things to do but just some notes for myself for when I pick this up, which seemed reasonable when I was thinking about it:

- Finish revamping project switching - https://github.com/focus-editor/focus/issues/393
    - Should we close this after it's done https://github.com/focus-editor/focus/issues/152
        - Projects revamp:
        - New Project command:
            - Opens up an open file dia1log (or a system dialog) for the user to choose a file
            - Makes sure the extension is .focus-config
            - When a file is created, we switch to project and open that file (and add to recent projects)
        - Switch To Project command:
            - One of the options would be to choose project from disk:
                - Opens up an open file dialog and allows to select a .focus-config file
                - Doesn't allow to select the current global config
                - When selected, we load the project and add it to recent projects (or bump it in the list)
        - Open Directory command:
            - Just open the directory and add it to workspace (only get rid of it if workspace was touched in the config)
            - If the directory has a project file, load it as well. Decide whether we require a `.` in that case. If we don't require it, consider not requiring it when launching focus from the command line as well
        - Save workspace as and open folder:
        (user feedback) Picture VSCode, you can go to File -> Open Folder and then it will give you all the files and stuff in that folder. I wanted to make something like that for Focus, but instead of it just opening a folder, it would open it, and then create an in-memory workspace for it. Then you can do Save Workspace As
        That way when I start a new project which is pretty much every 2 seconds, I don't have to navigate to the focus directory, copy and paste a config, and then edit it. I can simply just open it as a folder instead and then save that as a workspace, like in vscode and maybe other editors
        - Handle ./ in ignore and allow wildcards
            - Warn about the use of ../ or /../

If you'd like to work on this I'd be happy with that, if you're okay with some back and forth and potentially redoing things a couple of times. Otherwise I'll do it myself when I'm able to.

One more thing - I have a couple of branches with some serious refactoring going on around config and file watchers, so it's best not to touch config internals if possible, or there are going to be conflicts.

[focus-editor]

What would you think the new project-config should contain

Some minimal contents, maybe similar to what the Example Project file contains

[filippocrocchini]

Nice, I would love to work on this! I'm ok with doing some back and forth. It might take a while but that's ok. I'll check #393 and also what you are doing with config and file watcher so I know what not to touch. This is a bigger project than I was expecting 😅 but I think it will improve usability a lot. I think I will get back to you with a plan before I actually start changing stuff around.

[filippocrocchini]

So, initially I was thinking of adding a bunch of commands like "open project file", "new project", "new project file", "new project from folder" and so on but it didn't feel like it fit focus. There were too many edge cases. So here's what I think is best, which would build on the system as it currently is. Let me know what you think. If you like the idea I will start working on a proof of concept implementation.

We have the concept of project config which only exists when a project is open. My plan is to extend this concept to always existing even if no project is open. Think of it as a "workspace" config. To do so, when no project is open there will still be a config which will act as backed by a file, but it won't be (I guess it could also be backed by a temporary file). Meaning, you can save it, which will reload the "project" with the changes you made. And save it as, which will effectively create a new project by making it backed by a file. Once this core feature is there we can get everything else we want organically. I believe.

New/modified commands

• Remove show_default_config, this should no longer be necessary.
• Add switch_to_project_file.
• Add add_folder_to_project.
• Modify switch_to_project to display recent projects as well.
• Maybe add save_workspace_as_project, but I don't think it's strictly necessary.

Note:

• open_project_config will open the virtual config if no project is loaded.
• close_project will reset the virtual config if no project is loaded, prompting for saving as it's a destructive operation.
• switch_to_project_file: Pick a focus-config from file picker.
• switch_to_project: Pick from global and recent projects.
  • Question: Is there a reason why we can't use the file picker opened in the global config folder here? That way we don't need the "Switch to project file" command.

Examples

All of the following examples assume you have no project open, but will work if you do have one open. They will just achieve something different.

• Create a new project:
  1. open_project_config (virtual config)
  2. save_as (alternatively we can have a save_workspace_as_project command)
• Switch to a project that is not in the global config folder:
  1. switch_to_project_file
• Open a folder 1:
  1. open_project_config (virtual config)
  2. Add folder to [Workspace]
  3. save (or save_as to create a new project)
• Open a folder 2:
  1. add_folder_to_project (this way you can use file picker if you need to browse)

[focus-editor]

"open project file", "new project", "new project file", "new project from folder" and so on but it didn't feel like it fit focus

Not sure why those commands would be needed, you're right that we should keep things simple.

My plan is to extend this concept to always existing even if no project is open

I feel like this is already overcomplicating things. If no project is active, the user shouldn't be able to open its config file. Also remember that changing the way configs get loaded and applied would conflict with my config system rewrite.

Remove show_default_config, this should no longer be necessary.

I'm not seeing why it would no longer be necessary - it's still useful for people to reference after their custom configs have diverged from the default one.

Add switch_to_project_file.

Why? There's already switch_to_project, no need for another command - if the user wants to load a project from a file, there should be an option in the project list itself, which would then open a file picker.

Add add_folder_to_project.

I would suggest to call it add_directory_to_workspace - we don't use the word folder anywhere in the actions, and workspace always exists, even if there's no project.
Ideally the same thing should happen when a user drags a folder into the editor (but that could be something for later).

Modify switch_to_project to display recent projects as well.

I think it already acts like this.

Maybe add save_workspace_as_project, but I don't think it's strictly necessary.

It is useful and it was in the plan. It should also be easy to implement - just make it do what the create_new_project command would do, but when creating the project file just populate the workspace with whatever the user has loaded.

To reiterate, I don't think we should be introducing virtual projects. Everything that was planned as part of this work should be naturally implementable without adding new concepts

[filippocrocchini]

I feel like this is already overcomplicating things. If no project is active, the user shouldn't be able to open its config file. Also remember that changing the way configs get loaded and applied would conflict with my config system rewrite.

Sure, that's a good point. If for example you want to open a folder without creating a project first as you can do in many other editors, be it in memory or in a temp file, somewhere there must be a temporary "workspace config" that contains the currently tracked folder/s and so on. So, my proposal was to make that accessible to the user until it becomes a project file, that way they can change settings and add folders the same way they normally would. This would be the same behavior as VSCode. There is a workspace settings tab if you have a folder open (or a project obviously), they will create .vscode folder with workspace settings when you commit changes; if you have multiple folders in the workspace they will create a temporary workspace in AppData until you save it. I do concede that the naming it project-config might be confusing there, so following them and calling it workspace-config would be best imo.

I think in general it's a common pattern to open a text editor, open some folders, change some configs and then once it's set up, save the workspace to a file as a project --or maybe not--. So, I wanted to facilitate that workflow by delaying asking the user to make choices until it's unavoidable (e.g. picking where the project should go). Moreover it would remove the need for a new_project command, as closing the current project and adding a folder to the workspace (or opening a new focus instance) would be enough.

If you think there could be conflict between implementing this and your config and file watcher rewrite let me know and we can pause this until those are done. If instead you prefer not allowing users access to settings until they have created a project I understand and will move on with that.

[focus-editor]

somewhere there must be a temporary "workspace config" that contains the

currently tracked folder/s and so on There's the in-memory config which contains everything, when the user opens a folder, that in-memory workspace dir array will get modified, then if the user wants to save that as a project, the information can be taken from there to generate a config file. No need to invent any new concepts.

…

On Sat, Sep 27, 2025, 11:09 PM Filippo Crocchini ***@***.***> wrote: *filippocrocchini* left a comment (focus-editor/focus#595) <#595 (comment)> I feel like this is already overcomplicating things. If no project is active, the user shouldn't be able to open its config file. Also remember that changing the way configs get loaded and applied would conflict with my config system rewrite. Sure, that's a good point. If for example you want to open a folder *without creating a project first* as you can do in many other editors, be it in memory or in a temp file, somewhere there must be a temporary "workspace config" that contains the currently tracked folder/s and so on. So, my proposal was to make that accessible to the user until it becomes a project file, that way they can change settings and add folders the same way they normally would. This would be the same behavior as VSCode. There is a workspace settings tab if you have a folder open (or a project obviously), they will create .vscode folder with workspace settings when you commit changes; if you have multiple folders in the workspace they will create a temporary workspace in AppData until you save it. I do concede that the naming it project-config might be confusing there, so following them and calling it workspace-config would be best imo. I think in general it's a common pattern to open a text editor, open some folders, change some configs and then once it's set up, save the workspace to a file as a project --or maybe not--. So, I wanted to facilitate that workflow by delaying asking the user to make choices until it's unavoidable (e.g. picking where the project should go). Moreover it would remove the need for a new_project command, as closing the current project and adding a folder to the workspace (or opening a new focus instance) would be enough. If you think there could be conflict between implementing this and your config and file watcher rewrite let me know and we can pause this until those are done. If instead you prefer not allowing users access to settings until they have created a project I understand and will move on with that. — Reply to this email directly, view it on GitHub <#595 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A4OX77XQV4RC57334JPIGGL3UZV7BAVCNFSM6AAAAACGWCBBR6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGNBRGUZDSNBVGI> . You are receiving this because you commented.Message ID: ***@***.***>

[filippocrocchini]

I don't think I have as much time as I thought to work on this, I have been trying but I keep having to postpone it because of work and other stuff. I don't want to promise something I can't deliver. I don't know if you want to close this, but I don't think I will manage to implement this within the coming months. Maybe someone else can continue :/

[focus-editor]

I totally understand. Let's keep it open for now and then we'll see if we're able to continue this. Thanks for going this far with this.