ProjectManager

ProjectManager copied to clipboard

Hey ! I needed to have workspace management for my projects, and I already used your plugin so I modified it to fulfill my needs. I changed a bit of code, but the basis is still the same. I didn't document my modifications yet, but normally the name of the methods are pretty self-descriptive. I don't know if you're interested in this feature, theoretically everything works fine and the tests have been successful until now, but I didn't test it on different OS (even if no features should be OS-dependant) so you may want to check on your side if you're interested in merging.

The features I added are : creation, opening, opening in a new window, renaming and removing of workspaces. By default, if only one workspace exists, everything works as before and the upgrade should be transparent for the user. If you want more details about the modifications, feel free to ask !

Mar 09 '20 22:03 Valentin-Guillet

@Val95240 Sorry for the late reply. I read it on mobile and have totally forgotten to reply later when I went back to my desktop.

While I really love the idea of workspace management here. But it is a huge change in the code base and it makes merging the PR difficult. It would be nice if you could keep the number of changes minimal.

May 20 '20 06:05 randy3k

Hey ! I needed to have workspace management for my projects, and I already used your plugin so I modified it to fulfill my needs. I changed a bit of code, but the basis is still the same. I didn't document my modifications yet, but normally the name of the methods are pretty self-descriptive. I don't know if you're interested in this feature, theoretically everything works fine and the tests have been successful until now, but I didn't test it on different OS (even if no features should be OS-dependant) so you may want to check on your side if you're interested in merging.

The features I added are : creation, opening, opening in a new window, renaming and removing of workspaces. By default, if only one workspace exists, everything works as before and the upgrade should be transparent for the user. If you want more details about the modifications, feel free to ask !

What OS have you tested. This looks like a nice feature

Aug 28 '20 15:08 TerminalFi

Sorry I didn't have much time these last months to work on that.

@randy3k I understand your concern, it's true that I had to change quite a bit of the code base, but as I said, I tried to copy your code base as much as possible to mitigate this. So for example the new methods add_workspace, remove_workspace or rename_workspace are pretty much the same as their equivalent for projects. I also pushed some documentation for the functions I added in the hope of making the modifications clearer and more manageable. Unfortunately, dealing with sublime workspaces was not trivial and I don't think I could greatly reduce the number of modifications to the original code without losing some basic features or some safety checks. I'd understand if you didn't have time to review the code, but that's pretty much the best I can do...

@TheSecEng I tested the feature on Linux (Ubuntu 18.04 and 20.04) and Windows 10, but not on Mac OS as I don't have an easy access to this OS. However, the modifications I added should be OS independent as I only built on the existing base code which seems to work everywhere. Feel free to test the feature on other OS if you have the opportunity !

Aug 30 '20 21:08 Valentin-Guillet

@Val95240, I tried to clone your repo in order to test it out. I could not get is work with my projects saved in Packages/User/Projects/ folder (default in the upstream version). I don’t code in Python, but I noticed you mention some project folders in some PyDocs. Did you change some paths or whatever?

Just to be clear: I cannot open Open Project nor Open Project in New Window. Note that I did not test you package intensively.

BTW, I am on Fedora 32, ST3 3211, should that matter.

Oct 07 '20 12:10 tukusejssirs

@tukusejssirs It's difficult to say what could have gone wrong in your case, but my main theory is that the file that contains your recently opened projects Packages/User/Projects/recent.json isn't compatible with the update. To fix that, you can either call the ProjectManager Clear Recent Projects function, delete the file yourself or pull the commit I just pushed that will make the code do it for you automatically. Please tell me if it worked !

By the way, you don't have to clone the repository to install the package, you can call Package Control: Add Repository in Sublime and add the URL to the git repo (https://github.com/Val95240/ProjectManager), and then this is the version that will be installed when calling Package Control: Install Package -> ProjectManager. Hope this will make it easier for you !

Oct 07 '20 19:10 Valentin-Guillet

@Val95240, thanks for your answer!

It still does not work.

As for adding repo to Package Manager, I tried that before posting my first comment and even now. It works only when I remove the original/upstream (randy3k’s) version. On the other hand, I prefer installing such repos manually (I prefer updating them manually too). → Therefore, IMHO it is not easier, at least not for me.

When I find a bit more time, I’ll try your fork on a clean ST3.

Oct 12 '20 17:10 tukusejssirs

Hey ! I'm sorry that it didn't fix your issue. Unfortunately I don't have any specific idea about what goes wrong on your side, and I tried to test more extensively the plugin on my computer but I couldn't reproduce the issue. When you try to call the plugin, do you have an error message in the console (ctrl+`​ to open it) ? If so, could you send it to me ? Either here or on a new issue on my github repo, that could give me an idea on the origin of the bug and I could look deeper into it. Thanks !

Oct 12 '20 21:10 Valentin-Guillet

@Val95240, the console log contains the following error when I click on Projects → Project Manager → Project Manager:

Traceback (most recent call last):
  File "/opt/sublime_text/sublime_plugin.py", line 1052, in run_
    return self.run()
  File "/home/ts/.config/sublime-text-3/Packages/prman_val95240/project_manager.py", line 1030, in run
    self.manager = Manager(self.window)
  File "/home/ts/.config/sublime-text-3/Packages/prman_val95240/project_manager.py", line 141, in __init__
    if self.reorganize_files(self.projects_path):
  File "/home/ts/.config/sublime-text-3/Packages/prman_val95240/project_manager.py", line 196, in reorganize_files
    os.mkdir(directory)
FileExistsError: [Errno 17] File exists: '/home/ts/.config/sublime-text-3/Packages/User/Projects/ts'

After seeing that, I removed ~/.config/sublim-text-3 (after backing it up) and tried out your repo and it works as expected.

Note that there is no error when using the upstearm version.

I think that folder creation should not fail when it already exists. A mere warning would be enough if at all needed.

Oct 12 '20 21:10 tukusejssirs

@Val95240, now it works as expected.

However, I kind of miss a way to change the worspaces within a project, that is:

• in Projects → Project Manager, there should be Open a Workspace that would list all available workspaces for the particular project;
• in the sidebar, we could have a list (a collapsable tree) with workspaces connected with the particular project.

Oct 13 '20 15:10 tukusejssirs

Thanks for your feedback ! You're right, I didn't plan the case where the user already have a directory with the same name as a project in the User/Projects folder, it should be good now.

To change workspace within a project, there's actually an Open Workspace command:

• in Project -> Project Manager
• in the command palette (Ctrl+Shift+P)
• you can add a shortcut to it (cf. Preferences -> Package Settings -> ProjectManager -> Keybindings and this question in the README to enable it)

However, for these commands to do something, you must have several workspaces in your project already: you can create a new one by opening a project, and calling Project -> Project Manager -> Add New Workspace, or Add New Workspace in the command palette. Once you have several workspaces, the Open Workspace command will actually list them for you to choose which one you want to open. Tell me if that's not what you were looking for !

Oct 13 '20 17:10 Valentin-Guillet

1. Open Workspace indeed is in the main menu (Projects → Project Manager) and in the command palette, however, it is missing from the Projects →Project Manager → Project Manager (I have no idea how to call it; its command is project_manager). In the upstream PM, all commands (items) from Projects → Project Manager menu are listed in project_manager overlay (or what it is). I miss it there.

2. I have already create sevel keybinding for PM. :smiley:

3. I have created several workspaces using your Add New Workspace while a particular project was open. When I Open Workspace using your PM version, it does not work (no overlay to choose workspaces is output). I need to close the project (windows) and re-open it. Then it works as expected.

4. Another quite interesting bug occured to me, but I am not sure what or why happens (I have no idea how to debug this nor get some error log). When using your downstream PM version (i.e. this does not happen using the upstream version), I created a new project (it does not matter if I create it using the ST3 built-in Projects → Save Project As or the PM command) and then re-open it (either while it is open or closes), it crashes, closes the currently open window (in foreground; other windows stay open) or the window that would be open (if I try to open the project in a new window). Nothing really happens. OR Sometimes it opens a different project/workspace. This is quite annoying bug.

5. Slightly OT: I use subfolders under Packages/User/Projects in order to group projects. When a project called work is in a subfolder work (note that the project name and the subfolder name is same; this is kind of the default project for a particular group for me) and I delete that project, the whole folder is deleted. This might the issue in the upstream PM too.

6. Slightly OT: It might be a nice idea to output the subfolder name in the list of projects/workspaces (e.g. work/project_1 or work/worspace_1; see also #96, which deals with the same, but outputs it in the status bar).

Note that I always have my projects in the Projects/ folder. I don’t want to recreate the projects as there are several hundreds of files open across all my projects.

Oct 14 '20 12:10 tukusejssirs

Actually, the option to open a different workspace exists in the location you are describing (Projects → Project Manager → Project Manager), but the particularity is that it is available only if it could be applied, i.e. if the project has more than one workspace. And from the different weird behaviours and bugs you are describing, I think the plugin might not be working in your case because of the organization of your Projects/ folder.

Originally, with randy3k's default plugin, the .sublime-project and .sublime-workspace files were all saved in the folder without a specific subfolder for each project. Now, to deal with workspaces, I regrouped these files in a common folder for each project, but I think that your own organization is messing with the assumed one.

From what you're describing, I think that the command Add New Workspace doesn't work or at least doesn't save the new workspace in the right place, so that the plugin doesn't see it later and it could be why you're not seeing the option to Open Workspace appear in the location you described. In fact, I think that it might be the cause of your items 1., 3. and 4.

Now, I hear your need of self organizing your Projects folder, and it could be interesting to allow projects gathering in larger groups. In order for me to test what's messing things up and try to fix it, could you describe the file tree of your Projects folder ? For example, for the plugin, I assumed it would be

User/Projects/
|  Foo/
|  |- Foo.sublime-project
|  |- Foo.sublime-workspace             # Default workspace of this project
|  \- OtherWorkspace.sublime-workspace
|
|  Bar/
|  |- Bar.sublime-project
|  |- Bar.sublime-workspace
|  ...

but you seem to have a different one (if I understood well).

Oct 15 '20 18:10 Valentin-Guillet

The structure is similar to to the one you presented, however, with two differences:

1. Each subfolders (e.g. Foo or Bar) can contain one or more projects and workspaces (each workspace is associated to exactly one project).
2. Each workspace is located in the same folder as the project the workspace is associated with.
3. Currently, I have some projects/workspaces in the main folder (User/Projects). Those are from a period before I started to group projects/workspaces into subfolders. I want to move them into a subfolder, but did not found some time to accomplish this yet.

Note that I usually name a main project the same as the subfolder (e.g. Foo/Foo.sublime-project), however, I don’t this it should be made a hard-coded rule.

Oct 15 '20 19:10 tukusejssirs

I tried to test thoroughly the plugin with the same organisation of the User/Projects folder as you, but unfortunately I couldn't reproduce any bug. Sorry, I'm really not sure what's messing things up in your case, and it is pretty much impossible to debug in these conditions...

I checked and in my case, the plugin works:

• with several projects and workspaces in the same folder
• with subfolders in the main project folder
• when the project folders have a different name from the project file so in my case, this structure works flawlessly:

User/Projects/
|  Foo/
|  |- Group1/
|  |  |- Foo.sublime-project
|  |  |- Foo.sublime-workspace             # Default workspace of this project
|  |  \- OtherWorkspace.sublime-workspace
|  |
|  |- Group2/
|  |  |- Proj1.sublime-project
|  |  |- Proj1.sublime-workspace
|  |  |- Proj2.sublime-project
|  |  |- Proj2.sublime-workspace
|  |  \- Proj2Other.sublime-workspace
|
|  Bar/
|  |- OtherName.sublime-project
|  |- OtherName.sublime-workspace
|  ...

Moreover, if you have projects or workspaces directly in the main folder (User/Projects), the plugin should automatically reorganize them into a subdirectory of their own (with the same name as the .sublime-project file). If, when you execute any command of the plugin, it doesn't happen, that means that there's an issue quite early in the execution, maybe sublime doesn't have write permission in your Projects folder ?

I'm not really sure what you can do to fix all your issues, my main advice would be to delete your entire User/Projects folder (with a backup obviously) and copy back your saved project directories one by one to see which one may cause the issues. Hopefully you can then recreate the broken ones from the plugin to guaranty they work this time.

Regarding your remark about printing the subfolder name in the list of projects, I just pushed a commit in that sense: now, in the example tree from above, the projects Foo and Proj1 will appear as Foo/Foo and Foo/Proj1 in the list. I didn't want them to appear as Foo/Group1/Foo because then every default project will be named Proj/Proj and I find it unnecessary.

Oct 19 '20 18:10 Valentin-Guillet

@Val95240, I’ve just tried you latest version. Below is described what exactly I did.

Regarding your remark about printing the subfolder name in the list of projects, I just pushed a commit in that sense: now, in the example tree from above, the projects Foo and Proj1 will appear as Foo/Foo and Foo/Proj1 in the list. I didn't want them to appear as Foo/Group1/Foo because then every default project will be named Proj/Proj and I find it unnecessary.

I did not notice any project name in the statusbar yet. Do I have to enable them somehow?

Note that I also create a project asdf under test/ subfolder, but it still showed as asdf in the PM overlay list.

A suggestion: when/if you implement the project name output in the statusbar, I think it might be better to output the name of the workspace too, unless it is the default workspace; for example:

Oct 30 '20 15:10 tukusejssirs

Okay I'm not sure but I think I found and fixed the issue. It was a small problem with the automatic closing of empty workspaces, and my guess is that it's the reason you sometimes saw windows appearing and disappearing instantly. If I'm not mistaken, what happened in your case is:

6. When you created a new workspace, it must have closed immediately, leaving you in your Default workspace. You then closed every file from the Default workspace (a new workspace is always created empty, so the files you closed couldn't be in the new ws)

7. You wanted to switch to Default but you were still in it, so it "flashed". Then when trying to open the new test workspace which was still completely empty, it once again instantly closed

And in 8., your description of the .sublime-workspace files corresponds to that situation so that should be it. I just pushed a fix, so please try it and tell me if you're still having any issues !

Note that I also create a project asdf under test/ subfolder, but it still showed as asdf in the PM overlay list.

That's what I tried to explain in my previous message, a file Projects/test/asdf.sublime-project will be displayed as only asdf, and a file in a subfolder as Projects/test/subtest/asdf.sublime-project will be displayed as test/asdf (and not subtest/asdf). I made this choice because I don't want single projects to appear as Proj/Proj every time.

I did not notice any project name in the statusbar yet. Do I have to enable them somehow?

Regarding the status bar display, I didn't implement it yet, I only worked on the display of the names in the PM overlay list. However it could be interesting so I might work on that when I have the time, and I definitely will take your suggestions into account, thanks !

Nov 10 '20 21:11 Valentin-Guillet

I confirm that the issue described in this comment of mine (removing files from workspaces and subsequently crashing ST3) is fixed in the latest commit of the downstream repo.

I had to do the following:

• remove the upstream repo;
• add the downstream repo;
• back up Projects/ folder;
• remove the Projects/ folder;
• (probably) open the Project Manager project list overlay (I believe this creates the JSON files in the Projects/ folder);
• copy back the projects and workspaces from the backup to Projects/ folder (but only them, not the JSON files).

Notes:

• When creating new workspace, it opens a blank window (one without any files open), which IMO is the correct behaviour. :smiley: :+1:
• Without removing Projects/ folder, I tested tthe issue twice. First time it still occured, the other time it did not.
• In the downstream repo, the loading time of the projects list overlay tooks about 0.8 seconds, however in the upstream repo, it takes about 0.1 seconds. Can’t this be improved?

That's what I tried to explain in my previous message, a file Projects/test/asdf.sublime-project will be displayed as only asdf, and a file in a subfolder as Projects/test/subtest/asdf.sublime-project will be displayed as test/asdf (and not subtest/asdf). I made this choice because I don't want single projects to appear as Proj/Proj every time.

Well, this somewhat bugs me. I see you want to remove the of the subfolder (test), however, I’d like to keep it.

Reasoning: I use the Projects/* subfolders as (real-life) project groups to group subprojects. The subprojects (Sublime projects) can have same names (like proj1/test and proj2/test). Also note that I name the subprojects (Sublime projects) without the proj1 in their names (because I deam them as duplicity) and even if the subprojects have different names, it might be easier to know what project (subfolder) it is part of.

If you still require your current implementation, I suggest to add an option for this in the package settings.

Nov 15 '20 20:11 tukusejssirs

That's what I tried to explain in my previous message, a file Projects/test/asdf.sublime-project will be displayed as only asdf, and a file in a subfolder as Projects/test/subtest/asdf.sublime-project will be displayed as test/asdf (and not subtest/asdf). I made this choice because I don't want single projects to appear as Proj/Proj every time.

Well, this somewhat bugs me. I see you want to remove the of the subfolder (test), however, I’d like to keep it.

@Val95240, could you create a setting for this please? This is the only reason I still don’t use your fork instead of the upstream repo: I want to output the whole path to the project stripped of the projects folder (by default ~/.config/sublime_config/Packages/User/Projects in ST4 on Linux).

Actually, we already have a project_display_format setting that is set to {project_group}{project_name}{active_project_indicator} by default, so this shouldn’t be that hard to implement.

[@randy3k]

While I really love the idea of workspace management here. But it is a huge change in the code base and it makes merging the PR difficult. It would be nice if you could keep the number of changes minimal.

@Val95240, it would be nice if you could find some time to split this PR into small commits with individual changes that could be reviewed (by @randy3k) much more easily in order to merge your enhancements into the upstream repo.

// The string to use as the active indicator for the workspace list. "active_workspace_indicator": "*",

I have just went through the settings. I think that the indicator for workspaces should be a different character from one for projects. What do you think?

I have just tested out the latest commit of your fork, create a new workspace in an existing project with a default workspace only. Then I tried to switch back the the default workspace, but Open workspace commend did not show a list of workspaces nor did it automatically switch to the only other workspace. I presume this is a bug. Adding an additional workspaces to the project might have (somehow) corrupted the project/workspace files.

Jul 04 '21 12:07 tukusejssirs

@Val95240, could you create a setting for this please? This is the only reason I still don’t use your fork instead of the upstream repo: I want to output the whole path to the project stripped of the projects folder (by default ~/.config/sublime_config/Packages/User/Projects in ST4 on Linux).

What you're asking is not really compatible with the plugin as of today. Let me explain: if I understand correctly, the issue mainly comes from the fact that you have a folder that contains multiple project and workspace files, and you would like to display the name of the folder before the project names in the dropdown menu. But in the current implementation, it is not safe to have several projects in the same folder: each project must have its own subfolder containing the .sublime-project file and all its associated .sublime-workspace files. This is because the plugin has to automatically find every workspace associated with a given project, and it is currently done by scanning every file in the same folder. If you still have many projects in the same folder, the behavior of the plugin is not ensured: it may (or may not) break the different commands, such as workspace renaming, or project removal. If you are still inclined to gather different projects in the same folder, it might work well but I cannot guarantee that there won't be any weird behavior, as I didn't test this setup extensively.

If you want to group several projects together, you can put them in a common folder (what I called a group), but they still have to be in their corresponding subfolders. So you could organize your files like this:

User/Projects
|  ProjectGroup
|   |- Proj1
|   |   |- Proj1.sublime-project
|   |   \- Proj1.sublime-workspace
|   |
|   |- Proj2
|   |   |- Proj2.sublime-project
|   |   \- Proj2.sublime-workspace

In that case, they would appear as ProjectGroup/Proj1 and ProjectGroup/Proj2 in the dropdown menu. Once again, the need for these project-specific subfolders is to find associated workspace files efficiently, and as the objective of this plugin is to avoid having to manage project files manually, it was not specially made to accommodate with manually modified Projects folder structure.

@Val95240, it would be nice if you could find some time to split this PR into small commits with individual changes that could be reviewed (by @randy3k) much more easily in order to merge your enhancements into the upstream repo.

I agree that being able to merge would be nice, but as I said previously, I already tried my best to minimize the number of modifications in the code base. I largely followed the existing style, I commented every non-trivial method I added, and except some bug fixes, my commits are already organized in small enhancements/features. I completely understand if randy3k doesn't have the time to review my PR as it is still quite massive, however I won't be able to really simplify the process any further, as it would mean losing functionalities or remove safety checks.

Moreover, I made the modifications based on what I need in my everyday use of Sublime Text, and so I didn't check with randy3k whether he finds it useful or even relevant for this plugin. I think I made reasonable choices and I tried to keep the plugin as customizable as possible, but it is still based on my personal usage, and it may not fit randy3k's idea for his plugin.

I have just went through the settings. I think that the indicator for workspaces should be a different character from one for projects. What do you think?

As the projects and workspaces are never displayed at the same time, I find it logical to have the same character to indicate that either a project or a workspace is open. However, I agree that it's only my opinion, and that's why it is customizable in the sublime settings: if you prefer another character, you just have to modify the active_workspace_indicator in your local settings to override this value.

I have just tested out the latest commit of your fork, create a new workspace in an existing project with a default workspace only. Then I tried to switch back the the default workspace, but Open workspace commend did not show a list of workspaces nor did it automatically switch to the only other workspace. I presume this is a bug. Adding an additional workspaces to the project might have (somehow) corrupted the project/workspace files.

Sorry, I couldn't reproduce the bug on my side, everything seems to work as expected. It might be an issue of migration of the recent file, so just in case you can try to clean it and see if it fixes it. If it doesn't, can you send me the error messages in the sublime console so that I can investigate ? Thanks !

Jul 04 '21 20:07 Valentin-Guillet

Oh, I somehow overlooked (or forgot?) that besides having a folder per project group, I need to have a separate folder per project, which is obvious, as now we can use multiple workspaces per project and you don’t want to complicate the package with additional (e.g.) workspaces.json file to match the workspaces to projects or simply add the list of workspaces into the project file. Actually, each workspace file contains project property with the project filename the particular workspace belongs to, so the actual algorithm should not be that dificult, but nevermind. :wink:

Anyway, it might be a good idea to add an option to create a project group (a folder) and to choose a project group (or alternatively Projects/ folder as an alternative and the default option) when creating a new project. ~~Also when creating a new project, create a new folder (in the group folder or the Projects/ folder) with the same name as the new project, e.g. for project test in project group t create a folder Projects/t/test/ in which we would have the project and workspaces files.~~ [This is actually already done.]

On merging of this MR: it might actually look like @randy3k either don’t want to merge this MR or don’t have the time to review it or don’t have enough time to maintain entire Project Manager. I don’t say that he does not maintain PM anymore (there are some commits in May 2021, a bit in April 2021, but nothing more in 2021).

With this in mind, it might be a good idea to maintain a separate fork, then you should maybe rename your fork (as a package in Package Control at least) and we (I) should raise issues in your repo instead.

What do you think?

As the projects and workspaces are never displayed at the same time, I find it logical to have the same character to indicate that either a project or a workspace is open. However, I agree that it's only my opinion, and that's why it is customizable in the sublime settings: if you prefer another character, you just have to modify the active_workspace_indicator in your local settings to override this value.

Well, I think it might be a good idea to have a way to directly switch to (open) a specific workspace of a project which might not necessarily be open (i.e. not only switching between workspaces of a project, but between workspaces of all and any projects). This might require some major changes.

Actually, I think that ST distinction between workspace and project is somewhat arbitrary and confusing. We don’t actually switch between projects, but workspaces. The .sublime-project file contains some project metadata only (esp the paths that are included in a particular project), therefore we even now actually switch between workspaces (albeit the default project workspaces), not projects.

I suggest to either add a separate option to Switch to Workspace/Switch to Workspace in New Window or replace Open Project in New Window with a list of {group}/{project}: {workspace}{active_workspace_indicator}. Then the indicator for active projects would be irrelevant IMHO.

Would it be useful for you to add an option to delete empty workspaces (projects)? We already have Remove Dead Projects, but as far as I understand it correctly, it prompts to remove projects and their workspaces (all or just the default one?) which were not used (open) is some time lately, but I don’t think it is quite useful (not for me at least). By empty workspaces I mean ones without open files/tabs and by deleting I mean all empty workspaces and projects which would then would not have any workspaces assigned (or simply no workspaces in the folder the project file is saved in).

Sorry, I couldn't reproduce the bug on my side, everything seems to work as expected. It might be an issue of migration of the recent file, so just in case you can try to clean it and see if it fixes it. If it doesn't, can you send me the error messages in the sublime console so that I can investigate ?

Well, I presume that the issue comes from having all projects and workspaces in the project group folder and that collides with the logic you built into PM. Anyway, when I tried you fork, I tried to remove library.json and recent.json files, but it still did not work.

It might also be a good idea to move workspaces between projects, i.e. move the workspace file to the folder of a different project and replace the project property value.

I have just tested out your downstream fork. I have found some potential issues:

1. I tried to create a new project via PM option (I actually never done it, I usually create a new project via a keyboard shortcut assigned to Save Project As in ST). When I have some files open in current window, when I save a new project via PM, it asks me if I want to close all open files with/without saving them and then it creates a new, empty project. The Save Project As in ST works differently: it saves the current window (it does not matter if it is a project already or not) as a new project. I would presume the same behaviour in PM too. If changing the behaviour of Add New Project is not wanted, it would be nice to add an option to Save Current Window as a New Project. I think that this behaviour is the same in both upstream and downstream repos.

2. ~~In the PM overlay with commands (project_manager command), I miss some commands, like when I search for workspace, it does not find anything, but when I open Projects → Project Manager, I can find them. I think that all options found in Projects → Project Manager should be in the overlay.~~ It took some while until all the options shown up, so consider this as a non-issue, but it might be a good idea to document it as in a migration guide from @randy3k’s PM to yours.

3. Could we add a space after the colon (:) in project_manager.py (L158) and thus between the project name and workspace name in the statusbar? It might a good idea to create a setting to let the user configure the output in the statusbar which would default to [{group}/{project}: {workspace}].

4. It feels like opening, switching and creating projects and/or workspaces it much, much slower than in the upstream PM. It is slow even after ST restart.

5. I think that PM should output only warnings and errors to ST console. We should add a debbug setting and when it is set to true, only then output working dir (etc) to the console. At least I believe that it is output by PM.

6. I had open multiple ST windows. I had open a new, blank window, then I created a new project via PM Add New Project, then created a new workspace for that project via PM Add New Workspace. Then I switched to that new workspace, but the focus moved to the following window on the right of the new workspace (its window). I think it should not switch active windows. Note that this might be related to the fact that I use Linux (actually Fedora 32 x86_64 with SwayWM), but still think that it is a bug in PM.

Also note that currently, when I have open a non-default workspace of a project, when I try to switch to (open) the project (via Open Project), it won’t open anything. Also note that Open Workspace won’t always work, at least it does not work when both workspaces of total two workspaces of a project are open in different windows AND also when only the non-default workspace is open. Below is the trackback from the ST console. Note that this happened after I moved all my projects to separate subfolders in project folders in Projects/ (i.e. Projects/{group}/{project}/{project}.sublime-{project,workspace}). Actually now I cannot switch to any project or workspace and I alsways get the same traceback. Also note that now I use ST4 only.

Traceback (most recent call last):
  File "/home/ts/.config/sublime-text/Installed Packages/ProjectManager.sublime-package/project_manager.py", line 1415, in callback
  File "/home/ts/.config/sublime-text/Installed Packages/ProjectManager.sublime-package/project_manager.py", line 1326, in run
  File "/home/ts/.config/sublime-text/Installed Packages/ProjectManager.sublime-package/project_manager.py", line 1290, in choose_ws
  File "/home/ts/.config/sublime-text/Installed Packages/ProjectManager.sublime-package/project_manager.py", line 655, in display_workspaces
  File "/home/ts/.config/sublime-text/Installed Packages/ProjectManager.sublime-package/project_manager.py", line 702, in render_workspace
KeyError: 'file'
Traceback (most recent call last):
  File "/home/ts/.config/sublime-text/Installed Packages/ProjectManager.sublime-package/project_manager.py", line 1353, in callback
  File "/home/ts/.config/sublime-text/Installed Packages/ProjectManager.sublime-package/project_manager.py", line 1290, in choose_ws
  File "/home/ts/.config/sublime-text/Installed Packages/ProjectManager.sublime-package/project_manager.py", line 655, in display_workspaces
  File "/home/ts/.config/sublime-text/Installed Packages/ProjectManager.sublime-package/project_manager.py", line 702, in render_workspace
KeyError: 'file'

Update: Actually, now it won’t work either with upstream or downstream PM. It always complains about something (see the traceback below). During my tests, I always removed the previous PM, removed/added the repo (in case the downstream repo) and installed the other PM, all done using Package Control within ST4.

Traceback (most recent call last):
  File "/opt/sublime_text/Lib/python33/sublime_plugin.py", line 1456, in run_
    return self.run(**args)
  File "/home/ts/.config/sublime-text/Installed Packages/ProjectManager.sublime-package/project_manager.py", line 545, in run
  File "/home/ts/.config/sublime-text/Installed Packages/ProjectManager.sublime-package/project_manager.py", line 222, in display_projects
  File "/home/ts/.config/sublime-text/Installed Packages/ProjectManager.sublime-package/project_manager.py", line 232, in move_recent_projects_to_top
  File "/home/ts/.config/sublime-text/Installed Packages/ProjectManager.sublime-package/project_manager.py", line 232, in <listcomp>
  File "/home/ts/.config/sublime-text/Installed Packages/ProjectManager.sublime-package/project_manager.py", line 54, in pretty_path

Update 2: The problem with the upstream repo layed in the *.json files (I think that the culprit was recent.json specifically). Removing them, this issue resolved for the upstream repo. The issue, however, persists in the downstream repo.

Here’s how I actually move between upstream and downstream PMs. It might a good idea to add to the migration guide.

To Downstream

1. Open ST and remove the PM package via Package Control.
2. Close ST.
3. Remove files Projects/{library,recent}.json.
4. Open ST and add the downstream repo via Package Control, then install the PM package.

To Upstream

1. Open ST and remove the PM package via Package Control.
2. Then remove the downstream repo via Package Control.
3. Close ST.
4. Remove files Projects/{library,recent}.json.
5. Open ST and install the PM package.

Jul 08 '21 13:07 tukusejssirs

Anyway, it might be a good idea to add an option to create a project group (a folder) and to choose a project group (or alternatively Projects/ folder as an alternative and the default option) when creating a new project.

Once again, the group functionality is more of a bonus for me, and I don't think I'm gonna extend the number of options to manage groups, at least not yet. Right now, when creating a new project, you can name it my_group/new_project and it will be automatically created in the corresponding group. However, once a project is in a group, there's no way to move it into another group. For now, it's not a priority for me to implement that, but I might do it later.

With this in mind, it might be a good idea to maintain a separate fork, then you should maybe rename your fork (as a package in Package Control at least) and we (I) should raise issues in your repo instead.

What do you think?

I don't feel like pushing my fork on a separate package on Sublime Package Control for now, as it is originally not my work. I might do it later, but the current system is working for me. However, I enabled the issues on my fork so that we can discuss all of this on my repo instead of here, so feel free to migrate there.

Well, I think it might be a good idea to have a way to directly switch to (open) a specific workspace of a project which might not necessarily be open (i.e. not only switching between workspaces of a project, but between workspaces of all and any projects). This might require some major changes.

I don't think I understand your point here, as I feel this is already possible. If you have the activate_workspaces option equal to true (which is the case by default), then when you try to open a project (with the Open Project command), if this project has several workspaces then you will be asked to choose which existing workspace to open. So you can already open any workspace from anywhere, even in projects which are not already open.

Actually, I think that ST distinction between workspace and project is somewhat arbitrary and confusing. We don’t actually switch between projects, but workspaces. The .sublime-project file contains some project metadata only (esp the paths that are included in a particular project), therefore we even now actually switch between workspaces (albeit the default project workspaces), not projects.

I agree, we actually only switch between workspaces, and in our case the Open Project command just means "open a workspace which is located in a project different from the currently opened one".

I suggest to either add a separate option to Switch to Workspace/Switch to Workspace in New Window or replace Open Project in New Window with a list of {group}/{project}: {workspace}{active_workspace_indicator}. Then the indicator for active projects would be irrelevant IMHO.

Right now, what you suggest is divided into two steps: first, the projects are prompted in the form of a list of {group}/{project}, and then the workspaces are prompted in the form {workspace}{active_workspace_indicator}. I understand that these two steps could be merged into a single one, but I don't think it is a good idea, and I'd rather keep the separation between managing projects (as with the upstream repo) and the workspaces.

Would it be useful for you to add an option to delete empty workspaces (projects)? We already have Remove Dead Projects, but as far as I understand it correctly, it prompts to remove projects and their workspaces (all or just the default one?) which were not used (open) is some time lately, but I don’t think it is quite useful (not for me at least). By empty workspaces I mean ones without open files/tabs and by deleting I mean all empty workspaces and projects which would then would not have any workspaces assigned (or simply no workspaces in the folder the project file is saved in).

Actually, Remove Dead Projects remove all projects whose corresponding folder does not exist on the system anymore. For example, if there's a project associated with ~/MyProject and this folder cannot be found, then it will be removed from the projects list. Even if I don't think it is a priority, I can see the interest of having a Remove Dead Workspaces command and I may try to implement it later.

It might also be a good idea to move workspaces between projects, i.e. move the workspace file to the folder of a different project and replace the project property value.

I don't really see the interest of such a feature, as a workspace is intrinsically linked to a single project. Moving a workspace to a different project would mean that the tabs and open files must also appear in the project's folders. I think in the very specific case where this could make sense, it would be better to just remove the workspace and create a new one elsewhere.

I tried to create a new project via PM option [...]. I think that this behaviour is the same in both upstream and downstream repos.

Yeah, I agree that this behavior can be annoying, but I didn't modify the upstream repo, nor did I look into it yet. That's going on my todo list though.

In the PM overlay with commands (project_manager command), I miss some commands[...]. It took some while until all the options shown up, so consider this as a non-issue, but it might be a good idea to document it as in a migration guide from @randy3k’s PM to yours.

Actually, only available options are displayed in the overlay. More specifically, most of the commands acting on workspaces are not available if there is only one existing workspace in the current project (Open Workspace, Open Workspace in New Window, Rename Workspace and Remove Workspace to be precise). I made this choice because the open commands are useless in that context, and I don't think letting the user delete the only existing workspace is necessary, and it could lead to bugs. IMHO the only question could be for Rename Workspace, but once again I don't think there's a great interest in renaming a workspace if it's the only one that exists.

Could we add a space after the colon (:) in project_manager.py (L158) and thus between the project name and workspace name in the statusbar? It might a good idea to create a setting to let the user configure the output in the statusbar which would default to [{group}/{project}: {workspace}].

I originally wanted to create a user setting for that, but the issue is that I don't really see a way to make it compatible with hiding characters in the default situation. Let me explain: right now, if a project is not in a specific group, the {group}/ part is omitted, and it's the same for the :{workspace} part. If I were to create a user setting, I wouldn't be able to apply logic to omit the supplementary characters (/ and :), and it would always show at least as /{project}:, even without any group or workspace. I feel like this makes the user setting not worth it, but if you think of a solution for that problem, I'd be happy to hear it!

It feels like opening, switching and creating projects and/or workspaces it much, much slower than in the upstream PM. It is slow even after ST restart.

On my laptop, all of these commands are pretty much instantaneous, so I don't know what could make it slower in your case... Do you manage a huge number of projects and workspaces? To test what causes that, you could try to set the activate_workspaces option to false and measure if project management is still significantly slower than in the upstream repo. If it's the case, then I don't think this is caused by the modifications I made.

I think that PM should output only warnings and errors to ST console. We should add a debbug setting and when it is set to true, only then output working dir (etc) to the console. At least I believe that it is output by PM.

I don't really understand this point: what do you think should be printed in the console? Right now, the only outputs are some sublime message dialog when invalid command happens, and a few status message to indicate the result of certain commands. I don't think there really should be more than that from the user point of view.

I had open multiple ST windows [...], I still think that it is a bug in PM.

I don't understand this point either, I'm not sure what you are talking about when you say "the focus moved to the following window on the right of the new workspace". Can you be more precise please?

Also note that currently, when I have open a non-default workspace of a project, when I try to switch to (open) the project (via Open Project), it won’t open anything. [...] Actually now I cannot switch to any project or workspace and I alsways get the same traceback.

I think I found the issue, the last commit should resolve this traceback, please tell me if it is solved now!

Jul 14 '21 12:07 Valentin-Guillet

@Val95240, okay, I’ll create separate issues in your repo and comment in there.

Jul 14 '21 16:07 tukusejssirs

I don't feel like pushing my fork on a separate package on Sublime Package Control for now, as it is originally not my work.

I won’t push you into anything, but from my point of view it is originally not my work is not a reason for not publishing your version of the package, because it is MIT-licensed, so you can legally do it. However, do what you want with the code, I’m fine with installing your version via repo. :wink:

Jul 14 '21 17:07 tukusejssirs

@randy3k this has been here for some time. Is this even being considered

Jun 04 '22 12:06 TerminalFi

There're simply too much changes in the codebase. It will be difficult for me to merge all the changes at once.

Jun 04 '22 14:06 randy3k