LaTeX: fix #8686 Text can fall out of code-block at end of page #10577
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jfbu
commented
Jun 18, 2022
modified: sphinx/texinputs/sphinxlatexliterals.sty
modified: sphinx/texinputs/sphinxlatexliterals.sty
…en wrapping This maintains existing behavior.
|
Ready for review. In case of line wrapping the code line number is printed only once as is currently case. So this fixes #8686 with no other change to output. Example output: From this project |
|
The squashed commit message was written via the GitHub interface and is not hard-wrapped :-( |
jfbu
added a commit
to jfbu/sphinx
that referenced
this pull request
Jun 29, 2022
This does not fix entirely sphinx-doc#10610 but it does sufficiently for it not to require reverting sphinx-doc#10577 which tried to solve sphinx-doc#8686 conundrum. In extreme cases, the sphinx-doc#8686 problem meant that some contents disappearing at page bottom, so it is probably better that to maintain sphinx-doc#10577 which will avoid anysuch overflow of code beyond its frame, even though in some specific cases (a colored entity such as a long string is partly on both pages), some syntax highlighting gets lost. There are anyhow other issues with colors for wrapped code lines, even with no pagebreaks involved, such as sphinx-doc#10615. This patch does not change the situation there.
jfbu
added a commit
to jfbu/sphinx
that referenced
this pull request
Jun 29, 2022
This does not fix entirely sphinx-doc#10610 but it does sufficiently for it not to require reverting sphinx-doc#10577 which tried to solve sphinx-doc#8686 conundrum. In extreme cases, the sphinx-doc#8686 problem meant that some contents disappeared at page bottom, so it is probably better to maintain sphinx-doc#10577 which will avoid any such overflow of code beyond its frame, even though in some specific cases (a colored entity such as a long string is partly on both pages), some syntax highlighting gets lost. There are anyhow other issues with colors for wrapped code lines, even with no pagebreaks involved, such as sphinx-doc#10615. This patch does not change the situation there.
This was referenced Jun 29, 2022
jfbu
added a commit
to jfbu/sphinx
that referenced
this pull request
Jun 29, 2022
|
due to limitations of LaTeX |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is short but deep hack into
fancyvrbpackage which is used for legacy reasons by Sphinx LaTeX. It fixes #8686 issue in a way compatible with emphasized lines and line numbers. However it currently has breaking change that the line number is repeated identically for each piece of a wrapped line, whereas until now it is indicated only once, at the first line coming out from wrapped one.edit: the breaking changed about code line numbers has been removed in a later commit. And WIP status was thus removed.
Keeping this as WIP for the moment as I need to do some more testing. And I am hesitating if the PR should be on master and not 5.x.At the LaTeX level, I have made some internal name and interface changes for reasons of coherence but I feel it is very unlikely anyone actually modified or used the internal macros, so I don't consider this a breaking change.
Example of output (from the mwe at #8686):
(this was before removal of repeated code line number)
On sees the number 2 is repeated all along.
I can add some extras to not repeat but this means some complications.(update: done)I think it is very unlikely fancyvrb (in view of its recent changes over the last years) will ever change the core stuff we hacked into, so it seems reasonably safe. Nevertheless it is deep hack and things work in a delicate equilibrium with fancvyvrb internal dealings.
Relates