When you use atom as your git editor it is quite slow to open the git commit text (compared to other

[atom-bot]

When you use atom as your git editor it is quite slow to open the git commit text (compared to other editors). Then when you save you have to use command-W as command-w doesn't kick things back to the terminal.

Atom Version: 1
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Atom/0.46.0 Atom-Shell/0.7.6 Safari/537.36
User: @jonmagic

[nathansobo]

Perhaps when atom is launch in --wait mode it should close the window and return to the terminal when all editors are closed.

[kevinsawicki]

👍 to that idea

[jonmagic]

Cool. If we do this new behavior we just need to ensure it's always opened in a new window as you wouldn't want to close the whole window if the git text was just in a new tab in an existing window.

Only saying this because git/Sublime tries to open a new tab in an existing window first and if that fails does a new window.

[izuzak]

Perhaps when atom is launch in --wait mode it should close the window and return to the terminal when all editors are closed.

It sounds like "#863 - cmd-w after the last editor should close the window" covers this (except for the slow performance part). Would it be 🆒 to close this issue in favor of that one, or do we want to keep this open to track the performance issue?

[jasonrudolph]

Would it be 🆒 to close this issue in favor of that one, or do we want to keep this open to track the performance issue?

FWIW, I'm watching this issue exclusively for the performance part. I'd ❤️ to keep it open for that reason.

[izuzak]

I'd ❤️ to keep it open for that reason.

For sure, thanks Jason! 👍

[toolmantim]

This performance issue is killing me too. It takes ~ 5-8 seconds to show the commit message editor, even if Atom is open.

At the moment my typical flow looks like this:

• You're editing a project in Atom
• You switch to terminal, and git commit -va
• You wait ~ 5 seconds (or more), it opens a completely new atom window with the git commit message. You edit the commit message, ⌘-s and ⌘-w, and then manually hit the close window button (fixed in Add option to have cmd-w close the window when there are no editors open #863)
• You're back in terminal, and git push

The lag opening the window is the worst, especially given it's already running and it's just a single file.

In Sublime it just opens a new tab in the project window that's already open (given it's in the project dir as .git/COMMIT_EDITMSG), and it does it near instantly. Then you edit the commit message, hit ⌘-s and ⌘-w and you're back in Terminal for a quick git push

[toolmantim]

This is probably due to #1230 (opening a new window, ~ 4 seconds here), but with a few more seconds added on in this case.

[mlandauer]

👍 to this. I'm suffering from the same delay as others.

[luishdez]

+1 Not using atom as main IDE because the slow opening

[swrobel]

👍 wait should return on ⌘-w and should open git commit message a lot faster

[swrobel]

It seems that part of the problem is that Atom opens a new window when you pass -w/--wait, I suppose so that it can return after the window is closed. If the behavior was as expected, where ⌘+w on the tab that was opened from the command line returned, then I think this issue would be largely resolved since Atom wouldn't need to open a new window, which is considerably slower than opening a new tab (although that seems like a separate issue that needs attention).

[csauve]

+1 to opening in a new tab by default. Editing commit messages is the most common case for me, but I also experience the slowdown in scripts including atom -w and would love to see them a bit smoother.

Atom should only open the file in a new window if the command line -n option is given, which already exists and provides this behaviour when -w is not provided.

[NigelThorne]

Is this slow because the Atom editor scans + populates the folder tree even if you are only trying to edit a single file?

Is there a way to tell it on launch to only edit the file given, not load the folder as a project?

[toolmantim]

I don't think so, it's the same 10 second delay I'm getting when I open any new window. If we avoid opening the new window for a git commit message it'll avoid the problem in this case.

[namxam]

Any updates on this issue?
I am currently giving atom.io another try to use it as my main editor. But current --wait behavior is killing me.

• Why do I have to close the tab and then the window?
• Why is it taking forever to open that single window?

I know that there are reasons… but from a UX perspective it is really bad.

[mehcode]

Why is it taking forever to open that single window?

I assume you're using a HDD. Because of how many files atom loads it can take some time for a HDD to access them all.

However there is good news: #5382 -- when that is merged there will be a single file to load which should significantly increase startup time.

---

Why do I have to close the tab and then the window?

This is consistent with a lot of just plain text editors (eg. gedit).

You could use ctrl+shift+w (close window) instead of ctrl+w (close tab).

It might make sense for atom to add a standalone command-line switch that was intended for a single file (didn't load tree view, closed when you closed the file, no tabs, etc.); but, that would need to be opened as a different issue.

[yaroshevych]

I assume you're using a HDD. Because of how many files atom loads it can take some time for a HDD to access them all.

Atom lags even on MBPr with Core i7 and SSD drive. It takes up to 2 seconds to create new window with Cmd+Shift+N.

Atom 0.189.0, OSX 10.10.2.

[robtarr]

👍 For making this open faster. I like using Atom, but don't have it set up as my git editor, which is a hassle. ctrl+shift+w is a great tip, but an improvement of the opening time would be WONDERFUL.

[laughedelic]

@CrendKing do you use the --wait option? I'm on mac as well and I don't have to quit Atom, only to close the window.

[CrendKing]

Yes. My $EDITOR is atom -w. My Atom is 1.7.2. It is because I use --wait that git keeps waiting for the termination of Atom process.

My ps shows this after I close the window, and the Atom is still showing in the Dock.

<my_username>            90780   0.0  0.0  2439528   1232 s002  S+    3:47PM   0:00.02 /bin/bash /usr/local/bin/atom -w /tmp/test/.git/COMMIT_EDITMSG

@laughedelic, if you don't have the problem, I'm really interested in how I did wrong. I wonder if it is related to some system config in Mac. For example, automatically kill process when all foreground windows are closed.

[lee-dohm]

@CrendKing How to get --wait to stop waiting is off-topic for this Issue. If you have questions around that, please feel free to stop by Discuss, the official Atom forum, and myself or others from the community would be happy to help.

[tapajos]

I wrote a workaround for the closing part in https://atom.io/packages/close-after-last-tab-with-git.

It will close atom window when you close the last panel AND if your project folder is the git folder.

[trusktr]

Perhaps ServiceWorker can help cache things soAtom loads faster, so long as the Atom app stays open after last window is closed?

[RyanCCollins]

I am having this same issue and would be overjoyed if there was a fix. This is literally the only thing that bothers me about an otherwise incredible piece of software. I would really like to keep using it, but it's getting very bothersome to wait as much as 10-15, maybe even 20 seconds for atom to open a git commit window.

If anyone has any input on how I might speed it up, please do tell. Thanks so much!

[jmarchello]

To reduce boot time for quick edits you could use --safe mode, which bypasses loading all your packages. I've aliased atom -n --safe to atm for quick edits and it's pretty fast.

[RyanCCollins]

Hi @jmarchello that sounds like a great plan. I'll give it a shot. Thanks so much!

[bolinfest]

I came here to file an issue that atom --add --wait does not honor --add, but I guess that is effectively part of this issue?

I tried doing the following to make the ~/.atom I use with --wait as lightweight as possible:

mkdir ~/.atom-lite
cd ~/.atom-lite
ln -s ~/.atom/keymap.cson keymap.cson
ln -s ~/.atom/compile-cache compile-cache
ln -s ~/.atom/config.cson config.cson

And then created ~/bin/giteditor (remembering to chmod +x!):

#!/bin/bash
ATOM_HOME=/Users/mbolin/.atom-lite atom --wait --add --clear-window-state "$@"

And finally:

git config --global core.editor "/Users/mbolin/bin/giteditor"

But this still doesn't open nearly as fast as I would like. I think that being able to do:

git config --global core.editor "atom --add --wait"

is the only way to make this sufficiently fast, and as others have mentioned, closing the tab should signal the end of the atom --add --wait call. This would make Atom work more like EmacsClient, which has similar performance issues.

Has someone created a package to prototype this already?

[raphinesse]

@bolinfest I reallly liked your idea with the separate config, so I also took a look at your approach. The main problem for me was, that atom only looks at ATOM_HOME when there are no other instances running already. If there is a running atom instance, the newly started one will use the same home directory as the already running one.

Since for me, there is virtually always an open instance of atom, it makes it impossible to use a different configuration just for git editing. But that alone could have solved part of this issue, since you could disable almost all packages (including core ones like tree-view) for this use case, possibly benefiting application startup.

[peterbabic]

+1 for --add and --wait to work together...or simply for any fix that would not make --wait open a new windows but a tab instead

[nathggns]

--wait not supporting --add is basically a red line for me. Please fix this. Will be sticking with Sublime until you do unfortunately.

[blackst0ne]

I just came here to add more support to those requests above. 👍

[nicomartinezdev]

Any updates on this thread? The wait time is indeed annoying. Hoping that the new tab solution was a thing

[lee-dohm]

@nshtg and @tapajos your comments were deleted as a violation of the Atom Code of Conduct as they were insulting or derogatory. You may consider this an official warning.

[KevinBongart]

So… users have been complaining about this issue for 3 years now. What can experienced Atom contributors do to encourage more developers to solve the issue?

• Is this a performance problem? What are some options worth looking into? Are there any PRs already working on boot time?
• Is this a behavior problem? Should Atom support some options on launch to start a lighter one-file version?

Right now, it's daunting to just think about solving the issue myself, so I complained once in the last few years and get notified every few weeks when someone else complains. What are some pointers people can use to contribute to a solution? Documentation? Code? Pull requests? Other related issues?

Thanks

[nathansobo]

@KevinBongart I think you're right that we need to make this work. The problem has been that our main process code is a mess and we haven't had time to clean it up in a holistic way yet. Because of that, we have been reluctant to add launch-related features. At this point I think that we should probably just hack in a solution despite the debt it will incur.

We're going to discuss prioritizing this feature, but there are a bunch of other areas with similarly passionate appeals for us to make improvements, and it's just a balancing act to get to everything in the ideal order.

I'm in bugfix / PR review mode for the next 2-3 weeks, so if someone wants to ping me on a PR that adds and integration tests this feature, I am down to get it across the finish line.

[KevinBongart]

Thanks for the context @nathansobo, this is very helpful. Any PRs or open issues related to that messy process code?

[nathansobo]

After reviewing this long history more closely, it seems like teaching --wait and --add to get along gracefully would solve most people's issues. I've updated my previous comment slightly to reflect that.

As for an issue about the messiness of the main process @KevinBongart, none exists. Sorry.

[maxbrunsfeld]

Hey everyone. Sorry for the delay on this. The fix will ship in Atom 1.25.

[lock]

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!