Treemacs: Option to auto-create workspace for new perspective

Created on 21 Dec 2019  Â·  26Comments  Â·  Source: Alexander-Miller/treemacs

Enhancement Buffer Scope Looking for Input

Most helpful comment

Thanks for all the feedback everyone :+1:

But if such a scenario comes up, I would expect the workspace name to be same as project name. So, persp-name == project-dir-name == treemacs-workspace-name.

Treemacs doesn't pick persp or project names, those will be controlled by whatever you or your frameworks decide.

and as soon as the project is selected you are offered to select a file to open (in Spacemacs)

Treemacs gets its run after a perspective was activated, so I hope we won't run into strange issues with the timing of this process. I am only on spacemacs-base and I don't use persp-mode myself, so I will need help finding all the edge cases and fixing them.

would be nice for treemacs to detect this.

Find-file is not a problem. The current WIP implementation uses the builtin project detection which uses projectile (if installed) or project.el to look up the current project.

for Doom that will inherit the project from the workspace where it was created

Depending how that inheritance works it might have to be implemented on Doom's side.

What's the fallback workspace?

The one that's used when nothing else fits https://github.com/Alexander-Miller/treemacs#workspace-selection

I'd probably expect the workspace to just start blank.

Treemacs' validator treats empty workspaces as an error and I'd prefer to leave that part of the code base as is. The change wouldn't be complicated, just tedious, and persp is already giving me more trouble than I had expected.

I feel #2 might be asking for a whole other feature.

Maybe. It'd depend on how it's set up. If it's not up to treemacs so synchronize projectile & persp it should be doable, otherwise it'll be Big and Ugly. Either way I first want to clean up and stabilize the current case load. I've just gotten to the point where I don't see errors on every 2nd perspective switch, so I might have something worth testing next week.

It sounds like the people on doom or spacemacs will most likely move perspectives based on projects, so asking projectile should suffice most of the time. If it doesn't I'll use the projects from the fallback workspace. The choice can be made configurable as well, but I'll wait for feedback to see if there's demand.

Not sure if I need to mention this, or it's as expected, but keep in mind that the whole setup is persistent. If you have a workspace X for perspective X it'll be loaded and contain the same projects you left it with last time. So the content of workspace X and perspective X could drift apart eventually.

All 26 comments

And now a question for all the people who want to see this feature:

You switch to some new perspective. Treemacs' hooks kick in, and look up a workspace for it (matched by name). There is no fitting workspace so one is created. What project(s) should it contain? Whatever the previous one had? The same as the Default Workspace? The same as the fallback workspace? Just the one project that fits current-buffer? Then what if the current buffer is something like scratch and has no file?

CC @mattsawyer77 @richerve @sei40kr @nixmaniack @didibus :point_up:

I rarely create perspective manually, they're mostly project driven. My usual workflow is, open a list of known projectile projects to switch to and create a perspective for it. So, I would expect that perspective to have a new workspace dedicated for that project. IOW,

Just the one project that fits current-buffer

About,

Then what if the current buffer is something like scratch and has no file?

This generally wouldn't arise given that I create perspectives from known projects, and as soon as the project is selected you are offered to select a file to open (in Spacemacs). But if such a scenario comes up, I would expect the workspace name to be same as project name. So, persp-name == project-dir-name == treemacs-workspace-name.

@Alexander-Miller Let me know if this makes sense or needs more clarification.

I'll say that my workflow is similar to @nixmaniack. In doom emacs a projectile project is tied to a perspective by a concept of "doom workspace" that essentially works as tabs. But you can open a new doom workspace (a new tab) from the current workspace and it will re-use the previous workspace project. If I want to select a file outside the project, I do find-file, open it and essentially I'm now in a new perspective that either doesn't have project or it's a different one, would be nice for treemacs to detect this.

So for me this would be the things to consider:

  • If a perspective doesn't have a project associated then select either a Default one, or home or whatever other default path.
  • If a perspective have a project show only that project path/s.
  • For a new "clean" perspective it depends, as I said for Doom that will inherit the project from the workspace where it was created, but don't know in other cases like Spacemacs if this makes sense.
  • For a new "clean" perspective it depends, as I said for Doom that will inherit the project from the workspace where it was created, but don't know in other cases like Spacemacs if this makes sense.

In case of Spacemacs, there's no inheritance from where it was created for new "clean" perspective, the buffer is set to home buffer i.e.*spacemacs*. Since there's no file associated with it, IMO, selecting Default workspace is fine in this case.

What's the fallback workspace?

For me, I would create a new perspective, and then I'd probably expect the workspace to just start blank. And I'd add/remove projects that I want manually.

Like others have said, its most likely going to be one or more projectile projects.

I would be okay with the workspace just starting blank. I probably would prefer it blank then trying to pull in things by copying other workspaces. Because then as I add more projects to it, I also have to remove the ones I don't need that were added automatically.

So I'd vote for:

  1. On new perspective, create an empty workspace for it of the same name as the perspective.
  2. On running projectile-switch-project, the project switched too would be added to the treemacs workspace automatically.

I feel #2 might be asking for a whole other feature. Where in general, I think it be nice for treemacs to keep in sync the current workspace with projectile projects. So the current projectile project would be added to the workspace and all the following ones I switch too as well.

Thanks for all the feedback everyone :+1:

But if such a scenario comes up, I would expect the workspace name to be same as project name. So, persp-name == project-dir-name == treemacs-workspace-name.

Treemacs doesn't pick persp or project names, those will be controlled by whatever you or your frameworks decide.

and as soon as the project is selected you are offered to select a file to open (in Spacemacs)

Treemacs gets its run after a perspective was activated, so I hope we won't run into strange issues with the timing of this process. I am only on spacemacs-base and I don't use persp-mode myself, so I will need help finding all the edge cases and fixing them.

would be nice for treemacs to detect this.

Find-file is not a problem. The current WIP implementation uses the builtin project detection which uses projectile (if installed) or project.el to look up the current project.

for Doom that will inherit the project from the workspace where it was created

Depending how that inheritance works it might have to be implemented on Doom's side.

What's the fallback workspace?

The one that's used when nothing else fits https://github.com/Alexander-Miller/treemacs#workspace-selection

I'd probably expect the workspace to just start blank.

Treemacs' validator treats empty workspaces as an error and I'd prefer to leave that part of the code base as is. The change wouldn't be complicated, just tedious, and persp is already giving me more trouble than I had expected.

I feel #2 might be asking for a whole other feature.

Maybe. It'd depend on how it's set up. If it's not up to treemacs so synchronize projectile & persp it should be doable, otherwise it'll be Big and Ugly. Either way I first want to clean up and stabilize the current case load. I've just gotten to the point where I don't see errors on every 2nd perspective switch, so I might have something worth testing next week.

It sounds like the people on doom or spacemacs will most likely move perspectives based on projects, so asking projectile should suffice most of the time. If it doesn't I'll use the projects from the fallback workspace. The choice can be made configurable as well, but I'll wait for feedback to see if there's demand.

Not sure if I need to mention this, or it's as expected, but keep in mind that the whole setup is persistent. If you have a workspace X for perspective X it'll be loaded and contain the same projects you left it with last time. So the content of workspace X and perspective X could drift apart eventually.

Flu killed my flow and I can't rightly remember if I had any more plans for what I've implemented so far, so I have pushed what I have.

Workspaces will now be auto-mapped to perspectives, whenever the latter become active. You'll probably not start with the right workspace after things are first loaded (that's up next), but in general all the right things should be persisted.

Let me know if there's anything missing or buggy.

I've pulled latest treemacs to give this a shot.

Workspaces will now be auto-mapped to perspectives

Is this true other way around as well? If I create a perspective, would there be a workspace created for it?

I tried opening project based perspective (SPC p l in Spacemacs) but looks like treemacs adds projects to Default workspace. I see all projects in the treemacs window.

(treemacs-current-workspace)
#s(treemacs-workspace
   "Default"
   (#s(treemacs-project "project-1" "/Users/user/path/to/projects/project-1" local-readable)
      #s(treemacs-project ".emacs.d.spacemacs" "/Users/user/.emacs.d.spacemacs" local-readable)))

Or is it work in progress?

Is this true other way around as well? If I create a perspective, would there be a workspace created for it?

That is what I meant. When you switch a perspective the treemacs workspace will follow.

SPC p l in Spacemacs)

Could be a timing issue. You only select the file you want to open after the perspective was created, and the create-workspace-in-treemacs hook was run, so treemacs is looking at your old open file when selecting a workspace. I pushed a patch that should take care of that, tr again with the latest version.

I still see all projects after upgrading treemacs with this commit. The only difference that I see based on the commit message is that I use ivy instead of helm but not sure if that could be the reason.

Let me know if I can provide anything from running system to debug.

Ivy or helm shouldn't matter, it's just the selection front-end. The
problem was that the selection took place too late.

Let's check things from the ground up.

1) Restart Emacs, load treemacs
2) Make sure (treemacs-current-scope-type) returns persp-scope
3) Call treemacs-edit-workspaces and delete any previously-created and
incorrectly filled workspace that may have been there
4) SPC p l into a different project
5) Do you see the right projects? Did the workspace change?

I followed the steps you mentioned and it worked after deleting the incorrectly filled workspaces. Thanks. All projects were added to "Default" hence the issue I think.


Another issue that I have observed now is as follows:

  1. Open 2 projects (layouts with SPC p l)
  2. Open their treemacs window with SPT p t (in both projects)
  3. Now, if you switch between [these two] projects(SPC l n/SPC l p) you get following errors (copied from *Messages* buffer)
Error running timer: (wrong-type-argument window-live-p nil) [2 times]
Quit
Error running timer: (wrong-type-argument perspective nil)
Quit [2 times]
Error running timer: (wrong-type-argument window-live-p nil)

Looking into it.

That's an upstream issue. The spacemacs transient state prevents treemacs' display function from working.

Pushed a workaround, the problem should be fixed now.

I also introduced a small breaking change: perspectives will now be matched by looking for a workspace called "Perspective $name" instead of just the plain name of the perspective, and also saved in this format.

The reason is that SPC p l selects the project's path as the name of the perspective which makes it difficult to grasp where that filename-wokspace when you call something like treemacs-edit-workspaces.

The next step will be to make sure that things work correctly when you first load and start using treemacs & persp-mode.

Other than that is there anything else that needs doing?

I'll try again when the package is available on melpa and let you know my experience.

I have one unrelated question, how do I start with clean slate treemacs workspaces? If I delete everything in the org buffer of treemacs-edit-workspaces – it complains that Input is empty on C-c C-c.

The closest you can get to starting from scratch is leaving a single
workspace with a single project. Anything less will be (rightfully)
refused as not a valid state.

You would get the same result if you start treemacs for the first time
(or if you delete treemacs-persist-file in between Emacs sessions) - a
"Default Workspace" and a single project that you'd have to select.

Although the mentioned issue is fixed with latest change, there seems to be some more erratic behaviour regarding the project <-> treemacs-workspace mapping. I'll get back with more concrete repro steps later in the week if required but here's what I have observed.

The projects which are automatically mapped to Perspective <xyz> [sometimes] appear in No Perspective workspace [and then those projects sometimes appear in all perspectives].

I have found some issues w.r.t. workspace selection when you first enable or switch perspectives. Might be the same thing you are running into. Fix ETA: some time this week.

Patch is pushed now, let me know if it improves things.

And here's some small debugging code, if you see something that isn't right you can use it to verify that your buffer, workspace and projects are set up correctly:

(let* ((shelf (treemacs-current-scope-shelf))
       (ws (treemacs-scope-shelf->workspace shelf))
       (buf (treemacs-scope-shelf->buffer shelf)))
  (treemacs-log "Current Buffer: %s" (buffer-name buf))
  (treemacs-log "Current WS: %s" (treemacs-workspace->name ws))
  (dolist (pr (treemacs-workspace->projects ws))
    (treemacs-log "With Project %s : %s" (treemacs-project->name pr) (treemacs-project->path pr))))

A discrepancy between what this outputs and what it should output or what you see in the treemacs buffer would be very useful for debugging.

Everything is working as _I_ expected! No more issues in my workflow and testing. Thanks @Alexander-Miller!

About configuration, what's the recommended way to set it up? Is following the right way?

(with-eval-after-load "treemacs-persp"
    (treemacs-set-scope-type 'Perspectives))

That would work if you manually load the treemacs-persp module, or something else does. I assume you want to load it automatically after having started both treemacs and persp. For use-package that would look like this:

(use-package treemacs-persp
  :defer t
  :after (treemacs persp-mode)
  :config (treemacs-set-scope-type 'Perspectives))

In my case, spacemacs is doing the heavy lifting of bringing in packages and configuring it. I just wanted to tweak this setting hence the question.

Haven't heard anything in here for a while, I'll assume that means it's all working as intended.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

zoechi picture zoechi  Â·  6Comments

maxwedwards picture maxwedwards  Â·  3Comments

Compro-Prasad picture Compro-Prasad  Â·  12Comments

ianpan870102 picture ianpan870102  Â·  5Comments

dustinlacewell picture dustinlacewell  Â·  4Comments