JavascriptIsMagic/tree-view-git-projects

opening wrong project

Closed this issue · 8 comments

mark-hahn commented

When I am in project A and I select a tab that switches the tree to project B and then close the window things are left in a bad state. The next time I try to open project A I get project B instead. This even happens when there are no tabs open while closing.

There is a similar problem even without closing the window. When I'm viewing a tab in project B and all tabs are closed, the project is left at B and I can't open any of my project A files.

At the moment I'm kind of screwed. I can't get project A to open. I guess I'll have to manually open a file in A to get the tree switched.

IMHO, everything should be cleared to project A when the last tab is closed or if the window is closed.

Actually this package should save no state at all. I cant see any reason. If you have a reason maybe you should add a setting to stop saving state.

JavascriptIsMagic commented

"The next time I try to open project A"
How are you opening project A without opening a file?

I am not entirely sure where my package specifically other then atom.project.setPaths which I would assume would be the cleanest way to make the tree-view display the right project. I am unsure how I should go about clearing that state without saving previous state which I am not doing currently.

It's all of 20 lines of code right now in 0.1.2
https://github.com/JavascriptIsMagic/tree-view-git-projects/blob/master/lib/tree-view-git-projects.coffee
Basically, when any tab becomes active and a path for the filename being edited can be determined

It calls the gitDirectory function that recursively checks up the directory tree for the presence of a .git folder, if found it returns the project directory.

Once the git project directory of the current file is found, it compares that to atom.project.getPaths to determine if it needs to switch projects and reveal the current tab in tree-view.

The active tabs and atom.project keep the state, I don't save any state inside my package.

If you are using another project switching package, it may be the case that all it's doing is calling atom.project.setPaths to switch to project A without opening a tab, and then somehow re-activating a tab in project B immediately after which causes a .git path search and mis-match with atom.project.getPaths which then results in switching back to Project B.

I am not entirely sure how to fix this.. perhaps listening for atom.project.setPaths, determining it's from another package, saving that state, then on next tab activation ignore it and clear that state in order to attempt to guess at the intent of the setPaths?

mark-hahn commented

How are you opening project A without opening a file?

I usually open a project with atom --dev . in the project folder but sometimes I use Open In Atom in windows explorer. I never open single files.

I have some ideas on this. I suspect Atom's state-saving is interfering. When I get a chance I'll look at your code and see if I can help.

Did you try to repeat the problem?

JavascriptIsMagic commented

I could not reproduce most of this issue.

I may have found a similar issue in base atom editor:

  • I disabled my tree-view-git-projects package completely
  • I opened the command-line cd over to Project A
  • When I call atom --dev inside Project A it opens up a new window of atom set to Project A folder.
  • Then I cd over to Project B
  • When I call atom --dev inside Project B it opens up a new window of atom, but the project is still set to Project A (the wrong one)

I don't know if this is related, but that would be a bug in Atom editor itself, I can only work with the atom.project.getPaths() that atom gives me, and I also checked inside the activate: -> atom.project.getPaths() function and in that scenario atom editor is giving me the wrong project path to begin with, regardless of if the tab is switched or not.

even worse when I open the developer console and process.cwd() it does not seem to change and is stuck on Project A even after closing and atom --dev inside Project B.

mark-hahn commented

Can you file an issue at atom/atom with what you said here? Or do you want
me to do it? I thought it would be easier for you since you've already
done the testing.

On Fri, Jan 30, 2015 at 12:54 PM, CoffeeScript notifications@github.com
wrote:

I could not reproduce most of this issue.

I may have found a similar issue in base atom editor:

  • I disabled my tree-view-git-projects package completely
  • I opened the command-line cd over to Project A
  • When I call atom --dev inside Project A it opens up a new window of
    atom set to Project A folder.
  • Then I cd over to Project B
  • When I call atom --dev inside Project B it opens up a new window of
    atom, but the project is still set to Project A (the wrong one)

I don't know if this is related, but that would be a bug in Atom editor
itself, I can only work with the atom.project.getPaths() that atom gives
me, and I also checked inside the activate: -> atom.project.getPaths()
function and in that scenario atom editor is giving me the wrong project
path to begin with, regardless of if the tab is switched or not.

even worse when I open the developer console and process.cwd() it does
not seem to change and is stuck on Project A even after closing and atom
--dev inside Project B.

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

JavascriptIsMagic commented

Could you file the issue?

I just tried to reproduce it again and it seems to be be opening the proper project folder for me now after right-clicking on a folder and choosing Open with Atom and now seems to behave properly for me. I am not entirely sure what I did differently. (this is with my package enabled)

if you can get the bug to manifest more consistently, you should file the bug report,
process.cwd() and atom.project.getPaths()[0] are useful in the developer console.

mark-hahn commented

I was just looking at Project::setPaths and the paths seem to be
serialized. I'm not sure where they are stored but it I'm guessing atom is
later loading a directory and then deserializing the wrong paths that you
set. This might make sense if they did this in preparation for supporting
multiple projects at once.

So I fear that using setPaths for something not matching the directory that
was loaded doesn't work. How did you learn about setPaths? Did you see it
used in code somewhere else?

If I have time I'll chase down this serialization thing some more. If it
seems wrong I'll post an issue in atom/atom. Otherwise we might just be
screwed which is a shame since I like using it.

On Fri, Jan 30, 2015 at 1:09 PM, CoffeeScript notifications@github.com
wrote:

Could you file the issue?

I just tried to reproduce it again and it seems to be be opening the
proper project folder for me now after right-clicking on a folder and
choosing Open with Atom and now seems to behave properly for me. I am not
entirely sure what I did differently. (this is with my package enabled)

if you can get the bug to manifest more consistently, you should file the
bug report,
process.cwd() and atom.project.getPaths()[0] are useful in the developer
console.

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

JavascriptIsMagic commented

Yep, I was a little surprised that atom editor didn't have multiple projects support, or "favorites" support.

I looked at the source code for several project switching packages, most used Project::SetPath (singular, not plural) but when I looked into it a little more I found that apparently Project::SetPath is deprecated, so I decided to use Project::SetPaths (plural) instead as that seams to be in the latest documentation: https://atom.io/docs/api/v0.176.0/Project#instance-setPaths in fact if you look at the source code to atom, Project::SetPath just says it's deprecated and calls Project::SetPaths

JavascriptIsMagic commented

I am going to close this as the discussion should be moved to atom/atom#5533