Skip to content
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

Use \tcode for indexed type placeholders (also in math mode) #1274

Closed
wants to merge 3 commits into from

Conversation

jensmaurer
Copy link
Member

The canonical way to format an indexed type placeholder is now $\mcode{T}_i$. This works inside an outside a \tcode area.

Fixes #1139.

@jensmaurer
Copy link
Member Author

"diffpdf" is mostly silent on this change, except that Ti -> $T_i$ changes are detected.

@@ -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
Copy link
Contributor

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.

Copy link
Member Author

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.)

Copy link
Member Author

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 $N = \tcode{last - first}$.

\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.

Copy link
Contributor

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$.

Copy link
Contributor

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.

example output

On a more general note, I'm happy to help with any LaTeX code or questions.

Copy link
Contributor

@tkoeppe tkoeppe Dec 20, 2016

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!).

Copy link
Contributor

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''
Copy link
Contributor

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

@jensmaurer
Copy link
Member Author

Updated; now using \tcode everywhere.

@jensmaurer jensmaurer changed the title Introduce \mcode macro and apply it for indexed type placeholders Use \tcode for indexed type placeholders (also in math mode) Dec 20, 2016
@@ -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$:%
Copy link
Contributor

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.

Copy link
Member Author

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.
@jensmaurer
Copy link
Member Author

Each of the three patches should now be LaTeX-valid, with no traces of \mcode left.

@tkoeppe
Copy link
Contributor

tkoeppe commented Dec 20, 2016

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?

@jensmaurer
Copy link
Member Author

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
Copy link
Contributor

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},
Copy link
Contributor

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.

@jensmaurer
Copy link
Member Author

Ok, let's close this pull request then. I'll submit a fresh one that only does the non-observable changes, in particular:

  • \tcode{T}$_i$ to $\tcode{T}_i$
  • $T_i$ to $\tcode{T}_i$
    The rest can then be done manually section-by-section.

@jensmaurer jensmaurer closed this Dec 21, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants