Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

revealjs-url variable - absolute path is ignored #79

Open
newhallroad opened this issue May 28, 2018 · 8 comments
Open

revealjs-url variable - absolute path is ignored #79

newhallroad opened this issue May 28, 2018 · 8 comments

Comments

@newhallroad
Copy link

I am using Windows 7, pandoc 2.1 and the latest pandoc-mode.

I am converting md to reveal.js. I have been pointing to a local reveal.js path using the revealjs-url variable. I prefer to set this variable to an absolute path. That way, I only need to have one copy of reveal.js on my system. If I need to use the slides on another machine, I normally generate a self-contained file or convert the slides to a pdf.

From the command line, this works fine:

> pandoc -t revealjs -o slide-test.html -s -V revealjs-url=file:///C:\Users\<user-name>\reveal.js slide-test.md

Within emacs, however, the equivalent command does not work because the revealjs-url variable is ignored unless it is a relative path. If it is a relative path, the $revealjs-url$ variable in the pandoc template is replaced by that path but if it is absolute path, $revealjs-url$ is unchanged. This is not the behavior when pandoc is run from the command line.

Here are my pandoc-markdown settings for this file:

((standalone . t) (variable ("revealjs-url" . "C:\\Users\\<user-name>\\reveal.js")) (read . "markdown") (write . "revealjs") (output . t))

Your documentation does say that certain variables like css paths will automatically be treated as relative paths but it doesn't specify that this will happen with a variable like revealjs-url.

By the way, I see the attraction of converting paths to relative paths this if the files produced will be uploaded to a server. But for cases like mine, it would be nice to have the option of preserving absolute paths even for css, js and the like. One option would be to be able to use the C-u prefix to specify that the path is absolute.

@joostkremers
Copy link
Owner

I must admit, this has me a little puzzled. I use an absolute path for revealjs-url and it gets added to the output html file as-is. Admittedly, I use Linux, which may play a role here.

Could you show the actual Pandoc call that pandoc-mode runs? This should be displayed in the *Pandoc log* buffer after running pandoc, which can be made visible with C-c / L.

I noticed that in your command-line example you have an actual URI, while in the pandoc-mode configuration, you use a bare file path. Have you tried with "file:///C:\Users\<user-name>\reveal.js" as value for the reveal-js variable?

I agree that when it comes to file paths, there should probably be more flexibility. On the one hand, I'd like to offer file name completion, because it can make life much simpler, OTOH using file name completion can lead to paths being stored that aren't identical to what the user entered. This is complicated by the fact that there are different completion frameworks (default completion, ido, ivy, helm), which don't always return equivalent results, and by the fact that different OSes don't always behave equivalently.

I'll give this a bit more thought in the next few weeks and see if I can improve things a bit.

@newhallroad
Copy link
Author

Thanks for the response. It is puzzling. I've tried it with file:/// with no luck. Here is the log:

Mon May 28 14:24:11 2018

Calling pandoc.exe with:

C:\Users\<user-name>\Pandoc\pandoc-2.1\pandoc.exe --read=markdown --write=revealjs -output=c:/Users/<user-name>/Pandoc/pandoc-2.1//slide-test.html --standalone -V revealjs-url=file:///C:\Users\<user-name>\Pandoc\reveal.js

slide-test.md: pandoc.exe finished successfully

@joostkremers
Copy link
Owner

This is really puzzling... The *Pandoc log* buffer isn't lying, the command you see there is really the same command that Emacs runs. The only difference between the pandoc run from Emacs and pandoc run from the command line is that when run from Emacs, the Pandoc binary is passed its input file through stdin. So you might try that and see if it produces a different result. On Linux, this would be:

cat slide-test.md | pandoc -t revealjs -o slide-test.html -s -V revealjs-url=file:///C:\Users\<user-name>\reveal.js

I don't know what the corresponding command on Windows is. But I would be very surprised if that made any difference.

BTW, I noticed that pandoc-mode seems to be sending your output file to the same directory where pandoc.exe is installed. Is that deliberate?

@Iorest
Copy link

Iorest commented Nov 27, 2018

I also puzzled with this problem .on ubuntu.setting variables for other formats will also cause errors. I don't know how to solve this problem.

But I put the same command on the command line and there is no problem.

@Iorest
Copy link

Iorest commented Nov 27, 2018

Is it a problem when sending commands?

@joostkremers
Copy link
Owner

@Iorest You'll have to send me the settings you're using and the commands you use on the command line. It would also be helpful if you could send the contents of the *Pandoc log* buffer (use C-h / L to make it visible), so I can compare the two.

@Iorest
Copy link

Iorest commented Dec 4, 2018

pandoc --read=org --write=revealjs --output=/*/.html -V revealjs-url=https://cdnjs.cloudflare.com/ajax/libs/reveal.js/3.6.0/

I set the variable revealjs-url to "https://cdnjs.cloudflare.com/ajax/libs/reveal.js/3.6.0/",

I run this command in terminal and there is no problem.

@joostkremers
Copy link
Owner

@Iorest You'll have to send me the settings you're using and the commands you use on the command line. It would also be helpful if you could send the contents of the *Pandoc log* buffer (use C-h / L to make it visible), so I can compare the two.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants