Atom: "Open with Atom" removes added project folders

[csholmq]

I find the behaviour of right click -> Open with Atom to be non-intuitive on Windows.

If I have any added project folders they are successfully restored every time I fire up Atom. However, when I choose to open a single file or a directory using the right click menu, all added project folders and open file tabs are removed. Next time Atom is reopened it will remember only the latest opened folder/file.

Is this by design? I believe adding a folder/file would be much more intuitive. Especially when you work in multiple projects in parallel.

Atom 1.1.0 on Windows 7.

[LexGear]

Yes this is very annoying. I'm forever re-adding all my project folders.

[novelistparty]

Discovered this today. Don't like it.
Atom 1.2.4 OS X El Capitan

[garretwilson]

Oh, this is an irritating bug!!

Currently I have EmEditor as my "go-to" editor to edit whatever file I need to in a directory. I was considering switching to Atom. But on Windows 10 Pro 64-bit, if I use the Atom 1.3.2 "Open in Atom" context menu in Windows Explorer, Atom throws away my project folder!!!

This can only be a blatant bug. This makes no sense. Now I have to go add the project folder back---and I'll have to do it every time I use Atom to quickly edit a file on the fly. Which means I won't use Atom to edit files on the fly, and I'll stick with EmEditor or something else.

This should be fixed ASAP. Incredibly irritating and a big productivity loss.

[garretwilson]

@benogle , what does this "feedback" label mean? This is a defect, plain and simple. A huge, irritating defect. You might say that it is as designed, but the design has a defect. It should be marked as a bug.

[BrunoBernardino]

No feedback on this? Terrible UX.

[garretwilson]

Does anyone care that the "Open with Atom" functionality is effectively broken, because it removes all the other project folders I have added?

[LexGear]

Now I’m afraid to try. Thanks for the heads up.

Regards,
Luke Molnar

On 4 Feb 2016, at 07:50, Garret Wilson [email protected] wrote:

Does anyone care that the "Open with Atom" functionality is effectively broken, because it removes all the other project folders I have added?

—
Reply to this email directly or view it on GitHub https://github.com/atom/atom/issues/9643#issuecomment-179487910.

[EvHaus]

Very unhappy about this behaviour as well. I am constantly re-adding my project folders which is very time consuming. A very simple way to reproduce this bug:

• Launch Atom (Window 1)
• Added a Project Folder
• Go to File > New Window (Window 2)
• Window 2 will launch without any project folders (weird, but ok.. not a huge deal)
• Close Window 1
• Close Atom
• Re-launch Atom
• Project folders are gone with no way to recover

The above is a rare scenario. A more common one, is that I will have a single Atom window open and then close the App, but the App will hang. So I will Force Quit it and when I re-launch Atom -- the project folders are gone again. This is tracked in issue #9352 which is related I think.

[garretwilson]

But the most common scenario I believe is even worse, and it goes back to what was originally reported. Let's say I have may main project, C:\projects\foo, which I work on every day.

1. Launch Atom.
2. Add C:\projects\foo as a project folder.
3. Close Atom.

Then, for some other reason, I want to editC:\temp\bar.txt.

1. Right-click on C:\temp\bar.txt in Windows Explorer and select "Open in Atom".
2. Atom opens C:\temp\bar.txt. I edit the file.
3. Close Atom.
4. Reopen Atom. Atom has blown away my C:\projects\foo project folder!

This is completely counter-intuitive and anti-productive.

[holgerd77]

I'm also very unhappy about this. Have readded my project structure a dozen times or so since using Atom (couple of month). At least I now found this issue site and the cause of this, actually till now I never got this connected to the "Open with" action I seemed to always have done some time before.

Would be great if this could be fixed rather sooner than later.

[novelistparty]

Could any of the Atom devs perhaps point out for us on this thread the relevant code and maybe we could help with the bug? Not sure I could completely fix it, but I'd like to help the process along in some way.
@benogle ?

[robmosca]

I can confirm I also have this problem (Atom1.5.4, OS X El Capitan) and it is actually very annoying (well, I have to say this is one of the reasons I am not using Atom as my normal IDE).
Will this be addressed any time soon?

[hultberg]

Try out the project-manager package, it remembers all project folders for you. Even thou you must open projects with Alt+Shift+O

[mehcode]

An option I would recommend (without shame) is https://atom.io/packages/project-plus

It is not going to fix your issues with Open With Atom. But it will let you easily switch back (in the same window) to your project workspace that has all your project folders using ctrl-alt-p.

[Zireael07]

What's the difference between project manager and project plus?

[mehcode]

Project Manager

• Accesses projects out of a projects.cson file; which means that projects must be explicitly saved
• Opening projects opens a new window (with the option to close current), which is slow but easy/effective

Project Plus

• Access projects from previously serialized editor state; which means that there is zero configuration / atom already knows about your projects (which is why I suggested it as it would know about the multi-folder setup already existing)
• Opening projects opens in the same window (with the option to open a new window) using a new method I figured out that does not corrupt state and is lightning quick.

[holgerd77]

Nevertheless Project Manager is much more established for now with 300.000+ (project-manager) vs 200+ (project-plus) downloads.

Doesn't mean of course that project-plus can't be better - maybe it's just new on the market with a fresh approach - just want to mention this if stability/maturity considerations play a role.

[nemonein]

This bug still exists in Atom 1.6.0 on Linux(Ubuntu). It's really annoying.

[BrunoBernardino]

I've started looking into this, and the problem appears to be here. Basically if there are files being opened "when opening the app", it won't load the state. It seems a choice, not a bug, somehow.

Can we get some more information from someone in the team before I take more time trying to create a proper PR for this?

Locally, on OS X I can get the app to _"load properly"_ if I simply add @loadState(options) after @openWithOptions(options) in that first condition (if the file being opened is not a part of the existing project folders, it won't open it — it opens atom with the previous state —, but the previous project folders don't get lost).

[csholmq]

https://github.com/atom/atom/blame/master/src/browser/atom-application.coffee#L83-L86

@maxbrunsfeld @nathansobo

[BrunoBernardino]

BTW, the options are passed to loadState, but it ignores them: https://github.com/atom/atom/blame/master/src/browser/atom-application.coffee#L517

[ShayBox]

I've found a temporary solution, with project-ring package you can set a project to be loaded at startup, so if you open a file it will open it and override the current tabs, but the project folder wont. not completely working, but enough that you don't have to re-add the project folder every time

[BrunoBernardino]

I'd appreciate a "you're going in the right/wrong direction", if there's no bandwidth for the team to currently work on this. :)

[jaseeey]

@ShayBox Thank you for your suggestion, it auto loads the projects every time which is enough for me! I have 10+ projects loaded in Atom, so it's annoying every time they disappear.

[wangxiexe]

Any idea when it will be fixed?

[garretwilson]

I just wanted to update everyone that I'm working around this bug by using the project-plus add-on (mentioned by @mehcode above). I don't know what magic project-plus uses, but apparently Atom is keeping all of the "projects" or "sessions" saved somewhere anyway. Project-plus allows you to switch among them and even set up your own named projects, without saving special files in the working directory. It's really slick, although it crashes once in a while.

I'm still baffled why this incredibly obtuse exists in the first place.

[holgerd77]

F*, just read "I just wanted to update everyone that I'm working..." and thought it would go on with "on this bug". :-)

Happy too early.

[maxbrunsfeld]

Sorry for the poor experience, everyone.

Just to focus the discussion: I believe the behavior that you are all experiencing is by design, not by accident, so we need to come to agreement on the most intuitive behavior for all scenarios.

The current design is trying to satisfy these properties:

1. Running atom with no arguments (or double-clicking the Atom app) reopens Atom with whatever windows were opened previously.
2. Running atom path1 path2 path3 opens exactly one Atom window, with the exactly the specified paths as project folders. It does not any unrelated folders to the window. It also doesn't open any other unrelated windows.
3. Running atom -a dir _adds_ dir as a project folder to the most recently-focused Atom window.
4. The _Open with Atom_ shortcut does the same thing as running atom with the clicked path as an argument.

@garretwilson Thanks for providing a series of steps describing your workflow. I don't fully understand your expected behavior though. After clicking _Open with Atom_, do you expect Atom to open with two windows, one with the file you clicked, and one with the previously-opened folder? Or do you expect Atom to open one window, containing both your previously-opened folder and the file you clicked?

Neither of these options is initially intuitive to me; when I open a specific path with a text editor, I expect it to open _just_ that one path. I am definitely open to changing this expectation though, if a majority of the community feels that it is surprising. Alternatively, it should be pretty easy to resolve the issue with a package, which is Atom's preferred solution when people have different behavior preferences.

I haven't used project-plus. Does it completely solve the problem for people, or are there remaining issues?

[EvHaus]

For me personally, the expectation is that if I've used the "File > Add Project Folder" option, that project should be in my sidebar forever, unless I manually remove. It doesn't matter if I open Atom in a new window, or to a specific path, or Atom restarts, or Atom crashes, etc.. The list of the projects in the sidebar should always contain everything I've pinned into there.

project-plus does not fullfil this expectation for me.

[maxbrunsfeld]

@EvNaverniouk thanks for the explanation. I can see how that workflow would work.

I don't think we will change Atom to work that way by default, as it is currently designed to feel less stateful than that. Running atom dir1 followed by "Add Project Folder > dir2" is meant to be equivalent to running atom dir1 dir2.

However, I would like to make sure we're doing everything we can so that a package can easily provide the experience you described using our APIs. It sounds like you might want a package that adds a new command Pin Project Folder that uses the Project APIs to ensure that a folder is always present.

[holgerd77]

@maxbrunsfeld Hmm, I think that is what everyone is expecting here. :-/ For me it was so bad that I actually considered leaving Atom again, though in general I'm totally in love with the editor.

I actually have "solved" the problem now by always getting an anxious inner flash when tempted to use the "Open with Atom" context functionality and then just don't do it. :-)

[BrunoBernardino]

I agree with Evgueni.

[maxbrunsfeld]

I think that (@EvNaverniouk's comment) is what everyone is expecting here.

That would really surprise me; I think most people work on a variety of unrelated projects, so having a _global_ list of 'pinned' folders that persists across all Atom windows would not be very useful.

My guess is that more people would want a package like project-plus to be built into Atom. That would make Atom behave similarly to Sublime Text, an editor that many Atom users are familiar with.

[rapus95]

I think it's sort of obvious that most people that expect their "added Project folders" to be always in the sidebar, use Atom as IDE not just as text editor. And for IDEs the described behaviour is pretty common. When you open the IDE you select a workspace (a directory that usually contains some sort of metadata to organize the whole setup) and if you then select to open a file with the IDE there are two ways to work with that file:
a) it is included into the sidebar (that manages all projects that belong to the workspace) as some sort of snippet project (some temporary project only containing that file)
b) only a new tab is opened w/o adding anything to the project explorer(=sidebar) similar to the way preview tabs are working in atom, with the difference that you can have multiple tabs open whose directories etc DON'T appear in the sidebar.

Now from the point of a developer where you have workspaces containing several projects it is pretty sad behaviour if you open another project in the same workspace (=usually same parent directory) and Atom "forgets" about the workspace and the other projects, only because you didn't open the parent folder directly but a folder inside it.
This "problem" could be solved if there was some check for whether parent directories have any concrete setup(&new pinned folders) attached. In principle the behaviour of opening the parent directory to the file that is intended to be opened is already part of atom (you always get the whole folder into the sidebar). In case of simple workspace setups it could be solved by somehow finding out how many layers of parent directories to include.

A manual solution would be to add a context entry for the project folders to switch them into their parents and thus getting a wider view ("increasing the distance to my file").
(The opposite of "go into", a nice idea aswell, which sort of shifts the whole perspective into a folder, "getting a closer look")
After that function is added the next step would be some sort of automation/remembering how many layers were opened.

Whether the suggestions belong to a plugin, atom itself or anywhere else is not part of this post. It is just to clarify (at least my point of view of) the problem.

[iolsen]

Possibly related to https://github.com/atom/atom/issues/8427

[BrunoBernardino]

I'd say it's the same issue, _for me_.

[sherghan]

This is very annoying!

I get hit by this issue on a regular basis.
From time to time I forget to open Atom before opening any standalone text files and all of a sudden my whole workspace is gone. Then I need to go through all the different directories where I keep notes and different projects to re-add them.

Maybe we could have another view like _'bookmarked trees'_ or _'pinned view'_ if remembering (always) the projects that we added is too much for _'tree view'_?
... I'd gladly switch over from the current broken-by-design _'tree view'_ to the one that I can count on.

[sidewaysdesign]

This thread is nearly a year old and the same bug stands. Second time this week I've had to rebuild my project list. Persistence is utile!

[anatoli26]

@maxbrunsfeld, you say:

Neither of these options is initially intuitive to me; when I open a specific path with a text editor, I expect it to open just that one path.

I believe, that would make sense if, with the editor opened, you’d get a new window with just that one path.

But, as the new path is just opened inside the existing window, when atom is already opened, i.e. when atom is already running, opening a specific path is equivalent to ADDING it to the already existing session, keeping everything there, this is what most (I believe) users expect to happen when there is no editor running too.

I believe there are A LOT OF users that don’t like 2 instances of the editor, they work in a single window. See here: https://discuss.atom.io/t/dont-open-files-in-a-new-window/2916 and here https://github.com/atom/atom/issues/1722.

You commented there (https://github.com/atom/atom/issues/1722#issuecomment-74962806):

That's the expected behavior, which this PR originally implemented. To force a new new window, use this:

-n, --new-window Open a new window

Alternatively, you can pass the path to a directory instead of a file.

So, if with the editor opened the correct behavior is to ADD a new file to the existing session, why it’s not when the editor is not running? What’s the difference? If the user has enabled the editor to save and restore the current state on close/open of the editor, then he/she expects (IMO), that the state always persists. Otherwise the user would just open an empty editor (no session preserved) every time he/she launches one.

I believe that if a user wants to "open a specific path with a text editor" and "expect[s] it to open just that one path", then the user could pass the -n flag to the command and obtain the desired behavior.

For all other cases, especially when the requested path for open command is a file (that is the case for the "Open with Atom" context menu), the desired behavior (with the session restore functionality turned ON) is to always keep/restore the session, no matter if the editor is running or not.

[novelistparty]

👏

To add to @anatoli26 excellent point, in macOS the default behavior for as long as I can remember is that programs always re-open with the files/windows from the last session. Even if you open an additional file from the command line, that file is opened alongside the already opened files.

Atom's behavior is contrary to the defaults I experience every day on a Mac.

[novelistparty]

@maxbrunsfeld you said previously:

Neither of these options is initially intuitive to me; when I open a specific path with a text editor, I expect it to open just that one path.

I cannot understand how this would be the case if you use macOS or OS X. For example, I can open a text file in Xcode with xed file.txt and Xcode will open all windows from it's last session and add file.txt. This is the default behavior. Same for "Text Edit" and Text Wrangler and Mail.app and _everything_.

I haven't worked in Windows for years, but I think it's the same there.

[garretwilson]

I really think you guys are getting off track. (Not that it really matters --- I have no hopes anyone will address this issue anytime soon.) You're arguing how the _open windows_ behave. On Windows this can sometimes be configured on a per-application basis: if you set the application to have a single instance, then it would be expected that a new window would be added the existing opened windows. If the application were configured to have multiple instances, a new instance of the application would open with just the requested window (and the existing open instances wouldn't be changed).

But that's not what this issue is about at all. Here we're talking about the fixed sidebar which holds the directories that have been "pinned" for lack of a better word. That's an entirely different issue.

Add the requested file to the already open windows if you like. Or replace all opened windows with just the requested file. But just don't unpin folders that I have pinned to the tree view! End of story. This thing about open windows is a side issue.

[anatoli26]

@garretwilson, what you describe is one of the closely related problems, but not the only one. This issue (i.e. #9643) is a tracking thread for all the problems related to session not being restored on opening a new file with the editor not running.

Here alone you have 5 "... referenced this issue" bug report mentions for the same problem and in each of them there are about 5 more references to the bug reports for the same problem, all being closed in favor of this thread. So this thread tracks all these problems, which basically could be resumed as: inconsistent behavior in opening a new file when the editor is running and not running, with session restore functionality enabled.

In my opinion (and I believe a lot of users (if not most) share the same view), if the session restore functionality is enabled, it should be restored to the previous known state when opening the first instance of the editor, no matter if it was launched/invoked with or without additional paths.

If this rationale doesn't convince the developers enough to make this the default behavior, at least there should be an option that would enable this behavior, as the current state is quite frustrating for those of us who expect the editor to behave according to our logic.

[garretwilson]

This issue (i.e. #9643) is a tracking thread for all the problems related to session not being restored on opening a new file with the editor not running.

Rereading the description I see that you're right that the issue initially referred to open files as well, even though the title only referred to the saved project directories. I still think it's better to choose a focus and try to get things done one at a time. But as we're coming up to a year already of this issue being opened... good luck on whatever you can accomplish.

[novelistparty]

Can @maxbrunsfeld @nathansobo @benogle @damieng @50Wliu @lee-dohm @mnquintana or anyone provide some feedback on what is being done about this? Please.

The majority of people on this thread and all referencing threads disagree with @maxbrunsfeld and we would like to hear from other atom devs about what is/isn't being done about this. Also, we would much appreciate guidance (if lead devs won't fix this) on how to change this properly via a plugin or personal fork of atom.

There are so many other issues that have been closed in favor of this one, and we are all waiting for word from devs on what can/might/will be done about this behavior.

I see tons of commits on the atom project for all sorts of new features and improvements, but this issue is a fundamental problem with how the app behaves. Atom should not ignore the default behavior of every other text editor on my computer in order to do "the right thing" (at least according to @maxbrunsfeld ).

Please, other devs, give us some help here. This is a fundamental breakdown for Atom.

Thank you.

[damieng]

A quick-switching mechanism between projects is nearing completion. This will let you get back to your previous combination of open folders with just a couple of clicks.

If you want to try it out it's in the dg-reopen-project branch.

[damieng]

PR is up at https://github.com/atom/atom/pull/13046

[anatoli26]

Damien, the new functionality looks great, but I don't see how this resolves the problem of this thread. Do you mean that we'll be some clicks closer to the desired behavior, or it will solve the problem completely via some option (not mentioned in the PR) like 'always restore the last project, no mater the state of the editor' ('state' being running/not-running)?

If there's no 'always restore the last project' option in this PR, I guess the workflow would look like this:

1. The user works on a project and files, then closes the editor (e.g. to turn off the computer)
2. The user wants to edit a file (e.g. after turning on the computer) that was not in the previous session, and while the editor is NOT running, he/she double-clicks on the file or chooses the context menu 'Open with Atom'
3. The editor opens just the new file (when the user was expecting the editor to restore the last session + open the new file in the same window in a new tab)
4. The user (after some swear words) goes to: File -> Reopen Project -> Chooses the last project...
5. A NEW WINDOW with the last project opens (as according to the PR 'reopening a project always appears in a new window')
6. Now the user has 2 windows: one with the single file and the other one with the previous session, but the user wanted to have only one window with the previous session + the new file. If I understand it correctly, he/she won't be able to merge the 2 windows to obtain the desired state in one window, as he/she was hoping for.

[anatoli26]

To make myself clear, I don't have anything against the proposed PR, but not as the solution to the problem of this thread.

IMO, the only thing we need here is an option that would always restore the last session when starting the editor, no matter with what parameters it was launched (i.e. the parameters ADD to the last session, not replace it, except when the parameter is '-n', meaning a new window).

As others said, this is the default behavior for the majority of the programs. I would add two more:

Firefox

Chrome/Chromium

In both cases, if the browser is not running and we click on a link somewhere (i.e. in a mail client), a new browser instance launches, opening the last session + the new link, NOT just the new link, losing the previous state.

[50Wliu]

Disclaimer: I don't use "Open with Atom" that much, and don't even have it enabled on folders, only on files.

That being said, I enjoy the current functionality when clicking "Open with Atom" when Atom is already open. That is, the file is added to the last-focused window as if "Open File" was selected. So I think I would also lean towards adding the folder as a project when using Open with Atom. In general, removing projects is easier than re-adding.

[damieng]

"the user was expecting the editor to restore the last session + open the new file in the same window"

I wouldn't personally be expecting this from my editor. If I close a project then open a specific file or say write a commit message - the last thing I want is 25 tabs open.

I think we can agree that there is enough difference of opinion here that a config setting would be required.

If there were an option to treat opening a file through an association/open with atom/command-line as 'open file within last project'... what would opening a folder though those mechanisms do? Something totally different or treat as adding another root to the last project?

The PR is still valid as it addressing project switching in general (even with a restore-last-project setting getting back to the last-last project would be a pain if it contains multiple roots) and at least provides a little relief to people on this thread in the mean time.

[garretwilson]

This is the last time I'll say this, but it isn't helping any that we're mixing "folders I've pinned to the tree" and "files I have open". Sure, they are related, but they are orthogonal. If you mix these issues up, there will always be someone saying, "but I didn't expect it to work that way" and there will be no agreement. Split the issues up and focus on them each separately.

All I care about is that I told Atom to list a folder in the tree, and without asking me, it removed the folder _that I had explicitly put there_. Address that by itself, and I'll think that a clear majority will find that they agree that it is unexpected for Atom to remove folders from the tree that the user has specifically requested be there.

I am removing myself from notifications so that I will not be tempted to reply further, as I would just be repeating myself. Good luck.

[anatoli26]

What happened with the latest version 1.12.1 with respect to this issue? Now, when I try opening a file with Atom already running, I get a new window with the requested file, always.

From one hand, now the behavior is consistent in both cases: when Atom is running and not, i.e. a new file is always opened in a new window, without preserving the previous session.

Now is the question: when there will be an option for both the cases (running and not) to open in the same window if Atom is already running / restore the previous session if opening the requested file implies starting a first Atom instance?

[draeath]

This is incredibly aggravating. I just removed an old standard (Notepad++) intending to replace it with Atom, but I'm rethinking this since my "list" of projects is wiped out with the directory of the last item I open via the shell.

This list should be maintained by the user directly and never automatically changed.

Atom 1.12.7 here.

It's alright @garretwilson - we'll keep saying it ourselves.

[sidewaysdesign]

@draeath: The package "project-manager" is mentioned earlier in this thread, though I'm going to bump a recommendation for it.

It solves the issue of vanishing project lists, and adds a couple of features on top.

Easy to use, and reliably stores multiple sets of projects. Projects are stored as .cson, so in addition to some management menu options, they can be directly edited, sorted, renamed, etc.

Jumping back and forth between clients, some with a number of ongoing projects, is quick and worry-free.

Kudos to Daniel Brodin for such a useful plugin.

[damieng]

1.13 (beta) has a new menu option called Reopen Project which will allow you to easily re-open the the set of folders (project) you had open.

[draeath]

"project-manager" is cumbersome to use, but it'll do for now. If there's a way to have it open a 'project' when Atom launches, I'd be happy to know - I'm fairly sure you could put that in your init, but I've not any idea how to go about doing that.

The 'Reopen Project' item in 1.13 beta sounds good. But that shouldn't be buried in a menu or command palette.

I'd think a 'better' solution would just be to allow the user to specify a list (or a directory which first-level subdirectories would be used) of project directories to maintain in the list. Other items could then be dynamic as currently done, below the 'static' user-defined entries. I don't see how this wouldn't make everyone happy.

[novelistparty]

@draeath I'm frustrated too.

Brackets has this functionality.

Notepad++ has it.
Text Wrangler has it.
CotEditor has it.
Eclipse has it.

I'm frustrated that the same -- as is found in nearly _every_ graphical editor -- is not found in Atom.

[Blair2004]

That really s**k !!! Everytime i'm trying to open with. However, atom seems to be a good IDE (i've abandonnated Dreamweaver). Maybe this is a temporal solution :

• Before opening with Atom, i open Atom first, so all my project are loaded, then i open with Atom, so the projets folders won't be lost. I'm using keyboard shortcut on Win10, and it may takes time, but now i have it in my habits.

[JeffML]

Mac OS, 10.10.5

Open Atom
Add project folders
Project folders show in Reopen project...
Close Atom
Open Atom
No projects in Reopen Project...

[damieng]

@JeffML can you create a separate issue for that with the template filled in - it's a slightly different issue to what was being discussed here.

[Khovanov]

Same problem!
win10 (64)
Atom 1.13 ia32

[JeffML]

It appears that if I load a "new" project folder, the history comes back!

Sent from my T-Mobile 4G LTE Device
-------- Original message --------From: Stanislav [e-mail] Date: 1/24/17 10:21 PM (GMT-08:00) To: atom/atom [e-mail] Cc: Jeff Lowery [e-mail], Mention [e-mail] Subject: Re: [atom/atom] "Open with Atom" removes added project folders
  (#9643)
Same problem!

win10 (64)

Atom 1.13 ia32

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/atom/atom","title":"atom/atom","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/atom/atom"}},"updates":{"snippets":[{"icon":"PERSON","message":"@Khovanov in #9643: Same problem! \r\nwin10 (64)\r\nAtom 1.13 ia32"}],"action":{"name":"View Issue","url":"https://github.com/atom/atom/issues/9643#issuecomment-275029024"}}}

[damieng]

A project in atom is a collection of folders open at the same time. Whenever you launch Atom with no args it loads the most recently opened project.

The confusion seems to arise when somebody opens an individual file or folder in Atom using the command line or OS shell. When you do that and the file doesn't belong to an open project it effectively creates a new project.

So the next time you launch atom you get back the project it created for that file/folder which sometimes you don't want.

The good news is that in Atom 1.13 we added a Reopen Project feature. It is available from both the File menu and also using the Application: Reopen Project command (with a fuzzy finder) for the keyboard-inclined. Once you've done this then it is the most recent project and will be the default again.

[Khovanov]

Thanks, Reopen Project feature - well, but I temporarily resolve this problem by using the project-manager package.

[anatoli26]

@damieng, thanks for the information. I just wonder why there can't be an option to always reopen last session for those of us who don't use multiple instances of Atom and always work in the same window? That's just some 5 lines of code.

[damieng]

It is reopening the last session. It's just it created a new session when you opened a file from explorer/finder/command line.

It's hard to know when somebody opening a file from the command line/explorer didn't want a new session. While you could add command-line switches to prevent that chances are people would forget and still get in this scenario.

[anatoli26]

I was meaning to add a setting in Atom that would indicate such a behavior (always restore the last session). It could be implemented as a command-line param too, and the user could rewrite the association to always invoke Atom with the required param. Though, a GUI setting would be much better.

[lee-dohm]

@anatoli26 Atom has had the behavior to restore the last session since before v1.0, I believe. Atom also has had a setting to control whether to restore the last session for a number of releases. The setting has always defaulted to enabled and it has been exposed in the GUI in v1.14-beta:

The default in v1.14-beta is still to restore the last session. See my PR for more details.

[dlandis]

The good news is that in Atom 1.13 we added a Reopen Project feature

This sounds similar to what Visual Studio Code offers with the File -> Open Recent menu. However, it was never really a big issue with VS Code because you don't lose all your folders when you open an external file; it just opens the file in the Open Editors section without modifying your current project.

[damieng]

I thought I'd see what VS Code does and it isn't what you describe at all at least here on Windows;

When Code is not open (close between steps)

1. code c:\temp - opens VS Code with just temp folder
2. code - opens last project in 1
3. code c:\temp2 - opens VS code with only temp2 folder open
4. code c:\somefile.txt - Opens VS code blank with just somefile.txt and no temp2

Every one of those steps was the same with Atom.

1. code - opens with blank slate

This differs as Atom opens the state from step 4.

When Code already open

1. code c:\temp - opens VS code with just temp folder
2. code c:\somefile.txt - Opens somefile.txt in new VS window

This behavior is different. In Atom it opens as a tab in the existing Window so you actually don't lose your 'last' project - in Code if you close the project window before the new window then you do lose your 'last' project and will now get a blank 'new window' next time you launch Code.

[dlandis]

I thought I'd see what VS Code does and it isn't what you describe at all at least here on Windows;

I am on Mac, but actually I wasn't talking about using the command line at all. I double tapped (right-clicked) a file and chose Open With > VS Code. Similarly the issue I opened 6 months ago (#12171), which was marked as a duplicate of this issue was also not about command line.

[anatoli26]

@lee-dohm, if I understand you correctly, you're talking about restoring the last session on Atom's start without any parameters, i.e. without asking it to open a new file. This is the behavior we all know and what a lot of us want is to extend this behavior to ALL cases, i.e. no matter if Atom is started with or without parameters. This is THE behavior when an instance of Atom is already opened, i.e. it doesn't start a new instance on opening a new file, it just opens it in the same window. This is what we want to also happen when Atom is not running: first restore the previous session, and then open the file as if Atom was already running, i.e. in the same window.

So what a lot of us, the Atom users, are asking is to have a setting that would always restore the previous session, no matter how Atom was launched (with or without parameters).

[lee-dohm]

@anatoli26 I can understand that too. Discussions for that broad of a request are off topic for this issue which is solely focused on fixing the bug mentioned in the original posting. If you want to discuss broad solutions like you're proposing, you can talk about them on https://github.com/atom/atom/issues/10517.

[anatoli26]

@lee-dohm, as I already mentioned in one of my comments (https://github.com/atom/atom/issues/9643#issuecomment-255262690) here 3 months ago, "This issue (i.e. #9643) is a tracking thread for all the problems related to session not being restored on opening a new file with the editor not running." So I believe it's the place to discuss it.

Indeed, what's happening is that when Atom is not running and I choose to open some file with it, my previous session is lost. I don't think that the setting proposed in my last comment is somehow not related to the original issue reported here.

Anyway, what's the rationale behind not implementing it when so many users are asking for it? 5 lines of code and everyone is happy.

[50Wliu]

and everyone is happy.

There are people who have commented that they prefer the current behavior to the proposed behavior. Also keep in mind that people who are satisfied by the current behavior are much less likely to comment on this issue, as they would have no reason to look for it. Finally, the Atom team tries to avoid adding extra settings whenever possible. Of course, that may be unavoidable in this case; I'm not the best person to decide that.

[anatoli26]

That's why the proposal is NOT to _overwrite_ the current behavior, but to introduce an _option_ for everyone to _choose_ their preferred way of doing things. It could even default to the current behavior, no problem here, but please give the users a possibility to comfortably use this nice editor.

[lee-dohm]

So I believe it's the place to discuss it.

@anatoli26 I'm stating now that this isn't the place to discuss it. We're trying to get a handle on our issues list so that we can have a clean enumeration of all the things that we, the Atom organization, need to and intend to work on. The method that we have selected for doing that is to define all of our tasks by the title and initial post (that organization members will edit, as necessary, for clarity) of issues in our issues list. So, this issue is specifically about "Open with Atom" causing problems, not about sweeping changes to Atom's launch process ... which, as I have stated, is covered in #10517. If you would like to discuss this further, please feel free to contact me directly at [email protected].

[etc0de]

@damieng

"the user was expecting the editor to restore the last session + open the new file in the same window"

I wouldn't personally be expecting this from my editor. If I close a project then open a specific file or say write a commit message - the last thing I want is 25 tabs open.

The problem is that if you close Atom right now and reopen it regularly, you do actually get 25 tabs back open. The expectation is directly caused by Atom enabling session restore per default.

While the current behavior of not restoring the tabs in some cases is probably useful in some workflows (as confirmed e.g. also by some of the people commenting here they like it), it is super weird as a default because Atom establishes the expectation that it will remember what you had open when you close it and reopen it regularly, and then breaks with that behavior when opened differently without an obvious warning and no obvious quick fix for getting your huge pile of tabs back.

I'm not saying there isn't a reason that the current behavior is good for some workflows , I'm just saying to a new user it is less likely to be the expected simply based on the other behavior they will most likely have already observed. Also, there's no warning/hint before it happens and no easy/obvious way to fix it. (like e.g. a simple message box that asks me if I want to reopen my old tabs or forget about them when this case happens would do wonders)

I suggest choosing a new default that doesn't throw away lots of tabs without a warning is a much more reasonable choice. The old behavior can easily be an option/setting, also keep in mind closing all other tabs requires just 2 clicks.

If you really think this should stay the default behavior, add a message box when Atom launches in the discussed case and let the user decide what happens. A single additional click is much less annoying than searching one (or even multiple) projects on your disk again and reopen them one after one, for those users who require that for their workflows.

[damieng]

it is super weird as a default because Atom establishes the expectation that it will remember what you had open when you close it and reopen it regularly, and then breaks with that behavior when opened differently without an obvious warning and no obvious quick fix for getting your huge pile of tabs back.

Except it IS remembering what you had open. You had a single file open. What you're saying is that somehow people should expect opening a file from the explorer open should be treated differently from opening a file/folder from within Atom and I disagree that is a fair expectation.

The quick fix is to go File > Reopen Project and chose the first item in the list.

[etc0de]

@damieng no when you open the single file, it explicitly forgets and doesn't reopen those 25 tabs, doesn't it? (which is what I am suggesting is the unexpected, inconsistent thing) Afterwards it remembers again of course, but a single file leading to all those 25 tabs being gone is against what was established before.

You can disagree of course, but I was surprised by reading this ticket that this is what it is going to do in this case, and you can see by the many, many other people that I'm not alone.

If you still think we are wrong and your expectations are the one most people should have, maybe do some actual UI testing with people who have never seen Atom before and let them open a project, tell them to pretend to do a bit of coding, then make them close and reopen Atom to see that tabs are retained, and then make them restart the PC (a common thing people need to do at some point) and then e.g. give them instructions for the following two steps:

1. to open a single config file to change something and praise that Atom has good syntax highlighting for that too (so they'll open it up with Atom, maybe directly from the file explorer triggering this special case)
2. and to then return working on their project after doing that

.. and see what happens. If they end up frustrated because their project tabs end up gone: sorry that you disagreed, but it appears I was right. If they don't end up surprised: I was wrong, and you were right.

It is really pointless to disagree about what you think what a fair expectation is, if it doesn't match reality. (Same goes for me of course) So if nobody of us can tell for sure, do a real world test with people.

[damieng]

no when you open the single file, it explicitly forgets and doesn't reopen those 25 tabs, doesn't it?

No, it does not.

It opens the project/state associated with where the single file is and restores that state. If you haven't opened a file from that folder before then it will be fresh state.

This is then the most recent 'project'.

If you want to go back to any previous projects then you can select it from the reopen project menu.

This is a great way of working if you use Atom for multiple projects. It is less ideal if you have one main project and occasionally open other random files.

The alternative you describe would be more jarring, especially if you then open a bunch of additional files and work on them for a while. You'd close Atom, restart and all of a sudden you're looking at project state for a project you worked on potentially days ago and not the thing you were just working on.

[etc0de]

Sorry if I'm still misunderstanding, but if that config file is somewhere randomly else on the disk and not part of the last oepned project, wouldn't it behave exactly as I suggested? (and therefore be potentially unexpected in that situation)

Again I'm not suggesting the behavior isn't great for various scenarios, I'm just saying that it can lead to unexpected behavior in some situations (e.g. the one I described) and therefore maybe some different default behavior would be better, while retaining the current one as an option.

The alternative you describe would be more jarring, especially if you then open a bunch of additional files and work on them for a while. You'd close Atom, restart and all of a sudden you're looking at project state for a project you worked on potentially days ago and not the thing you were just working on.

How so, if it always reopened the last opened project? If you don't use Atom for weeks and open some config file and your old project comes back too as it always used to when you opened Atom in the past, how would that be unexpected / jarring? Maybe it would be a bit annoying if you don't use Atom for projects at all, but let's be honest here, Atom simply isn't Notepad.exe.

[damieng]

that config file is somewhere randomly else on the disk and not part of the last oepned project, wouldn't it behave exactly as I suggested?

No, it doesn't "forget those 25 tabs". They're still there as part of the virtual project that belongs to the folder(s) you had open last time. That is just no longer the current project because you opened something else.

If the config file lives in a folder that's never been used before it creates a 'fresh' project so that it looks like you just opened that file however if you've worked in that folder before then you may in fact see a whole bunch of different tabs open as it is now working with that project.

How so, if it always reopened the last opened project? If you don't use Atom for weeks and open some config file and your old project comes back too as it always used to when you opened Atom in the past, how would that be unexpected / jarring?

Many people don't just use Atom for one project and occasional files but have many projects and the current system means if you open an individual file that belongs to a project from your shell you get that project's state plus the file you opened.

If you only have one project I'd recommend creating a script or icon depending on how you launch atom that just specifies the project folders as part of the arguments. Then you'll always get that.

[anatoli26]

@JonasT, there were already dozens (if not hundreds) of people who have requested the "most expected" behavior for opening a new file, but Atom dev team just says that their use case is more important and valid than our and that they do NOT consider it acceptable to add an additional check box in the configuration to enable the users to choose the desired behavior.

For the Atom dev team I would recommend checking a nice presentation from the recent FOSDEM (Free and Open Source Developers’ European Meeting) titled "Sharing power in our communities - Designing and implementing better spaces for everyone": https://fosdem.org/2017/schedule/event/community_sharing_power_in_our_communities/ (slides and video).

[etc0de]

@damieng

No, it doesn't "forget those 25 tabs"

But does that really matter if to the newcoming users it looks like it did just that?

[damieng]

@JonasT, there were already dozens (if not hundreds) of people who have requested the "most expected" behavior for opening a new file

There are 31 people on this thread including 5 of the dev team. So 26 people reported they are unhappy about the default behavior. Atom has over a million users.

It's not a case of not listening to users it is prioritizing work based on the most effective use of the teams time. In this case the majority of users appear happy with the current behavior and there are simple workarounds for the behavior you want - create a shortcut or one-line cmd/bash script to open atom with your intended project folder.

There are many other open issues that affect significantly more people often in ways that have no easy workaround.

Yes, it would be great if every open source project had infinite resources but that isn't a reality.

If you feel strongly about wanting a checkbox for the behavior you describe you can always send us a PR for consideration.

[lee-dohm]

@anatoli26 your comment is a violation of the Atom Code of Conduct as is insulting or derogatory. You may consider this an official warning.

[BrunoBernardino]

If we could get a pointer to where one _would_ fix this, I'd be more than glad to push a PR or even a package that simply changes this behavior. I've asked before if what I thought at the time was correct or not. Thanks!

[lee-dohm]

@BrunoBernardino I understand this is frustrating. If someone knew off the top of their head where to put the change, they would have already given you an answer. In doing the investigation to tell you the exact point where one might make the perfect change, we would again be taking time away from other tasks that we've already stated are higher priority. So we're going to have to continue working on the higher priority stuff until we burn that down.

[draeath]

I guess this really depends on what users are using Atom for. TL;DR I'm a sysadmin, not a dev.

I am not primarily a developer, and I have several "scratchpads" that I frequently access (the items that I'd want persistent). But I also frequently work with one-off files and various shell scripts and other random items, and I do so with Atom because of all the functionality it offers - and these are the volatile items I'd not want to persist.

Just some clarification on my particular use case, if that's helpful at all.

[damieng]

I think the problem is there is no way for Atom to automatically know what's a scratch-pad that should not have state and what is an actual project for which you want state for.

I don't know what the checkbox would even be labelled/do. "Don't create project state when I open individual files from the shell unless there is already state associated with the folder they live in" ?

[BrunoBernardino]

@lee-dohm Thank you for the answer. I wasn't looking for a perfect suggestion on the fix, just if my assumptions were correct, and I understand that still would've taken time to consider.

I really like the PR suggestion from @anatoli26, @damieng .

[garretwilson]

I was on this discussion early on, but I'm trying to stay out of any arguments now. Let me add a couple of things that may be helpful. It seems that Atom creates some secret record of state associated with some open files. If you happen to open one of the files associated with that state, voila, you get all those files back. Otherwise, if you open any other files independently, any manual arrangement you made is seemingly lost, until you happen to come in contact with one of those previous files. Or something like that.

The thing which I'm not sure is getting through to the Atom development is that this is unexpected. I'm not saying it's bad. I'm not saying it's not not useful to somebody's workflow. Maybe it's even innovative and really freakin' cool. Whatever the case, it's different; nothing else I have works like that. It's unexpected. And unless I have been trained on this cool secret, different project-state-persistence thing, it's not only jarring, it's inconvenient if I've taken the time to put things in my file tree and expect them to be there. I say this in the hopes of furthering understanding on the Atom developers' side.

For helpful suggestions, here's an idea: why not have a little pin icon next to each tree in the tree panel or project pane or whatever it is. If I click it, the tree is pinned. It stays there. If I "Open with Atom" from the shell, I get the single file/folder --- but the pinned directories are there, too. If I open at by itself, Atom does whatever it normally does (I still don't remember what it does, because it's still a bit mysterious)---but the pinned files/directories are there, too. If I open another of those secret project states, fine --- but the pinned folders/files stay there too, until I unpin them.

This is not a final, fully thought-out solution---it's a brainstorming suggestion to help the discussion. The overall point is that we are not odd or dumb to think that if we put things on the sidebar, they will stay there until we remove them --- in fact that is what I would think most people would expect, unless they have been trained in the intricacies of this super-neat secret background state cache Atom uses, which I understand is very useful and dear to the hearts of the Atom development team.

I sincerely hope this was helpful. I will go back to lurking. Good luck.

(P.S. I see from the history I had removed myself from notifications to avoid the temptation of replying. Somehow I got added back; I don't know how. I'll remove myself again. Cheers.)

[draeath]

Garret's idea is wonderful, I think.

I guess I'd illustrate a potential reason for wanting such an arrangement by showing what my editor looks like at any random time. Note that I don't actually use "projects" per se, rather I have a few higher level directories pinned (one of which, ironically, is my projects directory. Others include a scratch directory and a remote filesystem)

Now, this does cause other grief as well. For instance, the git-diff plugin seems to lose it's mind, as I have far too many files in my "projects" and these projects are not git repos (but contain them, as you'll see in the screenshot!)

I think Atom is trying too hard to be an IDE, here. There's a difference between what I'd call a workspace and a project, and I (personally, at least) would expect the editor to operate in the context of workspaces, leaving individual projects to the shell and other tools. I come from a context where everything was done in the shell, using editors like vim (with more or less default configuration) or kate, or jEdit.

[DrZiggy]

A major discussion here but as far as I can tell nothing has resolved yet. I work for several customers and all have their own project folder. I have added these to the project list so I can quickly switch between them. This works great if I open the pinned item on the taskbar (win 10) and everything stays as it should.

If I forget to open Atom and double click on any php file (or other file associated with Atom) then all my added projects are lost and I can begin the tedious task of adding them again.

As almost everybody in here pointed out: If we add a project folder, keep it open no matter what!

[anatoli26]

Have you set the Settings -> Core -> Restore previous windows on start option to always?

[damieng]

@DrZiggy Or you can just go to File > Reopen Project. It will likely be the first item in that list.

[DrZiggy]

Thanks @anatoli26 , that seems to do the trick.

[Blair2004]

Since the time we had this issue, i've just changed Atom to ** and it works great for me.

[m-schubert]

The current state of Atom gets so close when Settings -> Core -> Restore previous windows on start is set to always:

• It restores projects when I close and open the application.
• When Atom is already open, opening a file from the filesystem just opens it in a new tab, whether it is a part of an existing project or not.

Where I think the behaviour is incorrect:

1. Opening a folder in Atom adds it as a project in a new window. This makes no sense to me. Why not just add it to the project list on the left in the existing window?

A bonus feature:

1. Opening a folder or a file from the filesystem that is a part of an existing project would highlight the folder/file in the project panel (and open it in a new tab if it was a file).

I guess fundamentally the issue I have is the insistence on Atom opening a new window when I open a file/folder from the filesystem when it is closed, or when I open a folder from the filesystem when it is open.

[hollerdawg]

I agree with @m-schubert on this. Atom remembering which project folders were open previously gets disrupted when a new instance is open rather than just maintaining a single instance at all times. To mitigate this in the long term, maybe we could just maintain a shared list of open project folders so that all instances of atom are basically in sync at all times? For the short term, I think that the correct behavior of atom should be to try and maintain a single window view instead of opening a new window when giving atom a folder to open.

[kolossalkernel]

This has been open for 3 years and still no fix?
Is it a really hard thing to fix?

[damieng]

@Asylum0722 If you read the thread you will see it's not a "fix". Some people expect one behavior, other people expect something different.

If you want to get the old project state back after opening a different folder you can do so just by clicking it from the Reopen Project menu.

I am going to close this thread as it's clear there is no consensus on what a behavior that would make everybody happy is and unless somebody puts the effort in to creating a robust PR for to allow a configuration to decide between a couple of different behaviors this thread is just noise.

[lock[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. If you can still reproduce this issue in Safe Mode then please open a new issue and fill out the entire issue template to ensure that we have enough information to address your issue. Thanks!