Quit Confirmation


#1

Scenario

Multiple buffers and multiple windows are opened. All files in all windows have been saved. User wants to close current buffer in current window by pressing ⌘w. Unfortunately, they inadvertently pressed ⌘q.

:boom: Everything disappears.

User now has to open every window and buffer again :anguished:


Listen for exit event
#2

Here is my hack of the v0.75.0 core that adds quit confirmation to WorkspaceView. It only works from within the workspace view, though (i.e., if you hit ⌘q within the Dev Tools or select the “Quit” menu, then there is no confirmation).

Add Quit Confirmation to Atom v0.75.0


#3

Would saving your window and tab state be a suitable replacement?

I generally find quit confirmations to be annoying, an indication that the application didn’t do it’s job … which is to make using it as simple as possible. If I accidentally hit quit once in a blue moon, then the penalty for that should be waiting for the application to start again … a second or two … not a few minutes to get everything set back up again like you say. But making me tell the application to quit twice … every … time … I … quit. That is penalizing me in the common case to “prevent” the rare case.


#4

My thought track was that it should have a setting whether to confirm or not for keyboard-driven “quit” (à la Google Chrome, where it can be set to require that you hit ⌘q twice). Quitting from the menu should just quit, now that you mention it. And, it should never confirm a quit when there are no opened windows, either. Come to think of it, the node.js REPL also has you press ^c twice…

I think there should also be an option for whether to save the session on quit. For example, it’s really annoying when windows that don’t need to be opened get opened when “I just want to edit this file over here … :shit: the windows from last time opened” kinda thing.


#5

I updated the patch to check atom.config.get('core.hacks.confirm-quit') :wink:


#6

I find that this just gets burnt into muscle memory and then you don’t have a quit confirmation, you just have a longer keybinding for quit :laughing:


#7

I agree. So, when you want to quit, you “double tap”, and when you don’t, you single tap and it says “push that again to quit”, where you can realize “oh, that was close!” When you think about it, though, ⌘qq really isn’t that bad…

The quit commands for both vim and emacs are at least two characters (ZQ, :cq etc. for vim, and ^x^z for emacs).

Anyway, since this is supposed to be a customizable and hackable editor, I think it would be nice to have some way of preempting the quit command (i.e., in order to ask for confirmation), as well as remapping ⌘q to something else.


#8

I implemented the “à la Google Chrome” and updated the gist (the workspace view still has to be in focus for the patched code to be run).

@leedohm Do you find this implementation to be still too annoying?


#9

SublimeText seems to handle this pretty well by continuously saving any changes you may have made in any open files to a special DB (or something, it doesn’t save to the actual file on the disk). If you accidentally quit, you can reopen it and all the windows, files, and even unsaved changes are there again.


#10

Yes, I philosophically disagree with quit confirmations because I believe that quit confirmations are solving a real problem with red tape. The real problem is “I don’t want to lose data accidentally”. A quit confirmation essentially says, “Ok … any time you do something that might be dangerous, I’ll make you work harder for it.” I believe that the application should just make it so quitting isn’t dangerous … like @jpostlethwait points out.

But you’re not writing the feature for me … you’re writing it for yourself. So make it how you like it.

It is obvious you feel strongly about having this feature. I’m not saying that it shouldn’t be there necessarily … for people who feel they need it. I am saying that Atom should be better than that … so that people do not need it, whether they want this feature or not.

And I do feel that there should be a quitting and quit event for overriding the exit behavior of the application.

You might want to read About Face. It is a refreshing look at a lot of assumptions that programmers make that users “need”, including confirmations like this. When I read the first edition in the mid-90s I thought that the author was crazy … though I slowly came around. And looking at smartphones and tablets, a lot of what he suggested decades ago is baked into their design (lack of user file system access, records not having to be explicitly “saved”, almost complete extinction of the dialog) … and look how popular and user friendly they are considered to be!

Again, if you want this feature and the Atom team wants to offer it … that’s fine. I’m just a guy engaging in a conversation.


#11

Thanks for the insight. I now understand your remarks from earlier.

I agree that nobody wants to loose data and that Atom should be trying very hard to prevent that from happening.

My problem, though, is that I tend to fat-finger the w and q keys. Having the editor disappear cramps my style. So, for me it’s not that quitting is a “dangerous” operation (if the editor is doing it’s best to keep data around), it’s just that quitting when I didn’t want to is a nuisance.

Haha, good point. So, for me, it is acceptable to press ⌘q twice to quit.

Indeed! I think we’re on the same page in that as long as there is some way to preempt events within Atom, anyone can make any kind of extension however they want, and anyone may then use any such extension. Also, that this “Quit Confirmation” need not be part of the core.

Much obliged for your time :smile: Always great to get insight from others.


#12

Sorry for jumping into this old thread — naturally, I’m doing it because I just did exactly what @execjosh described: pressed ⌘q when I meant to press ⌘w.

While I understand @leedohm’s issue with it being annoying, I have to ask: how often are you quitting your IDE? I leave mine open virtually at all times, especially on my work computer, so the issue we’re trying to solve probably happens more often than me wanting to quit — which as was said, becomes a muscle memory double-tap anyway.

Just my 2 cents.

Now off I go to look for a quit confirmation package…


#13

@LucasUnplugged

{remote} = require "electron"
atomApplication = remote.getGlobal("atomApplication")
app = remote.app

myQuit = () ->
   index = atom.confirm
      message: "Confirm Quit"
      detailedMessage: "Are you sure you want to quit?"
      buttons: ["Quit", "Cancel"]
   app.quit() if !index

atomApplication.removeAllListeners "application:quit"
atomApplication.on "application:quit", -> myQuit()

#14

@refkotay’s code looks good, but it’s not in a form to conveniently digest. I just went ahead and installed maybs-quit into my Atom 1.10.2 workspace, and it seems to work alright. I would be fine with a dialog instead of panel, but either way saves me the hassle of missing that ‘w’ key and getting the ‘q’ one instead.


#15

Hey guys, I used maybs-quit for a while but never got used to it, so I just made a package named quit-control da does a quit confirmation, not only on CMD+Q but on CMD+W if there are no open tabs since Atom quits in that situation (closing tabs in a hurry often results in unexpected Atom shutdown).

Quit confirmation:

Quit confirmation

Other features can be seen at the packages page.

After CMD+Q you just need to hit Return to confirm or Esc to close the prompt. Really fast to confirm or close the prompt but hard to quit Atom unintentionally.

Hope you enjoy it!


#16

Atom doesn’t quit when the last window is closed on macOS unless you’ve installed a package to make it behave like that. Additionally, if you uncheck “Close Empty Windows”, it won’t even close the window when the last tab is closed.


#17

Yeah it isn’t a proper quit, just the window that closes! Wrong choice of
words of mine.

But anyway, window closing when pressing Cmd+W in a hurry really bothers
me and happened too many times.

I used to turn off “Close Empty Windows” option, but the funny part is that
I missed closing empty windows on Cmd+W. That is the default beahvior of
many apps, including Atom.

I know that sounds like I don’t know what I really want from Atom hahaha
But as a UX enthusiast I tried to solve these problem.

I looked to some browser extensions that does that and first implemented a
Time/Debounce based approach. That didn’t work for many reasons. So I
looked forwards to maybs-quit package and tried a confirm based approach.
After some tweaking and testing I found out that it really worked in both
Cmd+Q and Cmd+W cases:

If I’m closing tabs in a hurry and hit Cmd+W too many times, I just need
to hit Esc and keep going.

If I really want to close the empty window I can hit Cmd+W and press
Return. Window is closed.

If I mistype Cmd+Q I just need to hit Esc and keep going.

If I really want to quit I can hit Cmd+Q and press Return. Atom quits.

Those simple key combinations doesn’t added any perceivable time to the
actions and enhanced my perception of control over Atom.

If my problem happens not to be a problem for most of Atom users it really
makes sense tho solve it in a package (that’s what I did). But since many
people raise up this issue over time, I think an Atom default
implementation would be welcome.


#18

I totally understand :+1: I was only correcting a statement that others have made that has led to misconceptions in the past :grinning: