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.

Sign up for GitHub

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

Jump to bottom

[index] Using "type!POD" vs. "POD type" #1033

Open
jlaire opened this issue Nov 14, 2016 · 5 comments
Open

[index] Using "type!POD" vs. "POD type" #1033

jlaire opened this issue Nov 14, 2016 · 5 comments

Comments

@jlaire
Copy link

jlaire commented Nov 14, 2016

There are index entries for "callable type", "integer type", "object type", "scalar type" and many others of this form. The index also has a list of terms under type, such as "type!POD" and "type!function". A few appear in both forms: there's "integral type" as well as "type!integral".

This makes the index hard to use, because it's not clear (to me) which form is used for any given term. I noticed this when trying to find the definition of "POD type". Would it make sense to list all of these terms as both "foo type" and "type!foo"?
@jensmaurer
Copy link
Member

We do say "foo type, see type, foo" in similar cases (maybe not with "type") and keep the list of page numbers exclusively with "type, foo".

@jensmaurer jensmaurer added the decision-required A decision of the editorial group (or the Project Editor) is required. label Nov 18, 2016
@burblebee
Copy link
Contributor

Please document the preferences/guidelines somewhere for future editor's benefit.

@jensmaurer
Copy link
Member

jensmaurer commented Mar 2, 2017 •
edited

Editorial meeting: In the index of library names, maybe distinguish class names from functions etc, e.g. postfix with ::. Alisdair dislikes :: not connecting things. Different uses of the index: One, just lookup a name (hierarchy not useful). Two, as a reference guide to the library names including nesting and subnamespaces. Maybe add "type" or "class" or "member" to the first-level entry.

@jensmaurer
Copy link
Member

jensmaurer commented Nov 7, 2017 •
edited

Editorial meeting consensus: We do want structure. For the primary index entry (with page numbers), use the natural decomposed form. Favor semantic locality in choosing the natural decomposed form (cf. expression, equivalent vs. equivalent, expression; the latter wins).

@zygoloid zygoloid removed the decision-required A decision of the editorial group (or the Project Editor) is required. label Nov 7, 2017
@jensmaurer jensmaurer mentioned this issue May 24, 2018
Closed
@jensmaurer
Copy link
Member

jensmaurer commented Jul 17, 2018 •
edited

Partially addressed by introducing \defnadj; see #2258.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@jlaire @zygoloid @burblebee @jensmaurer