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

Consider formatting ranges with math brackets #2556

Closed
Eelis opened this issue Dec 4, 2018 · 6 comments · Fixed by #5164
Closed

Consider formatting ranges with math brackets #2556

Eelis opened this issue Dec 4, 2018 · 6 comments · Fixed by #5164
Assignees

Comments

@Eelis
Copy link
Contributor

Eelis commented Dec 4, 2018

\Range and \range currently format the whole range, including the brackets and comma, as C++ code:

\newcommand{\Range}[4]{\tcode{#1#3,\penalty2000{} #4#2}}
\newcommand{\range}[2]{\Range{[}{)}{#1}{#2}}

But that's kinda weird, because something like [eback(), gptr()) isn't actually a syntactically well-formed C++ code fragment; only the eback() and gptr() parts are. So I think it might make more sense to format the brackets (and comma) as math. What do you think?

@tkoeppe
Copy link
Contributor

tkoeppe commented Dec 4, 2018

It's a trade-off. Using code font gives the thing a uniform look, and we do actually define the meaning of the notation. So it's not outright wrong. It's similar to how we use code font for conceptual placeholders, e.g. T when referring to an invented type. Not all code is code, if that makes sense.

@Eelis
Copy link
Contributor Author

Eelis commented Dec 4, 2018

It does make sense, it's just a bit unfortunate for cxxdraft-htmlgen that the same commands/environments are used for C++ code and non-C++ code, because cxxdraft-htmlgen should only syntax-highlight C++ code as C++. I currently use a patch that introduces \noncxxtcode and changes \Range to

\newcommand{\Range}[4]{\noncxxtcode{#1}\tcode{#3,\penalty2000{} #4}\noncxxtcode{#2}}

but it's not ideal. :)

@jensmaurer jensmaurer added the decision-required A decision of the editorial group (or the Project Editor) is required. label Dec 6, 2018
@FrankHB
Copy link
Contributor

FrankHB commented Dec 9, 2018

It's a trade-off. Using code font gives the thing a uniform look, and we do actually define the meaning of the notation. So it's not outright wrong. It's similar to how we use code font for conceptual placeholders, e.g. T when referring to an invented type. Not all code is code, if that makes sense.

An important difference is T can be well-formed and well-defined C++ code when in some invented context with intended meaning, but the interval notation is hardly in this sort.

@Eelis
Copy link
Contributor Author

Eelis commented Jan 22, 2019

Interestingly, there's a bunch of places in numerics.tex that don't use the range macros but instead use

$\bigl[ ... , ... \bigr)$

Example

Probably an oversight, but I'm reluctant to submit a patch to replace these with uses of the range macros, because I love the math brackets more than I hate the inconsistency. ;)

@jensmaurer
Copy link
Member

jensmaurer commented Jul 16, 2019

Editorial meeting: Do move away from \tcode for brackets and comma. Try the looks of two center dots as separator, with math brackets. Do not proceed without @tkoeppe's input.

@jensmaurer jensmaurer removed the decision-required A decision of the editorial group (or the Project Editor) is required. label Jul 16, 2019
@Eelis
Copy link
Contributor Author

Eelis commented Jul 17, 2019

Cool, thanks for the decision! I'd be happy to submit a patch to move away from \tcode for brackets and comma.

The idea of using two center dots as separator surprises me a little bit though, because combining center dots with round and square brackets to indicate inclusive-ness of the bounds doesn't match conventional mathematical interval notation. What would be the motivation for changing from comma to two center dots? :)

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 a pull request may close this issue.

4 participants