Skip to content

Commit 8dca61d

Browse files
authored
Improve some LaTeX code comments (#14220)
1 parent 8ab9600 commit 8dca61d

File tree

1 file changed

+33
-18
lines changed

1 file changed

+33
-18
lines changed

sphinx/texinputs/sphinxlatexliterals.sty

Lines changed: 33 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -39,9 +39,10 @@
3939
\RequirePackage{sphinxpackageboxes}
4040
% 7.4.0 removes unneeded usage of \spx@boxes@border
4141

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.
4546
\providecommand*\sphinxvspacefixafterfrenchlists{%
4647
\ifvmode\ifdim\lastskip<\z@ \vskip\parskip\fi\else\par\fi
4748
}
@@ -55,32 +56,45 @@
5556
% 3- optional line emphasizing
5657
% 4- while still allowing expansion of Pygments latex mark-up
5758
% 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.
6165
\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,
6367
% MEMO: attow (2025/12/26), a TAB can not be found inside a code-block
6468
% rendered by sphinxVerbatim because it has been replaced earlier by a
6569
% fixed number of spaces, as applies also to HTML output (#14065).
6670
% (default: 8 spaces per TAB). But this is not the case for contents
6771
% inserted via a literalinclude, and next line will have an impact on
6872
% TABs. cf #13656, #14064, #14065.
6973
\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:
7482
\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+
%
7589
% 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.
8094
%
8195
% 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.
8498
\def\spx@FV@Tab{\allowbreak\hbox to\FancyVerbTabSize\fontdimen2\font{\hss\FV@TabChar}}
8599
% MEMO: \FV@TabChar does nothing without option showtabs (which we do not
86100
% use). With the option showtabs, it would draw something similar to
@@ -416,7 +430,8 @@
416430
% \current@color, if \fvset has been used to set numbers to the right.
417431
}%
418432
% 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.
420435
\newcommand\sphinxVerbatimFormatLine[1]{\FV@ObeyTabs{\strut #1}}%
421436
% The next two macros are a deep hack of fancyvrb.sty core line processing in
422437
% order to wrap too long lines, either at spaces and natural break-points,

0 commit comments

Comments
 (0)