Convert "pdf-view" opener to "atom"

[Aerijo]

This generalises the Atom opener to whatever PDF package they may have installed, instead of restricting it to pdf-view. Cross ref https://github.com/Aerijo/atom-pdf-view-plus/issues/5.

It just renames the opener and removes the active package check. This check doesn't work when other packages are providing the PDF view, so removing it decreases the coupling between this package and any particular viewer.

This does mean that it could potentially open the PDF as a text file if the user has no viewer packages, but I would consider this acceptable.

[Aerijo]

The CI failure seems unrelated.

[Foggalong]

@thomasjo Any update on getting this merged?

[jstader]

I'd also like to see this get merged! @thomasjo

[thomasjo]

It seems CI is broken, and my resources are stretched pretty thin, so to get this merged I need some assistance. If anyone has the resources to set up a dev environment to verify that the test suite still passes, I can go ahead and merge this. I'd also be willing to accept reasonable extensive manual testing. Basically, we need to verify that this doesn't break anything and works as expected.

[Aerijo]

Manual testing just now:

• With pdf-view active: Still works as expected.
• With pdf-view-plus active: Opens as expected. The forward sync is already guarded, so if using pdf-view it still works, and if using a different viewer that doesn't define forwardSync it is safely skipped.
• With none: The PDF file binary is opened in a plain TextEditor pane.

The class rename does not need to be propagated, as the openers are already dynamically loaded just by being in the directory they are in.

I don't think it's possible to detect if a PDF package has been registered, as the handler is a function, so determining if there is a handler for a given file requires running all the handlers and seeing if seeing if they accept it (which also causes them to actually open the file as a side effect).

But even though we can't tell if Atom has a proper PDF viewer installed, I would consider this acceptable compared to the current design that locks itself to a specific PDF package. It could be patched by checking for one of the several current viewer packages, but that just punts the problem and would require maintenance to keep the list of packages up to date.

I'm having trouble running the specs because they depend on other packages but the configuration directory (~/.atom by default, which contains these packages) is changed to a temporary location for specs and so doesn't have any packages in there.

[TraceBivens]

Is this still on anyone's radar? I've been trying to set up an environment for doing homework with LaTeX, but have found that pdf-view becomes incredibly slow very rapidly and completely unusable if I try to load a textbook in another pane.

I'm happy to play guinea pig, but I'm new to Atom so I'm not sure how I'd go about installing this branch of the plugin.

[rohit49plus2]

Any updates on this?

[asiloisad]

Any updates on this?