Proposal: Behavior Services

[lee-dohm]

A class of Issue that keeps coming up is the feature that has too many possible implementations. Designing, coding and supporting all the possible implementations that the community asserts should be "the default" is too daunting a task. Some examples of Issues like this are:

• Behavior when closing the last open file or last open window (Add option to have cmd-w close the window when there are no editors open #863, Add a config setting for quitting the app when the last window is closed on Mac OS clicking the x icon directly #7835, On "core:close" (ctrl/cmd-w), closes window if no files/panes left to close #2411 (comment), Improve Command-W behavior on OS X #7726)
• Behavior when opening files via drag-and-drop, from the command line, whether inside or outside of the project folder ... whether there is a "project" or not, etc
• Sorting behavior in the Tree View
• Undo/Redo behavior
• Fuzzy matching (Convert fuzzy matching to a service #10266)

Additionally, adding configuration options for all the possible permutations of these behaviors is hard to design and difficult for users to understand.

Because of these challenges, I wanted to design a system that:

1. Keeps the base installation of Atom simpler and more approachable for new users
2. Allows for maximum configurability in keeping with the "hackable to the core" philosophy of Atom
3. Removes the necessity of the Atom Core team supporting all possible options

How It Works

When a feature (described as "foo" in this example) is identified for this approach:

1. A "behavior service" should be designed and built into Atom Core as: atom.foo-behavior
2. The current behavior should be used as a fallback in the case that no service provides an alternative (see the atom.file-icons service in the tree-view package as an example)
3. By convention, packages that implement alternatives will end with foo-behavior like my-awesome-foo-behavior
4. Any interested party implements a package that provides the service to customize Atom's behavior

Benefits

With this system in use, anyone can easily come along and implement their own behavior for this particular feature without:

1. Needing to describe the behavior in detail (the best specification is code, after all)
2. Needing to convince anyone that this is a good idea or "deserves to be in core"

This also allows for Atom to act in a manner that is perhaps more familiar and comfortable to the user but goes against the conventions of the platform that they are running Atom upon.

Challenges

There are some pitfalls I've identified with this approach. I don't think that they are significant enough to prevent going ahead with this, but they should be kept in mind and solutions should be identified and implemented over time.

How Granular Should Behavior Services Be?

In the example of the closing the last open file or last window mentioned in the introduction, there are actually a few tightly-related behaviors:

1. Does closing the last tab close the window?
2. Does closing the last window exit the application?
3. Does closing the last tab in a pane destroy the pane?
4. Does using the standard close command close the window if there is no file open?

Should this be one service? Or four? Or somewhere in between? Because of the way the service hub system works, there can be only one loaded and activated provider.

Discoverability

Let's say I have installed a package that overrides the tab/pane/window close behavior. How do we indicate to the user that to configure this behavior they no longer use the built-in configuration options, but have to go to the super-special-close-behavior package settings to configure it?

Supportability

When someone has an issue with how Atom is behaving, how can we easily find out that they have the super-broken-close-behavior package installed and enabled?

/cc @atom/feedback

[benogle]

I like this idea. Definitely the hard part seems to be in determining the edges in each case. I think we could come up with a behavior service for one feature and see how it goes.

[KenBridgeman]

One way to override existing functionality would be to override or hijack an event subscription. Say the tree-view listens for a double-click, override its action with your own.

of course the possibilities for carnage are through the roof.

[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!