为什么取消注释最后一句会将句号移至新行?

为什么取消注释最后一句会将句号移至新行?

下面的 MWE 中的最后一句话被注释掉了。然后这个段落就可以正常呈现了。

\documentclass[11pt,letterpaper]{book}
\usepackage{listings}
\usepackage[left=1.50in, right=1.00in, top=1.00in, bottom=1.00in]{geometry}

\begin{document}

\lstset{
     frameround=fttt
    ,language=SQL
    ,numbers=left
    ,breaklines=true
    ,showstringspaces=false
    ,basicstyle=\small
}

You probably noticed that I declared all dynamic SQL variables as \lstinline[columns=fixed]{nvarchar(max)}. Sometimes it would be an overkill, but doing so relieves me from a burden of picking length for the declaration. Maximum width will accommodate virtually any dynamic SQL out there. %If it has to be merged from several variables, each of them should be declared similarly.

\end{document}

但如果我取消注释最后一句话,那么内联列表后的句点就会移动到新行:

在此处输入图片描述

我对内联列表做错了什么?

附言:我遇到过这样的情况:当内联列表换行到新行时,单词之间的空格位于新行的开头,而不是完全不呈现或留在第一行的末尾。但我以某种方式编辑了这些示例,现在不再有任何示例可以在此处展示。这听起来像是一个相关问题。

答案1

断点似乎breaklines=true被添加到内联列表的末尾。所以最简单的事情是

\lstinline[columns=fixed,breaklines=false]{nvarchar(max)}.

但是如果您想允许在列表内中断,但不是在最后,我认为需要做一些不那么简单的事情(更改列表内部)。

最后一句话或多或少是无关的,除了 TeX 在选择换行符时会考虑整个段落,并且在发布的段落中.没有选择之前的换行符(但它始终是一个合法的断点)


好的,所以我想到了\zz下面这样的东西,它会删除最后一个断点,但它并没有真正的帮助,因为到处都有断点(例如,)在这种情况下,它不会停留.在线上,列表只是在(技术上)不同的地方中断。然而,列表将其所有断点都添加为,\discretionary这意味着你可以通过设置来调整在那里中断的可取性\exhyphenpenalty(100 似乎是一个不错的值,默认值是 50),这必须在段落级别(因此对于整个文档来说最容易)。如果您只是在内联列表周围本地设置它,则不会产生任何效果。

这也会使换行foo-bar稍微不那么受欢迎,但当 tex 自动为单词连接字符时,它不会影响正常隐式连字符处的换行。

最后一部分显示允许换行,尽管该设置已阻止测试段落中的换行。

在此处输入图片描述

\documentclass[11pt,letterpaper]{book}
\usepackage{listings}
\usepackage[left=1.50in, right=1.00in, top=1.00in, bottom=1.00in]{geometry}

\begin{document}

\lstset{
     frameround=fttt
    ,language=SQL
    ,numbers=left
    ,breaklines=true
    ,showstringspaces=false
    ,basicstyle=\small
}

\def\zz{\leavevmode\afterassignment\zzz\setbox0\vbox}

\def\zzz{\aftergroup\zzzz\noindent}
\def\zzzz{\setbox0\vbox{\unvbox0 \setbox2=\lastbox\global\setbox1\hbox{\unhbox2\unskip\unskip}}%
\unhbox1 }


%\showoutput

\smallskip\noindent\textbf{original}

You probably noticed that I declared all dynamic SQL variables as \lstinline[columns=fixed]{nvarchar(max)}. Sometimes it would be an overkill, but doing so relieves me from a burden of picking length for the declaration. Maximum width will accommodate virtually any dynamic SQL out there. If it has to be merged from several variables, each of them should be declared similarly.

\smallskip\noindent\textbf{linebreak}

You probably noticed that I declared all dynamic SQL variables as \lstinline[columns=fixed]{nvarchar(max)}.\linebreak Sometimes it would be an overkill, but doing so relieves me from a burden of picking length for the declaration. Maximum width will accommodate virtually any dynamic SQL out there. If it has to be merged from several variables, each of them should be declared similarly.

\smallskip\noindent\textbf{hbox}

You probably noticed that I declared all dynamic SQL variables as \hbox{\lstinline[columns=fixed]{nvarchar(max)}}. Sometimes it would be an overkill, but doing so relieves me from a burden of picking length for the declaration. Maximum width will accommodate virtually any dynamic SQL out there. If it has to be merged from several variables, each of them should be declared similarly.

\smallskip\noindent\textbf{breaklines=false}

You probably noticed that I declared all dynamic SQL variables as \lstinline[columns=fixed,breaklines=false]{nvarchar(max)}. Sometimes it would be an overkill, but doing so relieves me from a burden of picking length for the declaration. Maximum width will accommodate virtually any dynamic SQL out there. If it has to be merged from several variables, each of them should be declared similarly.

\smallskip\noindent\textbf{zz}

You probably noticed that I declared all dynamic SQL variables as \zz{\lstinline[columns=fixed]{nvarchar(max)}}. Sometimes it would be an overkill, but doing so relieves me from a burden of picking length for the declaration. Maximum width will accommodate virtually any dynamic SQL out there. If it has to be merged from several variables, each of them should be declared similarly.


\noindent\textbf{check zz breaking}

 a a a a a a a a a a a a a a a a a a a a
 a a a a a a a aa a a a a a a a
\lstinline[columns=fixed]{g g g g g g g g g g g g }.

 a a a a a a a a a a a a a a a a a a a a
 a a a a a a a aa a a a a a a a
\zz{\lstinline[columns=fixed]{g g g g g g g g g g g g }}.


\noindent\textbf{penalty at discretionary}

\exhyphenpenalty100 

You probably noticed that I declared all dynamic SQL variables as \lstinline[columns=fixed]{nvarchar(max)}. Sometimes it would be an overkill, but doing so relieves me from a burden of picking length for the declaration. Maximum width will accommodate virtually any dynamic SQL out there. If it has to be merged from several variables, each of them should be declared similarly.



\noindent\textbf{check  breaking with penalty}


 a a a a a a a a a a a a a a a a a a a a
 a a a a a a a aa a a a a a a a
\lstinline[columns=fixed]{g g g g g g g g g g g g }.

\end{document}

答案2

使用

\hbox{\lstinline[columns=fixed]{nvarchar(max)}.}

解决您的问题。无论最后一行是否存在,它都可以工作。

相关内容