-
Notifications
You must be signed in to change notification settings - Fork 206
Add unique output block references for literalinclude #852
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
base: master
Are you sure you want to change the base?
Add unique output block references for literalinclude #852
Conversation
This seems reasonable and useful to me. @lucyleeow can you look to see if you agree? Eventually we'd want tests (as mentioned above) and ideally it documented and shown somewhere in the config/use docs |
Will take a look this weekend! |
Agree seems like a easy to maintain, useful addition! Tests and documentation would be good. (The CI's are too old to look at what's erroring but running locally it seems to mostly be needing to add the extra positional argument to tests where we use |
@romanlutz I'm happy to add the tests and docs for this if you would be happy with this? |
@lucyleeow definitely, please go ahead! I won't get to it anytime soon I'm afraid. Thank you! |
Having a look at this I propose we adjust it slightly to use the
This way we also allow people to refer to the output via I have tested it out and it works with the
It looks like this (the output was just a matplotlib lines object). There is some weird padding in the box (but this might just go away with some fiddling): (WDYT @larsoner @romanlutz ?) |
That sounds like a clean solution to me! |
I've realised this would not work for html output (just 'text' output). html always has it's own header and is added at the end if captured output has both text and html, e.g.:
We could ignore html output or add the comments around all output? |
How would we be able to add comments around all the output? If it's somehow possible (without too much extra work) that would be great, otherwise perhaps even without html is fine (?) |
I think I could manage it and I agree, it's probably best to include html even though it's slightly uglier. Don't have the bandwidth atm but will work on this as soon as I do! |
It's sometimes useful to reference code block output in addition to produced images (using
figure
) or code lines (usingliteralinclude
), so this change adds comments to the produced RST file before and after the code output aswhich can then be referenced in other RST files as
The
:lines: 2-
part is necessary to avoid including.. code-block:
. AddingOut:
is also optional, but otherwise it doesn't necessarily distinguish output rendering from normal code blocks.I'm looking for feedback on this before proceeding with potentially adding tests and other required parts for merging this PR.
closes #851