Focus not being returned from SumatraPDF

[JorgeGT]

After compilation focus is always kept by SumatraPDF and not returned to the Atom editor even when the "keep focus" option is checked, on an updated Windows 10 machine running Atom 1.11.0-beta0 (the problem is still present with stable builds). No other packages are installed except for those recommended for atom-latextools. Is there any step that I'm missing? Thanks! :)

[r-stein]

The keep_focus option is not available for every viewer. SumatraPDF does not support this as an command line argument. Hence it requires special handling, which is not implemented yet.

[JorgeGT]

Ah thank you! Some DDE magic required? Any other PDF viewer that supports the feature in Windows?

[r-stein]

SumatraPDF is the only viewer, which is supported for windows. In Sublime Text we found a very unique way to set the focus back to ST just by calling it. Using DDE also had some flaws. Not sure, which would be the best method for Atom.

[ig0774]

There was some discussion of using DDE in #12, which would really solve this problem if we could figure out how to use it. The ST version stopped using DDE because the DDE code stopped working on ST3. I'm not really sure what the underlying cause was, but it may be an issue localised to ST.

On the other hand, DDE was easy to integrate because Python includes the ctypes library. Integrating DDE into Atom seems like more of a challenge.

Effectively there are two options I'm aware of:

1. There's this project, which uses Edge.js to call a (now unmaintained) CLR DLL (NDde) to make DDE calls.
2. We could alternatively use this relatively inactive ctypes library for Node.js or node-ffi to make the necessary C calls.

Either of these hit the same issue: they both depend on a native extension built using node-gyp, which in turn requires a C compiler (e.g. VisualStudio or the VisualStudio tools) and an install of Python 2.7. There are two ways of dealing with this:

1. We build the extension and ship it as a binary file. This extension may need to be recompiled as new versions of Atom / Electron are released using different versions of Node. We may also need to keep a number of such binaries available for backwards compatibility.
2. We simply add the packages as requirements to our packages.json so that it gets built on the users computer. This has the advantage of not needing all the backwards compatibility stuff but winds up adding VisualStudio tools and Python 2.7 as a prerequisite to use Sumatra.

Basically, the need to solve the problem of dealing with native code is why we haven't made a move to DDE.

All that said, if your needs PDF viewer-wise are simple, we do have support for the pdf-view package, which has some synctex capability (though it could be better) and at least doesn't suffer from the focus problem...

[JorgeGT]

Thanks for the detailed explanation @ig0774! I had looked at the source code for the Sublime 3 version, and found your curious trick, @r-stein. I agree that both options to deal with the problem (either compile or let the user compile) are tricky. I'm not sure if any of the two are worth the difficulty, maybe it is better to wait for better solutions either from Atom or Sumatra.

I have tested pdf-view but it struggles with my thesis, so I will stick to Sumatra with Sublime for the time being. But I will keep an eye here! :)