Difficulties using atom.workspace.addOpener()


I started with the standard package template, and I am following the approach used in the hex package to add workspace opener, but for some reason I can’t get it to work.

I added this to activate:

@openerDisposable = atom.workspace.addOpener(openURI)

and then I call atom.workspace.open(filePath) directly, but my opener is not invoked.

My code is here: https://github.com/fedorov/add-opener-test. The only file I modified is this: https://github.com/fedorov/add-opener-test/blob/master/lib/add-opener-test.coffee.

Can anyone spot the problem?


I believe the part you’re missing in the documentation is here:

An TextEditor will be used if no openers return a value.

console.log returns undefined.

Hmmmmm … well, the log should still happen …

You have activationCommands defined in your package.json. Did you activate your package first by executing the add-opener-test:toggle command?


Yes. toggle is triggered, and the console output here shows up, but the subsequent atom.workspace.open() does not trigger my opener.


Looking at the code for toggle here:

It looks like you’re trying to open the path for a file that is already open. If I recall correctly, of the things that Atom does is it checks to see if the file is already open, if it is, it just activates that tab.

Whoops … nope, that’s only if you set searchAllPanes to true

Aaaand I correct myself again. So there are Panes and Pane Items (pane items equate to tabs). It appears from the code here:


That the opener will be called if and only if that URI is not already open in the current pane. The searchAllPanes flag expands the search from the current pane to all panes.

So if you converted the file path from a standard path, e.g. /foo/bar/baz.html, to a URI with a fake protocol, e.g. custom://foo/bar/baz.html, it wouldn’t conflict and would open properly?


Aaaahh! So that is what this code was about in the hex package!

I had no clue! I initially started from hex, and got things working for the most part, but then decided I should start from a boilerplate template to have my package in a better shape before I share it publicly.

Should I get used to looking up this kind of things in the code directly while developing a basic package for atom? Should documentation be improved?

But I also have to say I am very impressed with the support, thank you @leedohm for getting back on this so quickly.


Yes and yes. The documentation can and should be improved. (And it is really appreciated when people take the time to submit PRs improving the documentation with these discoveries they make :wink:)

Realistically though, until the documentation improves significantly, there will be times when diving into the code of Atom, its packages or the packages of others is going to be the fastest way to figure something out. I would say about a third to half of the support I give is stuff I look up on the fly by diving into Atom’s code to supply people with the answer.


Makes sense, thanks!

Here is the pull request: https://github.com/atom/atom/pull/8672. Please let me know if this is the right place/format for this note!


I think this is definitely the right place. I’ll add other comments to the PR. Thanks for contributing!