Added prevent option to ::onWillDestroyPaneItem() #13812
Description of the Change
This PR implements the feature requested in issue #12376. It adds a method to the parameter of the
An alternative for the requested feature overall isn't really present, as the previous implementation would close the tab no matter what or request the user to safe in case of unsaved changes. Both of these are unwanted behaviour as described in #12376.
As for alternative ways to implement the functionality, I considered
Why Should This Be In Core?
As explained in #12376, the problem is that it isn't part of the core. As of now it is nearly impossible to implement this as a package, and non of the solutions I could think of are even remotely elegant (e.g. recording what tab(s) closed and reopening them after they've been closed).
It will help developers of packages prevent the unwanted closing of "special" tabs e.g. when "Close all tabs" is called by the user. This has, for example, been requested in this issue on one of my own packages.
When used incorrectly this functionality could make closing tabs impossible for users. However, simply disabling the package that uses this functionality incorrectly will solve the problem.
The text was updated successfully, but these errors were encountered:
Added a new key to the object provided to the onWillDestroyPaneItem callback with the name 'prevent'. The value for this key is a method that can be used to prevent closing the given pane item. This is done via a flag in the function calling the callback notifying that it shouldn't actually destroy the pane item.
Added a test case to the pane-spec.coffee testsuite testing the functionality of the prevent method on the ::onWillDestroyPaneItem callback parameter.
@50Wliu (or anyone else), I was wonder if you could help me here?
After I pushed some commits to this PR yesterday all CI systems have failed for some mysterious reason, I can build Atom locally. Also, the logs do not point to something related to my changes, but instead to a build issue related to node-gyp (see AppVeyor)... Maybe it possible to restart the CI systems?
Hi @sadick254, better late than never I guess
I would be more than happy to pick this up again but not sure how to go about that given that I removed my original fork. I tried to fork again and (force) push changes to the same branch, but that didn't seem to do anything... Any suggestions in that regard?
Hey Eric, can you try allowing maintainers edit access to your PR? You can find instructions on how to do so here if you're not familiar with the option: https://docs.github.com/en/github/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork
If that works, I can see if editing from the web UI is enough to get things back in order -- at the very least, GitHub isn't showing the PR coming from an unknown repository, which is a good sign