This will probably be less confusing for developers experimenting with
changing the default location. Also, we avoid storing extra info we
don't really need.
Also, ensure that passing an item that is not yet present in the
workspace does not interfere with resolving the location where we want
to place the item.
This commit changes the behavior of `open()` so that the item will be
added to the workspace—even if the `activateItem` option is false.
This provides a way to open (and add) an item without activating it,
but removes the ability to open without adding. For that, we've made
the `createItemForURI()` method public 😊
This adds an method for hiding items by URI and re-implements
`toggle()` in terms of it. (tbh it's really just extracting most of
`toggle()` into a new function.)
This ensures that the function always behaves asynchronously regardless
of the state of the workspace.
/cc @maxbrunsfeld
Signed-off-by: Antonio Scandurra <as-cii@github.com>
We thought it was a bug that activateItem: false caused the
item not to be added, but it turned out there were package
tests that depended on this behavior.
Ideally, we should have an addItem option that exhibits this
behavior instead.
Signed-off-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
* master: (43 commits)
If one arch fails, kill the other for perf on appveyor
⬆️ dalek@0.2.1
Revert "⬆️ all packages that use atom-select-list"
⬆️ atom-keymap
⬆️ status-bar
⬆️ all packages that use atom-select-list
⬆️language-ruby@0.71.0
⬆️autocomplete-css@0.16.1
Ensure `packagesCache` exists before accessing it
🎨⬆️ less-cache
Use `core/` instead of `<embedded>` for keymaps loaded during snapshot
Set also defaultSettings.core.projectHome when initializing Config
Fix tests
⬆️ atom-keymap
Replace CommandRegistry.addBundled with a boolean param in .add
Delete unused build scripts
🔥 Remove parserlib
Resolve style sheets paths during `script/build` for bundled packages
Don't use cached less sources and imported files in dev mode
...
This is a refactoring that sets up the work for #13878 (docks).
Because items will be able to dictate their preferred locations, we
need to detangle the item creation from their placement.
The comment was actually no longer accurate since arrow functions
aren't newable. After doing an audit, @maxbrunsfeld determined that it
could just be removed.
