PdfEditorView / getActiveEditor()

[nalcorso]

A pdf-view pane will not be returned to callers of workspace.getActiveEditor().

This prevents pdf-view from playing nice with other packages, for example that are attempting to query the filename of the underlying file. An example is process-palette, which can not determine the file name or other attributes of a pdf-view pane.

Would it be possible to embed the pdf-view within a regular editor-view? This would have the additional advantage of allowing users to toggle between rendered and plain text representation of the PDF file.

Thanks.

[izuzak]

Hey, @nalcorso. I don't see a getActiveEditor defined on workspace. As far as I can tell, there's such a method defined on Pane:

https://github.com/atom/atom/blob/62f4f32d237097b18e66a7fc2f00eb3a805739ef/src/pane.coffee#L288-L289.

Can you clarify what you're referring to exactly?

Also, can you explain why you can't use this: atom.workspace().getActivePaneItem().getPath()? That way, you can work with text editors and non-text editors. Embedding pdf-view within a text editor seems like a much messier solution to your problem than using getActivePaneItem().getPath(). pdf-view implements this method:

https://github.com/izuzak/atom-pdf-view/blob/27ca268f40c474ad058687b60f28f8e4f7a5afd3/lib/pdf-editor-view.js#L398-L400

Atom uses the same method internally for its needs:

https://github.com/atom/atom/blob/62f4f32d237097b18e66a7fc2f00eb3a805739ef/src/pane.coffee#L520

[nalcorso]

Hi Thank you @izuzak that is exactly what I am after. To be honest I looked at how the extension was determining the path and assumed it was correct. Instead, I will test the change you suggested atom.workspace().getActivePaneItem().getPath() and submit a pull request there.

Thank you so much for your thorough answer.