-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Breakable inline literals in LaTeX #3116
Conversation
modified: sphinx/texinputs/sphinx.sty
also use ``\sphinxcode`` for literals in titles which will add the extras (straight quotes, breaks allowed at ``/`` and some other characters)
this makes the LaTeX macros more robust, less worrying about where they are used.
@tk0miya Travis reported failure, only with Python=2.7 and docutils=1.12, for ee8b558: https://travis-ci.org/sphinx-doc/sphinx/jobs/173034777#L1447 with an error which seems unrelated with the present commits. However child commit aa1ea9b did not trigger this error report but its diff to the previous modified only quite older code, hence the Travis error report looks like a quantum singularity ;-) |
Agreed about the error. I will investigate it later if it raises again. |
thanks as always @tk0miya, merging. |
@tk0miya later today I will add a commit to make this behaviour optional in case people want to maintain exact same as before i.e. no linebreaks with inline literals at |
…te`` Since sphinx-doc#2627 (1.4.4), `\code`, and then again at sphinx-doc#3116 (1.5) `\sphinxcode` which is the new name has become more complicated than the original `\texttt{#1}`. This was to obtain straight codes in PDF output, and to allow long inline literals to break across lineswq. This means though that user who wants to customize `\sphinxcode`, for example to not only do `\texttt` but to use some colour, has to copy about 10 lines of complicated LaTeX macros with @ letter. This moves all the code out of `\sphinxcode` into new macro `\sphinxupquote`. The LaTeX files will contain `\sphinxcode{\sphinxupquote{foo}}` in place of former `\sphinxcode{foo}`. Moving the `\texttt` from innermost to outermost level is with no consequence.
…te`` Since sphinx-doc#2627 (1.4.4), `\code`, and then again at sphinx-doc#3116 (1.5) `\sphinxcode` which is the new name has become more complicated than the original `\texttt{#1}`. This was to obtain straight quotes in PDF output, and to allow long inline literals to break across lines. This means though that users who want to customize `\sphinxcode`, for example to not only do `\texttt` but to use some colour, have to copy about 10 lines of complicated LaTeX macros which should be not modified in any way. This commit moves all the code out of `\sphinxcode` into a separate macro `\sphinxupquote`. The LaTeX writer will output `\sphinxcode{\sphinxupquote{foo}}` in place of former `\sphinxcode{foo}`. Moving the `\texttt` from innermost to outermost level is with no consequence.
…te`` Since sphinx-doc#2627 (1.4.4), `\code`, and then again at sphinx-doc#3116 (1.5) `\sphinxcode` which is the new name has become more complicated than the original `\texttt{#1}`. This was to obtain straight quotes in PDF output, and to allow long inline literals to break across lines. This means though that users who want to customize `\sphinxcode`, for example to not only do `\texttt` but to use some colour, have to copy about 10 lines of complicated LaTeX macros which should be not modified in any way. This commit moves all the code out of `\sphinxcode` into a separate macro `\sphinxupquote`. The LaTeX writer will output `\sphinxcode{\sphinxupquote{foo}}` in place of former `\sphinxcode{foo}`. Moving the `\texttt` from innermost to outermost level is with no consequence.
Addresses #3110. Also, unify handling of inline literals by applying to all types (literalintitle, literalstrong, literalemphasis) use of
\sphinxcode
rather than simply\texttt
(which was the old definition of\sphinxcode
aka\code
). Also, use\protected
prefix (Sphinx assumes for long time e-TeX via use of\ifdefined
,\dimexpr
... hence we should also use\protected
for more robust macros).