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

Odd indexing for bitset::set #743

Closed
jwakely opened this issue Jun 9, 2016 · 7 comments
Closed

Odd indexing for bitset::set #743

jwakely opened this issue Jun 9, 2016 · 7 comments
Assignees

Comments

@jwakely
Copy link
Member

jwakely commented Jun 9, 2016

In the index of library names bitset::set is grouped under set along with members of std::set so looks like it's actually a member function, std::set::bitset

@AlisdairM
Copy link
Contributor

There is a similar problem with any/bitset::any

@jensmaurer
Copy link
Member

Well, \indexlibrarymember{a}{b} adds "b under a" and "a under b" index entries, so the above is a natural fallout of this design. But I agree it's confusing in this particular case.

@tkoeppe
Copy link
Contributor

tkoeppe commented Dec 13, 2016

This seems somewhat ad-hoc to me. The general problem is that a single top-level index entry with subentries is used with multiple different meanings that differ across the subentries. Are there more such cases? Is the right answer to randomly select one meaning as the desired one and discard the others? Or should we maybe disambiguate the meaning and keep both entries, such as "set (m)" for the member and "set (t)" for the type or template?

@jensmaurer
Copy link
Member

Good point: Maybe we should just say "set (member)" for the bitset members to disambiguate (and assume a class / template) otherwise).

@tkoeppe
Copy link
Contributor

tkoeppe commented Dec 13, 2016

Maybe \indexlibrarymember should always replace a (\textit{member}). That may be generally useful information.

jensmaurer added a commit to jensmaurer/draft that referenced this issue Dec 13, 2016
@jensmaurer
Copy link
Member

... at least for the first-level entry.

@tkoeppe
Copy link
Contributor

tkoeppe commented Dec 13, 2016

Your commit looks sensible, it's a nice local solution that's adequate for the problem.

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

No branches or pull requests

4 participants