-
Notifications
You must be signed in to change notification settings - Fork 772
Use \tcode for indexed type placeholders (also in math mode) #1274
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
Conversation
"diffpdf" is mostly silent on this change, except that Ti -> |
@@ -156,6 +156,7 @@ | |||
|
|||
% Code and definitions embedded in text. | |||
\newcommand{\tcode}[1]{\CodeStylex{#1}} | |||
\newcommand{\mcode}[1]{\text{\tcode{#1}}} % \tcode in math mode |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The \text
command works in non-math mode as well. You could simply adjust the definition of \tcode
:
\newcommand{\tcode}[1]{\text{\CodeStylex{#1}}}
and it would work just fine in both math mode and text mode.
The only potential downside to using \text
in text mode, it becomes the equivalent to \mbox
. The contents of \mbox
won't be split across lines. If that's a problem, we can further adjust the definition to work around this:
\newcommand{\tcode}[1]{%
\ifmmode\text{\CodeStylex{#1}}\else\CodeStylex{#1}\fi
}
The benefit to this approach is that it reduces the cognitive load on the author. The author can use a single macro instead of having to decide between two different macros depending on the mode they're in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the information.
@tkoeppe: Ok to redefine \tcode to the second form (allowing line breaks)? (In non-math-mode, we definitely want linebreaks inside \tcode.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We actually have existing evidence that \tcode
works in math mode as-is; see e.g. algorithms.tex:3665:
\bigoh{N\log(N)} comparisons, where
.
\tcode
is defined as \CodeStylex
, which is defined as \texttt
. Maybe that does work in math mode after all.
So, we could simply use \tcode
instead of \mcode
everywhere, knowing (through this issue) that we can differentiate between math mode and non-math-mode with \ifmmode
, as shown above, should the need ever arise. That seems the simplest solution to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jensmaurer: I agree. If \tcode
already works out of the box, we should just use that, never mind the name. So for example we can say $\tcode{T}_i$
rather that \tcode{T}$_i$
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jensmaurer A tangent to nitpick the example you raised. I would write it as $N = \tcode{last} - \tcode{first}$
instead of $N = \tcode{last - first}$
so that the minus sign gets rendered as a minus sign instead of a code-style hyphen.
On a more general note, I'm happy to help with any LaTeX code or questions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@godbyk: I don't think that's correct. There is no mathematical concept of subtracting iterators. However, we do have magic library wording that gives the (code) minus-expression meaning with the library (even if it's not defined for the actual iterator type!).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tkoeppe Okay, your argument has swayed me. :-)
\end{indented} | ||
and | ||
\tcode{P} | ||
is a type | ||
\begin{indented} | ||
$\mathit{cv}_{2,0}$ ``pointer to $\ldots$'' $\mathit{cv}_{2,n-1}$ ``pointer to'' | ||
$\mathit{cv}_{2,n}$ \tcode{T2}, | ||
$\text{\cv{}}_{2,0}$ ``pointer to $\ldots$'' $\text{\cv{}}_{2,n-1}$ ``pointer to'' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see any benefit to typing \cv{}
instead of \cv
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
Partially addresses cplusplus#1139.
Updated; now using \tcode everywhere. |
@@ -280,16 +280,16 @@ | |||
% NB: forbid line break between 'where' and 'cv' | |||
% to stop superscript j from running into | |||
% descender of p on the previous line. | |||
where~$cv_i^j$ denotes the cv-qualifiers in the cv-qualification signature of $T_j$:% | |||
where~$\text{\cv}_i^j$ denotes the cv-qualifiers in the cv-qualification signature of $\mcode{T}_j$:% |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This commit uses \mcode
which doesn't exist. do you want to retain the three separate commits? If yes, then please rearrange this so that each commit is correct on its own. Alternatively, we can squash all the commits.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Uh, sorry, I must have missed that one \mcode. Probably a rebase confusion.
And similar for Ui, Vi, and TiD; the latter becoming $\tcode{TD}_i$. Partially addresses cplusplus#1139.
Each of the three patches should now be LaTeX-valid, with no traces of |
I may be missing something, but what's the change of the "cv"s about? Is that in line with what we do elsewhere? Is it related to formatting indexed types? |
For "cv", we use \cv and/or \cv{} elsewhere. Except that we haven't updated the uses inside math mode, yet, which this patch does. It's unrelated to indexed types except that both use math mode, and it's a fairly small drive-by fix here. |
of \tcode{reference_wrapper}, then \tcode{Vi} is \tcode{Ui::type\&}, | ||
otherwise \tcode{Vi} is \tcode{Ui}. | ||
where \tcode{V1} and \tcode{V2} are determined as follows: Let $\tcode{U}_i$ be | ||
\tcode{decay_t<$\tcode{T}_i$>} for each $\tcode{T}_i$. If $\tcode{U}_i$ is a specialization |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure about this change. I have considered this section myself, and I deliberately didn't want to call the same type both T1
and T_1
. We should consistently stick with one name (which is T1
in this case). It's OK to define new types U_i
as the elements of a pack, say, but unless you say "Let T_1 be T1 and T_2 be T2", I'm concerned that this is making things less clear.
\item \tcode{Ti} is the $i^{th}$ type in the template parameter pack \tcode{BoundArgs}, | ||
\item \tcode{TiD} is the type \tcode{decay_t<Ti>}, | ||
\item $\tcode{T}_i$ is the $i^{th}$ type in the template parameter pack \tcode{BoundArgs}, | ||
\item $\tcode{TD}_i$ is the type \tcode{decay_t<$\tcode{T}_i$>}, | ||
\item \tcode{ti} is the $i^{th}$ argument in the function parameter pack \tcode{bound_args}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think here we would also like \tcode{t}_i
for the arguments.
I'm beginning to think that this changeset is getting too large. I had already been considering each of these passages individually, and each of them requires more care and finetuning that this blanket search-and-replace approach, I think. My recommendation would be to separate the strictly non-observable changes (\tcode{T}$_i$
to $\tcode{T}_i$
) from the rest, and revise each section separately for the more invasive changes. For example, #1251 is such a revision of one particular section.
Ok, let's close this pull request then. I'll submit a fresh one that only does the non-observable changes, in particular:
|
The canonical way to format an indexed type placeholder is now . This works inside an outside a \tcode area.
Fixes #1139.