After creating a new project, it is not available even after refreshing projects

[tukusejssirs]

I have just created a new project using Add New Project (I entered existing_folder/another_existing_folder/non-existing_existing_folder), but I cannot switch to it. Refresh[ing] Projects does not help either. Sublime Text restart didn’t help either.

The project and workspace files were successfully created (existing_folder/another_existing_folder/non-existing_existing_folder/non-existent_existing_folder.sublime-{project,workspace}).

Currently, I am running ST 4126 on Arch Linux.

I cannot even import the project (I need to open it using Project → Open Project…). Project Manager even shows a modal with Import name.sublime-project?, but after confirmation I cannot find it in the project list overlay.

I think I’ve found the culprit: I’ve already had a project with the same name, but under a different folder, for example:

• [existing project] folder/project/project.sublime-{project,workspace};
• [new project] different_folder/another_folder/project/project.sublime-{project,workspace}.

I suspect that Project Manager does not care about the path, only the project name.

[Valentin-Guillet]

Indeed, projects are managed by name and not by path so it is not possible to have different projects sharing the same name, even in different folders or groups. I added a safeguard to prevent creating a project with an existing name so that it doesn't happen again.

[tukusejssirs]

While you solved the immediate issue, wouldn’t it be better to add support of projects with the same name, but different paths? Of course, this would require to compare full path with filename, not only the filename when creating a new project.

In GUI, by default we would show the projects as we do now, but when there are two or more projects with the same name (but different path), we should output the path somewhere (e.g. output the full project path with its filename).

[Valentin-Guillet]

Such a feature would imply modifying a very large part of the code and would significantly make it less clear. The folder containing the projects files would have to be modified, either by having the whole path as the name of the folders for each directory, or by having an additional metadata saved in a new file somewhere. Moreover, when moving the code directory of a project, the project would now point to a wrong path and each project file would have to be modified automatically to take this into account. Such modifications would need refactoring the core usage of the plugin.

I think it is way easier, clearer and a better practice just to add an indicator to the name of the projects so that they don't collide, for instance DotfilesLocal and DotfilesRemote instead of having two Dotfiles projects.

[tukusejssirs]

Such a feature would imply modifying a very large part of the code and would significantly make it less clear. The folder containing the projects files would have to be modified, either by having the whole path as the name of the folders for each directory, or by having an additional metadata saved in a new file somewhere. Moreover, when moving the code directory of a project, the project would now point to a wrong path and each project file would have to be modified automatically to take this into account. Such modifications would need refactoring the core usage of the plugin.

Yeah, I agree it would require to modify everything that relying on unique project names, however, I thought it was done in a single place (like a function).

I think it is way easier, clearer and a better practice just to add an indicator to the name of the projects so that they don't collide, for instance DotfilesLocal and DotfilesRemote instead of having two Dotfiles projects.

Well, from my point of view, the differentiator is the path relative to ~/.config/sublime-text/Packages/User/Projects/, like for personal/someProject/someProject.sublime-project it is personal and for work/someProject/someProject.sublime-project it is work.

I understand that your proposal is easter from implementation point of view (no need to modify anything in PM), however, I consider my proposal better.

That said, if you don’t want to implement it, I’ll accept your decision.