Preview is failing

[p3dr0]

Installed in Atom 0.93 version from GUI Got no errors or warnings but when trying to display sample.rst file in preview (control+shift r) it opens empty white panel on the right
Console says

Uncaught Error: spawn ENOENT util.js:682
exports._errnoException util.js:682
ChildProcess._handle.onexit child_process.js:857
(anonymous function) child_process.js:1005
_tickCallback

[bnmnetp]

I'm using 0.94 and I don't see anything in the developer console. I don't get an empty white panel either, its all failing silently. (yes, pandoc is installed)

[jwprox]

I have a couple suggestions based off of my personal struggles getting this plugin to work properly.

PATH Variable Woes When...

This solved the ENOENT issue for me.

• You are using Homebrew (or anything that doesn't link to /usr/bin) to install Pandoc etc...
• Your are running Atom by clicking it's icon from the dock or Applications folder.

There is a pretty good chance your PATH environment variable isn't set properly. You can remedy this by editing ~/.bash_profile and adding something like:

export PATH=/usr/local/bin:$PATH
`launchctl setenv PATH $PATH`

Note, the command substitution (back ticks) around the launchctl command is important. I had seen this suggestions elsewhere without and it didn't work for me on Mavericks.

Of course, another alternative is to launch Atom, go to Atom->Install Shell Commands and just run atom from the terminal (like a pilgrim), which uses bash environment variables proper.

---

Oh Look! Restructured Text Language Support Package! Awesome!

This solved the silent failure issue for me.

So you might have installed this package: https://github.com/Lukasa/language-restructuredtext.

Yeah, that messes RST Preview up pretty bad because it changes the grammar of Restructured Text files. No worries though, just override the default grammars to support it by searching for the Rst Preview package in Atom's preferences and replacing or appending text.restructuredtext in the Grammars text box.

After getting over those two hurdles everything seems to be on the up and up. Hopefully this helps you guys.

[lhazlewood]

@jwprox your solution worked for me - thanks for writing it up! Much appreciated!

[jwprox]

@lhazlewood Awesome! Glad you got good use out of it.

[jekriske]

The posted solution doesn't function properly under Yosemite. The problem has to do with Yosemite not passing path variables to GUI apps.

This was fixed in November in Atom but I don't know if they pass that variable along for other packages to use. https://github.com/atom/atom/pull/4064/files

I've personally hardcoded my pandoc full path /usr/local/bin/pandoc in rst-preview-view.coffee until the issue gets resolved.

[jwprox]

@jekriske Sure enough, it seems that launchd doesn't behave the same in Yosemite as it did Mavericks. Thanks for the heads up. It should still work if you start atom from the terminal though - and of course hardcoding the path is a reasonable stopgap solution for this issue.

[jekriske]

@jwprox for me launching from terminal did not work 100% of the time. For some strange reason the plugin worked only every few launches from the terminal (fully closed the app between launches). It's very strange behavior...

[tfoote]

If others are finding this issue another very simple problem is that the plugin requires pandoc and you will get this error or similar if pandoc is not installed on your system.

[jekriske]

@tfoote The problem occurs WITH pandoc installed and happens on all of the machines I've tested with OSX Yosemite.

Steps to reproduce:

• install OSX Yosemite
• install atom
• install rst-preview

• install pandoc

  Open sample rst in atom and attempt to use plugin.

[lsegal]

Seems like an environment or Atom issue. You can print process.env.PATH.split(":") from the debugger console to see what Atom thinks is in your path-- if the pandoc directory is not there, that's likely the issue. Symlinking pandoc from /usr/bin would be the easiest fix, but I understand that's an awkward thing to do.

[danez]

Maybe an easier solution would be to add a text field to the settings where one can enter their path to pandoc.

[rasbt]

Now on Yosemite, having pandoc installed in /usr/local/bin/pandoc, launching atom via the command line seems to be the only way to make the previewer work. The rst-previewer is a great convenience tool, and I am wondering if someone is still planning to add an option to the settings menu for specifying the path; I am not sure how much effort it takes, but I think this would be a great, global solution for many users.

[lsegal]

Patches accepted, but note that this will be an issue with almost every Atom plugin you want to use if it needs to interact with executables in your environment (go-plus, atom-runner, etc). Adding an option to specify the full path to pandoc is just as much a workaround as modifying your environment, except one workaround only works for this specific plugin, and modifying your environment will make everything else in Atom work. Even with the customizable pandoc option, you should be choosing the latter.

Or, better yet, open an issue against Atom directly to find a way to resolve environment variable loading on their end, because plugins shouldn't have to write one-off hacks to run programs, and users shouldn't be forced to hardcode paths to standard binaries in order to run things. If nothing else, they should at least throw /usr/local/bin into their default ENV path on OS X because it seems like a pretty sane thing to do.

[rasbt]

Patches accepted, but note that this will be an issue with almost every Atom plugin you want to use if it needs to interact with executables in your environment

Thanks for the head-ups, I am pretty new to Atom, just about to transition and make it my "default editor"

Or, better yet, open an issue against Atom directly ... If nothing else, they should at least throw /usr/local/bin into their default ENV path on OS X because it seems like a pretty sane thing to do.

Yes, I think this would be a pretty straight-forward and good solution, I think this shouldn't take too much effort from their side.