|
39 | 39 | \RequirePackage{sphinxpackageboxes} |
40 | 40 | % 7.4.0 removes unneeded usage of \spx@boxes@border |
41 | 41 |
|
42 | | -% also in sphinxlatexadmonitions.sty: |
43 | | -% This is a workaround to a "feature" of French lists, when literal block |
44 | | -% follows immediately; usable generally (does only \par then), a priori... |
| 42 | +% Also in sphinxlatexadmonitions.sty: |
| 43 | +% This is a workaround to a "feature" of babel-french latex package, |
| 44 | +% which causes bad vertical spacing when a literal block follows a list. |
| 45 | +% Due to the conditional here, this should be usable generally. |
45 | 46 | \providecommand*\sphinxvspacefixafterfrenchlists{% |
46 | 47 | \ifvmode\ifdim\lastskip<\z@ \vskip\parskip\fi\else\par\fi |
47 | 48 | } |
|
55 | 56 | % 3- optional line emphasizing |
56 | 57 | % 4- while still allowing expansion of Pygments latex mark-up |
57 | 58 | % Other aspects such as framing, caption handling, codeline wrapping are |
58 | | -% added on top of it. We should stop using fancyvrb and implement |
59 | | -% 1, 2, 3, 4 by own Sphinx fully native Verbatim. This would greatly simplify |
60 | | -% in particular wrapping long code lines in a way allowing page breaks. |
| 59 | +% added on top of it. |
| 60 | +% Perhaps we could cease using fancyvrb and implement 1, 2, 3, 4 by own |
| 61 | +% pure LaTeX code. This would allow in particular to wrap long code lines |
| 62 | +% in a manner allowing a pagebreak in the middle. But dropping fancyvrb |
| 63 | +% and keeping its native features and those we added by hacking into it |
| 64 | +% would be a significant effort. |
61 | 65 | \RequirePackage{fancyvrb} |
62 | | -% Next line is in attempt to let TAB characters (ascii 9) obey tab stops, |
| 66 | +% Next line is in order to let TAB characters (ascii 9) obey tab stops, |
63 | 67 | % MEMO: attow (2025/12/26), a TAB can not be found inside a code-block |
64 | 68 | % rendered by sphinxVerbatim because it has been replaced earlier by a |
65 | 69 | % fixed number of spaces, as applies also to HTML output (#14065). |
66 | 70 | % (default: 8 spaces per TAB). But this is not the case for contents |
67 | 71 | % inserted via a literalinclude, and next line will have an impact on |
68 | 72 | % TABs. cf #13656, #14064, #14065. |
69 | 73 | \fvset{obeytabs} |
70 | | -% MEMO: The actual hard work will be done by next macro, which is a variant |
71 | | -% of the fancyvrb.sty one, adapted to our context. The trigger which |
72 | | -% maps the TABs to this macro is \FV@ObeyTabs. The main location where |
73 | | -% \FV@ObeyTabs has an effect is in \spx@verb@@PreProcessLine. |
| 74 | +% MEMO: with the above option, fancyvrb executes at each code-block some |
| 75 | +% initialization code which does in particular two things: |
| 76 | +% - make TABs act according to something called \FV@TrueTab, |
| 77 | +% - make some wrapper of each code line, called \FV@ObeyTabs, |
| 78 | +% act like something called \FV@@ObeyTabs and thus provide |
| 79 | +% the correct context for \FV@TrueTab. |
| 80 | +% We need a special variant of \FV@@ObeyTabs for compatibility with |
| 81 | +% our added feature of wrapping long code lines. Here it is: |
74 | 82 | \def\FV@@ObeyTabs#1{\setbox\FV@TabBox=\hbox{#1}\unhbox\FV@TabBox} |
| 83 | +% In code further down this file we use \FV@ObeyTabs, not \FV@@ObeyTabs, |
| 84 | +% knowing that the former is mapper to the latter. At some locations |
| 85 | +% the argument #1 is already a typeset box and nothing happens. One of |
| 86 | +% the two main locations where there will be an effect is the occurrence |
| 87 | +% in \spx@verb@@PreProcessLine. |
| 88 | +% |
75 | 89 | % Tab stops are located every 8 positions as per fancyvrb's default setting |
76 | | -% for its tabsize option. However, fancyvrb has a bug/limitation, and |
77 | | -% its \FV@Tab inside the #1 argument above can work only at "top level", |
78 | | -% i.e. breakage happens if the TAB character (hence \FV@Tab) is in the |
79 | | -% (second) argument of the Pygmentize \PYG highlighting macro. |
| 90 | +% for its tabsize option. However, fancyvrb has a bug/limitation, and its |
| 91 | +% \FV@TrueTab acting inside the #1 above can work only at "top level", |
| 92 | +% i.e. breakage (or rather loss of contents) happens if the TAB character |
| 93 | +% (hence \FV@TrueTab) is located in the (second) argument of \PYG. |
80 | 94 | % |
81 | 95 | % Hence, we prepare a "safe" variant, which is the one which will be used if |
82 | | -% found in the second argument of \PYG macro. For how this ends up into \PYG |
83 | | -% see sphinx.sty. |
| 96 | +% found in the second argument of \PYG. For how this ends up into \PYG, see |
| 97 | +% sphinx.sty. |
84 | 98 | \def\spx@FV@Tab{\allowbreak\hbox to\FancyVerbTabSize\fontdimen2\font{\hss\FV@TabChar}} |
85 | 99 | % MEMO: \FV@TabChar does nothing without option showtabs (which we do not |
86 | 100 | % use). With the option showtabs, it would draw something similar to |
|
416 | 430 | % \current@color, if \fvset has been used to set numbers to the right. |
417 | 431 | }% |
418 | 432 | % MEMO: if verbatimwrapslines is set to true (which is default) the #1 here is |
419 | | -% already a box, and the \FV@ObeyTabs here does nothing of significance. |
| 433 | +% already a box, and the \FV@ObeyTabs here can not modify it. The real action |
| 434 | +% happens in \spx@verb@@PreProcessLine. |
420 | 435 | \newcommand\sphinxVerbatimFormatLine[1]{\FV@ObeyTabs{\strut #1}}% |
421 | 436 | % The next two macros are a deep hack of fancyvrb.sty core line processing in |
422 | 437 | % order to wrap too long lines, either at spaces and natural break-points, |
|
0 commit comments