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

Use rst_prolog and rst_epilog only for rst files? #2445

Closed
mgeier opened this issue Apr 13, 2016 · 3 comments
Closed

Use rst_prolog and rst_epilog only for rst files? #2445

mgeier opened this issue Apr 13, 2016 · 3 comments

Comments

@mgeier
Copy link
Contributor

mgeier commented Apr 13, 2016

Apparently, Sphinx adds those to all source files, regardless if those are actually reST files or not.

This leads to problems with some custom source_parsers, e.g. spatialaudio/nbsphinx#38

I think rst_prolog and rst_epilog should only be prepended/appended for actual reST files.
Is there anything speaking against this?

@birkenfeld
Copy link
Member

No, that makes a lot of sense. Should be a bugfix for 1.4.2.

@birkenfeld birkenfeld added this to the 1.4.2 milestone Apr 13, 2016
@cmdcolin
Copy link

cmdcolin commented May 5, 2016

I might want to apply replacements in markdown for example (using recommonmark or similar), so it would be actually nice to preserve some way to do replacements on non RST.

I wasn't actually even getting the rst_epilog to work on markdown though so I am not sure if it's just me or not but this would be a nice-to-have for markdown :)

@tk0miya
Copy link
Member

tk0miya commented May 25, 2016

Fixed at 9cd5ba9.

BTW, rst_prolog is not related with substitution feature directly.
It is a feature of reStructured Text itself. so I think new feature is needed to substitute for markdown or other format.
Now, Sphinx emits source-read event for third party extensions. It might support to make extensions which supports substitution on markdowns.

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

No branches or pull requests

4 participants